美團(tuán)面試：如何設(shè)計(jì)一個(gè)注冊(cè)中心？
大家好，我是田哥
在前面，已經(jīng)跟大家分享過我去美團(tuán)面試中遇到的一些題目，對(duì)此我也把這些題目進(jìn)行了一系列分析。
文末文章有清單
今天，給大家分享如何設(shè)計(jì)一個(gè)注冊(cè)中心。
不管是出于面試，還是深入學(xué)習(xí)注冊(cè)中心，關(guān)于如何設(shè)計(jì)一個(gè)注冊(cè)中心都是一個(gè)很好的話題。
假設(shè)現(xiàn)在我們系統(tǒng)有兩個(gè)小系統(tǒng)：
訂單系統(tǒng) 商品系統(tǒng)
單個(gè)系統(tǒng)分別部署在不同服務(wù)器上，如果我們訂單系統(tǒng)需要調(diào)用商品系統(tǒng)的某個(gè)服務(wù)：
怎么調(diào)用？
方法1：商品系統(tǒng)開發(fā)的朋友告訴你對(duì)應(yīng)的地址。
方法2：商品系統(tǒng)開發(fā)的朋友把對(duì)應(yīng)API地址存放到某個(gè)地方。
方法3：直接通過Nginx，使用域名進(jìn)行轉(zhuǎn)發(fā)到某個(gè)實(shí)例上。
這時(shí)候，訂單系統(tǒng)就可以通過上述方法調(diào)用商品系統(tǒng)的API了。
問題來了
實(shí)際線上環(huán)境中，很少是單體機(jī)構(gòu)的，很多都是做了集群的，也就是說每個(gè)服務(wù)會(huì)有N個(gè)實(shí)例，少則幾個(gè)幾十個(gè)，多則幾百上千上萬。如果此時(shí)我們還用上面三種方法，當(dāng)我們的商品系統(tǒng)某個(gè)服務(wù)下線（宕機(jī)了），或者新增實(shí)例，此時(shí)是非常的頭疼。
所以，注冊(cè)中心就來了。
注冊(cè)中心來了
我們能不能搞一個(gè)第三方的節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)就用來存放我們商品系統(tǒng)的服務(wù)信息，這樣一來，其他系統(tǒng)需要服務(wù)信息，直接去第三方節(jié)點(diǎn)上去獲取即可。此時(shí)，其他系統(tǒng)只要知道這個(gè)第三方的節(jié)點(diǎn)地址就可以了。這個(gè)第三方的節(jié)點(diǎn)，我們也稱之為注冊(cè)中心。
下面我們用服務(wù)提供方（商品系統(tǒng)）稱之為provider，服務(wù)調(diào)用方（訂單系統(tǒng)）我們稱之為consumer。
如何設(shè)計(jì)一個(gè)注冊(cè)中心
我們需要解決如下幾個(gè)問題：
服務(wù)如何注冊(cè) consumer如何知道provider 服務(wù)注冊(cè)中心如何高可用 服務(wù)上下線，消費(fèi)端如何動(dòng)態(tài)感知
服務(wù)注冊(cè)
當(dāng)我們把服務(wù)信息注冊(cè)上去后，就應(yīng)該是：
服務(wù)列表保存通常有三種方式：本地內(nèi)存、數(shù)據(jù)庫、第三方緩存系統(tǒng)
注冊(cè)上去后，consumer需要服務(wù)地址的時(shí)候，就可以用相應(yīng)key去注冊(cè)中心獲取對(duì)應(yīng)的服務(wù)列表。
同一個(gè)服務(wù)注冊(cè)中心，我們可以注冊(cè)多個(gè)服務(wù)，比如用戶服務(wù)、商品服務(wù)、訂單服務(wù)...
服務(wù)消費(fèi)
consumer端通過key獲取指定的服務(wù)地址列表。
以上的還是蠻簡單的吧，簡單來說，我們就是引用了一個(gè)第三方的服務(wù)來存放我們的服務(wù)提供者列表。并且以key-value的形式存儲(chǔ)，key我們可以理解為服務(wù)名稱，value就是服務(wù)實(shí)例列表。
注冊(cè)中心高可用
高可用無非就是做集群，我們可以對(duì)注冊(cè)中心部署多個(gè)節(jié)點(diǎn)。在消費(fèi)端consumer只需要知道一個(gè)服務(wù)注冊(cè)中心集群地址cluster-url即可。
動(dòng)態(tài)感知服務(wù)上下線
consumer拿到服務(wù)列表后，會(huì)把服務(wù)列表保存起來，保存到本地緩存里。
consumer通過一定的負(fù)載均衡算法，選擇出一個(gè)地址，最后發(fā)起遠(yuǎn)程的調(diào)用。
如果我們的服務(wù)節(jié)點(diǎn)掛掉一個(gè)了，怎么辦？
此時(shí)，服務(wù)注冊(cè)中心的服務(wù)列表還是之前的列表，如果consumer調(diào)用到過掉的節(jié)點(diǎn)上，那豈不是會(huì)出問題呀。
所以，我們的服務(wù)注冊(cè)中心需要知道哪個(gè)服務(wù)節(jié)點(diǎn)掛了，然后從對(duì)應(yīng)服務(wù)列表里刪除。
有種辦法叫做心跳檢測heartBeat，即就是服務(wù)注冊(cè)中心，每隔一定時(shí)間去監(jiān)測一下provider，如果監(jiān)測到某個(gè)服務(wù)掛了，那就把對(duì)應(yīng)服務(wù)地址從服務(wù)列表中刪除。
根據(jù)心跳檢測，來提出無效服務(wù)。
可是不對(duì)呀，此時(shí)consumer端本地列表里還有過掉的服務(wù)地址，怎么辦呢？
或者是，在增加一個(gè)新的服務(wù)節(jié)點(diǎn)
對(duì)于服務(wù)注冊(cè)中心來說，就是服務(wù)列表里增加一個(gè)服務(wù)地址。
但是在消費(fèi)端存在同樣的問題，就是服務(wù)注冊(cè)中心的服務(wù)列表和consumer端的服務(wù)列表不一樣了。
如何讓consumer端也動(dòng)態(tài)感知呢？
其實(shí)很簡單，此時(shí)，我們得思維換一下，因?yàn)閏onsumer的服務(wù)列表是來自于服務(wù)注冊(cè)中心，我們就可以把consumer理解為消費(fèi)端，服務(wù)注冊(cè)中心理解為服務(wù)端。此時(shí)，consumer端就可以去服務(wù)端（服務(wù)注冊(cè)中心）拉取provider服務(wù)列表。
通常有兩種方案：push和pull
push：服務(wù)注冊(cè)中心主動(dòng)推送服務(wù)列表給consumer。 pull：consumer主動(dòng)從注冊(cè)中心拉取服務(wù)列表。
不管是push還是pull，都會(huì)存在consumer和服務(wù)注冊(cè)中心的通信管道。如果他們之間斷開了，那就無法獲取服務(wù)列表了。
還有就是服務(wù)注冊(cè)中心知道consumer的地址，比如
我得知道你的微信好友，不然我怎么把我手里的資源發(fā)給你
我們的網(wǎng)絡(luò)通信，必然會(huì)存在監(jiān)聽的動(dòng)作。
如果服務(wù)注冊(cè)中心要push到consumer，此時(shí)他們之間需要建立一個(gè)會(huì)話，所以，在服務(wù)注冊(cè)中心會(huì)維護(hù)一個(gè)會(huì)話管理的模塊。還有一種方式就是consumer提供一個(gè)API，這個(gè)API給服務(wù)注冊(cè)中心進(jìn)行回調(diào)。
本質(zhì)是我們是使用HTTP協(xié)議還是使用Socket監(jiān)聽
push有個(gè)不好點(diǎn)，那就是服務(wù)注冊(cè)中心需要維護(hù)大量的會(huì)話，而且還需要對(duì)每個(gè)會(huì)話維持一個(gè)心跳，一遍知曉這些會(huì)話狀態(tài)，得確保這些consumer能收到數(shù)據(jù)，
另外就是pull，pull其實(shí)就相對(duì)push就簡單多了。pull和我們前面說的心跳機(jī)制是類似的，consumer端啟動(dòng)定時(shí)任務(wù)，每個(gè)多久拉取服務(wù)注冊(cè)中心的服務(wù)列表。pull也不需要去維護(hù)大量的會(huì)話，我只需要每隔多久調(diào)用接口拉取服務(wù)列表即可。但是這里還是會(huì)存在一個(gè)問題，因?yàn)槭嵌〞r(shí)去拉取，所以會(huì)存在一定的數(shù)據(jù)延遲，比如consumer剛剛拉取服務(wù)列表，但就在拉取結(jié)束的后，某個(gè)服務(wù)provider掛了，consumer就要等下次拉取才知道對(duì)應(yīng)服務(wù)provider掛了。
如果定時(shí)任務(wù)是每隔30秒拉去一次，那就是說，延遲最長時(shí)間是30秒。
還有一種方式long-pull，也叫長輪詢，是上面兩種方案的優(yōu)化方案，consumer發(fā)起拉取請(qǐng)求時(shí)，先把這個(gè)請(qǐng)求hold住，當(dāng)服務(wù)注冊(cè)中心有發(fā)生變化后，consumer端能立馬感知。
關(guān)于長輪詢：
與簡單輪詢相似，只是在服務(wù)端在沒有新的返回?cái)?shù)據(jù)情況下不會(huì)立即響應(yīng)，而會(huì)掛起，直到有數(shù)據(jù)或即將超時(shí)
優(yōu)點(diǎn)：實(shí)現(xiàn)也不復(fù)雜，同時(shí)相對(duì)輪詢，節(jié)約帶寬
缺點(diǎn)：還是存在占用服務(wù)端資源的問題，雖然及時(shí)性比輪詢要高，但是會(huì)在沒有數(shù)據(jù)的時(shí)候在服務(wù)端掛起，所以會(huì)一直占用服務(wù)端資源，處理能力變少
應(yīng)用：一些早期的對(duì)及時(shí)性有一些要求的應(yīng)用：web IM 聊天
這樣，我們就搞定了所謂的服務(wù)上下線動(dòng)態(tài)感知。
通過上面的服務(wù)注冊(cè)、服務(wù)消費(fèi)、注冊(cè)中心高可用以及動(dòng)態(tài)感知服務(wù)的上下線，這就是我們?nèi)?shí)現(xiàn)一個(gè)服務(wù)注冊(cè)中心的通用模型。
小總結(jié)
關(guān)于如何設(shè)計(jì)一個(gè)注冊(cè)中心，無非重點(diǎn)關(guān)以下幾點(diǎn)：
服務(wù)是如何注冊(cè) 消費(fèi)端如何獲取服務(wù) 如何保證注冊(cè)中心的高可用 動(dòng)態(tài)感知服務(wù)的上下線
推薦閱讀：
歡迎關(guān)注微信公眾號(hào)：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價(jià)值的信息。