广告业务系统 之 智能保险丝 —— “智能流控”

除了 在 AB 环节 设计了出色的 重试机制 —— “ 双发 ” 外，在 ADX 系统的 核心终端 也存在着另一个 “智能流控” 机制，来保障 服务的健壮性，避免微服务架构中的层级效应。

这样的机制像一个个保险丝，各式各样的、一环嵌一环的 发挥着重要的流量熔断/自愈作用。

智能流控

当投放引擎拿到当前流量的特征时，将会实时请求 不同 DSP 的服务，去获取最新的广告候选信息。而在 ADX 对接的 DSP 中，各家服务的承载力在不同时间是不同的。

如果，我们把 平台全流量都直接灌给 DSP，DSP 却负担不起。可能会将 DSP 服务直接打垮，即使没垮，大量的超时和无响应会将 整个 ADX 服务出口耗时、失败率拉起来，进而造成业务事故。

常规流量调控

注：全链路流程图可参看 暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”

如图示，当投放引擎以 2w 流量并发请求各 DSP 时，将会通过一定规则进行流量干预，确保流量符合 DSP 承载上限。

在分布式部署的投放引擎每个实例中，实例将依据负载均衡的权重 1/4 、当前承载的单实例流量 5k ，去估算出 当前投放引擎下发的总流量 2w 。若超出预期，则 进行适配运算，得出最佳放量规模 2.5k 。

数据源计算

• 实例中当前流量统计，是由 广告业务系统 之 数据中转站 —— “日志中心-实时服务监控” 实时计算得出；
• DSP 服务承载的上限数据是由 广告业务系统 之 承前启后 —— “消息中心” BP 平台 透传给 消息中心，投放引擎侧从消息中心的存储加载而来。

智能流控

常规流量调控中的阈值是 DSP 技术同学评估的数值，实际生产中往往会有悖于此阈值。比如，当发生重大事件，服务稳定性降低；或者节点硬件设备故障；甚至服务功能迭代异常…

生产中如何灵活、动态的判定 DSP 服务的承载能力？并实时适配其等量的流量，是 ADX 中需要注重的重点问题。

这里我们介绍一个系统中常用架构 —— 挂载 模式。

功能挂载

挂载式，通过挂载核心动态阈值脚本，阈值数据的共享，触发流量控制策略。

我们将在服务外部，挂载一个 依托 prometheus 监控数据的 数据计算逻辑。将以 30s 粒度去轮询 DSP 最近 2min 的失败率及超时率。通过设定阈值的方式，做出流量与 DSP 承载力之间的关系决策。比如，超时率 > 5% 或 平均耗时 > 100ms，甚至是 超时率 > 5% && 平均耗时 > 100ms…

基于这个基准，我们做升降权机制。当流量溢出 DSP 承载力时，将做降权调整，以10%的幅度调整阈值；反之，做升权调整，以 2% 的步长增长至初始阈值。

阈值存储

当挂载数据发现，此时处于非常规状态时，将按 上述 “ 步长策略 ” 进行计算实时阈值，并放置于 MC 中。投放引擎会 先取 MC 的数值作为流量调控 阈值；若不存在非常规状态，则以 Redis 中数据阈值为准。

架构长短板

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

• 挂载式的架构模型，最大程度的进行策略解耦，灵活；
• 不足点，也十分明显，依赖外部脚本及第三方组件，当依赖部分出现故障，整体的流控功能将丧失。【一般会搭建对应的实时监控，以告警方式进行触达】

对于一个复杂的 ADX 系统，智能流控这样的设计极大程度的体现了 服务自主性，智能化。为大型业务系统架构设计中，无比珍贵的一环。

服务构建及部署

在 ADX 系统中，全链路涉及 大大小小的微服务 将近 百个。

良好的服务构建和灵活、敏捷的部署能力，是保证广告业务快速交付价值的基石…

---

见后续文章！

推荐阅读：
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
广告业务系统 之 辅助决策 —— “ AB 实验平台”
广告业务系统 之 框架沉淀 —— “数据消费型服务框架”

---

三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…