蚂蚁大促场景下的全链路压测体系构建与保障实践

1. 蚂蚁大促场景下的全链路压测体系构建与保障实践刘凯宁

2. 个人简介刘凯宁 ⚫ 蚂蚁集团 SRE 技术专家 ⚫ 多次参与蚂蚁集团超大型活动的稳定性保障，承担过大促保障队长、全链路压测负责人、全链路资源容量负责人、全链路资金安全保障负责人等角色 ⚫ QCon 2024 上海站明星讲师

3. 目录 01 蚂蚁大型活动保障架构概览 02 蚂蚁全链路压测体系 03 蚂蚁大促全链路压测实战 04 未来已来！AI 压测初探

4.

5. 01 蚂蚁大型活动保障架构概览

6. 引子：大促活动形式及特点 ① 支付峰值型大促 ② 玩法峰值型大促挑战点1：支付宝 SKA 商户峰值时间不确定挑战点1：伴随营销秒杀抢券 /红包发放，资金 /客诉风险高挑战点2 ：超级大促支付秒杀峰值高，链路压力巨大挑战点2 ：玩法多样复杂， C 端用户行为难以预测准确挑战点3 ：支付商户聚集，极易引发支付链路热点挑战点3 ：通常带来端增，整个 APP 以及在离线链路压力巨大支付链路瓶颈点瓶颈点异步化峰值时间不确定全链路自适应降级改造单商户热点高峰值验证算发奖提前演练对客风险识别布防用户动线分析端增流量分析 /限流会场玩法流量预估数据链路分层降级客户端离屏灰度商户热点优化提前布防常态化压测线上流量覆盖薄弱点梳理模拟外部流量异步化+ 自适应降级全链路压测/仿真分析极端流量防御多层限流/降级

7. 蚂蚁大促分级及活动保障 SOP 匹配大促 SOP 大促分级评估因素因素分级 M 人用户人群 N 人 X 人 Y 人整个个公司大型部门部门分级保障活动信息 S+ 级时间/玩法/峰值 XX 项保障动作、X 种角色参与必选（可选）资源评估 & 交付资金安全保障信息提报门禁中型部门小型部门 S 级 XX 项保障动作、X 种角色参与 M 元预算客户端保障 N 元全链路压测 X 元 Y 元大型部门负责人活动发起人业务形态 XX 项保障动作、X 种角色参与全链路压测门禁二三方保障中型部门负责人 B 级预案& 限流小型部门负责人封网& 变更管控节日氛围秒杀抢购活动上线前N 天门禁 A 级线上值班 XX 项保障动作、X 种角色参与

8. 蚂蚁大促保障整体流程

9. 什么是容量风险？在SRE （Site Reliability Engineering ，站点可靠性工程）领域中，“容量风险” （Capacity Risk）指的是：系统当前或未来可能因资源容量不足，无法满足用户需求或业务增长，从而导致性能下降、服务不可用或用户体验恶化的潜在风险。

10. 容量风险的本质：如何承接高并发流量？

11. 02 蚂蚁全链路压测体系

12. 全链路压测定义全链路压测是模拟真实业务场景流量，对完整系统链路（前端→后端→数据库等）进行高并发压力测试，发现性能瓶颈与单点故障，确保系统在峰值（如大促）下稳定运行。通过流量染色、影子表等技术实现零业务影响 —— From Ling- 1T 蚂蚁全链路压测特点典型使用场景

13. 蚂蚁全链路压测平台架构介绍压测管理平台压测管控模块项目管理场景管理压测管理压力机管理压测监控成员管理构建场景流量配置压力机上下线系统监控脚本管理数据管理压测执行压力机扩缩容流量监控报告管理监控管理压测记录压力机状态压力机监控分发调度压力机注册心跳检查监控汇总压力机模块脚本部署监控上报脚本执行注册 & 心跳压测风险模块压测窗口及白名单压测熔断压测前置校验

14. 蚂蚁全链路压测平台核心技术介绍_全链路染色打标生产流量应用服务流量接入层缓存中间件数据库基于 Trace 实现全链路上下文传递压测标压测流量压测标流量接入层透传压测标压测标应用服务判断压测标实现压测逻辑压测标压测标压测标中间件缓存数据库判断压测标接受或隔离压测请求判断压测标读写压测 Key 判断压测标读写压测表

15. 蚂蚁全链路压测平台核心技术介绍_压测隔离应用层中间件层缓存层存储层以消息中间件为例读写请求入口逻辑压测标正常逻辑生产消息压测消息消息 Pub 消息 Pub 压测逻辑出口逻辑压测消息白名单消息 Sub 读写请求压测标统一入口正式 Key 压测 Key 消息 Sub 统一缓存集群压测标正式表压测表统一数据库集群

16. 蚂蚁全链路压测平台核心技术介绍_压测前置风险校验压测前置校验压测起量之前，主动进行容量、中间件、限流、预案等风险的校验，提前感知并解除压测风险，避免压测过程中出现低级问题

17. 蚂蚁全链路压测平台核心技术介绍_压测熔断压测熔断：及时发现压测链路中的各种异常，快速、有效地阻隔压测风险

18. 蚂蚁全链路压测平台核心技术介绍_压测熔断_举例系统error熔断：监测应用的系统报错日志量级，超过特定阈值则会触发熔断熔断场景：被压测应用的系统报错量级上涨熔断时效：秒级，20 秒之内熔断要求：应用需要接入标准日志框架，并配置熔断报错阈值

19. 蚂蚁全链路压测平台核心技术介绍_压测溯源定位压测溯源：通过应用 appName 查询该应用当前的压测情况，快速获取某一应用被哪个场景压测，便于进行压测来源判断，异常情况下能够及时应急处理

20. 蚂蚁全链路压测平台核心技术介绍_压测窗口及白名单为统一管理压测流量，同时尽可能降低压测对线上产生影响，特设置多维度的压测管控窗口日常窗口早高峰大促窗口 XX 大促压测管控时间段 X 小时临时窗口重大事件全站封网 X 小时午高峰晚高峰 Y 小时其余时间都可以进行压测 Z 小时 XX 大促相关场景非大促其他场景线上故障正在处理 Y 小时压测平台临时封网所有场景不可压测容灾演练正在切换可以压测不可压测 Z 小时高峰期管控时间按照业务实际情况来定压测白名单机制 ◼ 原则上压测管控窗口期间需要严格按照封网要求进行压测变更管控，但在落地执行的时候实际情况可能较为复杂，本着实事求是的考虑，压测平台有白名单机制，允许某压测场景在一定时间之内可以不受压测窗口管控 ◼ 当前申请压测白名单需要走审批，审批人为申请人主管 + 压测平台管理员

21. 03 蚂蚁大促全链路压测实战

22. 全链路压测基本流程压测前压测中压测后

23. 压测风险 ⚫ 压测配置未完全与生产配置分开 ⚫ 压测之前应用未扩容到位 ⚫ 压测标记未透传，链路不通 ⚫ 不同 Zone 的机器不均匀 ⚫ 压测表未创建，数据库报错 ⚫ 压测限流未配置 ⚫ 缓存未使用压测 key，污染生产集群 ⚫ 压测熔断配置没开 ⚫ 未配置压测监控，压测期间未正确盯盘 ⚫ 起量过快，系统某些节点无法承载瞬间高压流量 ⚫ 线上有异常未及时感知并停压

24. 容量评估与资源准备单接口读写模型图整体流量模型图资源需求汇总表图只做示例，数字隐藏具体依赖视实际情况来定应用名总计 QPS 资源需求具体机房分配主应用 xxx QPS xxx cores 城市A ：xxx1 cores 城市B ：xxx1 cores 下游应用 01 xxx QPS xxx cores 城市A ：xxx1 cores 城市B ：xxx1 cores 下游应用 02 xxx * 2 QPS xxx cores 城市A ：xxx1 cores

25. 压测脚本编写、调试、验证压测基本概念压测前期准备 ⚫ 按照流量模型确认被压接口 ⚫ 为每个被压接口准备起量压测脚本 ⚫ 调试压测脚本并进行压测验证

26. 压测配置与资产准备压测配置：一般分为全局配置和业务自定义配置。全局配置一般用于通用内容配置，例如访问地址、环境信息等内容；业务自定义配置一般实现在业务接口中，在压测期间会推送对应的压测开关、压测特定配置等，来保证全链路压测能走通压测数据资产：用于业务流或业务单元脚本中需要用到的压测数据，一般是压测用户资产；在执行压测时，压测中心会将压测数据分发到各台压力机中，用于压测任务的执行全链路压测必须搭配压测配置及压测数据资产压测流量压测用户资产流量接入层识别压测用户压测标应用服务读取压测配置兼容压测逻辑压测标压测标中间件执行压测隔离、压测白名单、压测挡板等逻辑压测标缓存数据库透传压测逻辑读写压测 key 执行压测路由读写压测表

27. 压测计划制定由于全链路压测涉及到的范围广、链路长、人员众多，压测负责人必须制定详细的压测计划，以便压测过程顺利、压测问题及时解决，助力全链路压测尽快达成既定目标压测范围 ◼ ◼ ◼ ◼ 压什么场景？压哪些接口？涉及到哪些应用？可能会影响哪些业务？压测模型 ◼ 每个场景要压多少量级？ ◼ 核心应用总计要承接多少流量？ ◼ 哪些链路节点需要降级？ ◼ 机器资源是否扩容完毕？压测组织 ◼ 全链路压测需要哪些人员必须到场配合？ ◼ 整体压测形式是现场压测还是线上压测？ ◼ 压测要组织几个场次？压测执行 ◼ 每场压测具体起量计划是怎样的？ ◼ 压测需要重点关注哪些监控大盘？ ◼ 压测问题如何记录？ ◼ 压测复盘如何进行？

28. 压测执行及盯盘

29. 压测准出整体压测结论：压测是否通过？压测到量情况系统负载情况 ◼ 各个接口目标量级、压测量级、到量百分比 ◼ 业务指标：峰值成功量、峰 ◼ 各个下游服务依赖的实际到量情况 ◼ 系统指标： CPU 水位、内存压测产出值成功率、峰值耗时水位、JVM 情况、线程池情况、DB 负载、缓存负载…… 压测报告系统峰值水位截图压测问题情况 ◼ 已解决的问题：问题数量、问题原因、问题当前状态当前风险情况 ◼ 当前压测还遗留哪些风险？是否需要上升解决？ ◼ 未解决的问题：问题原因、问题跟进人、问题解决要求时间、问题当前状态压测到量监控截图压测执行记录链接压测问题记录列表

30. 04 未来已来：AI 压测初探

31. AI 链路的特点传统业务关注的核心指标总量 CPU 水位成功量峰值 QPS 对比传统业务链路， AI 业务链路最关注的技术风险目标：平均耗时网络延迟 ◼ 重点关注同一个业务场景在不同模型下的业务表现差异 ◼ 从提示词调优、全链路可观测、输出结果评测等多方面进行业务表现评估 ◼ 为用户交付优质结果的同时加强大模型风险管理 ◼ 重点关注端到端 TTFT 指标，持续优化 AI 业务链路各阶段耗时情况 ◼ 从基模选择、AI 服务多机房部署、 GPU 容量供给、全链路延迟可观测等方面提升用户体验 ◼ 为 AI 业务效果交付极速服务的同时提升 AI 保障效率 ◼ 重点关注 AI 服务层、AI 基础设施层的稳定性 ◼ 从模型部署成功率、AI 可观测、超大 GPU 集群调度等方面加强技术风险能力建设 ◼ 为 AI 服务保驾护航的同时兼顾 AI 成本

32. AI 链路压测实践

33.

34. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software