全部產品
Search

搜尋本產品

    Alibaba Cloud Service Mesh：使用AverageLatencySchedulingPolicy實現請求優先順序調度

    文件中心

    Alibaba Cloud Service Mesh：使用AverageLatencySchedulingPolicy實現請求優先順序調度

    更新時間：Jul 12, 2024

    ASM流量調度套件支援要求優先順序調度策略。當系統發生過載時，優先順序高的請求能夠更快地被處理。本文介紹如何使用流量調度套件提供的AverageLatencySchedulingPolicy來實現請求優先順序調度。

    背景資訊

    請求優先順序調度策略通過將即時延遲和歷史平均值進行比較來檢測流量過載，並通過令牌桶和優先順序機制來對請求進行調度。大致工作流程如下：

    1. 過載檢測：該策略會將過去一段時間內的平均延遲和當前延遲進行比較，判斷系統是否發生過載。

    2. 調整令牌發放速率：如果發生過載，上一步得到的監測資料會被發送給一個專用的控制器，這個控制器會控制令牌桶的填充速率。

    3. 請求調度：不同的請求可以擁有不同的優先順序，發生過載時，高優先順序的請求會有更大的機會獲得令牌。

    當遇到高並發造成服務阻塞，響應延遲持續上升的情況時，使用此策略可以對請求進行排隊。和常用的限流策略不同，此時請求不會被直接拒絕，而是進入一個優先順序隊列。最終，通過令牌桶機制對請求進行限速，並且根據優先順序調整請求處理順序。

    前提條件

    步驟一：建立AverageLatencySchedulingPolicy

    1. 使用kubectl串連到ASM執行個體，具體操作，請參見通過控制面kubectl訪問Istio資源。

    2. 使用以下內容，建立AverageLatencySchedulingPolicy.yaml檔案。

      apiVersion: istio.alibabacloud.com/v1
kind: AverageLatencySchedulingPolicy
metadata:
  name: workload-prioritization
  namespace: istio-system
spec:
  load_scheduling_core:
    aimd_load_scheduler:
      load_scheduler:
        workload_latency_based_tokens: true
        selectors:
          - service: httpbin.default.svc.cluster.local
        scheduler:
          workloads:
            - label_matcher:
                match_labels:
                  http.request.header.user_type: "guest"
              parameters:
                priority: 50.0
              name: "guest"
            - label_matcher:
                match_labels:
                  http.request.header.user_type: "subscriber"
              parameters:
                priority: 200.0
              name: "subscriber"

      部分配置項說明如下：

      欄位

      說明

      workload_latency_based_tokens

      基於workload的平均延遲來動態調整token數量。平均延遲的估算時間視窗是最近30min。

      service

      該調度策略在這個service上生效。

      workloads

      根據請求header中的user_type定義了兩類請求，分別是guest和subscriber。guest類型的請求優先順序是50，subscriber的請求優先順序是200。

      AverageLatencySchedulingPolicy支援的欄位請參考對應的CRD說明文檔AverageLatencySchedulingPolicy CRD說明。

    步驟二：測試

    這裡我們使用壓測工具fortio，安裝方式請參見安裝fortio。

    首先，我們類比一些平時的業務請求，此時主要是為了產生請求延遲的平均值：

    fortio load -c 20 -qps 100000 -t 60m http://${ASM網關IP}/status/200

    等待上述命令運行3分鐘後，重新開啟兩個終端，發送正式的測試請求。整個測試期間，請確保上面的fortio進程一直在運行中，不要關閉對應的終端。

    在新開啟的兩個終端中，分別運行下面兩個壓測命令（儘可能同時開始運行這兩個測試）：

    fortio load -c 40 -qps 100000  -H "user_type:guest" -t 3m http://${ASM網關IP}/status/201
    fortio load -c 40 -qps 100000  -H "user_type:subscriber" -t 3m http://${ASM網關IP}/status/202

    此處我們使用了不同的請求路徑，主要是為了方便從訪問日誌中觀察測試結果。

    步驟三：分析測試結果

    首先等待上述的兩個測試命令執行結束，當前測試環境下兩個命令的輸出的最後幾行分別是：

    Code 201 : 26852 (97.8 %)
Code 503 : 601 (2.2 %)
Response Header Sizes : count 27453 avg 242.91564 +/- 36.35 min 0 max 249 sum 6668763
Response Body/Total Sizes : count 27453 avg 246.17754 +/- 14.56 min 149 max 249 sum 6758312
All done 27453 calls (plus 40 warmup) 262.318 ms avg, 152.4 qps
    Code 202 : 52765 (100.0 %)
Response Header Sizes : count 52765 avg 248.86358 +/- 0.5951 min 248 max 250 sum 13131287
Response Body/Total Sizes : count 52765 avg 248.86358 +/- 0.5951 min 248 max 250 sum 13131287
All done 52765 calls (plus 40 warmup) 136.472 ms avg, 292.9 qps

    可以看出：

    • subscriber使用者的請求都成功了，沒有503的響應；guest使用者的請求有2.2%返回了503。

    • subscriber使用者的請求平均延遲大致為136ms；guest使用者平均延遲大約為262ms。並且兩個使用者的QPS也存在顯著差異。

    由此可以證明，在請求延遲突增時AverageLatencySchedulingPolicy會優先處理subscriber的請求。

    重要

    本文中的驗證結果僅為理論值，實際資料以您的作業環境為準。不同測試環境的壓力測試結果存在差異，此處僅分析資料的相對關係。

    （可選）步驟四：通過網關訪問日誌分析測試結果

    1. 登入ASM控制台，在左側導覽列，選擇服務網格 > 網格管理。

    2. 在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇ASM網關 > 入口網關。

    3. 點擊對應ASM網關名稱，進入網關概覽，點擊網關日誌，查看網關訪問日誌。

    4. guest和subscriber的訪問路徑不同，可以通過這點分別檢索兩者的訪問結果：

    image.png

    image.png