- 尽可能在 Filter/SDK 级别处理，避免流控请求影响业务时延
- 尽可能少上报到 Controller，降低 Controller 负载提升 Controller 效率
- 立足API Gateway第一个应用场景
- Controller 不需理解具体业务，由基于SDK封装的Filter适配具体业务与流控Controller
- 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系统的能力配置令牌的数量 。
- 当低优先级的请求到达时，如果高优先级的令牌量大于预留的数量，也可分配高优先级的令牌给该低优先级的请求 。对令牌设置预留量，保证低优先级请求不会耗尽高优先级的令牌 。
- 每种颜色的令牌有单独的请求缓存 。
- 问题：高精度、高吞吐的矛盾
- 为了实现高精度流控，API Gateway需要为每个API请求发送流控请求至流控服务，会很大程度降低处理请求的吞吐量 。
- 为了提高吞吐量 ， API Gateway需降低发送流控请求的频度，这会降低流控的精度 。发送流控请求的频度越低，流控的精度越低 。
- 提出一种高精度高吞吐量的流控算法HAT（High Accuracy, High Throughput）
- 把流控分为自主流控阶段和流控服务流控阶段 。
- 设流控阈值为L，自主流控阈值为S，API Gateway集群节点数量为N，当前流控周期内已经处理的API数量为R 。
- Go_Goroutine详解
- Go_Channel详解
- Docker | 容器数据卷详解
- MyBatis之ResultMap的association和collection标签详解
- Future详解
- Go的网络编程详解
- gorm中的关联操作详解
- Go中的闭包、递归
- liunx之expect操作详解
- 条件期望：Conditional Expectation 举例详解之入门之入门之草履虫都说听懂了
