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

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

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

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

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

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

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

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

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

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

注冊中心的作用

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

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

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

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

負載均衡

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

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

那些坑

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

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

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

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

分布式下，我想要一致性

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

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

注冊中心主動探測

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

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

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

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

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

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

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

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

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

通知風(fēng)暴

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

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