1 服務(wù)發(fā)現(xiàn)的意義

為高可用，生產(chǎn)環(huán)境中服務(wù)提供方都以集群對(duì)外提供服務(wù)，集群里這些IP隨時(shí)可能變化，也需要用一本“通信錄”及時(shí)獲取對(duì)應(yīng)服務(wù)節(jié)點(diǎn)，這獲取過程即“服務(wù)發(fā)現(xiàn)”。

對(duì)服務(wù)調(diào)用方和服務(wù)提供方，其契約就是接口，相當(dāng)于“通信錄”中的姓名，服務(wù)節(jié)點(diǎn)就是提供該契約的一個(gè)具體實(shí)例。服務(wù)IP集合作為“通信錄”中的地址，從而可通過接口獲取服務(wù)IP的集合來完成服務(wù)的發(fā)現(xiàn)。即PRC框架的服務(wù)發(fā)現(xiàn)：

RPC服務(wù)發(fā)現(xiàn)原理圖

1.1 服務(wù)注冊(cè)

在服務(wù)提供方啟動(dòng)時(shí)，將對(duì)外暴露的接口注冊(cè)到注冊(cè)中心，注冊(cè)中心將這個(gè)服務(wù)節(jié)點(diǎn)的IP和接口保存

1.2 服務(wù)訂閱

在服務(wù)調(diào)用方啟動(dòng)時(shí)，去注冊(cè)中心查找并訂閱服務(wù)提供方的IP，然后緩存到本地，并用于后續(xù)的遠(yuǎn)程調(diào)用

2 為何不使用DNS？

服務(wù)發(fā)現(xiàn)的本質(zhì)，就是完成接口跟服務(wù)提供者IP的映射。能否把服務(wù)提供者IP統(tǒng)一換成一個(gè)域名，利用DNS實(shí)現(xiàn)？

2.1 DNS流程

DNS查詢流程

所有服務(wù)提供者節(jié)點(diǎn)都配置在同一域名下，調(diào)用方是可通過DNS拿到隨機(jī)的一個(gè)服務(wù)提供者的IP，并建立長連接，但業(yè)界為何不用這方案？

異常考慮

• ? 若該IP端口下線了，服務(wù)調(diào)用者能否及時(shí)摘除服務(wù)節(jié)點(diǎn)
• ? 若在之前已上線一部分服務(wù)節(jié)點(diǎn)，突然對(duì)這服務(wù)擴(kuò)容，新上線的服務(wù)節(jié)點(diǎn)能否及時(shí)接收到流量

都不能。因?yàn)闉樘嵘阅芎蜏p少DNS服務(wù)壓力，DNS采取多級(jí)緩存，緩存時(shí)間較長，特別是JVM的默認(rèn)緩存是永久有效，所以服務(wù)調(diào)用者不能及時(shí)感知到服務(wù)節(jié)點(diǎn)變化。

是否可加一個(gè)負(fù)載均衡設(shè)備？將域名綁定到這臺(tái)負(fù)載均衡設(shè)備，通過DNS拿到負(fù)載均衡的IP。服務(wù)調(diào)用時(shí)，服務(wù)調(diào)用方就能直接跟VIP建立連接，然后由VIP機(jī)器完成TCP轉(zhuǎn)發(fā)：

VIP方案

這是能解決DNS遇到的一些問題，但RPC里不是很合適：

• ? 搭建負(fù)載均衡設(shè)備或TCP/IP四層代理，需額外成本
• ? 請(qǐng)求流量都經(jīng)過負(fù)載均衡設(shè)備，多經(jīng)過一次網(wǎng)絡(luò)傳輸，浪費(fèi)性能
• ? 負(fù)載均衡添加節(jié)點(diǎn)和摘除節(jié)點(diǎn)，一般要手動(dòng)添加，當(dāng)大批量擴(kuò)容和下線時(shí)，會(huì)有大量人工操作和生效延遲
• ? 服務(wù)治理時(shí)，需更靈活的負(fù)載均衡策略，目前負(fù)載均衡設(shè)備的算法不滿足靈活需求

由此可見，DNS或者VIP方案雖然可以充當(dāng)服務(wù)發(fā)現(xiàn)的角色，但在RPC場景里面直接用還是很難的。

3 基于zk的服務(wù)發(fā)現(xiàn)(CP)

服務(wù)發(fā)現(xiàn)的本質(zhì)：完成接口跟服務(wù)提供者IP的映射。就是一種命名服務(wù)，還希望注冊(cè)中心完成實(shí)時(shí)變更推送，zk、etcd都能實(shí)現(xiàn)。

搭建一個(gè)zk集群作為注冊(cè)中心集群，服務(wù)注冊(cè)時(shí)，只需服務(wù)節(jié)點(diǎn)向zk寫入注冊(cè)信息，利用zk的Watcher機(jī)制完成服務(wù)訂閱與服務(wù)下發(fā)功能。

整體流程

基于ZooKeeper服務(wù)發(fā)現(xiàn)結(jié)構(gòu)圖

1. 服務(wù)平臺(tái)管理端先在zk創(chuàng)建一個(gè)服務(wù)根路徑，可根據(jù)接口名命名（如：/service/com.javaedge.xxService），在這路徑再創(chuàng)建服務(wù)提供方目錄與服務(wù)調(diào)用方目錄（如：provider、consumer），分別存儲(chǔ)服務(wù)提供方、服務(wù)調(diào)用方的節(jié)點(diǎn)信息

2. 當(dāng)服務(wù)提供方發(fā)起注冊(cè)時(shí)，會(huì)在服務(wù)提供方目錄中創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)，節(jié)點(diǎn)中存儲(chǔ)該服務(wù)提供方的注冊(cè)信息

3. 當(dāng)服務(wù)調(diào)用方發(fā)起訂閱時(shí)，則在服務(wù)調(diào)用方目錄中創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)，節(jié)點(diǎn)中存儲(chǔ)該服務(wù)調(diào)用方的信息，同時(shí)服務(wù)調(diào)用方watch該服務(wù)的服務(wù)提供方目錄（/service/com.demo.xxService/provider）中所有的服務(wù)節(jié)點(diǎn)數(shù)據(jù)。

4. 當(dāng)服務(wù)提供方目錄下有節(jié)點(diǎn)數(shù)據(jù)發(fā)生變更時(shí)，zk通知給發(fā)起訂閱的服務(wù)調(diào)用方

zk缺陷

早期RPC框架服務(wù)發(fā)現(xiàn)就是基于zk實(shí)現(xiàn)，但后續(xù)團(tuán)隊(duì)微服務(wù)化程度越來越高，zk集群整體壓力越來越高，尤其在集中上線時(shí)越發(fā)明顯?！凹斜l(fā)”是在一次大規(guī)模上線時(shí)，當(dāng)時(shí)有超大批量服務(wù)節(jié)點(diǎn)在同時(shí)發(fā)起注冊(cè)操作，ZooKeeper集群的CPU飆升，導(dǎo)致集群不能工作，也無法立馬將zk集群重新啟動(dòng)，一直到zk集群恢復(fù)后業(yè)務(wù)才能繼續(xù)上線。

根本原因就是zk本身性能問題，當(dāng)連接到zk的節(jié)點(diǎn)數(shù)量特多，對(duì)zk讀寫特頻繁，且zk存儲(chǔ)目錄達(dá)到一定數(shù)量，zk將不再穩(wěn)定，CPU持續(xù)升高，最終宕機(jī)。宕機(jī)后，由于各業(yè)務(wù)的節(jié)點(diǎn)還在持續(xù)發(fā)送讀寫請(qǐng)求，剛一啟動(dòng)，zk就因無法承受瞬間的讀寫壓力，馬上宕機(jī)。

要重新考慮服務(wù)發(fā)現(xiàn)方案。

4 消息總線(AP)

zk強(qiáng)一致性，集群的每個(gè)節(jié)點(diǎn)的數(shù)據(jù)每次發(fā)生更新操作，都通知其它節(jié)點(diǎn)同時(shí)執(zhí)行更新。它要求保證每個(gè)節(jié)點(diǎn)的數(shù)據(jù)實(shí)時(shí)完全一致，直接導(dǎo)致集群性能下降。

而RPC框架的服務(wù)發(fā)現(xiàn)，在服務(wù)節(jié)點(diǎn)剛上線時(shí)，服務(wù)調(diào)用方可容忍在一段時(shí)間后（如幾s后）發(fā)現(xiàn)這個(gè)新上線的節(jié)點(diǎn)。畢竟服務(wù)節(jié)點(diǎn)剛上線后的幾s內(nèi)，甚至更長的一段時(shí)間內(nèi)沒有接收到請(qǐng)求流量，對(duì)整個(gè)服務(wù)集群沒有什么影響，可犧牲掉CP（強(qiáng)制一致性），選擇AP（最終一致），換取整個(gè)注冊(cè)中心集群的性能和穩(wěn)定性。

是否有一種簡單、高效，并且最終一致的更新機(jī)制，代替zk數(shù)據(jù)強(qiáng)一致的數(shù)據(jù)更新機(jī)制？最終一致性，可考慮消息總線機(jī)制。注冊(cè)數(shù)據(jù)可全量緩存在每個(gè)注冊(cè)中心的內(nèi)存，通過消息總線來同步數(shù)據(jù)。當(dāng)有一個(gè)注冊(cè)中心節(jié)點(diǎn)接收到服務(wù)節(jié)點(diǎn)注冊(cè)時(shí)，會(huì)產(chǎn)生一個(gè)消息推送給消息總線，再通過消息總線通知給其它注冊(cè)中心節(jié)點(diǎn)更新數(shù)據(jù)并進(jìn)行服務(wù)下發(fā)，從而達(dá)到注冊(cè)中心間數(shù)據(jù)最終一致性。

4.1 總體流程

流程圖

? 服務(wù)上線，注冊(cè)中心節(jié)點(diǎn)收到注冊(cè)請(qǐng)求，服務(wù)列表數(shù)據(jù)變化，生成一個(gè)消息，推送給消息總線，每個(gè)消息都有整體遞增的版本

? 消息總線主動(dòng)推送消息到各注冊(cè)中心，同時(shí)注冊(cè)中心定時(shí)拉取消息。對(duì)獲取到消息的，在消息回放模塊里面回放，只接受大于本地版本號(hào)的消息，小于本地版本號(hào)的消息直接丟棄，實(shí)現(xiàn)最終一致性

? 消費(fèi)者訂閱可從注冊(cè)中心內(nèi)存拿到指定接口的全部服務(wù)實(shí)例，并緩存到消費(fèi)者的內(nèi)存

? 采用推拉模式，消費(fèi)者可及時(shí)拿到服務(wù)實(shí)例增量變化情況，并和內(nèi)存中的緩存數(shù)據(jù)進(jìn)行合并。

為性能，這里采用兩級(jí)緩存，注冊(cè)中心和消費(fèi)者的內(nèi)存緩存，通過異步推拉模式確保最終一致性。

服務(wù)調(diào)用方拿到的服務(wù)節(jié)點(diǎn)不是最新的，所以目標(biāo)節(jié)點(diǎn)存在已下線或不提供指定接口服務(wù)的情況，這時(shí)咋辦？這問題放到RPC框架里處理，在服務(wù)調(diào)用方發(fā)送請(qǐng)求到目標(biāo)節(jié)點(diǎn)后，目標(biāo)節(jié)點(diǎn)會(huì)進(jìn)行合法性驗(yàn)證，若指定接口服務(wù)不存在或正在下線，則拒絕該請(qǐng)求。服務(wù)調(diào)用方收到拒絕異常后，會(huì)安全重試到其它節(jié)點(diǎn)。

通過消息總線，完成注冊(cè)中心集群間數(shù)據(jù)變更的通知，保證數(shù)據(jù)最終一致性，并能及時(shí)觸發(fā)注冊(cè)中心的服務(wù)下發(fā)。服務(wù)發(fā)現(xiàn)的特性是允許我們?cè)谠O(shè)計(jì)超大規(guī)模集群服務(wù)發(fā)現(xiàn)系統(tǒng)的時(shí)候，舍棄強(qiáng)一致性，更多考慮系統(tǒng)健壯性。最終一致性才是分布式系統(tǒng)設(shè)計(jì)更常用策略。

5 總結(jié)

通?？墒褂脄k、etcd或分布式緩存（如Hazelcast）解決事件通知問題，但當(dāng)集群達(dá)到一定規(guī)模之后，依賴的ZooKeeper集群、etcd集群可能就不穩(wěn)定，無法滿足需求。

在超大規(guī)模的服務(wù)集群下，注冊(cè)中心所面臨的挑戰(zhàn)就是超大批量服務(wù)節(jié)點(diǎn)同時(shí)上下線，注冊(cè)中心集群接受到大量服務(wù)變更請(qǐng)求，集群間各節(jié)點(diǎn)間需要同步大量服務(wù)節(jié)點(diǎn)數(shù)據(jù)，導(dǎo)致：

? 注冊(cè)中心負(fù)載過高

? 各節(jié)點(diǎn)數(shù)據(jù)不一致

? 服務(wù)下發(fā)不及時(shí)或下發(fā)錯(cuò)誤的服務(wù)節(jié)點(diǎn)列表

RPC框架依賴的注冊(cè)中心的服務(wù)數(shù)據(jù)的一致性其實(shí)并不需要滿足CP，只要滿足AP即可。我們就是采用“消息總線”的通知機(jī)制，來保證注冊(cè)中心數(shù)據(jù)的最終一致性，來解決這些問題的。

如服務(wù)節(jié)點(diǎn)數(shù)據(jù)的推送采用增量更新的方式，這種方式提高了注冊(cè)中心“服務(wù)下發(fā)”的效率，而這種方式，還可用于如統(tǒng)一配置中心，用此方式可以提升統(tǒng)一配置中心下發(fā)配置的效率。

6 FAQ

某大廠中間件的用戶平臺(tái)，服務(wù)掛了，在注冊(cè)中心上還得手動(dòng)刪除死亡的節(jié)點(diǎn)，若是zk，服務(wù)沒了，就代表會(huì)話也沒了，臨時(shí)節(jié)點(diǎn)應(yīng)該會(huì)被通知到把？為何還要手動(dòng)刪除？

臨時(shí)節(jié)點(diǎn)是需要等到超時(shí)時(shí)間之后才刪除，不夠?qū)崟r(shí)。

如果要能切換流量，要服務(wù)端配置權(quán)重負(fù)載均衡策略，這樣服務(wù)器端即可通過調(diào)整權(quán)重安排流量。

服務(wù)消費(fèi)者都是從注冊(cè)中心拉取服務(wù)提供者的地址信息，所以要切走某些服務(wù)提供者數(shù)據(jù)，只需要將注冊(cè)中心這些實(shí)例的地址信息刪除（其實(shí)下線應(yīng)用實(shí)例，實(shí)際也是去刪除注冊(cè)中心地址信息），然后注冊(cè)中心反向通知消費(fèi)者，消費(fèi)者受到拉取最新提供者地址信息就沒有這些實(shí)例了。

通過服務(wù)發(fā)現(xiàn)來摘除流量是最常見的手段，還可以上下線狀態(tài)、權(quán)重等方式。

現(xiàn)有開源注冊(cè)中心是不是還沒有消息總線這種實(shí)現(xiàn)方式？消息總線有沒有開源實(shí)現(xiàn)？

現(xiàn)成MQ也可充當(dāng)消息總線。

消息總棧類似一個(gè)隊(duì)列，隊(duì)列表示是遞增的數(shù)字，注冊(cè)中心集群的任何一個(gè)節(jié)點(diǎn)接收到注冊(cè)請(qǐng)求，都會(huì)把服務(wù)提供者信息發(fā)給消息總棧，消息總棧會(huì)像隊(duì)列以先進(jìn)先出的原則推送消息給所有注冊(cè)中心集群節(jié)點(diǎn)，集群節(jié)點(diǎn)接收到消息后會(huì)比較自己內(nèi)存中的當(dāng)前版本，保存版本大的，這種方式有很強(qiáng)的實(shí)效性，注冊(cè)中心集群也可以從消息總棧拉取消息，確保數(shù)據(jù)AP，個(gè)人理解這是為了防止消息未接收到導(dǎo)致個(gè)別節(jié)點(diǎn)數(shù)據(jù)不準(zhǔn)確，因?yàn)榉?wù)提供者可以向任意一個(gè)節(jié)點(diǎn)發(fā)送注冊(cè)請(qǐng)求，從而降低了單個(gè)注冊(cè)中心的壓力，而注冊(cè)和注冊(cè)中心同步是異步的，也解決了集中注冊(cè)的壓力，在Zookeeper中，因?yàn)閆ookeeper注冊(cè)集群的強(qiáng)一致性，導(dǎo)致必須所有節(jié)點(diǎn)執(zhí)行完一次同步，才能執(zhí)行新的同步，這樣導(dǎo)致注冊(cè)處理性能降低，從而高I/O操作宕機(jī)。

當(dāng)集中注冊(cè)時(shí)，消息總棧下發(fā)通知給注冊(cè)中心集群節(jié)點(diǎn)，對(duì)于單個(gè)節(jié)點(diǎn)也會(huì)不停的收到更新通知，這里也存在高I/O問題，會(huì)不會(huì)有宕機(jī)？event bus可以改造成主從模式保證高可用。

AP實(shí)現(xiàn)中“兩級(jí)緩存，注冊(cè)中心和消費(fèi)者的內(nèi)存緩存，通過異步推拉模式來確保最終一致性的具體實(shí)現(xiàn)？

推主要實(shí)現(xiàn)callback，拉的動(dòng)作在客戶端。

消息總線策略怎么保證消息總線全局版本遞增？最簡單的用時(shí)間戳。

消息總線構(gòu)建ap 型注冊(cè)中心，不是很理解。是多個(gè)注冊(cè)中心獨(dú)立提供讀寫，他們之間通過消息隊(duì)列做數(shù)據(jù)同步？那么一致性感覺不好保證，比如服務(wù)a 先注冊(cè)，再反注冊(cè)，但是分別發(fā)到兩個(gè)注冊(cè)中心節(jié)點(diǎn)，最終同步可能是亂序的哇？一般不會(huì)出現(xiàn)這種情況，只有連接斷開后，那需要重新注冊(cè)。

消息總線的另一個(gè)應(yīng)用case：配置中心。