微服務(wù)在當(dāng)今的互聯(lián)網(wǎng)架構(gòu)中的重要性我在這里就不多說了，隨著微服務(wù)的大范圍應(yīng)用，「服務(wù)發(fā)現(xiàn)」這個詞也變的越來越火熱。在平時的工作中，我發(fā)現(xiàn)現(xiàn)在很多人喜歡把一些很簡單的事情說的很復(fù)雜，比如什么BFF架構(gòu)，這中臺那中臺的。其實服務(wù)發(fā)現(xiàn)也是一樣，很多文章把這塊內(nèi)容寫的過于妖魔化，導(dǎo)致很多人看起來云里霧里的感覺好像很高深的樣子，接下來就放棄這塊了。「其實服務(wù)發(fā)現(xiàn)是個很簡單的過程」，稍微有點編碼基礎(chǔ)的人都能看懂。

傳統(tǒng)的客戶端和服務(wù)端的交互模式?

• 服務(wù)端1 2 3  分別提供了一個服務(wù)的「ip」和「端口號」
• 這里的客戶端不是咱們狹義理解的客戶端app或者前端，客戶端也可以是一個服務(wù)端，比如你在一個golang項目中需要不同的服務(wù)等，那么你這個golang項目就是上圖中的客戶端，這一點尤其要注意。
• 如果說的準確一點，這里的客戶端應(yīng)該叫做「服務(wù)消費者」,服務(wù)端應(yīng)該叫做「服務(wù)提供者」

上面這種傳統(tǒng)的交互模式看著沒什么問題，但是其實可用性并沒那么好，首先比如你的服務(wù)端2掛了，但是客戶端還是不知道的，依然會繼續(xù)請求，這樣可用性當(dāng)然是大大的下降的，所以接下來就引發(fā)出了我們接下來要講的「服務(wù)發(fā)現(xiàn)」模式

服務(wù)發(fā)現(xiàn)模式?

大概流程?

其實所謂的服務(wù)發(fā)現(xiàn)，就是服務(wù)消費者在調(diào)用服務(wù)提供者提供的服務(wù)的時候，多了一層「服務(wù)中介」。服務(wù)中介中有很多key/value鍵值對，key是「服務(wù)名稱」，value是「服務(wù)提供者的地址列表」?！府?dāng)你新增一個服務(wù)提供者的時候，就往服務(wù)中介中寫入kv數(shù)據(jù)，這個過程叫做服務(wù)注冊」 「當(dāng)你請求一個服務(wù)的時候，直接拿著key去服務(wù)中介中取對應(yīng)的value，也就是服務(wù)提供者的地址列表，然后去請求就可以了?！?/p>

當(dāng)服務(wù)提供者節(jié)點掛掉時，要求服務(wù)能夠及時取消注冊，比便及時通知消費者重新獲取服務(wù)地址。

當(dāng)服務(wù)提供者新加入時，要求服務(wù)中介能及時告知服務(wù)消費者，你要不要嘗試一下新的服務(wù)。

基本過程如下圖

• 步驟1:每次新增加一個服務(wù)提供者，需要先去服務(wù)注冊中心注冊一個key/value（服務(wù)名稱/服務(wù)提供者的地址列表）
• 步驟2:服務(wù)調(diào)用者不直接調(diào)用服務(wù)提供者，而是拿著標(biāo)志(也就是上面注冊的key(服務(wù)名稱))去服務(wù)注冊中心查找對應(yīng)的value(服務(wù)提供者的地址列表)
• 步驟3:服務(wù)注冊中心會告訴服務(wù)調(diào)用者對應(yīng)的key(服務(wù)名稱)是否有value(服務(wù)提供者的地址列表)，有的話會把對應(yīng)的value(服務(wù)提供者的地址列表)返回給服務(wù)調(diào)用者
• 步驟4:服務(wù)調(diào)用者會拿著返回的value(服務(wù)提供者的地址列表)去請求對應(yīng)的服務(wù)

服務(wù)發(fā)現(xiàn)是否太過簡單？?

上面的過程看起來好像是有點太簡單了，而且看起來也沒解決什么問題呀，而且好像還徒增了復(fù)雜度。其實并不是這樣的。

服務(wù)提供者進程如果被kill -9暴力殺死，服務(wù)消費者不知道怎么辦？

這個不用擔(dān)心，服務(wù)發(fā)現(xiàn)中引入「服務(wù)?；詈蜋z查機制」，并更換數(shù)據(jù)結(jié)構(gòu)。服務(wù)提供者需要每隔5秒左右向服務(wù)發(fā)現(xiàn)匯報存活，服務(wù)發(fā)現(xiàn)將服務(wù)地址和匯報時間記錄在kv中。服務(wù)中介需要每隔10秒左右檢查kv數(shù)據(jù)結(jié)構(gòu)，踢掉匯報時間嚴重落后的服務(wù)地址項。這樣就可以準實時地保證服務(wù)列表中服務(wù)地址的有效性。這也就是我們說的「服務(wù)健康檢查」

服務(wù)列表變動時如何通知消費者?

第一種方法是「輪詢」，消費者需要每隔幾秒查詢服務(wù)列表是否有改變。如果服務(wù)很多，服務(wù)列表很大，消費者很多，那么服務(wù)發(fā)現(xiàn)也會有一定的壓力 第二種方法是「訂閱消費模式」，服務(wù)消費者訂閱一個消息，服務(wù)提供者有變動直接往消息中發(fā)送對應(yīng)變化就行。

常見的服務(wù)發(fā)現(xiàn)方案?

• - DNS
• - mDNS
• - Zookeeper
• - Etcd
• - Consul

具體方案大概了解一下就行，后面我們會詳細介紹一下「Consul」，那么我們下期再見吧。如果這篇文章有幫助到你，