微服務理論與實踐-服務註冊與發現
1 背景
- 服務的客戶端（包括API網關或者其他服務）如何獲取服務端實例的位置
- 每個服務端實例都會在特定的位置（主機及端口）通過HTTP/REST或者Thrift等方式發佈一個遠程API
- 服務端實例的具體數量和位置會發生動態變化
- 虛擬機與容器通常會被分配動態IP地址
2 方案
2.1 客戶端服務發現
向某一服務發送請求時，客戶端會通過查詢Servcie Registry，即服務註冊表來回去該服務的具體位置/該註冊表包含全部服務的位置。
2.2 客戶端服務發現的優缺點
優點
- 相比服務端發現，客戶端服務發現的活動部件與網絡中轉數量更少。
缺點
- 需要爲應用程序中使用的每種語言建立客戶端發現邏輯
2.3 服務端服務發現
向某一服務發送請求時，客戶端會通知在已知位置的路由器（或者負載均衡器）發送請求。路由器會訪問服務註冊表，並向可用的服務實例轉發該請求。服務註冊表也可能被內建於路由器之中。
2.4 服務端發現的優缺點
優點
- 相較客戶端發現，其客戶端代碼無需實現服務發現功能，只需要向路由機制發送請求即可。
缺點
除非成爲雲環境的一部分，否則該路由機制必須作爲另一個系統組件進行安裝與配置。爲實現可用性和一定的接入能力，還需要爲其配置一定數量的副本。
相較於客戶端發現，服務端發現需要更多的網絡跳轉
3 服務註冊表
3.1 背景
服務的客戶端需要使用客戶端發現機制或者服務端發現機制，獲取需要發送請求的服務實例的位置
每個服務實例都會在特定位置（主機與端口）通過HTTP/REST或者Thrift等方式發佈一個遠程API。
- 服務實力的數量和位置會動態的發生變化。虛擬機與容器通常會被分配一個動態的IP地址。
3.2 方案
建立一套服務註冊表。即一個包括服務、服務的實例和起位置的數據庫。各服務示例需要在啓動時註冊至服務註冊表，並在關閉的時候進行註銷。該服務的客戶端或者路由器通過查詢此服務註冊表獲取可用的服務實例
3.3 服務註冊表模式的優缺點
優點
- 服務的客戶端及路由器可以獲取可用的服務實例的位置
缺點
除非服務註冊表被內置於基礎設施，否則其必須做爲另外的基礎設施組件進行安裝，配置及管理。
需要解決各服務示例如何註冊至註冊表，如何從註冊表中註銷
3.4 服務註冊表的註冊方式
3.4.1 需求
各服務實例必須在啓動時註冊到服務註冊表，並在關閉時從服務註冊表中註銷
崩潰的服務實例必須從服務註冊表中註銷
- 在運行但無力處理請求的服務實例必須從服務註冊表中註銷
3.4.2 方案
3.4.2.1 自注冊
一項服務實例必須可以自動註冊到服務註冊表中。在啓動時，該服務實例將自身（主機與IP地址）註冊至服務註冊表，使自身可被發現。客戶端必須定期更新其註冊信息，確保註冊表獲悉其仍處於運行狀態。在關閉時，服務實例從服務註冊表中自動註銷。這一流程通常由微服務底盤框架實現。
3.4.2.2 自注冊的優缺點
優點
- 服務實例瞭解自身的狀態，因而能夠實現比啓動/停止更爲負責的狀態模型。
缺點
- 將服務與註冊表耦合起來
- 需要爲編寫服務時使用的每種語言分別實現服務註冊邏輯。
- 正在運行但無法處理請求的服務示例往往無法自動在服務註冊表中進行自我註銷
3.4.2.3 第三方註冊
由第三方負責將服務和服務實例在服務註冊表中的註冊，並在服務啓動的時候將服務實例註冊到服務註冊表。而在服務實例關閉的時候在服務註冊表中註銷
3.4.2.4 第三方註冊的優缺點
優點
- 與自注冊相比，服務端無需實現自動註冊邏輯，複雜度較低
- 註冊工具可以對服務進行健康檢查，並根據健康檢查註冊或者註銷該實例
缺點
- 第三方註冊只能瞭解服務實例的一些表層狀態，例如其是否正在運行，並不能判斷正在運行的服務是否能夠處理請求
- 除非該註冊工具屬於基礎設施的一部分，否則我們需要對其進行安裝、配置及維護。由於其屬於關鍵部件，需要保證其高可用。