hello，大家好呀，我是小樓。今天不寫B(tài)UG，來(lái)聊一聊注冊(cè)中心。

標(biāo)題本來(lái)想叫《如何設(shè)計(jì)一個(gè)注冊(cè)中心》，但網(wǎng)上已經(jīng)有好多類似標(biāo)題的文章了。所以打算另辟蹊徑，換個(gè)角度，如何組裝一個(gè)注冊(cè)中心。

組裝意味著不必從0開(kāi)始造輪子，這也比較符合許多公司對(duì)待自研基礎(chǔ)組件的態(tài)度。

知道如何組裝一個(gè)注冊(cè)中心有什么用呢？

第一可以更深入理解注冊(cè)中心。以我個(gè)人經(jīng)歷來(lái)說(shuō)，注冊(cè)中心的第一印象就是Dubbo的Zookeeper（以下簡(jiǎn)稱zk），后來(lái)逐漸深入，學(xué)會(huì)了如何去zk上查看Dubbo注冊(cè)的數(shù)據(jù)，并能排查一些問(wèn)題。后來(lái)了解了Nacos，才發(fā)現(xiàn)，原來(lái)注冊(cè)中心還可以如此簡(jiǎn)單，再后來(lái)一直從事服務(wù)發(fā)現(xiàn)相關(guān)工作，對(duì)一些細(xì)枝末節(jié)也有了一些新的理解。

第二可以學(xué)習(xí)技術(shù)選型的方法，注冊(cè)中心中的每個(gè)模塊，都會(huì)在不同的需求下有不同的選擇，最終的選擇取決于對(duì)需求的把握以及技術(shù)視野，但這兩項(xiàng)是內(nèi)功，一時(shí)半會(huì)練不成，學(xué)個(gè)選型的方法還是可以的。

本文打算從需求分析開(kāi)始，一步步拆解各個(gè)模塊，整個(gè)注冊(cè)中心以一種如無(wú)必要，勿增實(shí)體的原則進(jìn)行組裝，但也不會(huì)是個(gè)玩具，向生產(chǎn)可用對(duì)齊。

當(dāng)然在實(shí)際項(xiàng)目中，不建議重復(fù)造輪子，盡量用現(xiàn)成的解決方案，所以本文僅供學(xué)習(xí)參考。

需求分析

本文的注冊(cè)中心需求很簡(jiǎn)單，就三點(diǎn)：可注冊(cè)、能發(fā)現(xiàn)、高可用。

服務(wù)的注冊(cè)和發(fā)現(xiàn)是注冊(cè)中心的基本功能，高可用則是生產(chǎn)環(huán)境的基本要求，如果高可用不要求，那本文可講解的內(nèi)容就很少，上圖中的高可用標(biāo)注只是個(gè)示意，高可用在很多方面都有體現(xiàn)。

至于其他花里胡哨的功能，我們暫且不表。

我們這里介紹三個(gè)角色，后文以此為基礎(chǔ)：

• 提供者（Provider）：服務(wù)的提供方（被調(diào)用方）
• 消費(fèi)者（Consumer）：服務(wù)的消費(fèi)方（調(diào)用方）
• 注冊(cè)中心（Registry）：本文主角，服務(wù)提供列表、消費(fèi)關(guān)系等數(shù)據(jù)的存儲(chǔ)方

接口定義

注冊(cè)中心和客戶端（SDK）的交互接口有三個(gè)：

• 注冊(cè)（register），將服務(wù)提供方注冊(cè)到注冊(cè)中心
• 注銷（unregister），將注冊(cè)的服務(wù)從注冊(cè)中心中刪除
• 訂閱（subscribe），服務(wù)消費(fèi)方訂閱需要的服務(wù)，訂閱后提供方有變更將通知到對(duì)應(yīng)的消費(fèi)方

注冊(cè)、注銷可以是服務(wù)提供方的進(jìn)程發(fā)起，也可以是其他的旁路程序輔助發(fā)起，比如發(fā)布系統(tǒng)在發(fā)布一臺(tái)機(jī)器完成后，可調(diào)用注冊(cè)接口，將其注冊(cè)到注冊(cè)中心，注銷也是類似流程，但這種方式并不多見(jiàn)，而且如果只考慮實(shí)現(xiàn)一個(gè)注冊(cè)中心，必然是可以單獨(dú)運(yùn)行的，所以通常注冊(cè)、注銷由提供方進(jìn)程負(fù)責(zé)。

有了這三個(gè)接口，我們?cè)撊绾稳ザx接口呢？注冊(cè)服務(wù)到底有哪些字段需要注冊(cè)？訂閱需要傳什么字段？以什么序列化方式？用什么協(xié)議傳輸？

這些問(wèn)題接踵而來(lái)，我覺(jué)得我們先不急著去做選擇，先看看這個(gè)領(lǐng)域有沒(méi)有相關(guān)標(biāo)準(zhǔn)，如果有就參考或者直接按照標(biāo)準(zhǔn)實(shí)現(xiàn)，如果沒(méi)有，再來(lái)分析每一點(diǎn)的選擇。

服務(wù)發(fā)現(xiàn)還真有一套標(biāo)準(zhǔn)，但又不完全有。它叫OpenSergo，它其實(shí)是服務(wù)治理的一套標(biāo)準(zhǔn)，包含了服務(wù)發(fā)現(xiàn)：

OpenSergo 是一套開(kāi)放、通用的、面向分布式服務(wù)架構(gòu)、覆蓋全鏈路異構(gòu)化生態(tài)的服務(wù)治理標(biāo)準(zhǔn)，基于業(yè)界服務(wù)治理場(chǎng)景與實(shí)踐形成通用標(biāo)準(zhǔn)規(guī)范。OpenSergo 的最大特點(diǎn)就是以統(tǒng)一的一套配置/DSL/協(xié)議定義服務(wù)治理規(guī)則，面向多語(yǔ)言異構(gòu)化架構(gòu)，做到全鏈路生態(tài)覆蓋。無(wú)論微服務(wù)的語(yǔ)言是 Java, Go, Node.js 還是其它語(yǔ)言，無(wú)論是標(biāo)準(zhǔn)微服務(wù)還是 Mesh 接入，從網(wǎng)關(guān)到微服務(wù)，從數(shù)據(jù)庫(kù)到緩存，從服務(wù)注冊(cè)發(fā)現(xiàn)到配置，開(kāi)發(fā)者都可以通過(guò)同一套 OpenSergo CRD 標(biāo)準(zhǔn)配置針對(duì)每一層進(jìn)行統(tǒng)一的治理管控，而無(wú)需關(guān)注各框架、語(yǔ)言的差異點(diǎn)，降低異構(gòu)化、全鏈路服務(wù)治理管控的復(fù)雜度。

官網(wǎng)：https://opensergo.io/

我們需要的服務(wù)注冊(cè)與發(fā)現(xiàn)也被納入其中：

說(shuō)有但也不是完全有是因?yàn)檫@個(gè)標(biāo)準(zhǔn)還在建設(shè)中，服務(wù)發(fā)現(xiàn)相關(guān)的標(biāo)準(zhǔn)在寫這篇文章的時(shí)候還沒(méi)有給出。

既然沒(méi)有標(biāo)準(zhǔn)，可以結(jié)合現(xiàn)有的系統(tǒng)以及經(jīng)驗(yàn)來(lái)定義，這里我用json的序列化方式給出，以下為筆者的總結(jié)，不能囊括所有情形，需要時(shí)根據(jù)業(yè)務(wù)適當(dāng)做一些調(diào)整：

服務(wù)注冊(cè)入?yún)?/strong>?

{
  "application":"provider_test", // 應(yīng)用名
  "protocol":"http", // 協(xié)議
  "addr":"127.0.0.1:8080", // 提供方的地址
  "meta":{ // 攜帶的元數(shù)據(jù)，以下三個(gè)為示例
    "cluster":"small",
    "idc":"shanghai",
    "tag":"read"
  }
}

服務(wù)訂閱入?yún)?/strong>

{
    "subscribes":[
        {
            "provider":"test_provider1", // 訂閱的應(yīng)用名
            "protocol":"http", // 訂閱的協(xié)議
            "meta":{ // 攜帶的元數(shù)據(jù)，以下為示例
                "cluster":"small",
                "idc":"shanghai",
                "tag":"read"
            }
        },
        {
            "provider":"test_provider2",
            "protocol":"http",
            "meta":{
                "cluster":"small",
                "tag":"read"
            }
        }
    ]
}

服務(wù)發(fā)現(xiàn)出參

{
    "version":"23des4f", // 版本
    "endpoints":[ // 實(shí)例
        {
            "application":"provider_test",
            "protocol":"http",
            "addr":"127.0.0.1:8080",
            "meta":{
                "cluster":"small",
                "idc":"shanghai",
                "tag":"read"
            }
        },
        {
            "application":"provider_test",
            "protocol":"http",
            "addr":"127.0.0.2:8080",
            "meta":{
                "cluster":"small",
                "idc":"shanghai",
                "tag":"read"
            }
        }
    ]
}

變更推送 & 服務(wù)健康檢查

有了定義，我們?nèi)绾芜x擇序列化方式？選擇序列化方式有兩個(gè)重要參考點(diǎn)：

• 語(yǔ)言的適配程度，比如 json 幾乎所有編程語(yǔ)言都能適配。除非能非常確定5-10年內(nèi)不會(huì)有多語(yǔ)言的需求，否則我還是非常建議你選擇一個(gè)跨語(yǔ)言的序列化協(xié)議
• 性能，序列化的性能包含了兩層意思，序列化的速度（cpu消耗）與序列化后的體積，設(shè)想一個(gè)場(chǎng)景，一個(gè)服務(wù)被非常多的應(yīng)用訂閱，如果此時(shí)該服務(wù)發(fā)布，則會(huì)觸發(fā)非常龐大的推送事件，此時(shí)注冊(cè)中心的cpu和網(wǎng)絡(luò)則有可能被打滿，導(dǎo)致服務(wù)不可用

至于編程語(yǔ)言的選擇，我覺(jué)得應(yīng)該更加偏向團(tuán)隊(duì)對(duì)語(yǔ)言的掌握，以能hold住為最主要，這點(diǎn)沒(méi)什么好說(shuō)的，一般也只會(huì)在 Java / Go 中去選，很少見(jiàn)用其他語(yǔ)言實(shí)現(xiàn)的注冊(cè)中心。

對(duì)于注冊(cè)、訂閱接口，無(wú)論是基于TCP的自定義私有協(xié)議，還是用HTTP協(xié)議，甚至基于HTTP2的gRPC我覺(jué)得都可以。

但變更推送這個(gè)技術(shù)點(diǎn)的實(shí)現(xiàn)，有多種實(shí)現(xiàn)方式：

• 定時(shí)輪詢，每隔一段時(shí)間向注冊(cè)中心請(qǐng)求查詢訂閱的服務(wù)提供列表
• 長(zhǎng)輪詢，向注冊(cè)中心查詢訂閱的服務(wù)提供列表，如果列表較上次沒(méi)有變化，則服務(wù)端hold住請(qǐng)求，等待有變化或者超時(shí)（較長(zhǎng)時(shí)間）才返回
• UDP推送，服務(wù)列表有變化時(shí)通過(guò)UDP將事件通知給客戶端，但UDP推送不一定可靠，可能會(huì)丟失、亂序，故要配合定時(shí)輪詢（較長(zhǎng)時(shí)間間隔）來(lái)作為一個(gè)兜底
• TCP長(zhǎng)連接推送，客戶端與注冊(cè)中心建立一個(gè)TCP長(zhǎng)連接，有變更時(shí)推送給客戶端

從實(shí)現(xiàn)的難易、實(shí)時(shí)性、資源消耗三個(gè)方面來(lái)比較這四種實(shí)現(xiàn)方式：

似乎我們不好抉擇到底使用哪種方式來(lái)做推送，但以我自己的經(jīng)驗(yàn)來(lái)看，定時(shí)輪詢應(yīng)該首先被排除，因?yàn)榧幢闶且粋€(gè)初具規(guī)模的公司，定時(shí)輪詢的消耗也是巨大的，更何況這種消耗隨著實(shí)時(shí)性以及服務(wù)的規(guī)模日漸龐大，最后變得不可維護(hù)。

剩下三種方案都可以選擇，我們可以繼續(xù)結(jié)合服務(wù)節(jié)點(diǎn)的健康檢查來(lái)綜合判斷。

服務(wù)啟動(dòng)時(shí)注冊(cè)到注冊(cè)中心，當(dāng)服務(wù)停止時(shí)，從注冊(cè)中心摘除，通常摘除會(huì)借助劫持kill?信號(hào)實(shí)現(xiàn)，如果是Java則有封裝好的ShutdownHook，當(dāng)進(jìn)程被 kill 時(shí)，觸發(fā)劫持邏輯，從注冊(cè)中心摘除，實(shí)現(xiàn)優(yōu)雅退出。

但事情不總是如預(yù)期，如果有人執(zhí)行了kill -9強(qiáng)制殺死進(jìn)程，或者機(jī)器出現(xiàn)硬件故障，會(huì)導(dǎo)致提供者還在注冊(cè)中心，但已無(wú)法提供服務(wù)。

此時(shí)需要一種健康檢查機(jī)制來(lái)確保服務(wù)宕機(jī)時(shí)，消費(fèi)者能正常感知，從而切走流量，保證線上服務(wù)的穩(wěn)定性。

關(guān)于健康檢查機(jī)制，在之前的文章《??服務(wù)探活的五種方式??》中有專門的總結(jié)，這里也列舉一下，以便做出正確的選擇：

我們暫時(shí)無(wú)法控制調(diào)用動(dòng)作，故而前2項(xiàng)依賴消費(fèi)者的方案排除，提供者上報(bào)心跳如果規(guī)模較小還好，上點(diǎn)規(guī)模也會(huì)不堪重任，這點(diǎn)在Nacos中就體現(xiàn)了，Nacos 1.x版本使用提供者上報(bào)心跳的方式保持服務(wù)健康狀態(tài)，由于每次上報(bào)健康狀態(tài)都需要寫入數(shù)據(jù)（最后健康檢查時(shí)間），故對(duì)資源的消耗是非常大的，所以Nacos 2.0版本后就改為了長(zhǎng)連接會(huì)話保持健康狀態(tài)。

所以健康檢查我個(gè)人比較傾向最后兩種方案：注冊(cè)中心主動(dòng)探測(cè)與提供者與注冊(cè)中心會(huì)話保持的方式。

結(jié)合上述變更推送，我們發(fā)現(xiàn)如果實(shí)現(xiàn)了長(zhǎng)連接，好處將很多，很多情況下，一個(gè)服務(wù)既是消費(fèi)者，又是提供者，此時(shí)一條TCP長(zhǎng)連接可以解決推送和健康檢查，甚至在注冊(cè)注銷接口的實(shí)現(xiàn)，我們也可以復(fù)用這條連接，可謂是一石三鳥(niǎo)。

長(zhǎng)連接技術(shù)選型

長(zhǎng)連接的技術(shù)選型，在《Nacos架構(gòu)與原理》這本電子書(shū)中有有詳細(xì)的介紹，我覺(jué)得這部分堪稱技術(shù)選型的典范，我們參考下，本節(jié)內(nèi)容大量參考《Nacos架構(gòu)與原理》，如有雷同，那便是真是雷同。

首先是長(zhǎng)連接的核心訴求：

圖來(lái)自《Nacos架構(gòu)與原理》

• 低成本快速感知：客戶端需要在服務(wù)端不可用時(shí)盡快地切換到新的服務(wù)節(jié)點(diǎn)，降低不可用時(shí)間

客戶端正常重啟：客戶端主動(dòng)關(guān)閉連接，服務(wù)端實(shí)時(shí)感知

服務(wù)端正常重啟 : 服務(wù)端主動(dòng)關(guān)閉連接，客戶端實(shí)時(shí)感知

• 防抖：網(wǎng)絡(luò)短暫不可用，客戶端需要能接受短暫網(wǎng)絡(luò)抖動(dòng)，需要一定重試機(jī)制，防止集群抖動(dòng)，超過(guò)閾值后需要自動(dòng)切換 server，但要防止請(qǐng)求風(fēng)暴
• 斷網(wǎng)：斷網(wǎng)場(chǎng)景下，以合理的頻率進(jìn)行重試，斷網(wǎng)結(jié)束時(shí)可以快速重連恢復(fù)
• 低成本多語(yǔ)言實(shí)現(xiàn)：在客戶端層面要盡可能多的支持多語(yǔ)言，降低多 語(yǔ)言實(shí)現(xiàn)成本
• 開(kāi)源社區(qū)：文檔，開(kāi)源社區(qū)活躍度，使用用戶數(shù)等，面向未來(lái)是否有足夠的支持度

據(jù)此，我們可選的輪子有：

我比較傾向gRPC，而且gRPC的社區(qū)活躍度要強(qiáng)于Rsocket。

數(shù)據(jù)存儲(chǔ)

注冊(cè)中心數(shù)據(jù)存儲(chǔ)方案，大致可分為2類：

• 利用第三方組件完成，如Mysql、Redis等，好處是有現(xiàn)成的水平擴(kuò)容方案，穩(wěn)定性強(qiáng)；壞處是架構(gòu)變得復(fù)雜
• 利用注冊(cè)中心本身來(lái)存儲(chǔ)數(shù)據(jù)，好處是無(wú)需引入額外組件；壞處是需要解決穩(wěn)定性問(wèn)題

第一種方案我們不必多說(shuō)，第二種方案中最關(guān)鍵的就是解決數(shù)據(jù)在注冊(cè)中心各節(jié)點(diǎn)之間的同步，因?yàn)樵跀?shù)據(jù)存儲(chǔ)在注冊(cè)中心本身節(jié)點(diǎn)上，如果是單機(jī)，機(jī)器故障或者掛掉，數(shù)據(jù)存在丟失風(fēng)險(xiǎn)，所以必須得有副本。

數(shù)據(jù)不能丟失，這點(diǎn)必須要保證，否則穩(wěn)定性就無(wú)從談起了。保證數(shù)據(jù)不丟失怎么理解？在客戶端向注冊(cè)中心發(fā)起注冊(cè)請(qǐng)求后，收到正常的響應(yīng)，這就意味著數(shù)據(jù)存儲(chǔ)了起來(lái)，除非所有注冊(cè)中心節(jié)點(diǎn)故障，否則數(shù)據(jù)就一定要存在。

如下圖，比如提供者往一個(gè)節(jié)點(diǎn)注冊(cè)數(shù)據(jù)后，正常響應(yīng)，但是數(shù)據(jù)同步是異步的，在同步完成前，nodeA節(jié)點(diǎn)就掛掉，則這條注冊(cè)數(shù)據(jù)就丟失了。

所以，我們要極力避免這種情況。

而一致性算法（如raft）就解決了這個(gè)問(wèn)題，一致性算法能保證大部分節(jié)點(diǎn)是正常的情況下，能對(duì)外提供一致的數(shù)據(jù)服務(wù)，但犧牲了性能和可用性，raft算法在選主時(shí)便不能對(duì)外提供服務(wù)。

有沒(méi)有退而求其次的算法呢？還真有，像Nacos、Eureka提供的AP模型，他們的核心點(diǎn)在于客戶端可以recover數(shù)據(jù)，也就是注冊(cè)中心追求最終一致性，如果某些數(shù)據(jù)丟失，服務(wù)提供方是可以重新將數(shù)據(jù)注冊(cè)上來(lái)。

比如我們將提供方與注冊(cè)中心之間設(shè)計(jì)為長(zhǎng)連接，提供方注冊(cè)服務(wù)后，連接的節(jié)點(diǎn)還沒(méi)來(lái)得及將數(shù)據(jù)同步到其他節(jié)點(diǎn)就掛了，此時(shí)提供方的連接也會(huì)斷開(kāi)，當(dāng)連接重新建立時(shí)，服務(wù)提供方可以重新注冊(cè)，恢復(fù)注冊(cè)中心的數(shù)據(jù)。

對(duì)于注冊(cè)中心選用AP、還是CP模型，業(yè)界早有爭(zhēng)論，但也基本達(dá)成了共識(shí)，AP要優(yōu)于CP，因?yàn)閿?shù)據(jù)不一致總比不可用要好吧？你說(shuō)是不是。

高可用

其實(shí)高可用的設(shè)計(jì)散落在各個(gè)細(xì)節(jié)點(diǎn)，如上文提到的數(shù)據(jù)存儲(chǔ)，其基本要求就是高可用。除此之外，我們的設(shè)計(jì)也都必須是面向失敗的設(shè)計(jì)。

假設(shè)我們的服務(wù)器會(huì)全部掛掉，怎樣才能保持服務(wù)間的調(diào)用不受影響？

通常注冊(cè)中心不侵入服務(wù)調(diào)用，而是在內(nèi)存（或磁盤）中緩存一份服務(wù)列表，當(dāng)注冊(cè)中心完全掛了，大不了這份緩存不再更新，但也不影響現(xiàn)有的服務(wù)調(diào)用，但新應(yīng)用啟動(dòng)就會(huì)受到影響。

總結(jié)

本文內(nèi)容略多，用一幅圖來(lái)總結(jié)：

組裝一個(gè)線上可用的注冊(cè)中心最小集，從需求分析出發(fā)，每一步都有許多選擇，本文通過(guò)一些核心的技術(shù)選型來(lái)描繪出一個(gè)大致藍(lán)圖，剩下的工作就是用代碼將這些組裝起來(lái)。