idou老師教你學Istio05: 如何用Isito實現智能路由配置

概要

要介紹 istio 請求路由，咱們不禁得先從 pilot 和 envoy 開始談起。 在服務網格中，Pilot 管理和配置全部的 envoy 實例。在 pilot 中，你幾乎能夠配置全部的關於流量導向規則及其餘故障恢復規則。而 Envoy 不只會得到從 pilot 拿到的基本負載均衡信息，同時週期性的健康檢查，也會告訴全部的 envoy 其餘的實例如今的運行情況。負載均衡信息，及健康檢查的信息可使 envoy 更加智能的去分發流量。

在上述的 pilot 結構中，不難理解，platform adapter 做爲平臺適配器，可使istio順利的在任何平臺下工做。Envoy Api 則提供動態更新信息，服務發現及配置路由規則的功能。

請求路由

在 istio 中，envoy 的存在爲流入及流出的流量提供了可控和可視的基本條件。Envoy 根據所維護的信息對請求流量的一方面有利於平衡各個 pod 的工做量，保證不會存在極端狀況而是「雨露均沾」。另外一方面，envoy 對請求流量的分發，從使用者角度來說是無感知的。

如圖中，用戶經過某個地址來訪問服務 A，服務A的 envoy 實時發現了網格內存在的服務 B，而且根據既定的轉發規則來分發流量（1%流入 pod4 訪問B’版本其他99%根據負載均衡信息流入 pod1-pod3 訪問 B 版本）。也正是envoy掛在服務外部的這一設計，方便開發和運維人員進行故障測試，熔斷以及實時監控。

VirtualService & DestinationRule

Virtualservice

VirtualService 中主要是定義了請求的路由規則，當某個請求知足了先前預設的路有條件，那麼這個請求就會路由至預設的服務。咱們看一個簡單的 VirtualService 例子:

在這個 virtualservice 中，綠色範圍內的 host 有兩條內容，第一條是服務的短名稱，實際上這個名稱是省略後的 FQDN，這裏的全稱應當是 reviews.default.svc.cluster.local 中間標紅的是規則所在的 namespace，而不是 reviews 所在的 namespace。第二條則是配置給 reviews 組件的經過負載均衡訪問的地址。黃色部分則是路由地址，其中的 subset 對應的是服務中的版本。

DestinationRule

DestinationRule 是路由後的流量訪問策略，訪問策略包含負載均衡算法，熔斷等限制。下圖是一個 destinationrule 的例子：

黃色部分很顯然是服務的兩個版本。綠色部分的意義是 TrafficPolicy，裏面配置的是負載均衡算法設定爲最小鏈接數，當兩個主機提供服務時，會自動選擇鏈接數最小的主機。咱們也能夠在這裏配置鏈接池，TLS 鏈接，端口級別策略，自動移除不健康主機等設置。

鏈接池管理

鏈接池配置給上游主機，這意味着該主機全部獲取到來自envoy的連接請求，都要遵循配置好的鏈接池原則，這些原則既能夠配在TCP層也能夠配在HTTP層。

所屬	類型	描述
TCP	ConnectionPoolSetting.TCPSettings	因爲HTTP和TCP的關係，這部分屬性既會做用在http鏈接也會做用在tcp鏈接
HTTP	ConnectionPoolSetting.HTTPSettings	這部分是對於應用層的HTTP鏈接專有的配置

HTTP鏈接池配置

• http1MaxPendingRequests： 到目標主機最大等待請求數，若是不設定默認是1024，這是針對http1.1設定的，對於http2由於不會將請求放入隊列因此不受影響。

• http2MaxRequests： 對後端的最大請求數量，不設定會默認爲102四、

• maxRequestsPerConnection： 每次鏈接最大的請求數，若是這個屬性值設爲1，那麼每次鏈接最多發送一個請求，也就是沒法保持鏈接。

• MaxRetries： 最大重試次數。

TCP鏈接池配置

• MaxConnections： 最大鏈接數，可是隻做用於http1.1也不做用於http2，由於後者只創建一次鏈接。

• ConnectionTimeOut： TCP鏈接超時

負載均衡器配置

負載均衡概述

負載均衡有兩種：基於負載均衡算法和基於一致性哈希。對於基於負載均衡算法的配置十分簡便，只要在simpleLB配上響應的字段便可。

算法字段	描述
ROUND_ROBIN	簡單的輪訓算法，這也是默認的方式
LEAST_CONN	隨機選擇兩個健康的主機，而且在二者中選擇鏈接數少的一個
RANDOM	健康主機內隨機選擇
PAASTHROUGH	直接分發到目標地址主機

基於一致性哈希的負載均衡方式能夠根據 HTTP header，cookie 來提供 soft session affinity，可是這種負載均衡方式僅支持 http 鏈接。

算法字段	描述
httpHeaderName	根據http header得到哈希
httpCookie	根據http cookie得到哈希
useSourceIp	根據IP地址得到哈希
minimumRingSize	哈希環中最小虛擬節點數，默認是1024

負載均衡樣例

負載均衡策略配置十分靈活，能夠針對某個服務進行配置，配置後隸屬於該服務的全部 pod 將會按照設定的負載均衡方式進行請求的分配，除此以外，istio 也容許用戶進行更深一層的配置，對於服務中的版本進行負載均衡配置的。配置後符合該版本的 pod 將會按照深層配置的負載均衡模式進行分配，其他的則還按服務層面的負載均衡模式進行分配。下面咱們根據一個實例來看這種狀況。

如圖所示，綠色的內容是針對服務層面設置的負載均衡方式，若是請求了 ratings 這個服務那麼默認將會採用最小鏈接數這個負載均衡方式，若是請求訪問這個服務須要的是v3版本這時候版本級的負載均衡方式將會覆蓋服務級的負載均衡方式，這時則會使用 ROUND_ROBIN 的方式。不一樣層級的負載均衡設置可讓操做者更加細化自身的服務設計。

總結

本文只介紹了很小一部分 istio 請求路由的內容，其靈活的配置，非侵入式的設計，跨平臺的支持極大地提高了開發效率，下降了測試難度。深刻理解 virtualservice，destinationrule 等是使用 istio 功能的基本前提，熟練使用鏈接池和負載均衡配置能夠在有限資源的前提下最大化的提高應用性能。