服務發現【淺談當下】

• 前言
• • 什麼是服務發現
  • 我的服務在哪裡
  • • 非雲環境下的服務發現
    • 基于雲的微服務環境下的服務發現
    • • 服務發現架構
      • 用戶端負載均衡
  • 總結

前言

随着微服務和基于雲的應用程式越來越多，諸如服務發現、服務路由等詞彙也火熱了起來。本篇文章接下來就基于服務發現做一個概述，後續文章将會以具體執行個體（Spring Cloud + Eureka的服務發現模式）描述服務發現的具體實作過程。

什麼是服務發現

在任何分布式架構中，都需要找到機器所在的實體位址，這個過程我們就可以叫服務發現。每當應用程式叼用分布在多個伺服器上的資源，這個應用程式就需要定位這些資源的實體位置。這是啥意思呢？比如說我（用戶端）要去烏鎮旅遊，我早就聽說烏鎮有很多很美的地方我都要去（用戶端請求），但是我不清楚那些地方都具體在烏鎮的哪個方位，于是我問住在桐鄉的小豪（服務代理），小豪于是就拿了一張烏鎮的地圖給我，上面有我想去地方的具體方位（IP和端口），然後我就根據這些具體方位找到了每一個目的地（服務）。

我的服務在哪裡

我們已經知道服務發現無非就是要進行服務位置的解析，那麼實作的方式肯定不止一種，針對不同的環境我們當然可以選擇不同的方式。接下來就給大家介紹目前兩種環境下的普遍服務發現方式：

非雲環境下的服務發現

在非雲的環境中，我們實作服務發現的方式通常是由DNS（Domain Name Serveice）和網絡負載均衡器的組合來解決的。其工作原理如下圖所示：

① 用戶端通過使用通用的DNS名稱以及唯一的服務路徑來調用目标服務，DNS名稱會被解析到一個負載均衡器。

②負載均衡器在接收到來自用戶端的請求時，會根據服務消費者嘗試通路的路徑，在路由表中定位服務實體位址條目。

③路由表條目包含了托管了目标服務的一個或多個伺服器清單，然後負載均衡器會選擇清單中的一個伺服器，将請求轉發到該伺服器上。

PING：輔助負載均衡器平時會處于空閑狀态，主要負責ping主負載均衡器以檢視它是否處于存活狀态。如果主負載均衡器出現了狀況，未處于存活狀态，那麼輔助負載均衡器将變為存活狀态，接管主負載均衡器的IP位址并開始提供請求。實作高可用性。

這種模型适用于在啟業資料中心内部運作的應用程式，以及服務較少的情況，但對基于雲的微服務應用程式來說，就顯得捉襟見肘了。那麼在需要處理大量事務和備援的雲環境中，我們該如何為其實作一個合适且健壯的服務發現機制呢？

基于雲的微服務環境下的服務發現

在目前的大環境下，基于雲的微服務環境的解決方案是使用服務發現機制。至于為什麼，接下來我本文将繼續介紹服務發現架構，然後根據它的特點來總結它之是以成為雲的微服務環境趨勢的原因：

服務發現架構

開始讨論服務發現架構之前，有4個概念我們是必須要了解的，這些概念在所有服務發現實作中是共通的：

1.服務注冊——服務如何使用服務發現代理進行注冊？

2.服務位址的用戶端查找——服務用戶端查找服務資訊的方法是什麼?

3.資訊共享——如何跨節點共享服務資訊？

4.健康監測——服務如何将它的健康資訊傳回給服務發現代理？

下圖展示了這四個概念的流程，以及在服務發現模式中通常會發生的情況。

當服務執行個體啟動的時候，服務A中的服務執行個體将通過一個或多個服務發現執行個體（也就是服務發現層的服務發現節點）來注冊它們可以通路的實體位置路徑和端口。每個服務執行個體都具有唯一的IP和端口，但是每個服務執行個體都将以相同的服務ID進行注冊。服務ID是唯一辨別一組相同服務執行個體的鍵。

服務通常隻在一個服務發現執行個體中進行注冊。但每個服務執行個體的資料都被會被傳遞到服務發現叢集中的所有其他節點。每個服務執行個體将通過服務發現服務去推送服務執行個體的狀态，或者服務發現服務從服務執行個體去拉取狀态。如果檢查到服務處于非健康狀态将從可用的服務執行個體池中删除（上圖示×）。

服務在向服務發現服務進行注冊之後，這個服務就可以被需要使用這項服務功能的應用程式或者其它服務使用。用戶端每次調用服務，就隻依賴于服務發現引擎來解析服務位置。

用戶端負載均衡

正如上面所說的這種服務發現方式，用戶端完全依賴于服務發現引擎來查找和調用服務，每次調用注冊的微服務執行個體時，服務發現引擎就會被調用。這種方法就顯得較為脆弱了，是以有了接下來要介紹的用戶端負載均衡模式來實作服務發現過程。模式如下圖：

在這個模型中，當服務消費者需要調用一個服務時：

1.它将聯系服務發現服務，擷取它請求的所有服務執行個體，然後在服務消費者的機器上本地緩存資料。

2.每當用戶端需要調用該服務時，服務消費者将從緩存中查找該服務的位置資訊。

3.然後，用戶端将頂起與服務發現服務進行聯系，并重新整理服務執行個體的緩存。用戶端緩存最終是一緻的，但這樣始終會存在這樣的風險：在用戶端聯系服務發現執行個體以進行重新整理和調用時，調用可能會被定向到不健康的服務執行個體上。

如果在調用服務的過程中，服務調用失敗，那麼本地的服務發現緩存失效，服務發現用戶端将嘗試從服務發現代理重新整理資料。

總結

上面我們介紹了在非雲環境下的服務發現方式（DNS+網絡負載均衡器），以及基于雲的微服務環境下的服務發現機制（服務發現架構，用戶端負載均衡），通過了解我們可以總結出在基于雲的微服務環境下使用服務發現機制有以下特點：

1.高可用——服務發現支援叢集環境，在服務發現叢集中可以跨多個節點共享服務查找。如果一個節點變得不可用，叢集中的其他節點應該能夠接管工作。

2.點對點——服務發現叢集中的每個節點共享服務執行個體狀态。

3.負載均衡——服務發現需要在所有服務執行個體之間動态的請求進行負載均衡，以確定服務調用分布在由它管理的所有服務執行個體上。

4.有彈性——服務發現的用戶端在本地“緩存”服務資訊。這樣，如果服務發現服務變得不可用，應用程式仍然可以基于本地緩存中維護的資訊來運作和定位服務。

5.容錯——服務發現需要檢測出服務執行個體什麼時候時不健康的，并從可以接收用戶端請求的可用服務清單中移除該執行個體。服務發現應該在沒有人為幹預的情況下，對這些故障進行檢測，并采取行動。

在下篇文章中，将詳細介紹Spring Cloud + Eureka的服務發現模式，敬請期待！