​​摘要:ROMA 平台的核心系统 ROMA Connect 源自华为流程 IT 的集成平台,在华为内部有超过 15 年的企业业务集成经验。

本文分享自华为云社区《ROMA集成关键技术(1)-API流控技术详解》,作者:中间件小哥 。

1、概述

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

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_ROMA Connect

图 1 ROMA Connect 功能视图

 

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

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

2.1 流量控制的动因

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

 

  • 流控的价值

1. 提升系统稳定性/防止雪崩

2. 保障高优先级服务

3. 降低响应时延,提升用户体验

4. 提升系统有效吞吐量

5. 限制性业务使用等

6. …

 

  • 流控的目标参数

1. 限制总并发数(比如数据库连接池、线程池)

2. 限制瞬时并发数(如 nginx 的 limit_conn 模块)

3. 限制时间窗口内的平均速率

4. 限制远程接口调用速率

5. 限制 MQ 的消费速率

6. 限制网络流量

7. 限制 CPU 与内存的使用率

8. …

2.2 业务挑战

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

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_API Gateway_02

图 2 业务挑战

 

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

 

  • 每天 10 次与每分钟 10 万次的流控同时存在

  • 流控反馈周期比流控周期还久

  • 流控的维度特别多

  • 流控同步处理时间影响用户体验

  • 流控静态设置,要么过高要么过低

  • 流控失效造成业务失效

  • 流控节点部署复杂资源消耗高

3、常见流控技术分析

3.1 常见流控逻辑架构

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_华为_03

图 3 常见流控逻辑架构

 

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

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_ROMA Connect_04

3.2 常见流控算法

3.2.1 计数器算法

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_华为_05

优点:1. 算法简单易实现。

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

3.2.2 滑动窗口算法

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_集成平台_06

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

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

3.2.3 漏桶算法

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_华为_07

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

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

3.2.4 令牌桶算法

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_API Gateway_08

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

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

4、ROMAConnect 流控技术实现

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 后流控的精度。

  • 当 RatelimitController 服务终止的时候,RatelimitSDK 支持自动降级。

  • 根据 API Gateway 采集的 API Response latency 等信息反馈,支持动态调整流控策略。

  • 支持 SLA-Based 流控 Policies。

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_集成平台_09

4.3 架构设计

  • 采用独立的 Controller 方案

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

Controller 内部采用 Sharding 机制

 

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

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

不同 Policy 关联不同的算法

 

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

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

预实现 API Gateway 等流控插件

 

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

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

详解 API Gateway 流控实现,揭开 ROMA 平台高性能秒级流控的技术细节_ROMA_10

4.4 内置算法

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

令牌桶算法的问题:

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

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

 

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

 

缓存:

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

  • 采用 FCFS 算法处理请求。

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

 

令牌

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

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

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

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

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

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

问题:高精度、高吞吐的矛盾

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

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

 

提出一种高精度高吞吐量的流控算法 HAT(High Accuracy, HighThroughput)

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

  • 设流控阈值为 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 调用流的动态流控策略。

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

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

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

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

 

点击关注,第一时间了解华为云新鲜技术~