微盟全链路压测：如何帮助电商业务实现 10 倍性能提升？
一分钟精华速览
全链路压测之所以被誉为电商大促备战的 “核武器” ，是因为它基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，能真实反映系统的状况，对系统风险和瓶颈真正做到心中有数。
微盟作为电商 SaaS 的龙头企业，支撑着数十万中小电商企业的经营，那么在电商大促中微盟系统面临过哪些容量保障挑战？他们的全链路压测又是如何发挥作用的？ 
作者介绍
微盟非功能测试负责人——赵金龙
TakinTalks 稳定性社区专家团成员，2017 年加入微盟，曾就职于上海北斗、携程，多年来一直从事性能和稳定性保障相关工作；目前担任微盟质量保障部非功能测试团队负责人，负责微盟非功能测试体系建设，多次担任大型项目一号位，带领团队完成了全链路压测体系从 0 到 1 的建设与落地；主导压测平台、故障演练等平台的建设。
温馨提醒：本文约 4400 字，预计花费 7 分钟阅读。
后台回复 “交流” 进入读者交流群；回复“1071”获取课件资料；
一、背景
微盟作为一家互联网电商企业，服务着众多商户，在电商促销活动期间，比如 618、双 11、双 12 等，微盟系统需要支持众多商户的大促活动，导致我们在这些活动期间的故障数量较多，在 2020 年之前微盟基本每次大促期间都会出现线上的事故。 
针对这些事故复盘后我们总结出很多不足，其中压测这部分的问题我简单地列了几点——
1、单接口压测为主
2、各业务单独压测
3、压测场景不够真实
4、压测工具不能满足高 QPS 复杂场景压测
基于这些不断的线上事故和复盘出来的问题点，我们下定决心在 2020 年双 11 期间落地全链路压测。
二、落地全链路压测遇到了哪些挑战？
从 2020 年 4 月份开始立项来做全链路压测，一直到双 11 大促的整个项目落地期间，我们前后做了比较周密的筹备。
2.1 方案调研
首先是方案调研，我们了解到全链路压测的目标是让一切压测结果更加真实，让压测更接近真实的用户场景，所以压测环境我们需要尽可能还原真实的线上环境；压测数据要切合真实的交易场景以及对应的数据量级；压测流量模型是非常重要的，它需要和真实业务情况保持一致；压测流量发起需要模拟真实的用户请求，在很复杂的流量模型下也能发起压测流量；问题定位要求我们有完善的监控和告警系统，以协助服务端快速定位问题。 
2.2 微盟当时现状
在公司内部推进全链路压测，我们面临了非常大的挑战，实际上在 2020 年之前我们每年都会讨论落地全链路压测，但最终都因为改造成本问题没有实施。
推进的阻力主要是基础架构组件版本不一致，各个业务方都有自己的技术栈，一些中间件、组件等选型使用都不一样，还有一些异步、回调通知、Job 等等，我们要针对这些问题做改造来实现全链路压测，成本是非常高的。
2.3 方案设计
为了应对 2020 年双十一的流量冲击，我们的实施方案经过了很多轮讨论，下图是我们最终的实施流程，线上全链路压测我们需要做流量识别改造、数据隔离改造、影子存储的配置。 
我们在改造的同时，也部署了一套独立的全链路压测环境，基本复刻了核心业务线的线上环境，快速同步线上应用及配置，直接同步线上数据并脱敏，在双 11 之前我们先在全链路压测环境做了大量的压测工作，包括各核心业务线的压测，以及全链路压测，在改造完成后，我们再在线上环境做全链路压测验证。
流量场景构造、压测执行等等，都依赖着压测的工具端，就会涉及到压测平台，所以在全链路压测项目立项后，对应的压测平台我们也做了独立的研发立项，这个在后面的平台建设部分再做详细介绍。
2.4 微盟流量模型
2.4.1 核心交易链路场景
前面有提到微盟的流量模型是非常复杂的，这是我们的核心链路模型。微盟是以电商零售业务为主的 SaaS 服务商，业务和天猫、京东有很多相似之处，核心以交易链路为主。 
2.4.2 不同入口流量模型
我们会有各种促销引流场景，比如拼团、秒杀等，也接入了很多渠道商引流，比如微信 H5 小程序、支付宝小程序、抖音、百度等，这里面包括各类优惠券引流以及活动商品引流等，在 2020 年还有一个非常火的场景是直播，直播业务场景也是我们非常核心的流量来源。
2.4.3 流量比例模型
压测业务各个场景的流量比例模型是怎么获取？我们基于像 618 这类大型活动的峰值数据去做一些基础数据，在双 11 期间翻倍去压测；还有其他的方式，如 CAT 统计交易配比，去统计不同活动期间的峰值流量模型。
2.5 压测平台的挑战
在双 11 期间我们做了多条业务线的验证，其中最核心的两条业务线就是电商零售和直播业务压测，另外还有一些营销活动等多条业务线需要混合压测。我们梳理出来的核心接口有 100 +，当时以 618 的流量峰值做了翻倍的目标，目标 QPS 需要达到 12 万+。
这里我简单列了当时的压测场景，可以看到每个业务线都有非常多的接口，我们要尽可能都去压测，包括每个接口都有它的目标 QPS 需要手动设置。
（2020 年微盟双十一直播场景核心链路，接口众多）
（2020 年微盟双十一零售场景核心链路，接口众多）
同时，压测平台是面向整个研发中心各个业务线去做的，所以涉及到的人会非常多，平台对于多人协作也有一定的要求，比如压测脚本创建、压测数据构造、压测实时结果查看等，在压测期间，压测团队和研发团队都会实时地查看压测结果，分析压测期间的瓶颈点，所以这对于压测平台也是非常大的挑战。
三、全链路压测平台建设有哪些技术要点？
前面有提到在 2020 年我们做全链路压测立项的同时，压测平台也单独做了立项，在立项之前的 2019 年，压测只是微盟质量平台的一个模块，且模块功能也比较简单，所以顺着全链路压测的项目，2020 年 9 月压测平台 1. 0 版本正式上线，承担了双 11 期间的压测任务执行。
2020 年-2022 年我们对平台做了很多优化，比如 2021 年我们对压测模型、场景设计、压测报告做了优化，2022 年我们主要对监控和调用链分析做了一些优化。接下来我就微盟压测平台的建设，给大家具体做一些分享。
3.1 工具选型
在压测平台建设之前，还是单独压测模块时，我们已经对工具做了一些选型，当时不同的业务团队使用的工具是不统一的，主要使用的有两个压测工具，Ngrinder 和 Jmeter。这里可以看到每种工具都有其优缺点，比如，Ngrinder 是 B/S 架构的，在脚本维护和压测结果记录方面，相比 Jmeter 的 C/S 有一定的优势。针对微盟的实际情况以及全链路压测对复杂场景的要求，我们最终选择 Jmeter 作为压测引擎，因为 Jmeter 有很多扩展插件，我们可以做定制化开发；另外，在复杂场景设计上，它相对于 Ngrinder 有更大的优势。 
3.2 平台架构
3.2.1 压测平台构成
压测平台分为 Server 端和 Agent 端，Agent 端主要是和压测执行引擎 Jmeter 做了一些互动。Server 端的控制操作有很多模块，比如压测数据构造、场景构造、压测执行等。结果中心可以在压测期间实时展示压测结果，压测执行完后，会有历史结果的沉淀，且接口都会保存一些基线版本的数据，这样针对每个版本的压测，会有版本之间的压测数据对比。我们还对接了公司的监控系统、调用链平台、资源监控告警等等。
最下面是数据存储层，DB 用的 MySQL，实时数据用的 influx DB，在压测期间的日志和压测结果，我们通过异步的方式做存储。
3.2.2 压测执行链路图
这是压测平台的压测执行链路图。从 Server 端发起压力测试，第一步它会先去查询空闲压力机，并且锁定对应的压力机，这里我只做了大概流程的展示，相对复杂的技术原理就不赘述了。接着运行压测 agent 端，去创建压测脚本， download 参数文件，参数文件里面有可能会涉及到文件的拆分等等。
准备工作做完后调度压测执行引擎，压测执行引擎会涉及到两部分结果，一个是 RunResult 实时结果，比如 TPS、响应时间等等；另外一部分是压测的日志记录，比如一些错误日志、响应内容等等都做了异步的处理。
期间 Server 端可以实时展示结果，在运行结束后会针对压测结果做持久化存储， 有一个 addRunResult 的步骤会保存所有压测数据，可能会有一些异常导致结果存储失败，我们也有补偿机制的设计，这是整个平台执行调度的大概过程。
3.3 平台能力
这里重点介绍一下微盟整个压测平台的能力——
支持 http、https、dubbo 接口压测，以及自定义 jar 压测；
支持流量染色；
支持丰富的复杂链路场景配置，目前支持 3 种压测模式（并发模式、RPS 模式、固定次数模式），5 种流量模型（固定压力、阶梯递增）；
压力机支持水平扩展，可发起超 25 万 QPS 的压力；
支持实时结果展示与历史结果展示；
性能缺陷管理，性能问题知识库；
提供 mock 能力，支持对第三方 mock 配置；
基于链路管理，聚合相关应用资源监控，包括 pod、DB、redis、es 等资源监控；
基于调用链数据监控，聚合链路中 top 耗时节点，以及链路节点耗时同比、环比分析；
3.4 产品应用展示
3.4.1 数据大盘
我们可以在平台中看到整个数据大盘，一个是汇总大盘，还有一个实时大盘。可以实时看到压测执行情况，以及历史时间段的执行情况，目前的最新数据压测执行已经超过 4 万次了。
3.4.2 压测场景-流量配比
施压配置中的并发模式可以看到有一个流量配比，配置不同接口在整个场景里的占比。 
3.4.3 压测场景-RPS 模式
根据每一个接口的目标 QPS，在做阶梯 RPS 递增时，可以基于 RPS 成倍地增加压力。 
3.4.4 流量打标
前面提到我们有 Http 接口和 Dubbo 接口。Http 通过自定义请求头信息来添加压测标识，Dubbo 是通过 RpcContext 做标识的传递。 
(Http 接口流量打标） 
(Dubbo 接口流量打标）
3.4.5 参数化设置
在压测过程中，参数化设置至关重要，前面提到我们摒弃了 Jmeter 原生的 master slave 方式，所以对于参数控制提取要做对于改造，当我们使用到多台 Agent 压测，且需要保证请求参数不重复时，所以针对参数文件我们要做独立地拆分，我们可以在系统中通过两个按钮独立地对文件做拆分。 
在做参数化设置时有很多参数化格式是一样的，所以在构建压测脚本时，我们会添加一个全局变量，这个变量以压测 agent ID 作为标识，由于 agent ID 在数据库中都是唯一的，所以做参数化设置时能够保证参数的唯一性。
3.4.6 压测实时结果
最终可以实时查看压测结果详情、压测结果聚合等，基于目标会做简单的计算，分析压测结果是否满足预期目标、与目标相差多少等。
（压测结果实时图表）
（混合场景压测报告）
3.5 压测平台效果
3.5.1 超 5000 次压测执行 压测平台于 9 月 15 日上线提供给整个研发中心使用，在 2020 年双十一压测期间，平台承担了超过 5000 次压测执行，里面涉及 HTTP 接口、Dubbo 接口，以及链路场景的压测。 
3.5.2 QPS 10 倍提升
经过多轮线上压测，电商零售场景的 QPS 从第一轮的不到 1 万提升为 10 万+，整体 QPS 有了 10 倍的提升，直播业务场景 QPS 也提升了 1.8 倍。 
2020 年双 11 期间，微盟线上没有出现性能事故，通过全链路压测保证了双 11 平稳度过，我认为这是全链路压测给我们带来了比较明显的收益。
四、压测平台在链路监控有哪些实践？
每一个接口都有对应的调用链路，我们通过调用链平台分析链路后，可以生成两个清单，应用清单和接口清单。应用清单会基于 APPID 通过发布平台 CMDB 关系查询到应用涉及的组件资源，如 DB、Redis、ES、Kafka 等等，进而拿到对应组件的监控数据。
基于接口清单，我们能够分析链路中所有涉及到的调用节点，每个节点的耗时情况都可以通过调用链监控查到数据。有了这些数据，我们就能在链路监控上做一些分析。比如，可以在整个调用链中查询 TOP 耗时的 API，并快速将高耗时的 API 列出来；再比如，基于不同版本接口的数据基线，对 API 做同比环比分析，以快速发现可能存在性能隐患的 API 等等。当然，这部分我们目前还在做优化，在分析上我们目前所提供的能力还不够完善，这也是我们后面重点要做的事情。
4.1 链路组件资源监控
这是我们目前版本的简单展示，这里已经聚合了组件监控，可以看到 MySQL 部分的监控数据。
4.2 调用链路监控
调用链是支持手动和自动的链路管理。在压测目标非常明确时，比如要压某一个接口，想重点监控该接口依赖的某几个 API，我们就可以通过手动的方式将这几个 API 配置到链路监控当中。当压测链路涉及到的节点很多，我们又想做完整的链路监控，此时就可以采用自动解析的方式。
4.3 链路监控收益
五、压测平台未来有哪些规划？
未来我们希望是往稳定性保障平台上做转变，目前压测平台核心的功能主要是在压测能力上，后面的规划会涉及到 SLA 的管理，包括整合压测 SLA 和故障演练 SLA。
我们也做了故障演练平台的开发，基于故障演练平台，我们要分析事故报告，提炼故障类型，不断地丰富演练场景以及标准化的演练模板，还要去完善故障演练期间的故障记录和场景复盘。故障演练平台和压测平台的整合，也是我们后面要做的事情。这是我们整个平台后期的规划。
（微盟故障演练平台能力展示）
Q&A
Q1 ：除了压测平台还有哪些工具在配合使用？有没有其他比较好的工具推荐？
Q2：完成压测平台建设，需要具备哪些条件因素？
Q3：工具模拟的场景，和真实用户使用的场景有什么区别？是不是能够完全地匹配？
Q4：对于双 11 压测，遇到的一些对于性能提升比较大的实践有哪些？
Q5：针对现有的架构环境开源的监控和自研有哪些优劣势？
Q6：怎么模拟混合场景，进行不同业务的容量测试？
答案请前往：https://news.shulie.io/?p=5638
了解更多全链路压测落地细节，欢迎公众号后台回复“交流”进入「读者交流群」，和老师实时互动。
公众号后台回复【1071】获取资料
更多内容欢迎点击“阅读原文”，进入「TakinTalks 稳定性社区」，获取更多稳定性相关资料和知识。
声明：本文由公众号「TakinTalks 稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。
本文由博客一文多发平台 OpenWrite 发布！