UAVStack服务治理之流量控制

背景

应用微服务化场景下，随着服务个数的增加，服务之间的相互调用变得更加复杂，服务治理需求愈加突出，其中服务流量控制是服务治理中的重要一环。

当前常用的流量控制方案主要有基于 Spring Cloud 的 Hystrix 和阿里开源的 Sentinel 应用流量控制降级方案。客观而言，两个方案都是侵入式的，要求用户在应用中引入相关包，编写相关逻辑。

UAVStack 作为一套智能化服务技术栈，其服务治理（UAV.ServiceGovern）模块提供了基于画像的服务注册与发现、服务访问授权及服务流量控制能力。

本文主要介绍 UAVStack 的无侵入式服务流量限制及降级方案。安装 UAV 后，通过页面配置即可用实现常用的 QPS 限流等。

一、限流模型

图 1 限流模型

UAV 服务治理流量控制采用上图所示的漏斗 + 能力池限流模型。将应用根据 UAV 画像抽象出三层，分别是应用层（应用实例层）、服务组件层和 URL 层。每一层均可以添加多个限流策略，多个限流策略以“且”的关系存在。请求呈漏斗状依次进入 URL 层限流、服务组件层限流、应用层限流，只有通过三层限流后才能进入应用。

• 应用层（应用实例层）：应用层代表当前应用实例整体，应用层限流即限制进入当前应用的总流量。应用层限流流量为服务组件层和 URL 层流量上限；

• 服务组件层：服务组件层是应用下所有服务组件的集合，包含一个或多个服务组件。可以针对每个服务组件配置不同的限流和降级策略，每个服务组件包含 0 个或多个 URL；

• URL 层：URL 层包含所有服务 URL。URL 层限流即限制进入具体 URL 的流量。

流量控制的目标不是仅仅限制 QPS，还要限制对系统资源的使用。服务能力池描述当前应用或组件对外提供的服务能力的上限，该上限为池的最大容量；由于不同的请求消耗的系统资源不一样，因此每种类型的请求将会被赋予不同的权重值。重的请求消耗更多系统资源，将被赋予更大的权重值，而轻的请求赋予较小的权重值。每个请求都会根据权重值消耗服务能力池中的能力，重的请求比轻的请求消耗得服务能力多。无法从服务能力池中获取足够的服务能力时，便会触发降级策略。

二、关键技术

2.1 MOF 中间件劫持

MOF(MonitorFramework) 中间件劫持为 UAV 服务治理中流量控制提供基础支撑。主要提供以下几方面的支撑：

• 请求捕获：捕获所有进入应用容器的请求，并将请求转入限流模型处理流程，实现流量控制和请求降级；

• 流量控制策略配置：基于 MOF 提供的基础能力实现流量控制策略配置、当前限流状态查询 / 开启 / 关闭等热控制。

2.2 限流器和降级策略

UAV 服务治理默认支持两种限流器：时间段计数限流器和基于令牌桶算法的服务能力限流器。

时间段计数限流器通过原子量累计时间段内请求个数。当请求个数超过限制总数时，执行降级策略。默认的降级策略是终止请求处理流程，返回 TOO_MANY_REQUEST。UAV 服务治理支持开发和配置自定义的降级策略。

基于令牌桶算法的服务能力限流器会随着时间变化按恒定时间间隔 (1/QPS，如果 QPS=100, 则间隔是 10ms) 向服务能力池中里补充，直至将能力池填满。出现新请求时，会根据当前请求权重值 N 拿走 N 个 Token；如果没有足够的 Token 可取，则会阻塞或拒绝请求，从而执行拒绝策略。基于令牌桶算法的服务能力限流器也支持开发和配置自定义的降级策略。

UAV 服务治理不仅支持自定义降级策略，也支持自定义限流器，满足不同用户的不同需求。

三、功能展示

3.1 限流策略配置树

页面根据应用画像以配置树形将应用展示为三层：应用实例层、服务组件层、URL 组件层。如图 2 所示，应用实例层节点代表当前应用实例（仅有一个）；服务组件节点代表当前应用下的某一具体服务组件，如 RS 服务组件，每个服务组件下可能包含 0 个或多个 URL 节点；一个 URL 节点代表应用对外提供的服务的具体 URL。

流量控制策略可以配置在三层中的任意节点上。配置在应用实例层节点可以限制进入整个应用的流量；配置在服务组件节点上可以控制当前服务组件下所有 URL 的流量；配置在 URL 节点上可以限制访问当前 URL 的流量。

图 2 应用配置树

3.2 策略配置及策略下发

策略配置中主要配置限流器、限流器参数、降级策略及降级策略参数。默认限流器是基于令牌桶算法的服务能力限流器，URL 节点需要配置限流阈值和当前节点的请求权重值。请求超过阈值时，默认降级策略会返回 TOOMANYREQUEST。

图 3 策略配置

配置策略完成，通过策略下发按钮将策略下发至目标应用，同时展示当前实时限流状态。

图 4 策略下发结果状态展示

3.3 限流效果及性能展示

图 5 为极简应用（接收到请求后直接返回）场景下的测试结果，包括在压力不断增强的情况下应用原生吞吐量（红线）、安装 UAV 不启用限流的吞吐量（黑线）、安装 UAV 限流 900QPS 时应用接收到的请求量（限流 900 整体，蓝线）、限流 900QPS 时正常处理的请求量（橙线，限流 900 正常请求）及限流 900QPS 时拒绝的请求量（绿线，限流 900 限流请求）。

图 5 应用吞吐量测试

从图 5 中可以看出，对比原生和安装 UAV 无限流情况，UAV 限流对应用的吞吐量影响比较小，基本可以忽略不计。随着请求量的增加，进入应用的正常请求量（橙线）稳定在 900 左右，被限流的请求量随着整体请求量增加而增加，且与未被限流的请求量之和为整体请求量，表明 UAV 限流有效。另一方面，随着请求量的增加，在原生和无限流的情况下，应用吞吐量在 1500 左右达到上限；但在限流 900QPS 的情况下，应用请求量一直在增加，因为超出的请求被直接拒绝，没有进入应用中，从侧面体现了 UAV 限流对应用的保护能力。

图 6 为极简应用场景的测试结果，为应用在压力不断增强的情况下的平均响应时间。在原生和无限流情况下（红线和黑线），应用的平均响应时间随着压力增大而增加，最终在 1300 左右时大幅增加，说明应用的服务能力已经接近极限；在 UAV 限流 900QPS 的情况，正常请求（橙线）的平均响应时间即使超过 1300 达到 2100 时也基本保持稳定，被拒绝的请求的平均响应时间未见大幅变动，应用服务器的平均响应时间也基本保持稳定。UAV 限流对应用实现了有效保护。

图 6 应用平均响应时间测试

总结

服务治理是微服务化场景下的一个重要问题。本文仅简单介绍 UAV 服务治理中服务端限流部分原理和功能展示。由于篇幅有限，暂不详细展开介绍。大家有兴趣可以继续关注 UAVStack 公众号或申请加入官方微信群，相信您一定会有所收获。

本文转载自宜信技术学院网站。

原文链接： http://college.creditease.cn/detail/255