白話講解微服務註冊發現及負載均衡

一、公益圖書館例子

筆者不想直接用專業的術語來說明“微服務註冊與發現”，所以我們來看生活中的一個案例：“公益圖書館”。隨着人們生活水平的不斷提高，追求精神食糧的朋友也越來越多。筆者曾經在一些城市看見過公益圖書館，其運行邏輯是：一些公益組織和個人提供一塊場所，然後由組織內的人向圖書館內捐書。捐出的書越多，一段時間內能夠借閱的書也就越多。這種做法有助於大家分享圖書、節約資金、交流讀書心得。那我們來看一下幾個關鍵環節：

• 捐書：組織內的人向公益圖書館捐書，是不是直接將書放到書架上就完事了呢？當然不是，是先向圖書管理系統記錄一下捐書的人、書名、捐書的時間等信息，再將書放到書架上。
• 借書：借書的人通常是通過圖書管理系統的一個小程序查詢圖書，然後取書，全靠自覺。圖書可能存在多個副本（多人捐的同一種書），借書的人會根據書籍狀態擇優選擇。
• 這其中非常重要的一個角色就是圖書管理系統及其小程序，爲大家捐書、借書提供了數據支持和集中管理功能。
• 兼職圖書管理員定期維護圖書，將破損圖書從圖書管理系統中下架維護。

其實上面的這個“公益圖書館的例子”就是典型的服務註冊與發現：

• 每一本圖書就是一個服務，捐書的過程就是“服務註冊”的過程。
• 借書的查詢圖書的過程就是“服務發現”的過程。
• 其中最重要的角色：圖書管理系統、管理員及其小程序，就是服務註冊中心或者服務註冊平臺。
• 捐書者可能同時是借書者。進行服務註冊的微服務節點，同時可能也使用服務發現機制發現其他微服務。
• 捐書是主動行爲，不是被動行爲。這和微服務的註冊是一樣的，微服務必須在啓動的時候向服務註冊組件進行主動註冊。這樣做的目的就是降低數據維護成本，不需要專人維護註冊數據。
• 圖書下架是被動的，不是主動的，不是捐書的人將其下架。微服務也是一樣，當服務出現故障發生問題，服務發現註冊組件應具備將服務下線的能力。
• 圖書管理員可以檢查圖書並下架，這過程在服務註冊與發現中被稱爲：健康檢查
• 對於同一種圖書可能存在多個同樣的副本，由使用者擇優選擇借哪一本書。對於服務發現獲得的結果：同一種服務的多個副本的情況，由服務調用者擇優決定使用哪一個服務副本。這種服務方式比較專業的說法是：客戶端負載均衡。

與客戶端負載均衡相對的方法就是服務端負載均衡，如果上面的例子中借書過程一本書有多個副本，由圖書管理員或系統決定借書者借其中的哪一個副本，這個就是服務端負載均衡。

二、服務註冊與發現

• 服務註冊 -服務在中央註冊表中註冊其服務位置的過程。通常註冊其主機和端口，有時還註冊認證憑證，協議，版本號和或環境信息。
• 服務發現 -客戶端應用程序查詢中央註冊表以瞭解服務位置的過程。
• 維護中央註冊表的角色被稱爲服務註冊平臺或者服務註冊中心

2.1. 服務註冊

當一個微服務啓動的時候，必須主動向服務註冊中心註冊其服務地址，以供其他微服務查詢調用。圖中橘黃色爲服務註冊中心，綠色爲微服務節點。

2.2.客戶端負載均衡

當一個微服務有多個副本的時候，由調用者決定使用哪一個副本提供服務。

三、Spring Cloud常用的服務註冊中心

• Eureka：Spring Cloud的大兒子，出生的時候條件一般，長大後素質有限
• Nacos：後起之秀，曾經Spring Cloud眼中“別人家的孩子”，已經納入收養範圍（孵化項目）。
• Apache Zookeeper：關係戶，與hadoop關係比較好
• etcd：關係戶，與kubernetes關係比較好
• Consul：關係戶，曾經與docker關係比較好

如果你的應用已經使用到了hadoop、kubernetes、docker，在Spring Cloud實施過程中可以考慮使用其關係戶組件，避免搭建兩套註冊中心，節省資源。但是二者兼容使用說說容易，真正用起來還需要功夫。目前看，筆者覺得與Spring Cloud關係最好的應該是Nacos。

期待您的關注

• 向您推薦博主的系列文檔：《手摸手教您學習SpringBoot系列-16章97節》
• 本文轉載註明出處（必須帶連接，不能只轉文字）：字母哥博客。