背景
应用微服务化场景下，随着服务个数的增加，服务之间的相互调用变得更加复杂，服务治理需求愈加突出，其中服务流量控制是服务治理中的重要一环。
当前常用的流量控制方案主要有基于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服务治理默认支持两种限流器：时间段计数限流器和基于令牌桶算法的服务能力限流器。
时间段计数限流器通过原子量累计时间段内请求个数。当请求个数超过限制总数时，执行降级策略。默认的降级策略是终止请求处理流程，返回TOOMANYREQUEST。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公众号或申请加入官方微信群，相信您一定会有所收获。
官方网站：https://uavorg.github.io/main/
开源地址：https://github.com/uavorg
UAVStack已在Github上开放源码，并提供了安装部署、架构说明和用户指南等双语文档，欢迎访问-给星-拉取~~~
作者：曾礼
原文发布于：UAVStack智能运维
