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：

對後端的最大請求數量，不設定會默認為1024、

maxRequestsPerConnection:

每次連接最大的請求數，如果這個屬性值設為1，那麼每次連接最多發送一個請求，也就是無法保持連接。

MaxRetries：

最大重試次數。

TCP連接池配置

MaxConnections:

最大連接數，但是只作用於http1.1也不作用於http2，因為後者只建立一次連接。

ConnectionTimeOut：

TCP連接超時

負載均衡器配置

負載均衡概述

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

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

負載均衡樣例

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

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

總結

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

推薦閱讀

idou老師教你學Istio 04：Istio性能及擴展性介紹

idou老師教你學Istio 03： istio故障注入功能的介紹和使用

Istio技術與實踐06：史上最全！Istio安裝參數介紹

點擊

閱讀原文

回帖搶手機，還在等什麼！