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的負載均衡

 

本篇內容節選及改編自《雲原生服務網格Istio：原理、實戰、架構與源碼解析》

本書購買連接：https://item.jd.com/12538407.html

 

將本篇內容轉發至朋友圈集齊6個贊，並截圖於「京東雲開發者社區」公衆號後臺進行回覆。

咱們將爲第六、6六、99位回覆者送出《雲原生服務網格Istio：原理、實戰、架構與源碼解析》。

本期獲獎名單將於本週日（7月7日）揭曉，快快點擊「好看」，而且轉發到朋友圈吧！

歡迎點擊「連接」瞭解京東雲更多精彩內容

 

推薦閱讀

乾貨 | 三分鐘帶你挑選專屬負載均衡

乾貨 | 京東雲應用負載均衡（ALB）多功能實操

 

點擊"京東雲"瞭解更多負載均衡產品信息