Istio流量治理原理之負載均衡

流量治理是一個非常寬泛的話題，例如：

• 動態修改服務間訪問的負載均衡策略，比如根據某個請求特徵做會話保持；

• 同一個服務有兩個版本線上，將一部分流量切到某個版本上；

• 對服務進行保護，例如限制併發連線數、限制請求數、隔離故障服務例項等；

• 動態修改服務中的內容，或者模擬一個服務執行故障等。

在Istio中實現這些服務治理功能時無須修改任何應用的程式碼。較之微服務的SDK方式，Istio以一種更輕便、透明的方式向使用者提供了這些功能。使用者可以用自己喜歡的任意語言和框架進行開發，專注於自己的業務，完全不用嵌入任何治理邏輯。只要應用執行在Istio的基礎設施上，就可以使用這些治理能力。

一句話總結Istio流量治理的目標：以基礎設施的方式提供給使用者非侵入的流量治理能力，使用者只需關注自己的業務邏輯開發，無須關注服務訪問管理。

Istio流量治理的概要流程如圖1所示：

圖1  Istio流量治理的概要流程

在控制面會經過如下流程：
（1）管理員透過命令列或者API建立流量規則；
（2）Pilot將流量規則轉換為Envoy的標準格式；
（3）Pilot將規則下發給Envoy。

在資料面會經過如下流程：
（1）Envoy攔截Pod上本地容器的Inbound流量和Outbound流量；
（2）在流量經過Envoy時執行對應的流量規則，對流量進行治理。

負載均衡

下面具體看看Istio提供了流量治理中的負載均衡功能。

負載均衡從嚴格意義上講不應該算治理能力，因為它只做了服務間互訪的基礎工作，在服務呼叫方使用一個服務名發起訪問的時候能找到一個合適的後端，把流量導過去。

如圖2所示，傳統的負載均衡一般是在服務端提供的，例如用瀏覽器或者手機訪問一個Web網站時，一般在網站入口處有一個負載均衡器來做請求的匯聚和轉發。服務的虛擬IP和後端例項一般是透過靜態配置檔案維護的，負載均衡器透過健康檢查保證客戶端的請求被路由到健康的後端例項上。

圖2  服務端的負載均衡器

在微服務場景下，負載均衡一般和服務發現配合使用，每個服務都有多個對等的服務例項，需要有一種機制將請求的服務名解析到服務例項地址上。服務發現負責從服務名中解析一組服務例項的列表，負載均衡負責從中選擇一個例項。

如圖3所示為服務發現和負載均衡的工作流程。不管是SDK的微服務架構，還是Istio這樣的Service Mesh架構，服務發現和負載均衡的工作流程都是類似的，如下所述：
（1）服務註冊。各服務將服務名和服務例項的對應資訊註冊到服務註冊中心。
（2）服務發現。在客戶端發起服務訪問時，以同步或者非同步的方式從服務註冊中心獲取服務對應的例項列表。
（3）負載均衡。根據配置的負載均衡演算法從例項列表中選擇一個服務例項。

圖3  服務發現和負載均衡的工作流程

Istio的負載均衡正是其中的一個具體應用。在Istio中，Pilot負責維護服務發現資料。如圖4所示為Istio負載均衡的流程，Pilot將服務發現資料透過Envoy的標準介面下發給資料面Envoy，Envoy則根據配置的負載均衡策略選擇一個例項轉發請求。Istio當前支援的主要負載均衡演算法包括：輪詢、隨機和最小連線數演算法。

圖4  Istio負載均衡的流程

在Kubernetes上支援Service的重要元件Kube-proxy，實際上也是執行在工作節點的一個網路代理和負載均衡器，它實現了Service模型，預設透過輪詢等方式把Service訪問轉發到後端例項Pod上，如圖5所示。

圖5  Kubernetes的負載均衡

歡迎點選“ 京東雲 ”瞭解更多精彩內容