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

傳統的客戶端和服務端的交互模式?

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

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

服務發現模式?

大概流程?

其實所謂的服務發現，就是服務消費者在調用服務提供者提供的服務的時候，多了一層「服務中介」。服務中介中有很多key/value鍵值對，key是「服務名稱」，value是「服務提供者的地址列表」。「當你新增一個服務提供者的時候，就往服務中介中寫入kv數據，這個過程叫做服務注冊」 「當你請求一個服務的時候，直接拿著key去服務中介中取對應的value，也就是服務提供者的地址列表，然后去請求就可以了。」

當服務提供者節點掛掉時，要求服務能夠及時取消注冊，比便及時通知消費者重新獲取服務地址。

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

基本過程如下圖

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

服務發現是否太過簡單？?

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

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

這個不用擔心，服務發現中引入「服務保活和檢查機制」，并更換數據結構。服務提供者需要每隔5秒左右向服務發現匯報存活，服務發現將服務地址和匯報時間記錄在kv中。服務中介需要每隔10秒左右檢查kv數據結構，踢掉匯報時間嚴重落后的服務地址項。這樣就可以準實時地保證服務列表中服務地址的有效性。這也就是我們說的「服務健康檢查」

服務列表變動時如何通知消費者?

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

常見的服務發現方案?

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

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