戳藍字“CSDN云計算”關注我們哦！

作者 |?鐘華

來源?|?ServiceMesher

隨著容器技術的流行，大量互聯網公司和傳統 IT 企業都在嘗試應用容器化和服務上云。容器化是一個持續的過程，伴隨著多地域部署、安全等級隔離、多云和混合云等復雜的場景需求。

上篇文章中我們成功將廣州和新加坡 2 地的 kubernetes 集群連通為一個服務網格，實現了多集群服務透明共享：recommend v1 和 recommend v2 分別部署在廣州和新加坡地域， 但是兩地用戶都可以無差別的訪問到任一版本。

接下來我們上述環境中， 嘗試幾個多集群服務網格的應用場景，包括：

• 異地容災

• 地域感知負載均衡

• 多地域負載策略分析

相關代碼匯總于：zhongfox/multicluster-demo

異地容災

要保證系統高可用和良好的用戶體驗，服務多副本部署、特別是異地多副本部署是必不可少的架構， 即使對于吞吐量低壓力小的應用，考慮「墨菲定律」單點部署仍是應該盡量避免的。對于 SLA 要求較高的關鍵系統，兩地部署甚至多地部署應對容災也是非常必要的。

在已部署的環境中， 我們嘗試將廣州集群中的 recommend v1 服務副本數刪除至 0 個，模擬廣州集群 recommend 服務實例不可用：

這時候我們分別多次訪問廣州和新加坡商城應用， 發現任一入口訪問， 頁面都可以正常顯示， 且「推薦商品」板塊顯示的都是 recommend v2 版本， 也就是部署在新加坡地域的有 banner 的版本：

現在我們把廣州集群 recommend v1 服務擴容為 1 個副本，將新加坡集群 recommend v2 服務副本數降至 0，類似的， 我們可以驗證， 兩地訪問商城應用， 頁面顯示都正常，而且顯示的都是廣州集群無 banner 的 recommend v1 版本：

---

地域感知負載均衡

在多地域部署架構中，地域感知負載均衡需求主要源自以下需求：

• 在跨地域部署的多集群中，各地域可能會部署本地區定制化的服務，比如不同地區的服務會有不同的顯示語言或定制功能，或者某些服務只在特定區域開放。這些場景要求服務間的訪問不能隨機路由，需要優先（或只能）訪問本地域服務。

• 在用作容災在多地域架構中， 往往會有一個主集群， 擁有較為充足的服務資源， 而容災地域的資源僅保證服務基本可用。因此我們要求正常情況下，請求能由主集群提供服務，流量不要地域間隨機路由。

• 即使不是以上場景，考慮 2 個異地對等集群，提供服務和持有資源完全相同， 我們也應該盡量滿足本地域內閉環服務， 因為跨地域的服務訪問往往會有較大的延遲，用戶體驗差， 且可能會讓容錯性較差的系統出現服務雪崩的風險。

Locality Load Balancing 是 istio 1.1 增加的 experimental 特性，接下來我們在上述環境中驗證此特性：

首先我們先還原上個場景的修改，將廣州地域和新加坡地域的 recommend 服務副本都設置為 1：

%?kubectl?--context?guangzhou?-nbase?scale?deploy/recommend-v1?--replicas=1
%?kubectl?--context?singapore?-nbase?scale?deploy/recommend-v2?--replicas=1

然后開啟 Locality Load Balancing：設置 Pilot 的環境變量：

%?kubectl?-n?istio-system?--context?guangzhou?edit?deploy?istio-pilot
......
env:
-?name:?PILOT_ENABLE_LOCALITY_LOAD_BALANCING
??value:?"ON"

稍等片刻，分別通過廣州和新加坡地域入口多次訪問商城應用，可以發現廣州入口一直展示 recommend v1 版本，新加坡地域一直展示 recommend v2 版本：

開啟「地域感知負載均衡」后， 因為流量都在同一個集群中，所以訪問速度開啟之前，會提升很多，我們實測一下， 在開啟「地域感知負載均衡」前后，使用 ab 工具， 模擬訪問 2 個地域各 100 次：

上圖所示，開啟「地域感知負載均衡」功能后，請求平均耗時從大概 1116~ 1159 毫秒下降到了 117~132 毫秒。

---

多地域負載策略分析

在 kubernetes 平臺， istio 根據 kubernetes node 上的約定地域標簽，來確定 node 上包含的 pod 的地域親和度, ?在 TKE 上， node 默認有了地域標簽：

~?%?kubectl?--context?guangzhou?get?node?--show-labels
NAME
172.16.48.35???......
failure-domain.beta.kubernetes.io/region=gz,
failure-domain.beta.kubernetes.io/zone=100002

~?%?kubectl?--context?singapore?get?node?--show-labels
NAME
172.22.0.42???......
failure-domain.beta.kubernetes.io/region=sg,
failure-domain.beta.kubernetes.io/zone=900001

failure-domain.beta.kubernetes.io/region表示地域， failure-domain.beta.kubernetes.io/zone表示可用區。

地域負載均衡默認會使用地域優先策略，具體講，一個具體區域的 envoy 會將其他實例做如下優先級處理：

Priority 0 最高優先級：相同地域且相同區域

Priority 1 第二優先級：相同地域但不同區域

Priority 2 最低優先級：不同地域

考慮開啟「地域感知負載均衡」后， 整個服務網格如何做失效轉移：

為了減少低效的跨地域訪問，istio 會盡量保證按照地域優先級負載均衡；但是當本地域服務的可用性降低時，流量應該適當的轉移一部分到下一優先級的地域去，流量的轉移應該盡量平滑。流量轉移的時機不應該等到本區域服務可用性降至零后才開始， 因為這會有服務中斷甚至雪崩的風險。

在 envoy 負載均衡策略中，有一個很重要的參數：Overprovisioning Factor 可以翻譯為 「預留資源」參數，區域流量降級的時機和比例，會受到本區域的「服務可用性」和「預留資源」參數共同決定。istio 中「預留資源」參數默認是 1.4。

可以這樣理解「預留資源」參數：指定區域部署的服務資源， 通常會高于系統實際需要的服務資源，以應對可能出現的各種異常導致的可用性降低。比如本區域 recommend 服務預估 100 副本可以滿足用戶需求，按照容災經驗我們可能會部署 140 副本。當本區域因為異常導致副本數下降，可用性降低時， 系統應該判斷，只有副本數低于 100 時，才開始將多余流量轉移到下一級地域。

基于以上網格環境， 我們對地域負載策略進行驗證：

在廣州集群中， 我們再部署一個新的 recommend deployment，名為 recommend-unhealthy，這個副本的推薦接口直接返回狀態碼 502，用以模擬不可用的服務實例：

get?'/recommend'?do
??status?502
end

同時我們給 recommd 服務加上斷路器:

apiVersion:?networking.istio.io/v1alpha3
kind:?DestinationRule
metadata:
??name:?recommend
??namespace:?base
spec:
??host:?recommend.base.svc.cluster.local
??trafficPolicy:
????tls:
??????mode:?ISTIO_MUTUAL
????outlierDetection:
??????consecutiveErrors:?3
??????interval:?30s
??????baseEjectionTime:?3m

表示 recommend 服務實例，如果連續 3 次訪問失敗，將標記為不可用。不可用實例將被隔離于可用實例之外，持續 3 分鐘。

以上操作可以通過執行以下命令實現：

kubectl?--context?guangzhou?-nbase?apply?-f?install/locality-load-balancing.yaml

廣州集群 2 個 ?recommend 共同組成該地域的服務 endpoints, 廣州 recommend 服務的健康度（可用性）可以表示為：

health?=?recommend-v1-replicas?/?(recommend-v1-replicas?+?recommend-unhealthy-replicas)

按照默認 Overprovisioning Factor 為 1.4，廣州集群負載均衡流量百分比數為：

guangzhou-LB?=?min(100,?1.4?*?100?*?health)

新加坡流量百分比數：

singapore-LB?=?100?-?guangzhou-LB

編寫一個 ruby 程序 進行驗證：

最初 recommend v1 副本數為 14， recommend unhealthy 副本數為 0， 一直保持 2 個 deployment 的副本總和為 14， 逐漸增加 unhealthy 副本的比重， 等待所有 pod ready 后， 使用廣州網關入口發起 1000 次請求， 然后根據響應內容判斷 recommend 服務的負載均衡情況：如果內容不包含 recommend banner，是由廣州集群提供服務， 如果內容包括 recommend banner， 那么請求就是轉移到了新加坡集群，測試結果如下圖：

ruby?./install/recommend_stat.rb?--ip?134.175.211.151?--count?1000

數據統計可以看出，廣州健康副本（v1）由 14 個下降到 10 個的過程中，不會出現流量降級到新加坡，當廣州健康副本數低于 10 個后，部分流量將會被負載均衡的新加坡集群：

只要廣州主集群的健康度不為 0（v1 副本 > 0）, 則第一優先級的廣州集群負載流量也會大于 0，保證剩余的可用性盡量滿足地域就近負載。

隨著 unhealthy 副本數的增加，我們可以看到訪問的錯誤請求數目并未按比例增加，一直保持在一個平穩的錯誤值，這是因為我們上面給 recommend 服務配置了斷路器，因此服務整體的高可用性得以保證。

---

在更多個集群連通的網格中，負載算法支持多層降級，另外每個地域也可以顯示指定流量降級時的下級集群， 各集群的負載權重也可以手動設置。

利用 Istio 和 envoy 的以上能力，結合各集群的資源情況和業務規劃，可以讓我們調配出高可用、高性能的多集群服務網格。

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

推薦閱讀：

• 做了中臺就不會死嗎？每年至少40%開發資源是被浪費的！

• 美女主播變大媽：在bug翻車現場說測試策略

• 漫畫高手、小說家、滑板專家……解鎖程序員的另一面！

• 手把手教你如何用Python模擬登錄淘寶

• 鴻蒙霸榜 GitHub，從最初的 Plan B 到“取代 Android”？

• 每天超50億推廣流量、3億商品展現，阿里媽媽的推薦技術有多牛？
  

真香，朕在看了！

總結

以上是生活随笔為你收集整理的Istio 庖丁解牛六：多集群网格应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。