一、概述
在微服務時代，註冊中心越來越被重視。服務治理逐漸跟業務服務並駕齊驅。所以本文想對註冊中心進行體系化探索。註冊中心，起源於分佈式時代。不管是水平拆分架構 或者 ESB架構；對於多服務、多實例的支持，出現服務治理的需求，註冊中心被用於服務治理中的服務發現、服務註冊、服務探活三個功能與需求。
架構師需要追尋事物的本質，才能設計使用好技術。那麼註冊中心的本質是什麼：
1、根據服務發現的需求反推出第一個本質是一個query函數
Si=F(serviceName)
serviceName查詢服務參數
si爲對應服務的可用列表(ip:port)
2、根據服務註冊的需求反推出第二個本質是一個獨立的、簡單的第三方存儲，用於服務基本信息的存儲。高內聚、低耦合的思維要求了註冊中心的存儲極簡化。業內比如dubbo 2.7對註冊中心進行拆分、剝離出元數據中心，其實就是單一職責原則的體現，也側邊證明了註冊中心的simple存儲。
3、根據服務探活的需求反推出第三個本質是節點監控通知。節點的探活應該是多樣化的，根據依賴倒置原則，節點既要提供默認探活-心跳，也應提供更多樣化的服務探活。對於服務節點的存活，上游是最有發言權的。
二、服務代理
註冊中心從需求上看是服務代理，常見服務代理有：
1、網絡代理方式
如果是http方式通信的服務，可以增加一個nginx做反向代理，轉發到兩個服務A的實例上。
如果是RPC服務則可以增加一個LVS或HAProxy或者ESB之類的網絡代理，客戶端配置網絡代理地址。
服務B我們再來一套一樣的配置，這時候又來了服務C、服務D、服務E...，好吧我們好還要再多維護同樣多的網絡代理。此外，所有的服務調用服務調用都必須經過網絡代理，我們還必須保證代理的高可用。最後，陷入運維災難
2、DNS方式
給服務A配置一個域名,然後通過配置兩個A記錄分別指向兩個服務A的實例，客戶端只要配置服務A的域名即可。
這種方式也存在問題：DNS 只是到 IP 級別，無法處理端口等信息。DNS 攜帶的數據較少，例如節點權重、序列化方式等等，無法傳遞。另外 DNS 沒有節點狀態管理功能，如果由外部系統刷新，那麼將無法剔除死的節點。
常見服務代理有很多問題，無法完全滿足註冊中心的三個需求，所以需要二次開發、引入新組件。
三、Zookeeper 註冊中心的討論
經常聽見有的初級使用者就說 Zookeeper 這不好那不行有很多坑，那麼架構師需要考慮是階段試用性、場景適配性。那咱們系統性的討論下zookeeper
首先了解一個產品，上官網，正常情況下，沒有比owner更清楚自己。
從官網描述上，我們並未發現zookeeper提供註冊中心的功能，所以註冊中心是我們加上的一個屬性。因此zookeeper做註冊中心是不優雅的。從網上對Zookeeper做註冊中心的侷限分析，比較權威的文章有以下兩篇：
第一篇文章，Eureka的文章：《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》
原文：https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764
第二篇文章，阿里文章:《阿里巴巴爲什麼不用 ZooKeeper 做服務發現？》
總結下zookeeper的侷限性
1、網絡劃分後，強一致性引起的服務註冊機制失效：
ZAB協議保證數據一致性，對於離線的少數節點進行保護，禁止讀寫引起。異地機房會有災難性影響。
註冊中心不能因爲自身的任何原因破壞服務之間本身的可連通性。
注：對於zab協議，可看公衆號<架構之美>的文章《分佈式系統選主怎麼玩》
2、持久化存儲和事務日誌
事務日誌：CP模式，半數節點寫入成功；採用事務日誌，2PC提交。
定期dump內存數據到硬盤，保持數據一致性。
註冊中心只關注實時的健康的服務列表，調用方不關心歷史服務與狀態
3、服務探活
Zk註冊中心通常利用session 活性心跳和臨時節點機制來進行服務探活
簡單而言，就是將服務的健康監測綁定在了 ZooKeeper 對於 Session 的健康監測上，
或者說綁定在TCP長鏈接活性探測上了
4、服務容災
服務調用鏈路弱依賴註冊中心 , zk客戶端並不提供緩存數據機制。
5、客戶端不好用
原生客戶端絕對稱不上好用，Curator 會好一點，但其實也好的有限。
6、易用難精
ZooKeeper 看似很簡單的一個產品，要完全理解 ZooKeeper 客戶端與 Server 之間的交互協議也並不簡單，完全理解並掌握 ZooKeeper Client/Session 的狀態機並不簡單。Zk集羣常見坑：
https://yq.aliyun.com/articles/227260
zookeeper做註冊中心是伴隨着dubbo的流行而火熱起來的，zk有那麼多侷限，又有那麼多使用，這貌似是一個矛盾體，但存在即合理，所以需要分析dubbo使用zookeeper的合理場景：
- 侷限一推導出zookeeper註冊中心適用於單數據中心。但市面上大部分公司都用不到多數據中心，所以糾結的前提，多數據中心需求？過度設計並不是都是好的。
- 侷限二需要去測試，得出一個精準上限值。但網易考拉、dubbo2.7都對此進行優化，如元數據中心。原始上限值是千位級服務，優化後上限值更高。微小企業貌似也用不到。
- 侷限三、
- 侷限四、侷限五關注於zk客戶端，很多框架，包含dubbo對這方面的client都已經原生帶有，在絕大部分時候使用者是無感知的
- 侷限六，zookeeper是大數據之王，理所當然的沒有那麼簡單。在註冊中心場景下，大部分情況是不需要那麼深度的瞭解。
我們爲啥做了那麼分析呢。首先zookeeper註冊中心源於dubbo的火熱，dubbo的廣泛使用，造成了大量存量的zookeeper註冊中心，這些系統的註冊中心是否需要升級，不能簡單因爲一句這不好那不行去否定。身爲架構師，需要考慮全局性，比如小公司中間件部署維護通用就是一個選型指標：在引入一箇中間件，增加系統的維護難度，是否可以接受；在比如註冊中心足夠穩定下，是否需要投入人力去做這注冊中心的更換，是否將有限資源投入其他更緊急事項中……。架構是全局的，也是全棧的，需要取捨，只有階段最合適。
四、服務規模
一說起微服務，我們習慣性說起規模，api有多少個、服務多少個、示例多少個。根據這些年看到聽到的說法，個人總結了下有以下幾個類型，這些類型是微服務時代組件選型的隱藏指標。
1、微型註冊中心
該階段註冊中心，一般只關心服務本身，且是業務迭代比技術演進更被重視，需要的是一個無感知、部署簡單的環境。指標如下：
api數量0-100，
部署服務個位數(註冊中心客戶端)
2、小型註冊中心
該階段註冊中心，一般最關心服務發現特性，可能是一個很小的體量、很短的開發迭代週期、需要一個快速開發上手的環境。指標如下：
單數據中心
服務規模較小(接口數在 100-5K，註冊中心客戶端數量在 百位數 以下)
3、中型註冊中心
該階段註冊中心，架構已經非常複雜，涉及到跨機房容災等特性。一般會有專門的技術團隊來做註冊中心的日常運維。指標如下：
多數據中心
服務規模較大：接口數在 20K 以下，註冊中心客戶端數量在200K以下。
4、大型註冊中心
該階段註冊中心，數據量已經非常大，可能一個註冊中心已經無法滿足需求，必須拆爲多個註冊中心，甚至需要容量的無限擴展。指標如下：
非常多的數據中心
服務規模十分大，單節點無法滿足全量存儲。
5、總結
架構是演進出來的，絕大部分使用者還屬於微小型註冊中心階段；不需要一開始考慮機房容災，不是一開始就上最終級的架構方案；每個階段要挑最合適技術，而不是最好技術。如果目前就千來個接口百來個客戶端的服務註冊中心，隨便哪個方案都能Hold住你的需求
五、選型
網上對consul有的說是ca模型，對於分佈式時代，如果丟失了p-分區容錯性，本質上回歸成單機應用，完全可以ACID。所以作者上官網考究下：
第四節對zookeeper侷限性做了大量分析，所以根據表格指標，在目前階段和可預期的未來，推薦nacos。