全部產品
Search
文件中心

Alibaba Cloud Service Mesh:結合ASM與GTM應對地區級故障容災

更新時間:May 21, 2026

地區級故障是雲上業務可能遭遇的一種極端類型的故障。當地區級故障發生時,特定地區下任何可用性區域內的服務都面臨著無法串連、資料丟失以及工作負載無法運行等風險。Service Mesh (ASM)支援將ASM入口網關部署在Kubernetes叢集或Elastic Container Instance (ECI)中,作為業務應用統一的流量入口,並在每個叢集中擁有獨立的流量入口IP地址。當其中一個地區發生故障的時候把故障IP剔除,並將流量全部轉移到正常地區,以實現對地區級故障的容災。

容災架構

為驗證應對地區層級故障的能力,以下以雙地區、雙叢集為例,介紹容災架構:

  1. 構建多主控制面架構,即在兩個地區分別部署一個K8s叢集,並且在兩個叢集中部署完全對等的業務雲原生服務,服務之間通過K8s叢集網域名稱相互調用。

    說明

    使用多主控制面,可以保證每個地區的網格代理的推送延遲都是可控的,並且達到生產可用水準。同時也可以確保在地區故障時,控制面的災備高可用。

  2. 兩個叢集均需要部署ASM網關,並配置ASM網關通過公網CLB或NLB對外暴露公網入口的IP或網域名稱。再結合Alibaba Cloud DNS和全域流量管理GTM,將網域名稱分別解析到兩個IP地址。

  3. 當發生地區層級的故障時,另一個健康地區中的業務不受影響。此時,全域流量管理GTM會自動將故障地區的IP剔除出解析池,並將流量全部解析至健康地區的ASM網關上。

當出現突發流量時,您可以通過配置以下功能,進一步最佳化地區故障時的流量轉移行為。

  1. 為ASM網關啟用擴縮容HPA:迅速擴容出更多的ASM網關執行個體,以應對突發流量。

    說明

    擴縮容HPA功能僅適用於企業版或旗艦版ASM執行個體。

  2. 為ASM網關或叢集中的關鍵服務配置限流:通過ASM的限流功能,可以有效防止突增流量超過叢集服務的承載能力,從而避免健康地區的應用服務因大量流量轉移而崩潰。

  3. (可選)您還可以配置ASM的限流指標監測與警示機制,便於即時觀察和及時發現故障事件,以迅速對健康地區的工作負載進行擴容。

容災實踐流程

跨地區容災支援所有類型的叢集。本實踐以ACK託管叢集為例,示範從建立叢集和ASM執行個體開始,到完成所有容災配置並進行故障演練的整個過程。

容災配置實踐

以下以CLB類型的入口網關為例進行實踐操作。關於NLB類型入口網關接入GTM的具體操作,請參見業務網域名稱接入GTM

步驟一:構建多主控制面架構

  1. 在兩個不同的地區建立兩個叢集,分別命名為cluster-1和cluster-2,並開啟使用 EIP 暴露 API server。具體操作,請參見建立ACK託管叢集

  2. 在叢集所在的地區分別建立服務網格執行個體,命名為mesh-1和mesh-2,並分別添加cluster-1和cluster-2到ASM執行個體,以構建多主控制面架構服務網格。具體操作,請參見通過ASM多主控制面架構實現多叢集容災的步驟一和步驟二。

步驟二:部署入口網關與樣本應用

  1. 在兩個ASM執行個體中,分別建立名為ingressgateway的ASM入口網關。具體操作,請參見建立入口網關

  2. 在cluster-1和cluster-2叢集中,分別部署Bookinfo樣本應用。具體操作,請參見在ASM執行個體關聯的叢集中部署應用

  3. 在兩個ASM執行個體中,分別為樣本應用建立網關規則和虛擬服務,將ASM網關作為Bookinfo應用的流量入口。具體操作,請參見使用Istio資源實現版本流量路由

  4. 為兩個ASM執行個體分別開啟全域維度叢集內流量保持功能。具體操作,請參見按照全域開啟叢集內流量保持功能

    說明

    在地區級故障容災的情境下,我們希望流量始終保持在單個叢集中。當同一個服務網格執行個體加入兩個及以上的Kubernetes叢集時,如果不做任何配置,服務網格的預設負載平衡機制會使服務嘗試調用對側叢集對等部署的服務。通過開啟ASM叢集內流量保持功能,可以將對服務的請求始終保持在叢集內,避免出現跨叢集調用的情況。

(可選)步驟三:驗證服務狀態

  1. 擷取兩個ASM網關的公網IP,用於驗證服務狀態及後續配置GTM。具體操作,請參見擷取入口網關地址

  2. 分別使用cluster-1和cluster-2叢集的kubeconfig,查看reviews服務的Pod名稱。

    kubectl get pod| grep reviews

    預期輸出:

    reviews-v1-5d99dxxxxx-xxxxx       2/2     Running   0          3d17h
    reviews-v2-69fbbxxxxx-xxxxx       2/2     Running   0          3d17h
    reviews-v3-8c44xxxxx-xxxxx        2/2     Running   0          3d17h
  3. 在瀏覽器地址欄,依次輸入http://{mesh-1入口網關的IP地址}/productpagehttp://{mesh-2入口網關的IP地址}/productpage,並持續重新整理頁面10次,訪問Bookinfo應用。

    每次重新整理都會訪問reviews服務的v1、v2或v3版本。您可以看到,兩個叢集的reviews服務三個版本均與上一步輸出的Pod名稱一致。即服務運行狀態正常,並且叢集內流量保持功能已生效。

    reviews-v1 版本的評論不顯示星級評等,reviews-v2 版本的評論顯示黑色星級評等,reviews-v3 版本的評論顯示紅色星級評等,據此可直觀辨別當前訪問的服務版本。

步驟四:配置全域流量管理GTM

將擷取的兩個公網IP作為應用的流量入口IP,並配置GTM的多活負載和容災。具體操作,請參見GTM如何?多活負載並容災

配置完成後的效果如下:

image

(可選)步驟五:配置本地限流和基於限流的觀測及警示

  1. 使用以下內容,分別為mesh-1和mesh-2配置本地限流規則。具體操作,請參見為入口網關配置本地限流

    apiVersion: istio.alibabacloud.com/v1beta1
    kind: ASMLocalRateLimiter
    metadata:
      name: ingressgateway
      namespace: istio-system
    spec:
      configs:
        - limit:
            fill_interval:
              seconds: 1
            quota: 100
          match:
            vhost:
              name: '*'
              port: 80
              route:
                name_match: gw-to-productage
      isGateway: true
      workloadSelector:
        labels:
          istio: ingressgateway
  2. 分別為兩個ASM執行個體配置本地限流的指標採集和警示。具體操作,請參見配置本地限流指標採集和警示

故障演練

本演練使用fortio工具對樣本應用進行壓測,來類比外部使用者進行訪問。壓測期間,將通過手動刪除入口網關工作負載的方式類比地區發生故障,以觀察容災轉移的效果。

  1. 執行以下命令,對樣本應用進行五分鐘的壓測。請將命令中的網域名稱替換為實際在GTM中配置的網域名稱。

    fortio load -jitter=False  -c 1 -qps 100 -t 300s -keepalive=False -a http://{網域名稱}/productpage
  2. 在壓測進行的同時,以cluster-2為故障叢集,類比地區故障。

    1. 登入Container Service管理主控台,在左側導覽列選擇叢集列表

    2. 叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇工作負載 > 無狀態

    3. 單擊命名空間下拉框,選擇istio-system

    4. 在工作負載列表中找到istio-ingressgateway,單擊操作列的更多 > 刪除

  3. 等待壓測結束,預期輸出如下。

    # range, mid point, percentile, count
    >= -261.054 <= -0.0693516 , -130.561 , 100.00, 3899
    # target 50% -130.595
    WARNING 100.00% of sleep were falling behind
    Aggregated Function Time : count 3899 avg 0.076910055 +/- 0.02867 min 0.062074583 max 1.079674 sum 299.872304
    # range, mid point, percentile, count
    >= 0.0620746 <= 0.07 , 0.0660373 , 19.34, 754
    > 0.07 <= 0.08 , 0.075 , 71.94, 2051
    > 0.08 <= 0.09 , 0.085 , 96.08, 941
    > 0.09 <= 0.1 , 0.095 , 99.23, 123
    > 0.1 <= 0.12 , 0.11 , 99.62, 15
    > 0.12 <= 0.14 , 0.13 , 99.82, 8
    > 0.14 <= 0.16 , 0.15 , 99.92, 4
    > 1 <= 1.07967 , 1.03984 , 100.00, 3
    # target 50% 0.0758289
    # target 75% 0.0812673
    # target 90% 0.0874825
    # target 99% 0.0992691
    # target 99.9% 0.155505
    Error cases : count 527 avg 0.074144883 +/- 0.07572 min 0.062074583 max 1.079674 sum 39.0743532
    # range, mid point, percentile, count
    >= 0.0620746 <= 0.07 , 0.0660373 , 82.54, 435
    > 0.07 <= 0.08 , 0.075 , 96.58, 74
    > 0.08 <= 0.09 , 0.085 , 99.05, 13
    > 0.09 <= 0.1 , 0.095 , 99.24, 1
    > 0.12 <= 0.14 , 0.13 , 99.43, 1
    > 1 <= 1.07967 , 1.03984 , 100.00, 3
    # target 50% 0.0668682
    # target 75% 0.0692741
    # target 90% 0.0753108
    # target 99% 0.0897923
    # target 99.9% 1.06568
    # Socket and IP used for each connection:
    [0] 3900 socket used, resolved to [39.XXX.XXX.160:80 (3373), 106.XXX.XXX.73:80 (527)], connection timing : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
    Connection time histogram (s) : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
    # range, mid point, percentile, count
    >= 0.027057 <= 0.03 , 0.0285285 , 13.28, 518
    > 0.03 <= 0.035 , 0.0325 , 62.79, 1931
    > 0.035 <= 0.04 , 0.0375 , 83.95, 825
    > 0.04 <= 0.045 , 0.0425 , 86.13, 85
    > 0.045 <= 0.05 , 0.0475 , 86.18, 2
    > 0.05 <= 0.06 , 0.055 , 86.28, 4
    > 0.06 <= 0.07 , 0.065 , 98.03, 458
    > 0.07 <= 0.08 , 0.075 , 99.77, 68
    > 0.08 <= 0.09 , 0.085 , 99.92, 6
    > 1 <= 1.07747 , 1.03874 , 100.00, 3
    # target 50% 0.0337079
    # target 75% 0.0378848
    # target 90% 0.0631659
    # target 99% 0.0755882
    # target 99.9% 0.0885
    Sockets used: 3900 (for perfect keepalive, would be 1)
    Uniform: false, Jitter: false, Catchup allowed: true
    IP addresses distribution:
    39.XXX.XXX.160:80: 3373
    106.XXX.XXX.73:80: 527
    Code  -1 : 527 (13.5 %)
    Code 200 : 3372 (86.5 %)
    Response Header Sizes : count 3899 avg 178.19851 +/- 70.45 min 0 max 207 sum 694796
    Response Body/Total Sizes : count 3899 avg 4477.7081 +/- 1822 min 0 max 5501 sum 17458584
    All done 3899 calls (plus 1 warmup) 76.910 ms avg, 13.0 qps

    可以看到,有少量請求在類比的地區故障下發生了無法串連的錯誤,但大部分請求成功。這證明ASM結合GTM有效地對地區層級的故障完成了容災。

  4. 查看GTM中的接入網域名稱狀態,可以看到cluster-2的IP地址已經被剔除。

    image

    您也可以通過配置警示的方式,在IP不可用時接收警示,並手動剔除停用IP地址。具體操作,請參見警示配置