使用AverageLatencySchedulingPolicy实现请求优先级调度

背景信息

请求优先级调度策略通过将实时延迟和历史平均值进行比较来检测流量过载，并通过令牌桶和优先级机制来对请求进行调度。大致工作流程如下：

1. 过载检测：该策略会将过去一段时间内的平均延迟和当前延迟进行比较，判断系统是否发生过载。

2. 调整令牌发放速率：如果发生过载，上一步得到的监测数据会被发送给一个专用的控制器，这个控制器会控制令牌桶的填充速率。

3. 请求调度：不同的请求可以拥有不同的优先级，发生过载时，高优先级的请求会有更大的机会获得令牌。

当遇到高并发造成服务阻塞，响应延迟持续上升的情况时，使用此策略可以对请求进行排队。和常用的限流策略不同，此时请求不会被直接拒绝，而是进入一个优先级队列。最终，通过令牌桶机制对请求进行限速，并且根据优先级调整请求处理顺序。

前提条件

• 已添加Kubernetes托管版集群到ASM实例，且ASM实例为v1.21.6.44及以上。具体操作，请参见添加集群到ASM实例。

• 已为Kubernetes集群中的default命名空间开启自动注入。具体操作，请参见管理全局命名空间。

• 已通过kubectl连接至ACK集群。 具体操作，请参见获取集群KubeConfig并通过kubectl工具连接集群。

• 已开启ASM流量调度套件。具体操作，请参见开启ASM流量调度套件。

• 已经部署httpbin应用，并且可以通过网关访问，具体操作，请参见部署httpbin应用

• （可选）已经开启ASM网关访问日志，请参见生成和采集ASM网关访问日志

步骤一：创建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的访问路径不同，可以通过这点分别检索两者的访问结果：