服務發現的幾種模式介紹

微服務架構下服務實例具有動態分配的網絡地址，隨着服務的自動擴展、故障和發布升級，導致服務實例的網絡地址發生動態變更。因此，需要一種機制，支持服務消費者在服務提供者實例地址發生變更時，能夠及時感知獲取實例最新的地址，即服務發現機制。

 

服務發現的介紹

 

服務發現的概念是隨着計算機體系結構的發展而演變的舊概念。網絡時代初期，不同的計算機需要相互定位，這是通過一個全球文本文件HOSTS.TXT完成的。因為不經常添加新主機，所以手動維護文件的地址列表。隨着互聯網的發展，主機的增加速度越來越快，需要一個自動化，可擴展性的更強系統，從而導致了DNS的發明和廣泛采用。

 

現在，微服務架構正在推動服務發現的不斷發展。隨着容器化平台或雲平台的不斷普及，基於平台的微服務架構部署，服務的生命周期以秒和分鍾來衡量。同時，因為微服務的自動擴展、故障和發布升級，導致微服務具有動態變化的地址列表，微服務的靈活性再次推動了服務發現技術的發展。現代基於容器化平台或雲平台的微服務應用程序，需要解決服務地址動態變化的問題。

如上圖所示，服務實例的地址動態變化，對於客戶端而言，手工維護服務實例地址列表的方式已經不能滿足需求，而使用服務發現模式動態更新維護服務實例地址列表是目前微服務架構下使用的必備技術。

 

微服務的兩種主要服務發現模式

 

目前微服務的服務發現機制主要包含三個角色：服務提供者、服務消費者和服務注冊表

 

• 服務提供者（Service Provider）：服務啟動時將服務信息注冊到服務注冊表，服務退出時將服務注冊表的服務信息刪除掉。

• 服務消費者（Service Consumer）：從服務注冊表獲取服務提供者的最新網絡位置等服務信息，維護與服務提供者之間的通信。

• 服務注冊表（Service Registry）：聯系服務提供者和服務消費者的橋梁，維護服務提供者的最新網絡位置等服務信息。
  

服務發現機制的關鍵部分是服務注冊表（Service Registry）。服務注冊表提供管理和查詢服務注冊信息的API。當服務提供者的實例發生變更時（新增/刪除服務），服務注冊表需要通知服務消費者同步最新的服務實例地址列表。目前大多數的微服務框架使用Netflix Eureka、Etcd、Consul或Apache Zookeeper等作為服務注冊表。 

為了說明服務發現模式是如何解決微服務實例地址動態變化的問題，下面介紹兩種主要的服務發現模式：客戶端發現模式和服務端發現模式。

2.1. 客戶端發現模式

使用客戶端發現模式，客戶端負責確定服務提供者的可用實例地址列表和負載均衡策略。客戶端訪問服務注冊表，定時同步目標服務的實例地址列表，然后基於負載均衡算法選擇目標服務的一個可用實例地址發送請求。

 

上圖所示客戶端服務發現包含自注冊和客戶端發現兩個部分：

 

1. 自注冊：服務實例調用服務注冊表的注冊接口進行實例地址注冊。服務實例還可以提供服務運行狀況檢查接口，服務注冊表定期訪問接口檢查服務實例是否健康和處理請求。服務注冊表可能要求服務實例定期調用“心跳”API以防止服務實例注冊過期。

2. 客戶端發現：當服務客戶端調用目標服務時，它會查詢服務注冊表以獲取服務實例地址列表。為了提高性能，客戶端緩存服務實例地址列表。然后，服務客戶端使用負載均衡算法（如循環或隨機）來選擇服務實例發送請求。
   
   

微保的第2代微服務框架（MSF）的服務發現實現就是客戶端發現模式的一個例子。其中Etcd是一個服務注冊表，它是一個強一致性鍵值數據存儲的分布式系統，它提供了REST APIs，用於管理服務實例注冊和查詢服務實例地址列表。MSF SDK是一個微服務SDK，它提供了服務注冊功能，支持定期續租服務注冊信息。它提供了服務發現功能，訪問服務注冊表同步並緩存目標服務的實例地址列表，支持基於負載均衡策略選擇可用的目標服務並發送請求。 

 

優點：

• 通常是服務客戶端查詢目標服務的實例地址列表之后，執行負載均衡算法選擇可用的目標服務。優點是服務客戶端可以靈活、智能地制定負載均衡策略，包括輪詢、加權輪詢、一致性哈希等策略。

• 可以實現點對點的網狀通訊，即去中心化的通訊。可以有效避開單點造成的性能瓶頸和可靠性下降等問題。

• 服務客戶端通常以SDK的方式直接引入到項目，這種方式語言的整合程度最佳，程序執行性能最佳，程序錯誤排查更加容易。
  
  

缺點：

• 服務客戶端與服務注冊表耦合。需要為服務客戶端使用的每種編程語言和框架實現客戶端服務發現邏輯。

• 服務客戶端通常以SDK方式使用服務發現功能。這種侵入式方案存在於應用程序的所有客戶端，如果客戶端服務發現功能需要進行更新，要求所有的應用程序重新編譯，部署服務。微服務的規模越大，服務更新越困難，這在一定程度上違背了微服務架構提倡的技術獨立性。

 

2.2. 服務端發現模式

使用服務端發現模式，服務客戶端通過路由器（或者負載均衡器）訪問目標服務。路由器負責查詢服務注冊表，獲取目標服務實例的地址列表轉發請求。

 

 

上圖所示服務端服務發現包含第三方注冊和服務端發現兩個部分：

 

1. 第三方注冊：這種方式不是服務客戶端向服務注冊表注冊服務，而是通過一個注冊處理器處理服務注冊（通常是部署平台的一部分）。

2. 服務端發現：這種方式不是服務客戶端查詢服務注冊表，而是發送請求給路由器（或者負載均衡器），路由器查詢服務注冊表獲取目標服務的實例地址列表，使用負載均衡算法（如循環或隨機）選擇可用的服務實例轉發請求。

    

現代容器化部署平台（如Docker和Kubernetes）就是服務端服務發現模式的一個例子，這些部署平台都具有內置的服務注冊表和服務發現機制。容器化部署平台為每個服務提供路由請求的能力。服務客戶端向路由器（或者負載均衡器）發出請求，容器化部署平台自動將請求路由到目標服務一個可用的服務實例。因此，服務注冊，服務發現和請求路由完全由容器化部署平台處理。

優點：

• 部署平台提供服務發現功能，負責處理服務發現的所有方面。因此，無論使用任何語言，所有的服務提供者和消費者都可以輕松地使用服務發現機制。

• 服務發現功能對於服務客戶端而言是透明的，因此，服務發現功能的相關更新對於服務客戶端是無感知的。
  
  

缺點：

• 部署平台的服務發現功能僅支持發現使用該平台部署的服務。例如，基於Kubernetes 的服務發現僅適應於在Kubernetes上部署運行的服務。

• 服務的架構增加了一次轉發，延遲時間會增加。整個系統增加了一個故障點，系統的運維難度增加。最關鍵的是負責轉發請求的路由器或者負載均衡器可能變成性能的瓶頸。

• 微服務的一個目標是故障隔離，將整個系統切割為多個服務共同運行，如果某服務無法正常運行，只會影響到整個系統的相關部分功能，其它功能能夠正常運行，即去中心化。然而，服務端發現模式實際上是集中式的做法，如果路由器或者負載均衡器無法提供服務，那么將導致整個系統癱瘓。

 

Service Mesh微服務架構的服務發現模式

3.1. Service Mesh 介紹

Service Mesh服務網格是服務於微服務應用程序的可配置基礎設施層，旨在處理服務之間的大量基於網絡的進程間通信。服務網絡確保服務之間的通信靈活、可靠、快速和安全。服務網格提供的關鍵功能包括服務發現、負載平衡、加密、可觀察性、可追溯性、熔斷、身份驗證和授權等。

 

服務網格通過為每個服務實例提供稱為sidecar的代理實例來實現。Sidecars負責處理服務間通信、監控和安全相關等所有從各個服務抽象出來的功能。這樣，開發人員負責業務服務的開發、支持和維護；運營團隊負責維護服務網格並運行業務服務。

3.2. 客戶端發現模式

服務網格提供的服務發現功能是客戶端服務發現模式的一種升級實現，該功能基於sidecar和pilot實現。Sidecars，即數據面板（Data Plane），負責發現目標服務實例地址列表並轉發請求。Pilots，即控制面板（Control Plane），負責管理服務注冊表的所有服務注冊信息。

上圖所示客戶端服務發現包含自注冊和客戶端發現兩個部分：

 

1. 自注冊：Sidecar實例，而不是服務本身，負責調用服務注冊表的注冊接口進行實例地址注冊；負責定期調用“心跳”API以續租服務實例注冊信息。

2. 客戶端發現：Sidecar實例負責與控制面板之間基於雙向流式實時同步服務數據。當服務客戶端發送請求時，負責轉發請求的Sidecar實例查詢本地緩存的目標服務實例地址列表，基於負載均衡算法選擇一個可用的實例地址轉發請求。

    

微保的第3代微服務框架的服務發現實現就是Service Mesh微服務架構下服務發現模式的一個例子。其中Pilots負責對接服務注冊表，緩存所有注冊的服務信息，實時感知服務注冊信息的變更，更新本地緩存，實時推送變更數據給所有訂閱的Sidecars。Sidecars負責對接服務注冊表提供服務注冊功能，負責對接Pilots提供服務發現功能。

 

Service Mesh微服務架構下服務發現模式是客戶端發現模式的一種升級模式，它保持了常規客戶端發現模式的優點，解決了客戶端發現模式的缺點:

• Sidecars可以靈活、智能地制定負載均衡策略，包括輪詢、加權輪詢、一致性哈希等策略。實現點對點的去中心化的通訊，可以有效避開單點造成的性能瓶頸和可靠性下降問題。

• 通過Sidecars，業務服務不需要關注服務注冊、服務發現功能，不需要關注服務之間的通訊以及微服務治理等基本能力。通過Pilots，服務消費者的客戶端與服務注冊表解耦，支持對接不同的服務注冊表。兩者的組合真正意義上實現了跨語言能力，解耦了業務代碼和微服務基礎框架，而且能夠實現業務無感知的情況下升級微服務新特性。

 

總結

 

微服務架構模式下，服務實例具有動態分配的網絡地址，為了滿足服務客戶端向服務提供者發送請求，必須使用服務發現機制。

服務發現的關鍵部分是服務注冊表。服務注冊表提供管理和查詢服務注冊信息的API。可以使用Netflix Eureka、Etcd、Consul或Apache Zookeeper等服務注冊表搭建服務發現基礎設施。

微服務架構主要包括兩種服務發現模式：客戶端發現和服務端發現。客戶端發現模式，客戶端負責查詢服務注冊表，選擇可用的實例地址轉發請求。服務端發現模式，客戶端通過路由器或者負載均衡器轉發請求，路由器負責查詢服務注冊表，選擇可用的實例地址轉發請求。基於Service Mesh架構的服務發現模式是客戶端發現模式的一種升級，它解決了客戶端發現模式的缺點。

 

這個世界沒有完美的架構和模式，不同的場景都有適合的解決方案。我們在調研決策的時候，一定要根據實際情況去權衡對比，選擇最適合當前階段的方案，然后通過漸進迭代的方式不斷完善優化方案。

 

摘自: https://mp.weixin.qq.com/s/RImcOeDI5QRQIRwD0Fd8qw