详解ROMA Connect API 流控实现技术

1、概述

ROMA平台的核心系统ROMA Connect源自华为流程IT的集成平台，在华为内部有超过15年的企业业务集成经验。依托ROMA Connect，可以将物联网、大数据、视频、统一通信、GIS等基础平台及各个应用的服务、消息、数据统一集成适配以及编排，屏蔽各个平台对上层业务的接口差异性，对上提供服务、消息、数据集成使能服务，以支撑新业务的快速开发部署，提升应用开发效率。适用于平安园区、智慧城市、企业数字化转型等场景，图1展示了ROMA Connect的功能视图。

图1 ROMA Connect功能视图

其中APIC(APIC Connect)作为核心组件包含了API Gateway能力，承载了API的集成和开放能力，流控作为API Gateway的关键特性，为用户的API集成、开放提供了快速、有效的安全防护，本文将详细描述API Gateway流控实现，揭开高性能秒级流控的技术细节。

2、高并发高吞吐系统流控需求

2.1流量控制的动因

在高并发高吞吐系统中，通常的技术关键词是降级、缓存、流控等，流控更是其中的核心技术，当然，这些技术是相辅相成的。

1、流控的价值

• 提升系统稳定性/防止雪崩
• 保障高优先级服务
• 降低响应时延，提升用户体验
• 提升系统有效吞吐量
• 限制性业务使用等
• …

2、流控的目标参数

• 限制总并发数（比如数据库连接池、线程池）
• 限制瞬时并发数（如nginx的limit_conn模块）
• 限制时间窗口内的平均速率
• 限制远程接口调用速率
• 限制MQ的消费速率
• 限制网络流量
• 限制CPU与内存的使用率
• …

2.2业务挑战

在大业务场景下，主要挑战是高并发、低时延、高精度、多维度灵活扩展等诉求。

图2 业务挑战

而对于流控的具体挑战如下：

• 每天10次与每分钟10万次的流控同时存在
• 流控反馈周期比流控周期还久
• 流控的维度特别多
• 流控同步处理时间影响用户体验
• 流控静态设置，要么过高要么过低
• 流控失效造成业务失效
• 流控节点部署复杂资源消耗高
• …

3、常见流控技术分析

3.1常见流控逻辑架构

图3 常见流控逻辑架构

各种方案的优缺点如下表所示：

3.2常见流控算法

3.2.1计数器算法

优点：算法简单易实现。

不足：（1）输出不平滑。（2）有临界问题，在流控周期边界处易发生输出激增，大幅超过流控阈值，冲坏后端服务。

3.2.2滑动窗口算法

优点：（1）可以解决计数器算法的临界问题。（2）算法简单易实现。

不足：（1）精度要求越高需要的窗口格子越多，内存开销较大。（2）不保证输出平滑。

3.2.3漏桶算法

优点：（1）输出速度与输入速度无关，是恒定的，流控效果平滑。（2）无临界问题。（3）不依赖令牌。

不足：（1）由于漏桶输出速度恒定，所以不支持一定程度的突发请求。（2）如果桶满，输入数据会被丢弃

3.2.4令牌桶算法

优点：（1）允许一定程度的突发流量。（2）通过定制令牌添加方法，可定制复杂的流控策略。（3）无临界问题。

不足：（1）当桶内无可用令牌时，输入请求会被直接丢弃。（2）不支持按优先级处理输入请求。

4、ROMA Connect流控技术实现

4.1总体策略

• 对高精度与高吞吐进行分层，区别不同场景的流控，采用不同策略与算法

• 对高精度低吞吐流控进行持久化； 高吞吐高频纯内存计数策略

• 高吞吐高频流控， 不进行 HA 保障， 故障后数据清零重新计算

• 多维度多优先级，采用Policy 多维度控制，单一请求可触发多Policy

• 解耦复杂控制， 采用多条简单策略分别映射；降低用户使用复杂度

• 单一请求可触发所有满足条件的 Policy， 进行综合流控

• 通过分发策略、异步、批申报等机制，降低请求时延与降低Controller 工作量

• 尽可能在 Filter/SDK 级别处理， 避免流控请求影响业务时延

• 尽可能少上报到 Controller， 降低 Controller 负载提升 Controller 效率

• Filter 与算法门限降级放通，避免Ratelimit机制故障对业务造成影响

• 采用KEY/VALUE 模式和多维，提供通用机制，适应不同场景不同应用流控诉求

• 立足API Gateway第一个应用场景

• Controller 不需理解具体业务，由基于SDK封装的Filter适配具体业务与流控Controller

4.2逻辑视图

• RateLimit SDK访问根据一致性hash访问sharding后的RateLimit Controller，对于高吞吐高精度的流控集中在Controller内存进行限流计算。
• RateLimit Controller对于高精度高吞吐只集中在本地内存计算，无需考虑crash后保留历史限流信息。
• RateLimit Controller对于高精度低吞吐的限流采取异步持久化策略，确保Controller crash后流控的精度。
• 当Ratelimit Controller服务终止的时候，Ratelimit SDK支持自动降级。
• 根据API Gateway采集的API Response latency等信息反馈，支持动态调整流控策略。
• 支持SLA-Based 流控 Policies。

4.3架构设计

• 采用独立的Controller 方案

• 独立集群 Controller 提供全局精确高吞吐流控

• Controller 内部采用 Sharding 机制

• 采用通用的Policy与Key/Value模型

• 采用可扩展的 Domain/Policy机制，适应不同业务场景

• 不同Policy关联不同的算法

• 提供SDK与Tools，开发API G等插件

• 提供可重用的SDK与调试工具等

• 预实现API Gateway等流控插件

• 外置日志、流控数据分析模块

• 通过数据挖掘、预测等反馈到配置/策略管理模块，动态修订流控策略

4.4内置算法

4.4.1带缓存带颜色的令牌桶算法

• 令牌桶算法的问题：

• 当无可用令牌时， 请求会被立即拒绝。而用户可能会继续不断发送请求，直到有可用的令牌。这会增加API Gateway的负载和流控服务的负载。

• 所有的请求以同样的概率获得令牌，不支持优先级。而在实际应用中，一些请求需要被优先处理，另一些请求可以被延迟处理或者直接拒绝。例如，应该优先处理电子商务网站的付款请求，而浏览商品的请求可以被延迟处理。

• 设计了一种支持缓存和优先级的令牌桶算法

• 缓存：

• 当无可用令牌时，把请求暂时放在请求队列里，待有可用令牌时再处理。

• 采用FCFS算法处理请求。

• 如果缓存也无可用空间，就直接拒绝请求。

• 令牌

• 令牌分为多种颜色，不同颜色代表不同优先级，如绿色、黄色、红色表示优先级由高至低。

• 在API配置文件里，可配置不同API的优先级。根据预先配置的优先级，对请求分配相应颜色的令牌。如果请求没有优先级，则使用默认优先级。

• 根据API Gateway系统的能力配置令牌的数量。

• 当低优先级的请求到达时，如果高优先级的令牌量大于预留的数量，也可分配高优先级的令牌给该低优先级的请求。对令牌设置预留量，保证低优先级请求不会耗尽高优先级的令牌。

• 每种颜色的令牌有单独的请求缓存。

4.4.2高精度高吞吐量的流控算法

• 问题：高精度、高吞吐的矛盾

• 为了实现高精度流控，API Gateway需要为每个API请求发送流控请求至流控服务，会很大程度降低处理请求的吞吐量。

• 为了提高吞吐量，API Gateway需降低发送流控请求的频度，这会降低流控的精度。发送流控请求的频度越低，流控的精度越低。

• 提出一种高精度高吞吐量的流控算法HAT（High Accuracy, High Throughput）

• 把流控分为自主流控阶段和流控服务流控阶段。

• 设流控阈值为L，自主流控阈值为S，API Gateway集群节点数量为N，当前流控周期内已经处理的API数量为R。

• 流控服务计算：自主流控阈值S = L/N，并分发给每个API Gateway节点。

• 在自主流控阈值范围内，每个API Gateway节点可做自主流控，无需向流控服务发送流控请求。

• 当API Gateway集群中有一个节点的API请求量超过自主流控阈值–α时，该节点发送流控请求至流控服务，申请新的流控阈值。此时，流控服务联系API Gateway的其它节点获得它们处理的API请求量。然后，流控服务重新计算自主流控阈值S = （L – R）/ N，并发送给各个API Gateway节点。

• 当流量余额 < δ时，不再更新自主流控阈值。

• 当进入下一流控周期时，流控服务重置S，各API Gateway节点联系流控服务更新自主流控阈值。

• 算法分析

• 设u是单个流控周期内自主流控阈值更新的次数，Pi表示第i个API Gateway节点处理API的速度。

• 单个流控周期的流控请求的数量由L降至u*N。

• 最优情况是API Gateway集群的每个节点的性能完全一样，此时，u = 1。当流控阈值是10000，API Gateway节点数量是10时，单个流控周期的流控请求从10000降至10。

• API Gateway集群的每个节点的性能越接近，u越接近1。API Gateway集群的每个节点的性能差距越大，u越大。

4.4.3动态流控算法

基于运行状态、趋势、API调用链进行动态流控。

• 请求取得令牌后，流控服务开始处理请求，生成流控响应（接受/拒绝，降级，或黑白名单）。

• 基于运行状态的动态流控策略

• 根据使用网络状态（可用连接数，网络延迟），请求处理延迟，API Gateway的cpu、memory等运行状态，动态修改流控阈值。也可等等。

• 当cpu、内存等使用率远小于阈值时，正常处理请求。

• 当cpu、内存等使用率接近阈值时，降低流控阈值（降级），减少API Gateway的负载。

• 当cpu、内存等使用率超过阈值很多时，提高降低流控阈值的速度。

• 当无可用cpu、内存时，直接拒绝请求。

• 当cpu、内存等使用率降低至正常水平时，恢复流控阈值。

• 基于运行状态趋势的动态流控策略

• 利用机器学习，分析历史数据，生成预测模型，预测API Gateway的负载，提前修改流控阈值或降级服务，保证API Gateway负载平滑稳定。

• 利用机器学习发现应加入黑名单的请求。

• 基于API调用流的动态流控策略

• Case: API调用流。

• 设计一种基于API调用流的动态流控策略。

• 利用机器学习发现API调用流。流控服务保存API调用关系。

• 当系统负载较高时，当一个API请求达到阈值被限流后， 对于相关联的同一层次和低层次的所有API请求，不再访问Redis获取实时数据和处理，而是直接延迟处理或拒绝。

• 当API Gateway系统负载正常时，不启动该动态流控策略。

• 通过这种方式，可在基本不影响API处理速度的前提下，降低API Gateway的负载和流控服务的负载。