•  分布式系統(tǒng)為什么需要注冊(cè)中心呢?
• 分布式系統(tǒng)注冊(cè)中心有哪些坑?
• 分布式系統(tǒng)注冊(cè)中心怎么來實(shí)現(xiàn)呢?
• 注冊(cè)中心利用現(xiàn)成的組件很好實(shí)現(xiàn)嗎?

看到標(biāo)題你可能會(huì)鄙視一下，注冊(cè)中心有是什么講的。注冊(cè)中心作為現(xiàn)在架構(gòu)中的一個(gè)組件來說，確實(shí)很常見。微服務(wù)作為分布式系統(tǒng)最典型的一種表現(xiàn)形式，是最近幾年最流行的概念之一。每個(gè)講微服務(wù)的文章中或多或少都會(huì)提及注冊(cè)中心，但也只是一帶而過，注冊(cè)中心作為分布式系統(tǒng)或者微服務(wù)架構(gòu)中最重要的一環(huán)，我覺得有必要寫一篇單獨(dú)的文章來詳細(xì)的介紹一下，這也是有這篇文章的原因。

分布式系統(tǒng)的痛點(diǎn)

注冊(cè)中心從架構(gòu)的角度來講，其實(shí)是一個(gè)統(tǒng)稱的概念，并非現(xiàn)在流行的微服務(wù)所有，在很早之前利用Nginx做負(fù)載均衡(反向代理)的時(shí)候，Nginx會(huì)根據(jù)配置文件把每個(gè)請(qǐng)求根據(jù)配置的策略導(dǎo)向后端具體的處理程序，在這個(gè)流程中，站在客戶端角度，Nginx很像一個(gè)網(wǎng)關(guān)，站在后端處理程序的角度，Nginx更像是服務(wù)的管理中心，它管理著所有可以提供服務(wù)的后端處理程序信息，并且還可以利用某些手段來達(dá)到服務(wù)的健康檢查，服務(wù)的自動(dòng)注冊(cè)和剔除等操作。

當(dāng)然現(xiàn)在流行微服務(wù)，網(wǎng)關(guān)和注冊(cè)中心被分為兩個(gè)并行的概念和組件。在重要性上來說，我覺得注冊(cè)中心的權(quán)重要大于網(wǎng)關(guān)?，F(xiàn)在十分流行單體服務(wù)拆分操作，但是這里我要強(qiáng)調(diào)一點(diǎn)，你的單體服務(wù)是否有必要拆分，還要根據(jù)很多情況來綜合考慮，畢竟拆分成小的微服務(wù)并非沒有代價(jià)。

在很早之前，如果客戶端需要請(qǐng)求后端的多個(gè)服務(wù)，很多情況下后端的服務(wù)信息是寫在請(qǐng)求方的配置文件中的，類似于這樣

{ 
    "ServiceA":[ 
        "http://192.168.100.100", 
        "http://192.168.100.101", 
        "http://192.168.100.102" 
    ] 
} 

這種方式固然是一種解決方案，但是隨著系統(tǒng)的不斷升級(jí)會(huì)遇到很多問題：

• 在系統(tǒng)需要擴(kuò)容后端服務(wù)器的時(shí)候，需要手動(dòng)修改客戶端的配置文件，而且在多數(shù)情況下還需要重啟客戶端進(jìn)程
• 當(dāng)后端的一個(gè)服務(wù)節(jié)點(diǎn)出現(xiàn)故障的時(shí)候，需要手動(dòng)刪除客戶端配置文件中對(duì)應(yīng)的節(jié)點(diǎn)，而且在多數(shù)情況下還需要重啟客戶端進(jìn)程
• 每次增加或者刪除節(jié)點(diǎn)的時(shí)候需要人工干預(yù)，大大提高了維護(hù)成本

鑒于以上幾個(gè)原因，注冊(cè)中心應(yīng)運(yùn)而生。

注冊(cè)中心的作用

注冊(cè)中心不僅僅解決了服務(wù)節(jié)點(diǎn)的增加刪除問題，而且在整個(gè)的查找服務(wù)可用節(jié)點(diǎn)的流程上做了修改，在搭配了服務(wù)健康檢查的手段之后，更可以做到自動(dòng)化。目前業(yè)界有很多可供選擇的注冊(cè)中心，比如ZooKeeper，ETCD，阿里的微服務(wù)注冊(cè)中心 Nacos、Spring Cloud 的 Eureka 等等，之前菜菜的文章就有寫過利用ETCD來實(shí)現(xiàn)一個(gè)配置中心

服務(wù)注冊(cè)發(fā)現(xiàn)

服務(wù)的注冊(cè)發(fā)現(xiàn)是注冊(cè)中心提供的最基礎(chǔ)也是最主要的功能：

• 當(dāng)一個(gè)新的服務(wù)節(jié)點(diǎn)上線的時(shí)候，可以通過注冊(cè)中心的接口進(jìn)行注冊(cè)，當(dāng)一個(gè)服務(wù)節(jié)點(diǎn)發(fā)生故障的時(shí)候，注冊(cè)中心會(huì)自動(dòng)刪除該服務(wù)節(jié)點(diǎn)
• 當(dāng)注冊(cè)中心的服務(wù)節(jié)點(diǎn)發(fā)生變化的時(shí)候，能夠及時(shí)通知調(diào)用方，服務(wù)的調(diào)用方可以近乎實(shí)時(shí)的來更新可用的服務(wù)節(jié)點(diǎn)信息

負(fù)載均衡

當(dāng)客戶端在注冊(cè)中心獲取到可用的服務(wù)節(jié)點(diǎn)之后，就可以根據(jù)輪訓(xùn)或者權(quán)重等策略來訪問服務(wù)了，這種場景下注冊(cè)中心更像一個(gè)負(fù)載均衡器，把流量導(dǎo)向多個(gè)不同的節(jié)點(diǎn)。

既然是負(fù)載均衡，在某種意義上講就可以實(shí)現(xiàn)服務(wù)的橫向擴(kuò)展，說實(shí)話這確實(shí)沒有什么問題，道理和Nginx做負(fù)載均衡道理類似。

那些坑

服務(wù)中心雖然在整體架構(gòu)模式上解決了很多問題，但是在使用中我們也要直面它所帶來的一些副作用，而且這些副作用有時(shí)候會(huì)成為整個(gè)系統(tǒng)癱瘓的導(dǎo)火線。

數(shù)據(jù)一致性問題

數(shù)據(jù)的一致性好像是所有系統(tǒng)都要面對(duì)的問題，注冊(cè)中心也不例外。這里的一致性是指注冊(cè)中心內(nèi)存儲(chǔ)的可用節(jié)點(diǎn)數(shù)據(jù)和后端真實(shí)可用節(jié)點(diǎn)以及客戶端存儲(chǔ)的可用節(jié)點(diǎn)之間的差異性問題。舉個(gè)栗子：假如注冊(cè)中心中存儲(chǔ)了ABC三個(gè)服務(wù)節(jié)點(diǎn)信息，而這個(gè)時(shí)候節(jié)點(diǎn)A由于某種原因下線了，注冊(cè)中心必須要及時(shí)把A節(jié)點(diǎn)移除掉，并且通知客戶端也把A節(jié)點(diǎn)移除。

從理論上來講，以上過程跨越了注冊(cè)中心和調(diào)用方以及被調(diào)用方的交互流程，屬于分布式中的事務(wù)問題，即：分布式事務(wù)問題。在之前菜菜的文章中也說過，分布式的事務(wù)要想保證嚴(yán)格的一致性必然會(huì)影響可用性

分布式下，我想要一致性

而且從目前主流的注冊(cè)中心技術(shù)來看，注冊(cè)中心和雙方的通信流程屬于異步流程，所以做不到實(shí)時(shí)的事務(wù)性要求。

目前注冊(cè)中心在通知客戶端變化的方面可以做到近乎于實(shí)時(shí)(其實(shí)并非實(shí)時(shí))，但是在監(jiān)測后端服務(wù)節(jié)點(diǎn)是否可用的過程中，卻很難做到近乎實(shí)時(shí)。其中的原因一是因?yàn)榫W(wǎng)絡(luò)的不可靠特性，一次網(wǎng)絡(luò)通信失敗，并非意味著下次網(wǎng)絡(luò)通信失敗，二是監(jiān)測后端服務(wù)可用的方式并非實(shí)時(shí)的。目前流行的兩種探測后端服務(wù)可用的方式為：

注冊(cè)中心主動(dòng)探測

很多注冊(cè)中心的組件都支持這種方式，在這種方式下，后端的每個(gè)服務(wù)需要提供一個(gè)可供探測的接口或者端口，注冊(cè)中心根據(jù)配置每隔一段時(shí)間去調(diào)用一次服務(wù)的接口或端口，如果返回正常就認(rèn)為服務(wù)處于正常運(yùn)行狀態(tài)，否則則認(rèn)為服務(wù)不可用，不可用的情況下注冊(cè)中心會(huì)主動(dòng)把當(dāng)前服務(wù)移除列表，并通知客戶端。

雖然這種方式看似很完美，其實(shí)還是有坑：

• 注冊(cè)中心在探測的過程中，可能會(huì)由于網(wǎng)絡(luò)問題而出錯(cuò)，但是服務(wù)其實(shí)是在正常運(yùn)行狀態(tài)，也就是說會(huì)產(chǎn)生誤判的結(jié)果，當(dāng)然這種問題，我們可以設(shè)置通過多次探測結(jié)果來確定，而不是通過一次探測結(jié)果就草草確定。
• 如果服務(wù)節(jié)點(diǎn)比較多，注冊(cè)中心相當(dāng)于承受了比較重的探測任務(wù)，會(huì)對(duì)注冊(cè)中心的性能造成一定損失，影響它的可用性。
• 如果服務(wù)是以端口的形式開放探測接口，在服務(wù)較多的情況下可能會(huì)產(chǎn)生端口搶占的情況，畢竟這些服務(wù)可能會(huì)是不同團(tuán)隊(duì)開發(fā)的。

后端服務(wù)主動(dòng)心跳

相比較注冊(cè)中心主動(dòng)探測的模式，我更喜歡使用服務(wù)主動(dòng)上報(bào)心跳的模式。采用心跳的模式大體流程是這樣的：

• 后端的每個(gè)服務(wù)節(jié)點(diǎn)都按照配置(這個(gè)配置可以修改)每隔固定時(shí)間就主動(dòng)向注冊(cè)中心發(fā)送心跳包，至于心跳包的內(nèi)容可以協(xié)商約定，比如有的系統(tǒng)只發(fā)送ping命令，有的會(huì)發(fā)送比較詳細(xì)的服務(wù)狀態(tài)，比如cpu使用率，內(nèi)存使用率等信息，然后注冊(cè)中心就可以根據(jù)這些信息來做更精確的流量分配工作，比如，可以讓資源充沛的服務(wù)節(jié)點(diǎn)承擔(dān)更多的流量。
• 注冊(cè)中心在接收到服務(wù)節(jié)點(diǎn)的心跳包之后，可以以滑動(dòng)窗口的形式給服務(wù)節(jié)點(diǎn)續(xù)約時(shí)間(存活時(shí)間)，只要服務(wù)節(jié)點(diǎn)不停的發(fā)送心跳包，注冊(cè)中心就可以判定這個(gè)節(jié)點(diǎn)一直在正常運(yùn)行。

當(dāng)然這個(gè)流程中也會(huì)有意外情況發(fā)生，比如由于網(wǎng)絡(luò)情況，某個(gè)服務(wù)節(jié)點(diǎn)上報(bào)心跳失敗，但是服務(wù)是在正常運(yùn)行的，這種場景下，最直接的解決方案是：注冊(cè)中心判斷服務(wù)存活的時(shí)間窗口大于上報(bào)時(shí)間間隔即可，比如：心跳上報(bào)時(shí)間是10秒的話，注冊(cè)中心判定服務(wù)不可用的時(shí)間窗口設(shè)置為30秒，既：三次心跳時(shí)間都沒有上報(bào)心跳，就判定服務(wù)不可用。

當(dāng)然以上只是注冊(cè)中心的一個(gè)假設(shè)而已，其實(shí)系統(tǒng)可以結(jié)合主動(dòng)探測的方式來判定服務(wù)是否可用，這樣的話，結(jié)果的正確率會(huì)更高。也就是說：當(dāng)服務(wù)的某個(gè)節(jié)點(diǎn)，超過配置的N次心跳時(shí)間仍然沒有上報(bào)心跳數(shù)據(jù)，注冊(cè)中心可以通過主動(dòng)探測的方式來再次確定服務(wù)是否處于正常運(yùn)行狀態(tài)，當(dāng)然，這在設(shè)計(jì)上增加了一定的復(fù)雜度，需要編寫更多的代碼。

還有一個(gè)不太常見的但是我們需要考慮的場景，假如所有的服務(wù)節(jié)點(diǎn)都因?yàn)榫W(wǎng)絡(luò)異常情況而發(fā)生心跳上報(bào)超時(shí)，而且主動(dòng)探測失敗的情況，按照約定，注冊(cè)中心會(huì)逐步移除所有的節(jié)點(diǎn)信息，這樣造成的后果是系統(tǒng)肯定會(huì)出問題，有的時(shí)候系統(tǒng)設(shè)計(jì)的同時(shí)可以考慮一些保護(hù)措施，比如：當(dāng)節(jié)點(diǎn)信息移除的數(shù)目大于一定比率的時(shí)候，就停止移除操作并且發(fā)送報(bào)警信息，這在一定程度上可以避免注冊(cè)中心無節(jié)點(diǎn)數(shù)據(jù)的情況發(fā)生，當(dāng)然客戶端也可以有這樣的保護(hù)策略。

通知風(fēng)暴

雖然這個(gè)問題在多數(shù)情況下不算是個(gè)問題，但是還是有必要提及一下。當(dāng)注冊(cè)中心隨著項(xiàng)目的升級(jí)承擔(dān)起越來越多的服務(wù)節(jié)點(diǎn)的時(shí)候，服務(wù)間的調(diào)用鏈復(fù)雜度也隨之上升，伴隨而來的是新增一個(gè)節(jié)點(diǎn)可能要通知數(shù)十個(gè)客戶端，移除一個(gè)節(jié)點(diǎn)也會(huì)有類似情況發(fā)生，如果有多個(gè)服務(wù)同時(shí)發(fā)生新增或移除節(jié)點(diǎn)操作，注冊(cè)中心推送的消息將會(huì)更多。這樣的場景下就需要系統(tǒng)設(shè)計(jì)者控制注冊(cè)中心服務(wù)節(jié)點(diǎn)的數(shù)量來避免產(chǎn)生網(wǎng)絡(luò)風(fēng)暴，這個(gè)數(shù)量具體多少可以根據(jù)服務(wù)器的峰值帶寬來確定。

 本文轉(zhuǎn)載自微信公眾號(hào)「 架構(gòu)師修行之路」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 架構(gòu)師修行之路公眾號(hào)。