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

開源產品受開發者熱捧，是由於其代碼透明、能夠參與共建、有社區進行交流和學習，固然更重要的是開源產品的接入成本低。我的開發者或者中小型公司每每會將開源產品做爲選型首選。

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

另外一方面，做爲默默支持的產品，服務註冊中心每每隱藏在服務框架背後。優秀的服務框架每每會支持多種配置中心，可是註冊中心的選擇依然與服務框架強關聯，廣泛的狀況是一種服務框架會帶一個默認的服務註冊中心。這樣雖然免去了用戶在選型上的煩惱，可是單個註冊中心的侷限性，致使用戶使用多個服務框架時，必須部署多套徹底不一樣的註冊中心，這些註冊中心之間的數據協同是一個問題。

本文來自Nacos社區，做者是 Nacos PMC 朱鵬飛，做者力求公正和客觀的去看待主流微服務註冊中心的各個維度。本文不只僅包含常見服務註冊中心產品的對比，也試圖從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，則攜帶着阿里巴巴大規模服務生產經驗，試圖在服務註冊和配置管理這個市場上，提供給用戶一個新的選擇。

當市面上有多種類似功能的產品出現時，人們每每但願知道這些產品相比較的優劣。產品自己的定位會決定它包含了哪些功能，而產品架構的設計，則會影響產品的性能和可用性等。開源產品的一個優點是開發人員能夠去閱讀源代碼，理解產品的功能設計和架構設計，同時也能夠經過本地部署來測試性能，隨之而來的是各類產品的對比文章。不過當前關於註冊中心的對比，每每停留在表面的功能對比上，對架構或者性能並無很是深刻的探討。

另外一個現象是服務註冊中心每每隱藏在服務框架背後，做爲默默支持的產品。優秀的服務框架每每會支持多種配置中心，可是註冊中心的選擇依然強關聯與服務框架，一種廣泛的狀況是一種服務框架會帶一個默認的服務註冊中心。這樣雖然免去了用戶在選型上的煩惱，可是單個註冊中心的侷限性，致使用戶使用多個服務框架時，必須部署多套徹底不一樣的註冊中心，這些註冊中心之間的數據協同也是一個問題。

本文是一篇來自Nacos項目組的文章，雖然是來自Nacos，咱們依然力求公正和客觀的去看待服務發現全部產品的各個維度。本文不只僅包含常見服務註冊中心產品的對比，還試圖從咱們的經驗和調研中總結和闡述服務註冊中心產品設計上應該去遵循和考慮的要點。

數據模型

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

Zookeeper沒有針對服務發現設計數據模型，它的數據是以一種更加抽象的樹形K-V組織的，所以理論上能夠存儲任何語義的數據。而Eureka或者Consul都是作到了實例級別的數據擴展，這能夠知足大部分的場景，不過沒法知足大規模和多環境的服務數據存儲。Nacos在通過內部多年生產經驗後提煉出的數據模型，則是一種服務-集羣-實例的三層模型。如上文所說，這樣基本能夠知足服務在全部場景下的數據存儲和管理。

Nacos的數據模型雖然相對複雜，可是它並不強制你使用它裏面的全部數據，在大多數場景下，你能夠選擇忽略這些數據屬性，此時能夠降維成和Eureka和Consul同樣的數據模型。

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

Nacos提供了四層的數據邏輯隔離模型，用戶帳號對應的多是一個企業或者獨立的個體，這個數據通常狀況下不會透傳到服務註冊中心。一個用戶帳號能夠新建多個命名空間，每一個命名空間對應一個客戶端實例，這個命名空間對應的註冊中心物理集羣是能夠根據規則進行路由的，這樣可讓註冊中心內部的升級和遷移對用戶是無感知的，同時能夠根據用戶的級別，爲用戶提供不一樣服務級別的物理集羣。再往下是服務分組和服務名組成的二維服務標識，能夠知足接口級別的服務隔離。

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

在大中型的公司裏，這兩種類型的服務每每都有。一些基礎的組件例如數據庫、緩存等，這些每每不能上報心跳，這種類型的服務在註冊時，就須要做爲持久化實例註冊。而上層的業務服務，例如微服務或者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重點是作了一些邏輯的優化和性能的調優。

負載均衡

負載均衡嚴格的來講，並不算是傳統註冊中心的功能。通常來講服務發現的完整流程應該是先從註冊中心獲取到服務的實例列表，而後再根據自身的需求，來選擇其中的部分實例或者按照必定的流量分配機制來訪問不一樣的服務提供者，所以註冊中心自己通常不限定服務消費者的訪問策略。Eureka、Zookeeper包括Consul，自己都沒有去實現可配置及可擴展的負載均衡機制，Eureka的負載均衡是由ribbon來完成的，而Consul則是由Fabio作負載均衡。

在阿里巴巴集團內部，倒是使用的相反的思路。服務消費者每每並不關心所訪問的服務提供者的負載均衡，它們只關心以最高效和正確的訪問服務提供者的服務。而服務提供者，則很是關注自身被訪問的流量的調配，這其中的第一個緣由是，阿里巴巴集團內部服務訪問流量巨大，稍有不慎就會致使流量異常壓垮服務提供者的服務。所以服務提供者須要可以徹底掌控服務的流量調配，並能夠動態調整。

服務端的負載均衡，給服務提供者更強的流量控制權，可是沒法知足不一樣的消費者但願使用不一樣負載均衡策略的需求。而不一樣負載均衡策略的場景，確實是存在的。而客戶端的負載均衡則提供了這種靈活性，並對用戶擴展提供更加友好的支持。可是客戶端負載均衡策略若是配置不當，可能會致使服務提供者出現熱點，或者壓根就拿不到任何服務提供者。

拋開負載均衡究竟是在服務提供者實現仍是在服務消費者實現，咱們看到目前的負載均衡有基於權重、服務提供者負載、響應時間、標籤等策略。其中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是不同的。同時服務端健康檢查沒法摘除不健康實例，這意味着只要註冊過的服務實例，若是不調用接口主動註銷，這些服務實例都須要去維持健康檢查的探測任務，而客戶端則能夠隨時摘除不健康實例，減輕服務端的壓力。

Nacos既支持客戶端的健康檢查，也支持服務端的健康檢查，同一個服務能夠切換健康檢查模式。咱們認爲這種健康檢查方式的多樣性很是重要，這樣能夠支持各類類型的服務，讓這些服務均可以使用到Nacos的負載均衡能力。Nacos下一步要作的是實現健康檢查方式的用戶擴展機制，無論是服務端探測仍是客戶端探測。這樣能夠支持用戶傳入一條業務語義的請求，而後由Nacos去執行，作到健康檢查的定製。

性能與容量

雖然大部分用戶用到的性能不高，可是他們仍然但願選用的產品的性能越高越好。影響讀寫性能的因素不少：一致性協議、機器的配置、集羣的規模、存量數據的規模、數據結構及讀寫邏輯的設計等等。在服務發現的場景中，咱們認爲讀寫性能都是很是關鍵的，可是並不是性能越高就越好，由於追求性能每每須要其餘方面作出犧牲。Zookeeper在寫性能上彷佛能達到上萬的TPS，這得益於Zookeeper精巧的設計，不過這顯然是由於有一系列的前提存在。首先Zookeeper的寫邏輯就是進行K-V的寫入，內部沒有聚合；其次Zookeeper捨棄了服務發現的基本功能如健康檢查、友好的查詢接口，它在支持這些功能的時候，顯然須要增長一些邏輯，甚至棄用現有的數據結構；最後，Paxos協議自己就限制了Zookeeper集羣的規模，三、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版本進行壓力測試後的結果總結，針對容量、併發、擴展性和延時等進行了測試和統計。

易用性

易用性也是用戶比較關注的一塊內容。產品雖然能夠在功能特性或者性能上作到很是先進，可是若是用戶的使用成本極高，也會讓用戶望而卻步。易用性包括多方面的工做，例如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集羣在擴容以後，性能上有很大問題。

集羣擴展性的另外一個方面是多地域部署和容災的支持。當講究集羣的高可用和穩定性以及網絡上的跨地域延遲要求可以在每一個地域都部署集羣的時候，咱們現有的方案有多機房容災、異地多活、多數據中心等。

首先是雙機房容災，基於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之間的數據同步。

用戶擴展性

在框架的設計中，擴展性是一個重要的設計原則。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的架構和功能是由阿里巴巴內部十年的運行演進經驗得來，因此兩者的比較也必定會讓你們更加了解他們的定位和演進方向是徹底不同的。

爲了能讓你們對註冊中心產品總體的差別有一個快速的總覽，咱們製做了下面這個表格：

	Nacos	Eureka	Consul	CoreDNS	Zookeeper
一致性協議	CP+AP	AP	CP	—	CP
健康檢查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	—	Keep Alive
負載均衡策略	權重/ metadata/Selector	Ribbon	Fabio	RoundRobin	—
雪崩保護	有	有	無	無	無
自動註銷實例	支持	支持	不支持	不支持	支持
訪問協議	HTTP/DNS	HTTP	HTTP/DNS	DNS	TCP
監聽支持	支持	支持	支持	不支持	支持
多數據中心	支持	支持	支持	不支持	不支持
跨註冊中心同步	支持	不支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	不支持	不支持
Dubbo集成	支持	不支持	不支持	不支持	支持
K8S集成	支持	不支持	支持	支持	不支持

Nacos已經在4月10號發佈GA版本，後續將會以和社區共建的方式，持續輸出新的功能，在服務發現和配置管理這兩大領域繼續深耕，期待與你們一塊兒建設出最好用的服務發現和配置管理平臺。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。