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

科技 04-19

朱鵬飛，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的架構和功能是由阿里巴巴內部十年的運行演進經驗得來，所以二者的比較也一定會讓大家更加了解他們的定位和演進方向是完全不一樣的。

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

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