性能之全链路那些事

这两天产品的分析，很少人看，我猜测应该是获取目的不一样了，我在观察一下，如果阅读量 超过30，我再次回复产品的分享、

一、什么是全链路压测

基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

二、全链路压测解决什么问题

针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。

三、面对的问题点以及解决方案

1、业务模型梳理

首先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块，

针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。

2、数据模型构建

数据构建和准备，应该考虑这几点问题：

①、数据的真实性和可用性

可以从生产环境完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量；

②、数据脱敏

基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以免对生产造成影响，影响用户体验等，因此在数据准备时需要进行数据脱敏；

③、数据隔离

同样，为了避免造成脏数据写入，可以考虑通过压测数据隔离处理，落入影子库，mock对象等手段，来防止数据污染；

3、压测工具选型

全链路压测应对的都是海量的用户请求冲击，可以使用分布式压测的手段来进行用户请求模拟，目前有很多的开源工具可以提供分布式压测的方式，比如jmeter、Ngrinder、locust等。

可以基于这些压测工具进行二次开发，由Contorller机器负责请求分发，agent机器进行压测，然后测试结果上传Contorller机器。

考虑到压测量较大的情况下回传测试结果会对agent本身造成一定资源占用，可以考虑异步上传，甚至事务补偿机制。

4、压测环境搭建

全链路压测都是基于生产环境，解决了业务模型和数据以及压测工具选型开发，就要考虑系统扩容和风险规避了，比如压测不能影响实际的生产业务运行，还有资源申请等。

重新搭建一套完全匹配生产环境的压测环境，成本太高，且需求频次较低，投入成本太大。

5、系统容量规划

前面提到了业务拆分和流量预估，在系统容量规划阶段，首先应该对单个接口单个服务进行基准测试，调整配置参数，得到一个基准线，然后进行分布式集群部署，通过nginx负载均衡。

至于扩容，要考虑到服务扩容和DB资源扩容，以及服务扩容带来的递减效应。

至于大流量冲击情况下，可以考虑队列等待、容器锁、长连接回调、事务降级等方式来解决。

6、测试集群部署

能做全链路压测的业务系统，基本都是分布式系统架构，服务集群部署和负载均衡，就是需要实现和考虑的技术点。

需要解决的问题有：

①、服务间通信问题

一般通信方式有两种：同步和异步。

同步调用：

REST（JAX-RS，Spring Boot）

RPC（Thrift, Dubbo）

异步调用：

(Kafka, Notify, MetaQ)

同步调用一致性强，但是要考虑性能和调用失败的事务处理。

异步调用的话，可以降低服务间的耦合，提升性能体验，但是一致性是需要解决的（分布式架构有个CAP理论，感兴趣的可以查询相关资料看看）。

②、负载均衡问题

需要将大流量冲击均匀的分发给集群上的每台机器，目前比较优秀的负载均衡服务器是nginx，但nginx的部署貌似也存在一些问题，我们公司之前就遇到过订单重复问题。

③、容灾问题

需要确保的一点是：当服务中的某台或者某部分服务宕机，可以及时的进行服务转发，而不至于连锁反应下整个系统链路的服务挂掉（可以参考我之前的博客：容灾测试）。

7、数据收集监控

压测数据收集，需要由agent机回送给Contorller机器，但数据量过大会占用一定的资源，可以考虑异步实现测试结果回送。

至于监控，现在有很多优秀的专业监控工具，比如JVM自带的JConsole、JPS、jstack、jmap，前端监控工具yslow以及一些数据库监控工具。

饿了么全链路压测平台的实现与原理

整个过程实践下来主要还存在以下问题：

测试成本较高，几乎每个环节都需要人力支撑，费时费力。

由于测试用例较多，涉及的测试机范围较广，手工执行容易犯错，线上测试尤其危险。

记录结果和测试报告极不方便，需要二次加工、填写和上传。

测试过程中靠手工监控，覆盖不全且定位问题困难。

基于这些因素，我们决定推进全链路压测的自动化进程。这篇我们主要介绍全链路压测平台的实践。

目标

为了解决以上核心痛点，平台至少需要保证以下方面的功能：

用例管理：用户建立测试用例，上传资源文件，系统进行分类管理。

压测执行：一键触发已有测试用例，可指定线程数、预热时间、测试周期和测试机等，可以自动切分数据，分布式执行。

实时结果(热数据)：响应时间、吞吐量、错误率等数据以图表形式实时显示。

测试结果(冷数据)：平均响应时间、平均吞吐量，90/95/99线等数据以图表形式在测试结束后显示。

测试机集群监控：监控测试集群的使用状态，提示用户可用的测试机。

安全保障：平台应该对用户操作进行适当限制，并能自我应对一些异常情况。

主要功能与实现概要

压测平台是典型的B/S类型Java Web项目，基于Spring Boot开发，前端使用AngularJS。平台本身不执行测试只做调度，避免成为瓶颈，后台均使用JMeter执行测试；平台自身会维护压测机集群，保证压测机是可供测试的；测试期间产生的冷数据(用例数据、结果数据)持久化至MongoDB，热数据(实时数据)持久化至InfluxDB并定期清理。

分布式测试

在使用JMeter进行性能测试时，如果并发量比较大，单机的配置可能无法支持，这时需要联合多机进行分布式测试。我们并没有采用JMeter自身的分布式功能，而是自己做了实现，主要是考虑到：

JMeter的分布式测试执行和单机执行方式的差异较大，这会导致平台架构不必要的复杂度，实际用户只感知测试机的数量区别。

JMeter分布式执行的方式，master机通常不参与测试，而是收集slave信息，但这会造成一定程度上的资源浪费。

我们使用饿了么内部的EOC工具对压测机进行调度，并实现了JMeter自身具备的分布式调度功能，相应的对比见下表。基于我们的实现，压测过程中热数据和冷数据是分离传输的，冷数据在测试完成后才会传输(如果不需要压测端数据，甚至可以配置不存储冷数据)，因此该方案对于扩容是非常友好的，理论上支持的TPS没有上限。

测试状态流转

测试状态流转是压测平台的核心，每一轮正常的测试工作都会经历一条主线，即：配置 -> 触发 -> 运行 -> 结果收集 -> 清理。测试状态流转的设计围绕着这条主线，辅以外部干预和内部监控功能，保证测试的正常进行。

此外，我们还需要鉴别出各种可能的异常情况(如测试触发失败)和合理情况(如用户主动停止)，并据此输出不同的反馈信息，并且无论测试流程出现何种分支，最后都能形成闭环，这对系统的健壮性非常重要。以下是状态流转图：

举两个典型的应用场景：

用户触发测试后，由于测试压力过大，运维要求立刻停止测试，这时的闭环为：初始 -> BOOTING -> LAUNCHING -> 用户触发停止 -> 直接进入收集流程 -> 状态标记为STOP -> 清理压测机 -> 初始

用户触发测试后，压测机由于某些原因突然断网，这时的闭环为：初始 -> BOOTING -> LAUNCHING -> 监控发现问题 -> 状态标记为FAILURE -> 清理压测机 -> 初始

整个状态流转的实现，采用异步Job机制实现了类似状态机的概念，状态属性持久化到数据库中，便于恢复。

实时数据

JMeter本身并不提供图形化的实时数据展示功能，以往我们只能通过JMeter Log看到一些粗略的信息，并结合外部监控工具观察指标情况。在压测平台中，我们对该功能进行了实现，主要原理是通过JMeter的Backend Listener (JMeter 3.2+)，将测试结果实时发往InfluxDB，同时平台向InfluxDB轮询查询数据，得到实时曲线并展示给用户。

在实践过程中，向InfluxDB发送数据的频次是比较高的，可能会对压测机造成压力，因此我们改造了JMeter的InfluxDB sender，替换了HTTP方式，增加了以UDP协议发送数据的实现，解决了这一问题。

预配置

在“测试状态流转”一节中，阐明了测试的总体流程，第一步即为配置，配置的具体内容是：将测试需要的脚本、数据文件和插件，推送到每一台测试机上，为测试执行做好准备。

但如果测试文件比较大，或者需要配置的压测机数量比较多，配置可能会占用较多时间，影响测试进程，这是很多平台遇到的共性问题。对此，我们提出了预配置的概念，即用户可以提前对测试用例，针对某几台压测机进行配置工作，但并不执行。预配置会保留一定的时间，在这段时间内，用户可以直接执行测试，不需要再重复配置。

以下为预配置的状态转换图：

熔断与兜底

全链路压测一般都在线上真实环境进行，安全是首要考虑的因素，不能因为测试本身而导致服务不可用或事故。我们提供了四个维度的机制进行安全保障。

权限管理：用户权限分级管理，不能随意触发他人的测试用例，同时高峰期和禁止发布期，不允许执行任何测试。

停止功能：这是面向用户的手动停止功能，用户可以随时点击运行状态下的测试用例上的停止按钮，后台会直接kill掉所有运行该测试用例的测试机上的JMeter进程。

熔断功能：系统会根据实时信息中的错误率进行判断，当一定时间内的实时错误率达到或超过某个阈值时，该次测试将被自动熔断，无需用户干预。

兜底脚本：最极端的情况，当整个系统不可用，而此时需要停止测试时，我们提供了一份外部脚本直接进行停止。

结果收集

由于我们自己实现了JMeter分布式的管理，因此我们也需要自己对结果集进行处理，结果的主要来源为测试生成的JTL文件。

针对JTL，结果数据需要做预聚合再存入，原因是JTL中单条结果数据的大小非常小(大约100多个字节)，但总量很大(可能有几万到几百万条)，很容易由于重复存储维度字段的KEY值而导致表过大。预聚合主要根据以label作大分类，维度作小分类，以时间作为聚合标准，interval固定，从而保证Document大小不会过大。

以下是结果集片段的数据结构概要(单label)：

前端会根据持久化的数据，形成可视化图表，为用户展现。

总结与展望

全链路压测平台自今年7月上线以来，为超过5个部门累计提供了上千次测试服务。按照每一类测试配置和执行的人力成本为15分钟计算，大约节省了1000个小时的工作量。

目前，全链路压测的自动化只是针对测试执行范畴，我们还有很多工作要做，在未来，我们希望能够将自动化的脚步覆盖到测试前和测试后，真正建设出全链路压测的自动化生态体系。

上面的内容，通过网络整理和汇总，和个人的一些思考，权当参考，如有错误或者更好的建议，可以在评论区指正，不胜感激！