迎關注我的頭條號：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的描述如下：
從 CAP 模型來分析， 優雅的注冊中心，需要AP模型，根據以上多維度對比，Eurake 和 Nacos 是 AP 模型，由于Netflix Eurake 2.0 已經停止更新，推薦阿裏巴巴Nacos。
PS：對 Consul 的CAP模型，很多人認爲是 CA 模型，對于分布式時代，如果丟失了 P 分區容錯性，本質上回歸成單機應用，意義不大。Consul官網對 Consul CAP 模型定義如下：