idou老師教你學Istio 19 : Istio 流量治理功能原理與實戰

1、負載均衡算法原理與實戰

負載均衡算法（load balancing algorithm）,定義了幾種基本的流量分發方式，在Istio中一共有4種標準負載均衡算法。

•Round_Robin： 輪詢算法，顧名思義請求將會依次發給每個實例，來共同分擔全部的請求。

•Random： 隨機算法，將全部的請求隨機分發給健康的實例

•Least_Conn: 最小鏈接數，在全部健康的實例中任選兩個，將請求發給鏈接數較小的那一個實例。

接下來，咱們將根據以上幾個算法結合APM（應用性能管理）的監控拓撲圖來實戰下。

·實戰環境·

華爲雲開啓了Istio服務網格的CCE集羣 

官方最佳時間Bookinfo應用，而且給Reviews配置了五個實例

開通APM測試服務（免費）

咱們知道若是用戶不進行任何配置，負載均衡算法默認是輪詢算法，因此咱們現將負載均衡算法設爲隨機（Random）。

步驟 1

在雲容器引擎界面點擊應用管理，選擇流量治理。

步驟 2

右側出現拓撲圖，在上面的選項欄中選擇集羣，命名空間，應用。而後點擊咱們想配置的組件，這裏是 reviews，右側則會出現流量治理的界面。

 

步驟 3

在負載均衡算法中，由Round_Robin 改成random。

步驟 4

在左側導航欄中選擇流量治理下面的流量監控，再選擇相應的集羣，命名空間，應用。多訪問幾回，或者後臺寫腳本一直curl productpage，能夠從拓撲圖中觀察數據。

步驟 5

當有流量時，鼠標右鍵點擊reviews組件，選擇展開選項這時咱們能夠看到全部實例的被分發狀況。

 

 

實例編號	1	2	3	4	5
訪問次數	62	38	39	42	52

其他負載均衡算法基本同樣，咱們在步驟上不作贅述，直接展現結果。

 

輪詢算法：

實例編號	1	2	3	4	5
訪問次數	47	47	48	46	47

2、會話保持原理與實戰

會話保持（Session Affinity）是經過設定的某個指標來計算，將哈希值相同的請求分發至某個固定的實例來處理。如今支持基於HTTP頭部設定指標和Cookie鍵值設定指標。

 

咱們當前還在輪詢算法中，因此全部請求會均勻的分配給全部實例，設置會話保持基於HTTP請求頭部，而且設爲Cookie。咱們後臺curl的請求cookie設爲了一個固定值，理論上來說全部的請求都會分發至同一個pod。

咱們依然採用流量監控，展開reviews組件來觀察分發狀況。

 

 

根據圖中不難看出，全部的請求都分發至了第二個實例，由於cookie一致因此保持了這個會話連接。

3、故障注入原理與實戰

故障注入（Fault Injection）爲開發和測試人員主動向系統中引入故障，來觀察系統在非正常狀態下的行爲，是一種可靠性，穩定性的驗證手段。Istio也支持了非侵入式的注入故障，分爲時延故障和中斷故障。

故障注入的步驟大體相同在流量治理頁面的下方，選擇時延故障，而且輸入觸發百分比和延時時間。而後再打開productpage 手動刷新幾回，能明顯感受到延遲有了變化，固然也能夠打開F12調試界面，觀察網絡請求情況，不難發現productpage請求耗時都在2秒上下。

 

這時候咱們打開流量監控界面觀察下發現productpage與reviews受到了明顯的影響。紅色表示請求狀態極差，虛線表示是由時延形成的。

接下來咱們來測試而且使用中斷故障，咱們對details配置中斷故障，中斷返回碼設爲501。

 

配置完後，咱們再去手動訪問幾回productpage來觀察下結果。

發現如今的右側details已經報了error

 

咱們回到流量監控圖，能夠看到組件之間的訪問狀況。在給ratings配置了中斷故障後，本來調用ratings組件的reviews組件，已經沒法和ratings通訊了。

本文以華爲雲istio服務結合APM服務爲你們演示了流量治理中的主要功能。但願你們在從此的開發和測試中能夠利用istio靈活的非侵入的治理功能提升開發和測試的效率。

相關服務請訪問https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019