一、公益圖書館例子
筆者不想直接用專業的術語來說明“微服務注冊與發現”，所以我們來看生活中的一個案例：“公益圖書館”。隨着人們生活水平的不斷提高，追求精神食糧的朋友也越來越多。筆者曾經在一些城市看見過公益圖書館，其運行邏輯是：一些公益組織和個人提供一塊場所，然后由組織內的人向圖書館內捐書。捐出的書越多，一段時間內能夠借閱的書也就越多。這種做法有助於大家分享圖書、節約資金、交流讀書心得。那我們來看一下幾個關鍵環節：
- 捐書：組織內的人向公益圖書館捐書，是不是直接將書放到書架上就完事了呢？當然不是，是先向圖書管理系統記錄一下捐書的人、書名、捐書的時間等信息，再將書放到書架上。
- 借書：借書的人通常是通過圖書管理系統的一個小程序查詢圖書，然后取書，全靠自覺。圖書可能存在多個副本（多人捐的同一種書），借書的人會根據書籍狀態擇優選擇。
- 這其中非常重要的一個角色就是圖書管理系統及其小程序，為大家捐書、借書提供了數據支持和集中管理功能。
- 兼職圖書管理員定期維護圖書，將破損圖書從圖書管理系統中下架維護。
其實上面的這個“公益圖書館的例子”就是典型的服務注冊與發現：
- 每一本圖書就是一個服務，捐書的過程就是“服務注冊”的過程。
- 借書的查詢圖書的過程就是“服務發現”的過程。
- 其中最重要的角色：圖書管理系統、管理員及其小程序，就是服務注冊中心或者服務注冊平台。
- 捐書者可能同時是借書者。進行服務注冊的微服務節點，同時可能也使用服務發現機制發現其他微服務。
- 捐書是主動行為，不是被動行為。這和微服務的注冊是一樣的，微服務必須在啟動的時候向服務注冊組件進行主動注冊。這樣做的目的就是降低數據維護成本，不需要專人維護注冊數據。
- 圖書下架是被動的，不是主動的，不是捐書的人將其下架。微服務也是一樣，當服務出現故障發生問題，服務發現注冊組件應具備將服務下線的能力。
- 圖書管理員可以檢查圖書並下架，這過程在服務注冊與發現中被稱為：健康檢查
- 對於同一種圖書可能存在多個同樣的副本，由使用者擇優選擇借哪一本書。對於服務發現獲得的結果：同一種服務的多個副本的情況，由服務調用者擇優決定使用哪一個服務副本。這種服務方式比較專業的說法是：客戶端負載均衡。
與客戶端負載均衡相對的方法就是服務端負載均衡，如果上面的例子中借書過程一本書有多個副本，由圖書管理員或系統決定借書者借其中的哪一個副本，這個就是服務端負載均衡。
二、服務注冊與發現
- 服務注冊 -服務在中央注冊表中注冊其服務位置的過程。通常注冊其主機和端口，有時還注冊認證憑證，協議，版本號和或環境信息。
- 服務發現 -客戶端應用程序查詢中央注冊表以了解服務位置的過程。
- 維護中央注冊表的角色被稱為服務注冊平台或者服務注冊中心
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節》
- 本文轉載注明出處（必須帶連接，不能只轉文字）：字母哥博客。