服务的高可用 —— 智能流控设计

Posted 2022-07-20 魏小言

目录

智能流控

背景

动态阈值及流量控制

动态阈值

流量控制

优势及不足

附录

---

智能流控

智能流控，听起来是流量的拆分控制。不错，就这回事，下面以广告业务为例来讲解，如何设计搭建一智能流控机制。

背景

当 A 模块从上游模块拿到倒排、召回后的广告投放计划后，会以并发的方式请求 各家 dsp 获取各自广告的出价、尺寸，等广告信息。在并发请求时，响应时间由最后返回的 dsp 决定。最坏情况是 dsp 超时无反馈，响应时间由默认配置的最大超时时间决定，此时会拖慢整个 A 服务，同时广告链路各微服务之间产生连级反应，整条链路被影响。由于 上游对 dsp 服务的承载能力及容灾等情况不可控，故需要对其做流控策略。

动态阈值及流量控制

在智能流控策略中，依赖的组件有  memcache\\redis\\prometheus。架构模型是挂载式，通过挂载核心动态阈值脚本，阈值数据的共享，触发流量控制策略。下面依次讲解，动态阈值脚本 及 流量控制策略。

动态阈值

在动态阈值脚本中，我们达到智能、动态的前提是，有个阈值的基准。这个一般是由 dsp 接入时，有双方技术判定的服务承载健康值。比如，QPS 支撑 5000……

基于这个基准，我们做升降权机制。当流量溢出 dsp 承载力时，将做降权调整，以10%的幅度调整阈值；反之，做升权调整，以 2% 的步长增长至初始阈值。那么如何做出流量与 dsp 承载力之间的关系判断呢/？

这个时候，我们依赖流处理组件 prometheus，我们以 30s 粒度去轮询  dsp 最近 2min 的失败率及超时率，通过设定阈值的方式，做出流量与 dsp 承载力之间的关系决策。比如，超时率 > 20% 或 平均耗时 > 100ms，甚至是 超时率 > 10% && 平均耗时 > 80ms…

流量控制

在流量控制策略中，我们是持有了两份流量阈值数据，一份是 memache（动态值），一份是 redis （初始值）。两份优先级是 memache > redis 。拿到有效的阈值后，服务会读取最近 2m 的 QPS/120 依据当前机器的权重计算总 QPS 与 阈值做对比，做出是否调控的判定。判定后，将产生 0～总QPS的 随机数，命中 0～阈值的部分流量正常请求，反之进行留存数据后抛弃。比如，当前有 5 个节点，平均 20 的 QPS，此时阈值为 80。则单台计算如下，20 * 5 = 100 > 80 ，20 * 80/100 = 16 ，将保持 16 的 QPS 进行请求。

优势及不足

挂载式的架构模型，最大程度的进行策略解耦，灵活。

动态阈值脚本 配合 流量调控策略 两部分独立并协作构成一智能流控系统，将文首的问题进行了消除。在升降权机制中，可任意配置化控制平滑过度的粒度大小。

不足点，也十分明显，依赖外部脚本及第三方组件，当依赖部分出现故障，整体的流控功能将丧失。【一般会搭建对应的实时监控，以告警方式进行触达】

附录

相关智能流控架构流图，可私信或者关注公众号获取。