ASM流量調度套件支援通過QuotaSchedulingPolicy實現指定請求調用配額下的請求優先順序調度。當系統中正在處理的請求速率超過指定的配額時，後續的請求將會被排隊，同時優先順序高的請求能夠被更快處理。本文介紹如何使用流量調度套件提供的QuotaSchedulingPolicy來實現請求調用配額管理。
背景資訊
QuotaSchedulingPolicy通過令牌桶演算法來控制調用指定服務的請求速率，並在速率超過指定配額時對請求進行排隊處理。大致工作流程如下：
使用限流器對請求進行速率限制：使用令牌桶演算法對請求進行限流，有關限流器的演算法實現，可詳細參考使用RateLimitingPolicy實現分使用者限流情境的背景資訊。
請求調度：請求速率超過配額限制後，後續請求將會被排隊，等待先前請求處理完成後再發送給服務，以保證請求速率始終保持在給定數值。同時，高優先順序的請求有更大的機會被從隊列中取出發送給服務。
和限流的情境不同，使用QuotaSchedulingPolicy時，若請求速率超過限制，此時請求不會被直接拒絕，而是進入一個優先順序隊列，在保證請求速率始終在限制內的同時對請求進行優先順序調度。
前提條件
已添加Kubernetes託管版叢集到ASM執行個體，且ASM執行個體為1.21.6.95版本及以上。具體操作，請參見添加叢集到ASM執行個體。
已通過kubectl串連至ACK叢集。 具體操作，請參見擷取叢集KubeConfig並通過kubectl工具串連叢集。
已開啟ASM流量調度套件。具體操作，請參見開啟ASM流量調度套件。
已為Kubernetes叢集中的default命名空間開啟自動注入。具體操作，請參見管理全域命名空間。
已建立名為ingressgateway的入口網關，並開啟80連接埠。具體操作，請參見建立入口網關。
已經部署httpbin應用，並且可以通過網關訪問。具體操作，請參見部署httpbin應用。
步驟一：建立QuotaSchedulingPolicy配額管理規則
使用kubectl串連到ASM執行個體，具體操作，請參見通過控制面kubectl訪問Istio資源。
使用以下內容建立quotaschedulingpolicy.yaml檔案
apiVersion: istio.alibabacloud.com/v1 kind: QuotaSchedulingPolicy metadata: name: quotascheduling namespace: istio-system spec: quota_scheduler: bucket_capacity: 10 fill_amount: 10 rate_limiter: interval: 1s 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 selectors: - service: httpbin.default.svc.cluster.local部分配置項說明如下。關於配置項的更多資訊，請參見QuotaSchedulingPolicy CRD說明。
配置項
說明
fill_amount
在interval指定的時間間隔內填充令牌的數量。樣本中指定為10，即每過interval指定的時間間隔後便向令牌桶填充10個令牌。
interval
向令牌桶中填充令牌的時間間隔。樣本中指定為1s，即每過1秒後便向令牌桶填充10個令牌。
bucket_capacity
令牌桶內的令牌數量上限。當請求速率小於令牌桶填充速率時，令牌桶內的令牌數量會持續增加，最大將達到
bucket_capacity。使用bucket_capacity可以容許一定程度的突發流量。樣本中設定為10，和fill_amount相同，即不允許任何突發流量。workloads
根據請求header中的
user_type定義了兩類請求，分別是guest和subscriber。guest類型的請求優先順序是50，subscriber類型的請求優先順序是200。selectors
指定應用限流策略的多個服務。樣本中使用httpbin.default.svc.cluster.local 服務進行並行度限制。
執行以下命令，建立配額管理規則
kubectl apply -f quotaschedulingpolicy.yaml步驟二：測試請求配額管理效果
本步驟使用壓測工具fortio進行測試，安裝方式請參見安裝fortio。
同時開啟兩個終端，並分別運行下面兩個壓測命令（儘可能同時開始這兩個測試），整個測試期間，請確保不要關閉對應的終端。兩個測試都使用10並發、10000預期QPS的設定對服務發起調用，遠遠超過了服務的預期並發度限制。
fortio load -c 10 -qps 10000 -H "user_type:guest" -t 30s -timeout 60s -a http://${ASM網關IP}/status/201fortio load -c 10 -qps 10000 -H "user_type:subscriber" -t 30s -timeout 60s -a http://${ASM網關IP}/status/202說明請將上述指令中的
${ASM網關IP}替換為ASM網關的IP地址。有關擷取ASM網關IP地址的具體操作，請參見使用Istio資源實現版本流量路由。測試1的預期輸出：
... # target 50% 4.83333 # target 75% 5.20763 # target 90% 5.38203 # target 99% 5.48668 # target 99.9% 5.49714 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 201 : 70 (100.0 %) Response Header Sizes : count 70 avg 249.94286 +/- 0.2871 min 248 max 250 sum 17496 Response Body/Total Sizes : count 70 avg 249.94286 +/- 0.2871 min 248 max 250 sum 17496 All done 70 calls (plus 10 warmup) 4566.839 ms avg, 2.1 qps Successfully wrote 4693 bytes of Json data to 2024-07-26-232250_114_55_5_155_status_201_iZbp1cz9ur77robaiv085tZ.json測試2的預期輸出：
fortio load -c 10 -qps 10000 -H "user_type:subscriber" -t 30s -timeout 60s -a http://114.55.xx.xx/status/202 ... # target 50% 0.253333 # target 75% 1.875 # target 90% 4.26635 # target 99% 4.47301 # target 99.9% 4.49367 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 202 : 250 (100.0 %) Response Header Sizes : count 250 avg 250.264 +/- 0.4408 min 250 max 251 sum 62566 Response Body/Total Sizes : count 250 avg 250.264 +/- 0.4408 min 250 max 251 sum 62566 All done 250 calls (plus 10 warmup) 1226.657 ms avg, 8.0 qps Successfully wrote 4509 bytes of Json data to 2024-07-26-232250_114_55_5_155_status_202_iZbp1cz9ur77robaiv085tZ.json可以看到，測試2的平均請求延遲約為測試1的四分之一，QPS約為測試1的四倍。這是由於先前定義的策略中，subscriber類型的請求優先順序是guest類型的請求的四倍。同時，兩個測試在30秒內總共完成了320個請求，除去最開始預熱使用的20個請求，服務收到的請求速率正好是1秒鐘10個請求，證明服務收到的請求始終在給定限額之內。