當應用開始脫離單機運行和訪問時，服務發(fā)現(xiàn)就誕生了。目前的網(wǎng)絡架構是每個主機都有?個獨立的 IP 地址，服務發(fā)現(xiàn)基本都是通過某種方式獲取到服務所部署的 IP 地址。

DNS 協(xié)議是最早將?個網(wǎng)絡名稱翻譯為網(wǎng)絡 IP 的協(xié)議，在最初的架構選型中，DNS+LVS+Nginx 基本滿足所有 RESTful 服務的發(fā)現(xiàn)，此時服務的 IP 列表通常配置在 nginx 或 LVS。后來出現(xiàn) RPC 服務，服務的上下線更加頻繁，人們開始尋求?種能夠支持動態(tài)上下線并且推送 IP 列表變化的注冊中心產(chǎn)品。

互聯(lián)網(wǎng)軟件行業(yè)普遍熱捧開源產(chǎn)品，因為開源產(chǎn)品代碼透明、可以參與共建、有社區(qū)進行交流和學習，當然更重要是免費。個人開發(fā)者或者中小型公司往往會將開源產(chǎn)品作為選型首選。

1 開源產(chǎn)品

1.1 Zookeeper

經(jīng)典服務注冊中心產(chǎn)品（雖然它最初的定位并不在于此），在很長?段時間里，是國人在提起 RPC 服務注冊中心時心里想到的唯?選擇，這很大程度上與 Dubbo 在中國的普及程度有關。

1.2 Consul 和 Eureka

都出現(xiàn)于 2014 年：

• Consul 在設計上把很多分布式服務治理上要用到的功能都包含在內(nèi)，可以支持服務注冊、健康檢查、配置管理、Service Mesh 等
• Eureka借微服務概念流行，與 SpringCloud 生態(tài)的深度結合，也獲取了大量的用戶

1.3 Nacos

則攜帶著阿里巴巴大規(guī)模服務生產(chǎn)經(jīng)驗，試圖在服務注冊和配置管理這個市場上，提供給用戶?個新的選擇。

圖 1 服務發(fā)現(xiàn)：

1.4 開源產(chǎn)品的優(yōu)勢

開發(fā)人員可以去閱讀源代碼，理解產(chǎn)品的功能設計和架構設計，同時也可以通過本地部署來測試性能，隨之而來的是各種產(chǎn)品的對比文章。

不過當前關于注冊中心的對比，往往停留在表面的功能對比上，對架構或者性能并沒深入探討。

1.5 痛點

是服務注冊中心往往隱藏在服務框架背后，作為默默支持的產(chǎn)品。優(yōu)秀的服務框架往往支持多種配置中心，但是注冊中心的選擇依然強關聯(lián)與服務框架，?種普遍的情況是?種服務框架會帶?個默認的服務注冊中心。這樣雖然免去了用戶在選型上的煩惱，但是單個注冊中心的局限性，導致用戶使用多個服務框架時，必須部署多套完全不同的注冊中心，這些注冊中心之間的數(shù)據(jù)協(xié)同也是?個問題。

本文從各個角度深度介紹 Nacos 注冊中心的設計原理，并試圖從我們的經(jīng)驗和調(diào)研中總結和闡述服務注冊中心產(chǎn)品設計上應該去遵循和考慮的要點。

2 數(shù)據(jù)模型

注冊中心的核心數(shù)據(jù)：

• 服務的名字
• 它對應的網(wǎng)絡地址

當服務注冊了多個實例時，我們需要對不健康的實例過濾或針對實例的?些特征進行流量分配，就需要在實例存儲?些如健康狀態(tài)、權重等屬性。隨服務規(guī)模擴大，漸漸的又需要在整個服務級別設定?些權限規(guī)則、以及對所有實例都生效的?些開關，于是在服務級別又會設立?些屬性。再往后，我們又發(fā)現(xiàn)單個服務的實例又會有劃分為多個子集的需求，例如?個服務是多機房部署的，那么可能需要對每個機房的實例做不同的配置，這樣又需要在服務和實例之間再設定?個數(shù)據(jù)級別。

對比

• Zookeeper 沒有針對服務發(fā)現(xiàn)設計數(shù)據(jù)模型，它的數(shù)據(jù)是以?種更加抽象的樹形 K-V 組織的，因此理論上可以存儲任何語義的數(shù)據(jù)
• Eureka 或者 Consul 都做到實例級的數(shù)據(jù)擴展，可滿足大部分的場景，不過無法滿足大規(guī)模和多環(huán)境的服務數(shù)據(jù)存儲
• Nacos 在經(jīng)過內(nèi)部多年生產(chǎn)經(jīng)驗后提煉出的數(shù)據(jù)模型，則是?種服務-集群-實例的三層模型?；緷M足服務在所有場景下的數(shù)據(jù)存儲和管理。

Nacos 的數(shù)據(jù)模型雖然相對復雜，但它不強制你使用它里面的所有數(shù)據(jù)，在大多數(shù)場景下，你可以選擇忽略這些數(shù)據(jù)屬性，此時可降維成和 Eureka 和 Consul ?樣的數(shù)據(jù)模型。

數(shù)據(jù)的隔離模型

作為?個共享服務型的組件，需要能夠在多個用戶或者業(yè)務方使用情況下，保證數(shù)據(jù)的隔離和安全，這在稍微大?點的業(yè)務場景中非常常見。另?方面服務注冊中心往往會支持云上部署，此時就要求服務注冊中心的數(shù)據(jù)模型能夠適配云上的通用模型。

Zookeeper、Consul 和 Eureka 在開源層面都沒有很明確的針對服務隔離的模型，Nacos 則在?開始就考慮到如何讓用戶能夠以多種維度進行數(shù)據(jù)隔離，同時能夠平滑的遷移到阿里云上對應的商業(yè)化產(chǎn)品。

圖 3 服務的四層的數(shù)據(jù)邏輯隔離模型：

用戶賬號對應可能是?個企業(yè)或獨立的個體，這個數(shù)據(jù)?般情況不會透傳到服務注冊中心。?個用戶賬號可新建多個命名空間，每個命名空間對應?個客戶端實例，這個命名空間對應的注冊中心物理集群是可以根據(jù)規(guī)則進行路由的，這樣可以讓注冊中心內(nèi)部的升級和遷移對用戶無感知，同時根據(jù)用戶的級別，為用戶提供不同服務級別的物理集群。

再往下是服務分組和服務名組成的二維服務標識，可以滿足接口級別的服務隔離。

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

圖 4 臨時實例和持久化實例：

大中型公司，這兩種類型的服務都有：

• ?些基礎組件如數(shù)據(jù)庫、緩存等，這些往往不能上報心跳，這種類型的服務在注冊時，就需要作為持久化實例注冊
• 上層的業(yè)務服務，例如微服務或者 Dubbo 服務，服務的 Provider 端支持添加匯報心跳的邏輯，可使用動態(tài)服務的注冊方式

Nacos 2.0 沿用持久化及非持久化的設定，但有調(diào)整。Nacos 1.0 中持久化及非持久化的屬性是作為實例的?個元數(shù)據(jù)進行存儲和識別。導致同?個服務下可同時存在持久化實例和非持久化實例。但實際使用中，這種模式：

• 會給運維人員帶來極大的困惑和運維復雜度
• 從系統(tǒng)架構來看，?個服務同時存在持久化及非持久化實例的場景也是存在?定矛盾

導致該能力事實上未被廣泛使用。為簡化 Nacos 的服務數(shù)據(jù)模型，降低運維復雜度，提升 Nacos 易用性，在 Nacos2.0 中：

• 是否持久化的數(shù)據(jù)抽象至服務級別
• 不再允許?個服務同時存在持久化實例和非持久化實例，實例的持久化屬性繼承自服務的持久化屬性

3 數(shù)據(jù)?致性

分布式系統(tǒng)永恒話題，協(xié)議層面上看，?致性的選型已經(jīng)很長時間沒有新的成員加入了。目前來看基本

可歸兩家：

• 基于 Leader 的非對等部署的單點寫?致性
• 對等部署的多寫?致性

選用服務注冊中心，沒有?種協(xié)議能覆蓋所有場景，如：

• 當注冊的服務節(jié)點不會定時發(fā)送心跳到注冊中心時，強?致協(xié)議看起來是唯?的選擇，因為無法通過心跳來進行數(shù)據(jù)的補償注冊，第?次注冊就必須保證數(shù)據(jù)不會丟失
• 而當客戶端會定時發(fā)送心跳來匯報健康狀態(tài)時，第?次的注冊的成功率并不是非常關鍵（當然也很關鍵，只是相對來說我們?nèi)萑虜?shù)據(jù)的少量寫失?。驗楹罄m(xù)還可以通過心跳再把數(shù)據(jù)補償上來，此時 Paxos 協(xié)議的單點瓶頸就會不太劃算了，這也是Eureka 為什么不采用 Paxos 協(xié)議而采用自定義的 Renew 機制

這兩種數(shù)據(jù)?致性協(xié)議有各自使用場景，對服務注冊需求不同，就會導致使用不同協(xié)議。Zookeeper 在 Dubbo 體系下表現(xiàn)出的行為，其實采用 Eureka 的 Renew 機制更合適，因為 Dubbo 服務往 Zookeeper 注冊的就是臨時節(jié)點，需要定時發(fā)心跳到 Zookeeper來續(xù)約節(jié)點，并允許服務下線時，將 Zookeeper 上相應的節(jié)點摘除。Zookeeper 使用 ZAB 雖保證數(shù)據(jù)的強?致，但是它的機房容災能力的缺乏，無法適應?些大型場景。

Nacos 因為要支持多種服務類型的注冊，并能夠具有機房容災、集群擴展等必不可少的能力，1.0.0 正式支持 AP 和 CP 兩種?致性協(xié)議并存。1.0.0 重構數(shù)據(jù)的讀寫和同步邏輯，將與業(yè)務相關的 CRUD 與底層的?致性同步邏輯進行了分層隔離。然后將業(yè)務的讀寫（主要是寫，因為讀會直接使用業(yè)務層的緩存）抽象為 Nacos 定義的數(shù)據(jù)類型，調(diào)用?致性服務進行數(shù)據(jù)同步。在決定使用 CP 還是 AP ?致性時，使用?個代理，通過可控制的規(guī)則進行轉(zhuǎn)發(fā)。

目前的?致性協(xié)議實現(xiàn)，?個是基于簡化的 Raft 的 CP ?致性，?個是基于自研協(xié)議 Distro 的AP ?致性。Raft 協(xié)議不必多言，基于 Leader 進行寫入，其 CP 也并不是嚴格的，只是能保證?半所見?致，以及數(shù)據(jù)的丟失概率較小。Distro 協(xié)議則是參考了內(nèi)部 ConfigServer 和開源 Eureka，在不借助第三方存儲的情況下，實現(xiàn)基本大同小異。Distro 重點是做了?些邏輯的優(yōu)化和性能的調(diào)優(yōu)

圖 5 Nacos ?致性協(xié)議：

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！文章來源地址http://www.zghlxwxcb.cn/news/detail-692868.html

到了這里，關于Nacos 注冊中心的設計原理：讓你的應用輕松實現(xiàn)高效注冊與發(fā)現(xiàn)！的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！