概要
要介紹 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： 對後端的最大請求數量，不設定會預設為1024、
-
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 功能的基本前提，熟練使用連線池和負載均衡配置可以在有限資源的前提下最大化的提升應用效能。