主流微服務註冊中心淺析和對比

朱鵬飛，Github ID: nkorange，Nacos 註冊中心等模組主要貢獻者，阿裡巴巴中介軟體高階開發工程師。

 

編者按：

開源產品受開發者熱捧，是因為其程式碼透明、可以參與共建、有社群進行交流和學習，當然更重要的是開源產品的接入成本低。個人開發者或者中小型公司往往會將開源產品作為選型首選。

 

開發者透過閱讀原始碼，理解產品的功能設計和架構設計，同時也可以透過本地部署來測試效能，隨之而來的是對各類開源產品的對比，用以選型。不過當前關於微服務註冊中心的對比，大多聚焦在功能上的對比，對架構或者效能的深入探討，比較少見。

 

另一方面，作為默默支援的產品，服務註冊中心往往隱藏在服務框架背後。優秀的服務框架往往會支援多種配置中心，但是註冊中心的選擇依然與服務框架強關聯，普遍的情況是一種服務框架會帶一個預設的服務註冊中心。這樣雖然免去了使用者在選型上的煩惱，但是單個註冊中心的侷限性，導致用戶使用多個服務框架時，必須部署多套完全不同的註冊中心，這些註冊中心之間的資料協同是一個問題。

 

本文來自Nacos社群，作者是Nacos Committer朱鵬飛，作者力求公正和客觀的去看待主流微服務註冊中心的各個維度。本文不僅僅包含常見服務註冊中心產品的對比，也試圖從Nacos的經驗和調研中總結並闡述服務註冊中心產品設計上應該去遵循和考慮的要點，文章篇幅較長，若您有不同的看法，歡迎在文末留言，或到Nacos @GitHub 提issue。

 

前言

 

服務發現是一個古老的話題，當應用開始脫離單機執行和訪問時，服務發現就誕生了。

 

目前的網路架構是每個主機都有一個獨立的IP地址，那麼服務發現基本上都是透過某種方式獲取到服務所部署的IP地址。DNS協議是最早將一個網路名稱翻譯為網路IP的協議，在最初的架構選型中，DNS+LVS+Nginx基本可以滿足所有的RESTful服務的發現，此時服務的IP串列通常配置在Nginx或者LVS。後來出現了RPC服務，服務的上下線更加頻繁，人們開始尋求一種能夠支援動態上下線並且推送IP串列變化的註冊中心產品。

 

ZooKeeper是一款經典的服務註冊中心產品（雖然它最初的定位並不在於此），在很長一段時間裡，它是國人在提起RPC服務註冊中心時心裡想到的唯一選擇，這很大程度上與Dubbo在中國的普及程度有關。Consul和Eureka都出現於2014年，Consul在設計上把很多分散式服務治理上要用到的功能都包含在內，可以支援服務註冊、健康檢查、配置管理、Service Mesh等。而Eureka則藉著微服務概念的流行，與SpringCloud生態的深度結合，也獲取了大量的使用者。去年開源的Nacos，則攜帶著阿裡巴巴大規模服務生產經驗，試圖在服務註冊和配置管理這個市場上，提供給使用者一個新的選擇。

圖1 服務發現

 

資料模型

 

註冊中心的核心資料是服務的名字和它對應的網路地址，當服務註冊了多個實體時，我們需要對不健康的實體進行過濾或者針對實體的一些特徵進行流量的分配，那麼就需要在實體上儲存一些例如健康狀態、權重等屬性。隨著服務規模的擴大，漸漸的又需要在整個服務級別設定一些許可權規則、以及對所有實體都生效的一些開關，於是在服務級別又會設立一些屬性。再往後，我們又發現單個服務的實體又會有劃分為多個子集的需求，例如一個服務是多機房部署的，那麼可能需要對每個機房的實體做不同的配置，這樣又需要在服務和實體之間再設定一個資料級別。

 

Zookeeper沒有針對服務發現設計資料模型，它的資料是以一種更加抽象的樹形K-V組織的，因此理論上可以儲存任何語意的資料。而Eureka或者Consul都是做到了實體級別的資料擴充套件，這可以滿足大部分的場景，不過無法滿足大規模和多環境的服務資料儲存。Nacos在經過內部多年生產經驗後提煉出的資料模型，則是一種服務-叢集-實體的三層模型。如上文所說，這樣基本可以滿足服務在所有場景下的資料儲存和管理。

 

圖2 服務的分級模型

 

Nacos的資料模型雖然相對複雜，但是它並不強制你使用它裡面的所有資料，在大多數場景下，你可以選擇忽略這些資料屬性，此時可以降維成和Eureka和Consul一樣的資料模型。

 

另外一個需要考慮的是資料的隔離模型，作為一個共享服務型的元件，需要能夠在多個使用者或者業務方使用的情況下，保證資料的隔離和安全，這在稍微大一點的業務場景中非常常見。另一方面服務註冊中心往往會支援雲上部署，此時就要求服務註冊中心的資料模型能夠適配雲上的通用模型。Zookeeper、Consul和Eureka在開源層面都沒有很明確的針對服務隔離的模型，Nacos則在一開始就考慮到如何讓使用者能夠以多種維度進行資料隔離，同時能夠平滑的遷移到阿裡雲上對應的商業化產品。

圖3 服務的邏輯隔離模型

 

Nacos提供了四層的資料邏輯隔離模型，使用者賬號對應的可能是一個企業或者獨立的個體，這個資料一般情況下不會透傳到服務註冊中心。一個使用者賬號可以新建多個名稱空間，每個名稱空間對應一個客戶端實體，這個名稱空間對應的註冊中心物理叢集是可以根據規則進行路由的，這樣可以讓註冊中心內部的升級和遷移對使用者是無感知的，同時可以根據使用者的級別，為使用者提供不同服務級別的物理叢集。再往下是服務分組和服務名組成的二維服務標識，可以滿足介面級別的服務隔離。

 

Nacos 1.0.0介紹的另外一個新特性是：臨時實體和持久化實體。在定義上區分臨時實體和持久化實體的關鍵是健康檢查的方式。臨時實體使用客戶端上報樣式，而持久化實體使用服務端反向探測樣式。臨時實體需要能夠自動摘除不健康實體，而且無需持久化儲存實體，那麼這種實體就適用於類Gossip的協議。右邊的持久化實體使用服務端探測的健康檢查方式，因為客戶端不會上報心跳，那麼自然就不能去自動摘除下線的實體。

圖4 臨時實體和持久化實體

在大中型的公司裡，這兩種型別的服務往往都有。一些基礎的元件例如資料庫、快取等，這些往往不能上報心跳，這種型別的服務在註冊時，就需要作為持久化實體註冊。而上層的業務服務，例如微服務或者Dubbo服務，服務的Provider端支援新增彙報心跳的邏輯，此時就可以使用動態服務的註冊方式。

 

資料一致性

 

資料一致性是分散式系統永恆的話題，Paxos協議的艱深更讓資料一致性成為程式員大牛們吹水的常見話題。不過從協議層面上看，一致性的選型已經很長時間沒有新的成員加入了。目前來看基本可以歸為兩家：一種是基於Leader的非對等部署的單點寫一致性，一種是對等部署的多寫一致性。當我們選用服務註冊中心的時候，並沒有一種協議能夠改寫所有場景，例如當註冊的服務節點不會定時傳送心跳到註冊中心時，強一致協議看起來是唯一的選擇，因為無法透過心跳來進行資料的補償註冊，第一次註冊就必須保證資料不會丟失。而當客戶端會定時傳送心跳來彙報健康狀態時，第一次的註冊的成功率並不是非常關鍵（當然也很關鍵，只是相對來說我們容忍資料的少量寫失敗），因為後續還可以透過心跳再把資料補償上來，此時Paxos協議的單點瓶頸就會不太划算了，這也是Eureka為什麼不採用Paxos協議而採用自定義的Renew機制的原因。

 

這兩種資料一致性協議有各自的使用場景，對服務註冊的需求不同，就會導致使用不同的協議。在這裡可以發現，Zookeeper在Dubbo體系下表現出的行為，其實採用Eureka的Renew機制更加合適，因為Dubbo服務往Zookeeper註冊的就是臨時節點，需要定時發心跳到Zookeeper來續約節點，並允許服務下線時，將Zookeeper上相應的節點摘除。Zookeeper使用ZAB協議雖然保證了資料的強一致，但是它的機房容災能力的缺乏，無法適應一些大型場景。

 

Nacos因為要支援多種服務型別的註冊，並能夠具有機房容災、叢集擴充套件等必不可少的能力，在1.0.0正式支援AP和CP兩種一致性協議並存。1.0.0重構了資料的讀寫和同步邏輯，將與業務相關的CRUD與底層的一致性同步邏輯進行了分層隔離。然後將業務的讀寫（主要是寫，因為讀會直接使用業務層的快取）抽象為Nacos定義的資料型別，呼叫一致性服務進行資料同步。在決定使用CP還是AP一致性時，使用一個代理，透過可控制的規則進行轉發。

 

目前的一致性協議實現，一個是基於簡化的Raft的CP一致性，一個是基於自研協議Distro的AP一致性。Raft協議不必多言，基於Leader進行寫入，其CP也並不是嚴格的，只是能保證一半所見一致，以及資料的丟失機率較小。Distro協議則是參考了內部ConfigServer和開源Eureka，在不借助第三方儲存的情況下，實現基本大同小異。Distro重點是做了一些邏輯的最佳化和效能的調優。

圖5 Nacos一致性協議

 

 

負載均衡

 

負載均衡嚴格的來說，並不算是傳統註冊中心的功能。一般來說服務發現的完整流程應該是先從註冊中心獲取到服務的實體串列，然後再根據自身的需求，來選擇其中的部分實體或者按照一定的流量分配機制來訪問不同的服務提供者，因此註冊中心本身一般不限定服務消費者的訪問策略。Eureka、ZooKeeper包括Consul，本身都沒有去實現可配置及可擴充套件的負載均衡機制，Eureka的負載均衡是由Ribbon來完成的，而Consul則是由Fabio做負載均衡。

 

圖6 客戶端側負載均衡

 

在阿裡巴巴集團內部，卻是使用的相反的思路。服務消費者往往並不關心所訪問的服務提供者的負載均衡，它們只關心以最高效和正確的訪問服務提供者的服務。而服務提供者，則非常關註自身被訪問的流量的調配，這其中的第一個原因是，阿裡巴巴集團內部服務訪問流量巨大，稍有不慎就會導致流量異常壓垮服務提供者的服務。因此服務提供者需要能夠完全掌控服務的流量調配，並可以動態調整。

 

服務端的負載均衡，給服務提供者更強的流量控制權，但是無法滿足不同的消費者希望使用不同負載均衡策略的需求。而不同負載均衡策略的場景，確實是存在的。而客戶端的負載均衡則提供了這種靈活性，並對使用者擴充套件提供更加友好的支援。但是客戶端負載均衡策略如果配置不當，可能會導致服務提供者出現熱點，或者壓根就拿不到任何服務提供者。

 

圖7 服務端側負載均衡

 

拋開負載均衡到底是在服務提供者實現還是在服務消費者實現，我們看到目前的負載均衡有基於權重、服務提供者負載、響應時間、標簽等策略。其中Ribbon設計的客戶端負載均衡機制，主要是選擇合適現有的IRule、ServerListFilter等介面實現，或者自己繼承這些介面，實現自己的過濾邏輯。這裡Ribbon採用的是兩步負載均衡，第一步是先過濾掉不會採用的服務提供者實體，第二步是在過濾後的服務提供者實體裡，實施負載均衡策略。Ribbon內建的幾種負載均衡策略功能還是比較強大的，同時又因為允許使用者去擴充套件，這可以說是一種比較好的設計。

基於標簽的負載均衡策略可以做到非常靈活，Kubernetes和Fabio都已經將標簽運用到了對資源的過濾中，使用標簽幾乎可以實現任意比例和權重的服務流量調配。但是標簽本身需要單獨的儲存以及讀寫功能，不管是放在註冊中心本身或者對接第三方的CMDB。

在Nacos 0.7.0版本中，我們除了提供基於健康檢查和權重的負載均衡方式外，還新提供了基於第三方CMDB的標簽負載均衡器，具體可以參考CMDB功能介紹相關的文章。使用基於標簽的負載均衡器，目前可以實現同標簽優先訪問的流量排程策略，實際的應用場景中，可以用來實現服務的就近訪問，當您的服務部署在多個地域時，這非常有用。使用這個標簽負載均衡器，可以支援非常多的場景，這不是本文要詳細介紹的。雖然目前Nacos裡支援的標簽運算式並不豐富，不過我們會逐步擴充套件它支援的語法。除此以外，Nacos定義了Selector，作為負載均衡的統一抽象。關於Selector，由於篇幅關係，我們會有單獨的文章進行介紹。

 

理想的負載均衡實現應該是什麼樣的呢？不同的人會有不同的答案。Nacos試圖做的是將服務端負載均衡與客戶端負載均衡透過某種機制結合起來，提供使用者擴充套件性，並給予使用者充分的自主選擇權和輕便的使用方式。負載均衡是一個很大的話題，當我們在關註註冊中心提供的負載均衡策略時，需要註意該註冊中心是否有我需要的負載均衡方式，使用方式是否複雜。如果沒有，那麼是否允許我方便的擴充套件來實現我需求的負載均衡策略。

 

健康檢查

 

ZooKeeper和Eureka都實現了一種TTL的機制，就是如果客戶端在一定時間內沒有向註冊中心傳送心跳，則會將這個客戶端摘除。Eureka做的更好的一點在於它允許在註冊服務的時候，自定義檢查自身狀態的健康檢查方法。這在服務實體能夠保持心跳上報的場景下，是一種比較好的體驗，在Dubbo和SpringCloud這兩大體系內，也被培養成使用者心智上的預設行為。Nacos也支援這種TTL機制，不過這與ConfigServer在阿裡巴巴內部的機制又有一些區別。Nacos目前支援臨時實體使用心跳上報方式維持活性，傳送心跳的週期預設是5秒，Nacos服務端會在15秒沒收到心跳後將實體設定為不健康，在30秒沒收到心跳時將這個臨時實體摘除。

 

不過正如前文所說，有一些服務無法上報心跳，但是可以提供一個檢測介面，由外部去探測。這樣的服務也是廣泛存在的，而且以我們的經驗，這些服務對服務發現和負載均衡的需求同樣強烈。服務端健康檢查最常見的方式是TCP埠探測和HTTP介面傳回碼探測，這兩種探測方式因為其協議的通用性可以支援絕大多數的健康檢查場景。在其他一些特殊的場景中，可能還需要執行特殊的接口才能判斷服務是否可用。例如部署了資料庫的主備，資料庫的主備可能會在某些情況下切換，需要透過服務名對外提供訪問，保證當前訪問的庫是主庫。此時的健康檢查介面，可能就是一個檢查資料庫是否是主庫的MYSQL命令了。

 

客戶端健康檢查和服務端健康檢查有一些不同的關註點。客戶端健康檢查主要關註客戶端上報心跳的方式、服務端摘除不健康客戶端的機制。而服務端健康檢查，則關註探測客戶端的方式、靈敏度及設定客戶端健康狀態的機制。從實現複雜性來說，服務端探測肯定是要更加複雜的，因為需要服務端根據註冊服務配置的健康檢查方式，去執行相應的介面，判斷相應的傳回結果，並做好重試機制和執行緒池的管理。這與客戶端探測，只需要等待心跳，然後掃清TTL是不一樣的。同時服務端健康檢查無法摘除不健康實體，這意味著只要註冊過的服務實體，如果不呼叫介面主動登出，這些服務實體都需要去維持健康檢查的探測任務，而客戶端則可以隨時摘除不健康實體，減輕服務端的壓力。

 

圖8 Nacos的健康檢查

 

Nacos既支援客戶端的健康檢查，也支援服務端的健康檢查，同一個服務可以切換健康檢查樣式。我們認為這種健康檢查方式的多樣性非常重要，這樣可以支援各種型別的服務，讓這些服務都可以使用到Nacos的負載均衡能力。Nacos下一步要做的是實現健康檢查方式的使用者擴充套件機制，不管是服務端探測還是客戶端探測。這樣可以支援使用者傳入一條業務語意的請求，然後由Nacos去執行，做到健康檢查的定製。

 

效能與容量

 

雖然大部分使用者用到的效能不高，但是他們仍然希望選用的產品的效能越高越好。影響讀寫效能的因素很多：一致性協議、機器的配置、叢集的規模、存量資料的規模、資料結構及讀寫邏輯的設計等等。在服務發現的場景中，我們認為讀寫效能都是非常關鍵的，但是並非效能越高就越好，因為追求效能往往需要其他方面做出犧牲。ZooKeeper在寫效能上似乎能達到上萬的TPS，這得益於ZooKeeper精巧的設計，不過這顯然是因為有一系列的前提存在。首先ZooKeeper的寫邏輯就是進行K-V的寫入，內部沒有聚合；其次ZooKeeper捨棄了服務發現的基本功能如健康檢查、友好的查詢介面，它在支援這些功能的時候，顯然需要增加一些邏輯，甚至棄用現有的資料結構；最後，Paxos協議本身就限制了ZooKeeper叢集的規模，3、5個節點是不能應對大規模的服務訂閱和查詢的。

 

在對容量的評估時，不僅要針對企業現有的服務規模進行評估，也要對未來3到5年的擴充套件規模進行預測。阿裡巴巴的中介軟體在內部支撐著集團百萬級別服務實體，在容量上遇到的挑戰可以說不會小於任何網際網路公司。這個容量不僅僅意味著整體註冊的實體數，也同時包含單個服務的實體數、整體的訂閱者的數目以及查詢的QPS等。Nacos在內部淘汰ZooKeeper和Eureka的過程中，容量是一個非常重要的因素。

 

ZooKeeper的容量，從儲存節點數來說，可以達到百萬級別。不過如上面所說，這並不代表容量的全部，當大量的實體上下線時，ZooKeeper的表現並不穩定，同時在推送機制上的缺陷，會引起客戶端的資源佔用上升，從而效能急劇下降。

 

Eureka在服務實體規模在5000左右的時候，就已經出現服務不可用的問題，甚至在壓測的過程中，如果併發的執行緒數過高，就會造成Eureka crash。不過如果服務規模在1000上下，幾乎目前所有的註冊中心都可以滿足。畢竟我們看到Eureka作為SpringCloud的註冊中心，在國內也沒有看到很廣泛的對於容量或者效能的問題報告。

 

Nacos在開源版本中，服務實體註冊的支撐量約為100萬，服務的數量可以達到10萬以上。在實際的部署環境中，這個數字還會因為機器、網路的配置與JVM引數的不同，可能會有所差別。圖9展示了Nacos在使用1.0.0版本進行壓力測試後的結果總結，針對容量、併發、擴充套件性和延時等進行了測試和統計。

圖9 Nacos效能與容量報告

 

完整的測試報告可以參考Nacos官網:
https://nacos.io/en-us/docs/nacos-naming-benchmark.htmlhttps://nacos.io/en-us/docs/nacos-config-benchmark.html

 

易用性

 

易用性也是使用者比較關註的一塊內容。產品雖然可以在功能特性或者效能上做到非常先進，但是如果使用者的使用成本極高，也會讓使用者望而卻步。易用性包括多方面的工作，例如API和客戶端的接入是否簡單，檔案是否齊全易懂，控制檯介面是否完善等。對於開源產品來說，還有一塊是社群是否活躍。在比較Nacos、Eureka和ZooKeeper在易用性上的表現時，我們誠邀社群的使用者進行全方位的反饋，因為畢竟在阿裡巴巴集團內部，我們對Eureka、ZooKeeper的使用場景是有限的。從我們使用的經驗和調研來看，ZooKeeper的易用性是比較差的，ZooKeeper的客戶端使用比較複雜，沒有針對服務發現的模型設計以及相應的API封裝，需要依賴方自己處理。對多語言的支援也不太好，同時沒有比較好用的控制檯進行運維管理。

 

Eureka和Nacos相比較ZooKeeper而言，已經改善很多，這兩個產品有針對服務註冊與發現的客戶端，也有基於SpringCloud體系的starter，幫助使用者以非常低的成本無感知的做到服務註冊與發現。同時還暴露標準的HTTP介面，支援多語言和跨平臺訪問。Eureka和Nacos都提供官方的控制檯來查詢服務註冊情況。不過隨著Eureka 2.0宣佈停止開發，Eureka在針對使用者使用上的最佳化後續應該不會再有比較大的投入，而Nacos目前依然在建設中，除了目前支援的易用性特性以外，後續還會繼續增強控制檯的能力，增加控制檯登入和許可權的管控，監控體系和Metrics的暴露，持續透過官網等渠道完善使用檔案，多語言SDK的開發等。

 

從社群活躍度的角度來看，目前由於ZooKeeper和Eureka的存量使用者較多，很多教程以及問題排查都可以在社群搜尋到，這方面新開源的Nacos還需要隨著時間繼續沉澱。

 

叢集擴充套件性

 

叢集擴充套件性和叢集容量以及讀寫效能關係緊密。當使用一個比較小的叢集規模就可以支撐遠高於現有數量的服務註冊及訪問時，叢集的擴充套件能力暫時就不會那麼重要。從協議的層面上來說，ZooKeeper使用的ZAB協議，由於是單點寫，在叢集擴充套件性上不具備優勢。Eureka在協議上來說理論上可以擴充套件到很大規模，因為都是點對點的資料同步，但是從我們對Eureka的運維經驗來看，Eureka叢集在擴容之後，效能上有很大問題。

 

叢集擴充套件性的另一個方面是多地域部署和容災的支援。當講究叢集的高可用和穩定性以及網路上的跨地域延遲要求能夠在每個地域都部署叢集的時候，我們現有的方案有多機房容災、異地多活、多資料中心等。

圖10 Nacos的多機房部署和容災

 

首先是雙機房容災，基於Leader寫的協議不做改造是無法支援的，這意味著Zookeeper不能在沒有人工幹預的情況下做到雙機房容災。在單機房斷網情況下，使機房內服務可用並不難，難的是如何在斷網恢復後做資料聚合，ZooKeeper的單點寫樣式就會有斷網恢復後的資料對賬問題。Eureka的部署樣式天然支援多機房容災，因為Eureka採用的是純臨時實體的註冊樣式：不持久化、所有資料都可以透過客戶端心跳上報進行補償。上面說到，臨時實體和持久化實體都有它的應用場景，為了能夠相容這兩種場景，Nacos支援兩種樣式的部署，一種是和Eureka一樣的AP協議的部署，這種樣式只支援臨時實體，可以完美替代當前的ZooKeeper、Eureka，並支援機房容災。另一種是支援持久化實體的CP樣式，這種情況下不支援雙機房容災。

 

在談到異地多活時，很巧的是，很多業務元件的異地多活正是依靠服務註冊中心和配置中心來實現的，這其中包含流量的排程和叢集的訪問規則的修改等。機房容災是異地多活的一部分，但是要讓業務能夠在訪問服務註冊中心時，動態調整訪問的叢集節點，這需要第三方的元件來做路由。異地多活往往是一個包含所有產品線的總體方案，很難說單個產品是否支援異地多活。

 

多資料中心其實也算是異地多活的一部分。從單個產品的維度上，ZooKeeper和Eureka沒有給出官方的多資料中心方案。Nacos基於阿裡巴巴內部的使用經驗，提供的解決方案是才有Nacos-Sync元件來做資料中心之間的資料同步，這意味著每個資料中心的Nacos叢集都會有多個資料中心的全量資料。Nacos-Sync是Nacos生態元件裡的重要一環，不僅會承擔Nacos叢集與Nacos叢集之間的資料同步，也會承擔Nacos叢集與Eureka、Zookeeper、Kubernetes及Consul之間的資料同步。

 

圖11 Nacos的多資料中心方案

 

使用者擴充套件性

 

在框架的設計中，擴充套件性是一個重要的設計原則。Spring、Dubbo、Ribbon等框架都在使用者擴充套件性上做了比較好的設計。這些框架的擴充套件性往往由面向介面及動態類載入等技術，來執行使用者擴充套件約定的介面，實現使用者自定義的邏輯。在Server的設計中，使用者擴充套件是比較審慎的。因為使用者擴充套件程式碼的引入，可能會影響原有Server服務的可用性，同時如果出問題，排查的難度也是比較大的。設計良好的SPI是可能的，但是由此帶來的穩定性和運維的風險是需要仔細考慮的。在開源軟體中，往往透過直接貢獻程式碼的方式來實現使用者擴充套件，好的擴充套件會被很多人不停的更新和維護，這也是一種比較好的開發樣式。ZooKeeper和Eureka目前Server端都不支援使用者擴充套件，一個支援使用者擴充套件的服務發現產品是CoreDNS。CoreDNS整體架構就是透過外掛來串聯起來的，透過將外掛程式碼以約定的方式放到CoreDNS工程下，重新構建就可以將外掛新增到CoreDNS整體功能鏈路的一環中。

 

那麼這樣的擴充套件性是否是有必要的呢？舉一個上文提到過的例子，假如要新增一種新的健康檢查方式，連線資料庫執行一條MySQL命令，通常的方式是在程式碼裡增加MySQL型別的健康檢查方法、構建、測試然後最終釋出。但是如果允許使用者上傳一個jar包放到Server部署目錄下的某個位置，Server就會自動掃描並識別到這張新的健康檢查方式呢？這樣不僅更酷，也讓整個擴充套件的流程與Server的程式碼解耦，變得非常簡單。所以對於系統的一些功能，如果能夠透過精心的設計開放給使用者在執行時去擴充套件，那麼為什麼不做呢？畢竟增加擴充套件的支援並不會讓原有的功能有任何損失。

 

所有產品都應該儘量支援使用者執行時擴充套件，這需要Server端SPI機制設計的足夠健壯和容錯。Nacos在這方面已經開放了對第三方CMDB的擴充套件支援，後續很快會開放健康檢查及負載均衡等核心功能的使用者擴充套件。目的就是為了能夠以一種解耦的方式支援使用者各種各樣的需求。

 

尾聲

 

本文並沒有把完整介紹Nacos的所有功能，例如Nacos支援的DNS協議，打自定義標等能力。Consul也並沒有在本文做重點比較，因為Consul實際上是和Nacos比較相似的產品，雖然Consul目前的主要發展方向放在了Service Mesh，但是Consul最初支援的服務發現和配置管理，也是Nacos的兩大功能。與Consul的詳細比較將會透過另外一篇文章單獨介紹，雖然Nacos在Consul之後以與之相似的部署架構開源，但這並不意味著Nacos在功能和架構上也模仿Consul，Nacos的架構和功能是由阿裡巴巴內部十年的執行演進經驗得來，所以二者的比較也一定會讓大家更加瞭解他們的定位和演進方向是完全不一樣的。

 

為了能讓大家對註冊中心產品整體的差異有一個快速的總覽，我們製作了下麵這個表格：