Skip to main content

moregeek program

详解roma connect api 流控实现技术_wx630f055ce23fc的博客-多极客编程

1、概述

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

详解ROMA Connect API 流控实现技术_高精度

图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业务挑战

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

详解ROMA Connect API 流控实现技术_优先级_02

图2 业务挑战

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

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

3、常见流控技术分析

3.1常见流控逻辑架构

详解ROMA Connect API 流控实现技术_优先级_03

图3 常见流控逻辑架构

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

详解ROMA Connect API 流控实现技术_优先级_04

3.2常见流控算法

3.2.1计数器算法

优点:算法简单易实现。

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

3.2.2滑动窗口算法

详解ROMA Connect API 流控实现技术_优先级_05

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

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

3.2.3漏桶算法

详解ROMA Connect API 流控实现技术_高精度_06

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

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

3.2.4令牌桶算法

详解ROMA Connect API 流控实现技术_高精度_07

优点:(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。

详解ROMA Connect API 流控实现技术_缓存_08

4.3架构设计

  • 采用独立的Controller 方案
  • 独立集群 Controller 提供全局精确高吞吐流控
  • Controller 内部采用 Sharding 机制
  • 采用通用的Policy与Key/Value模型
  • 采用可扩展的 Domain/Policy机制,适应不同业务场景
  • 不同Policy关联不同的算法
  • 提供SDK与Tools,开发API G等插件
  • 提供可重用的SDK与调试工具等
  • 预实现API Gateway等流控插件
  • 外置日志、流控数据分析模块
  • 通过数据挖掘、预测等反馈到配置/策略管理模块,动态修订流控策略

详解ROMA Connect API 流控实现技术_高精度_09

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的负载和流控服务的负载。

©著作权归作者所有:来自51CTO博客作者小二上酒8的原创作品,请联系作者获取转载授权,否则将追究法律责任

没有使用iac的devops系统都是耍流氓_wx630f055ce23fc的博客-多极客编程

作为现代软件工程的基础实践,基础设施即代码(Infrastructure as Code, IaC)是云原生、容器、微服务以及DevOps背后的底层逻辑。应该说,以上所有这些技术或者实践都是以基础设施即代码为基本模式的一种或者多种方法的集合。基础设施即代码并不是一种特定的技术,而是一种解决问题的思路。本文将从基础设施即代码的含义,原则和落地方法三个层面来帮助你理解为什么没有使用IaC的DevOps

mysql事务篇:acid原则、事务隔离级别及事务机制原理剖析_wx630f055ce23fc的博客-多极客编程

引言众所周知,​​MySQL​​数据库的核心功能就是存储数据,通常是整个业务系统中最重要的一层,可谓是整个系统的“大本营”,因此只要​​MySQL​​存在些许隐患问题,对于整个系统而言都是致命的。那此刻不妨思考一个问题:​​MySQL​​在接受外部数据写入时,有没有可能会发生问题呢?有人也许会笑着回答:“那怎么可能啊,​​MySQL​​在写入数据时怎么会存在问题呢”。的确,​​MySQL​​本身在

@transactional注解真的有必要声明rollbackfor属性吗?_wx630f055ce23fc的博客-多极客编程

今天在看spring的事务底层源码时,想到一个问题,@Transactional注解真的有必要声明rollbackFor属性吗?因为之前有许多资料,包括公司的java编码规范上也有提及到这一点。 不知道读者们有没想过这个问题,但我看完源码后,个人觉得是有必要的。见解不到位的话,希望读者能指明。**异常:**如下图所示,我们都知道Exception分为运行时异常RuntimeException和非运

agileboot - 基于springboot + vue3的前后端快速开发脚手架_wx630f055ce23fc的博客-多极客编程

由来AgileBoot这个项目的建立是因为闲暇时间想自己捣鼓一点小东西,于是当时网上找了很多快速开发脚手架。比如Ruoyi/Jeecg-boot/ElAdmin/renren等框架。芋道也弄了一个Ruoyi-Pro的项目,但是功能一大堆,太重了,可能质量得不到保证。最后选择了Ruoyi框架作为自己开发一些小东西的脚手架。首先首先,非常感谢Ruoyi作者整理出这个项目。但是当我把Ruoyi项目翻了一

既生atomicxxx,何生longadder?_wx630f055ce23fc的博客-多极客编程

既生AtomicXXX,何生LongAdder?LongAdder是JDK1.8在​​java.util.concurrent.atomic​​包下新引入的 为了高并发下实现高性能统计的类。不是有​​AtomicInteger​​ 和 ​​AtomicLong​​嘛,咋还蹦出来个​​LongAdder​​???首先,我们要知道的是,无论是​​AtomicInteger​​还是​​AtomicLon

从零到一搭建基础架构-如何构建基础架构模块划分_wx630f055ce23fc的博客-多极客编程

本文将为大家详细介绍如何划分工程内的Maven模块,开发纵享丝滑。一、为什么我们要划分Maven模块我们通过Idea的Springboot脚手架新建一个Springboot工程的时候,项目默认的初始化结构就是单模块结构。我们使用单模块进行MVC的规范进行开发的时候非常的简单粗暴,在单模块下面建立Service包、Mapper包、Contoller包就可以开始开发了。Demo、小型工具类型、小型线上

没有使用iac的devops系统都是耍流氓_wx630f055ce23fc的博客-多极客编程

作为现代软件工程的基础实践,基础设施即代码(Infrastructure as Code, IaC)是云原生、容器、微服务以及DevOps背后的底层逻辑。应该说,以上所有这些技术或者实践都是以基础设施即代码为基本模式的一种或者多种方法的集合。基础设施即代码并不是一种特定的技术,而是一种解决问题的思路。本文将从基础设施即代码的含义,原则和落地方法三个层面来帮助你理解为什么没有使用IaC的DevOps

mysql事务篇:acid原则、事务隔离级别及事务机制原理剖析_wx630f055ce23fc的博客-多极客编程

引言众所周知,​​MySQL​​数据库的核心功能就是存储数据,通常是整个业务系统中最重要的一层,可谓是整个系统的“大本营”,因此只要​​MySQL​​存在些许隐患问题,对于整个系统而言都是致命的。那此刻不妨思考一个问题:​​MySQL​​在接受外部数据写入时,有没有可能会发生问题呢?有人也许会笑着回答:“那怎么可能啊,​​MySQL​​在写入数据时怎么会存在问题呢”。的确,​​MySQL​​本身在

@transactional注解真的有必要声明rollbackfor属性吗?_wx630f055ce23fc的博客-多极客编程

今天在看spring的事务底层源码时,想到一个问题,@Transactional注解真的有必要声明rollbackFor属性吗?因为之前有许多资料,包括公司的java编码规范上也有提及到这一点。 不知道读者们有没想过这个问题,但我看完源码后,个人觉得是有必要的。见解不到位的话,希望读者能指明。**异常:**如下图所示,我们都知道Exception分为运行时异常RuntimeException和非运

【pandas总结】第三节 pandas 的显示设置(总结所有常用显示设置)_这么神奇的博客-多极客编程

在使用pandas时,经常会遇到令人不满意的显示,这时候我们需要调整Pandas的显示设置!显示设置非常的常用,可以给我们写代码带来很多的方便哟~~~ 本文总结所有Pandas 常用的显示设置,相信对后续Pandas的使用会有很大帮助; 1. Pandas 显示所有的行和列 这应该是我们最常用的显示设置了,总有些时候我们想要看df里有什么东西,但是print(df)后发现,pandas打印出来的是

车牌识别(2)-搭建车牌识别模型_domi+1的博客-多极客编程

上一期分享了模拟生成车牌的方法,今天分享一下搭建要给简单的车牌识别模型,模拟生成车牌的方法参看:​​车牌识别(1)-车牌数据集生成​​生成的车牌如下图准备数据集,图片放在path下面,同时把图片名称和图片的车牌号对应关系写入到txt文件,读取对应的数据到变量# 读取数据集 path = './plate2/' # 车牌号数据集路径(车牌图片宽240,高80) data = {}

深度学习基础知识串烧_domi+1的博客-多极客编程

分享一些最近看到的深度学习文章,大概整理了一些基础知识作为入门,1.CNN模型具体分析(AlexNet网络结构)1.1 网络结构AlexNet有5个卷积层和3个全连接层C1:96×11×11×3 (卷积核个数/宽/高/深度)               34848个C2:256×5×5×48(卷积核个数/宽/高/深度)           307200个C3:384×3×3×256(卷积核个数/宽