迎關注我的頭條號：Wooola，10 年 Java 軟件開發及架構設計經驗，專注於 Java、Go 語言、微服務架構，致力於每天分享原創文章、快樂編碼和開源技術。

概述

在微服務時代，註冊中心越來越被重視。服務治理逐漸跟業務服務並駕齊驅。所以本文想對註冊中心進行體系化探索。註冊中心，起源於分佈式時代。不管是水平拆分架構，或者垂直拆分架構，對於多服務、多實例的支持，都需要對服務進行治理。註冊中心被用於服務治理中的服務註冊、服務發現、服務探活等場景。

架構師需要追尋事物的本質，並做好設計平衡，才能真正做到降本增效。那麼註冊中心的本質是什麼：

1、根據服務發現的需求反推出第一個本質是一個Query函數

Si = F(serviceName)

serviceName 查詢服務參數

Si 為對應服務的可用列表（IP：Port）

2、根據服務註冊的需求反推出第二個本質是一個獨立的、簡單的第三方存儲，用於服務元信息的存儲。

高內聚、低耦合的設計思維要求註冊中心存儲的極簡化。業內比如 dubbo 2.7 對註冊中心進行拆分、剝離出元數據中心，其實就是單一職責原則的體現，也證明了註冊中心的 simple 存儲。

3、 根據服務探活的需求反推出第三個本質是節點監控通知。

節點的探活應該是多樣化的，根據依賴倒置原則，節點既要提供默認探活：比如心跳機制，也應提供更多樣化的服務探活。對於服務節點的存活，上游調用是最有發言權的。

服務代理

註冊中心從需求上看是服務代理，常見服務代理有：

01 / 網路代理方式

對多實例服務的訪問，可以通過增加反向代理，比如Nginx，上游調用方只需要訪問Nginx，從而做到上游調用方對服務 A 多實例的透明。

如果公司有很多服務：服務 B、服務 C、服務 D、服務 E 等，遵循同樣的基於反向代理的調用， 並必須保證代理的高可用，會陷入運維災難。

02 / DNS方式

給服務 A 配置一個域名，通過配置兩個 A 記錄分別指向服務 A 的兩個實例，客戶端只要配置服務 A 的域名。

這種方式存在問題：DNS 只是 IP 級別，無法處理端口等信息。DNS 攜帶的數據較少，例如節點權重、序列化方式等等，無法傳遞。另外 DNS 沒有節點狀態管理功能，無法及時剔除死掉的節點。

以上兩者方式有很多問題，無法完全滿足註冊中心的三個需求，我們進一步探討思考。

ZooKeeper 註冊中心討論

ZooKeeper用作註冊中心是否適合？一切脫離場景談架構都是耍流氓。NX架構師需要考慮針對場景進行探討和分析。

官網對ZooKeeper的描述如下：

從官網描述上，我們並未發現 ZooKeeper 提供註冊中心的功能，所以註冊中心是我們加上的一個屬性。從架構本質來分析，ZooKeeper 做註冊中心是不優雅的，參見歷史文章 《微服務架構中註冊中心的設計思考》。

之所以不優雅，總結了ZooKeeper 的侷限性如下：

1、多機房網絡劃分後，強一致性引起的服務註冊機制失效

ZAB 協議保證數據一致性，對於離線的少數節點進行保護，禁止讀寫引起。異地機房會有災難性影響。 註冊中心不能因為自身的任何原因破壞服務之間本身的可連通性。

2、持久化存儲和事務日誌

事務日誌：CP 模式，半數節點寫入成功；採用事務日誌，2PC 提交。定期 Dump 內存數據到硬盤，保持數據一致性。註冊中心只關注實時的健康的服務列表，調用方不關心歷史服務與狀態。

3、服務探活

ZooKeeper 註冊中心通常利用 session 活性心跳和臨時節點機制來進行服務探活。簡單而言，就是將服務的健康監測綁定在了 ZooKeeper 對於 Session 的健康監測上，或者說綁定在 TCP 長鏈接活性探測。

4、服務容災

服務調用鏈路需要弱依賴註冊中心，可是 ZooKeeper 原生客戶端並不提供緩存服務節點機制。

5、客戶端設計不優雅

原生客戶端絕對稱不上好用，Netflix Curator 會好一點，但其實也好的有限。

6、易用難精

ZooKeeper 看似很簡單的一個產品，要完全理解 ZooKeeper 客戶端與 Server 之間的交互協議也並不簡單，完全理解並掌握 ZooKeeper Client/Session 的狀態機並不簡單。ZooKeeper 集群常見坑參考如下：

https://yq.aliyun.com/articles/227260

ZooKeeper 做註冊中心是伴隨著 Dubbo 的流行而火熱起來，他們之間相互成就，ZooKeeper 有侷限，在業界也有眾多的使用方，存在即合理，我們分析下 Dubbo 使用 ZooKeeper 的合理場景：

1、侷限 1 推導出 ZooKeeper 註冊中心適用於單數據中心。但市面上大部分公司都用不到多數據中心，所以不用糾結多數據中心。

2、侷限 2 需要去測試，得出一個精準上限值。但網易考拉、Dubbo2.7 都對此進行優化，如元數據中心。原始上限值是千位級服務，優化和上限值更高。

3、侷限 3、4、5 關注於 ZooKeeper 客戶端，很多框架，包含 dubbo 對 Client 都已經原生支持，在絕大部分時候使用者是無感知的。

5、侷限 6，ZooKeeper 是大數據之王，作為大數據協調器，在Hadoop生態中廣泛使用。

ZooKeeper 作為註冊中心源於 Dubbo 的火熱，Dubbo 的廣泛使用，造成了大量存量的 公司採用 ZooKeeper 作為註冊中心，這些公司的註冊中心是否需要升級，不能簡單因為ZooKeeper本身存在的侷限去否定。作為NX架構師，需要全局考慮，比如小公司中間件部署維護通常只有一個選型指標：引入一箇中間件，增加系統的維護難度，是否可以接受；再比如註冊中心足夠穩定下，是否需要投入人力去做註冊中心的更換，是否將有限資源投入其他更緊急業務項目中等。架構設計是全局的，需要取捨，做好折中，只有階段最合適。

微服務規模

1、微型註冊中心

該階段註冊中心，一般只關心服務本身，且是業務迭代比技術演進更被重視，需要的是一個無感知、部署簡單的環境。指標如下：

API 數量 0-100

部署服務個位數

2、小型註冊中心

該階段註冊中心，一般最關心服務發現特性，可能是一個很小的體量、很短的開發迭代週期、需要一個快速開發上手的環境。指標如下：

單數據中心，服務規模較小（API 數在 5K 以下，註冊中心客戶端數量在 50K 以下）

3、中型註冊中心該階段註冊中心，架構已經非常複雜，涉及到跨機房容災等特性。一般會有專門的技術團隊來做註冊中心的日常運維。指標如下：

多數據中心

服務規模較大：API 數在 20K 以下，註冊中心客戶端數量在 200K 以下

4、大型註冊中心

該階段註冊中心，服務量已經非常大，可能一個註冊中心已經無法滿足需求，必須拆為多個註冊中心，甚至需要容量的無限擴展。指標如下：

非常多的數據中心

服務規模十分大，單註冊集群無法滿足全量存儲

5、總結

架構是不斷演進的，絕大部分使用者還屬於微小型註冊中心階段；不需要一開始考慮機房容災，不是一開始就使用最終級的架構方案；每個階段要選型最合適技術，而不是最好技術。如果目前就千級別API接口、上百客戶端調用的服務註冊中心，ZooKeeper是能夠很好滿足需求的。

選型

從 CAP 模型來分析， 優雅的註冊中心，需要AP模型，根據以上多維度對比，Eurake 和 Nacos 是 AP 模型，由於Netflix Eurake 2.0 已經停止更新，推薦阿里巴巴Nacos。

PS：對 Consul 的CAP模型，很多人認為是 CA 模型，對於分佈式時代，如果丟失了 P 分區容錯性，本質上回歸成單機應用，意義不大。Consul官網對 Consul CAP 模型定義如下：

來源 https://mp.weixin.qq.com/s/y3Ic_XJFEWlIqZ8YcVokxw

閱讀更多 Wooola 的文章

關鍵字: Nginx DNS 設計