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