全链路压测实施思路流程分析

最近公司出现线上性能问题，为了节省资源，提前发现问题，因此研究一下全链路压测，协助解决线上问题

一.核心链路的确认

1.链路出现问题会对企业业务造成重大影响的链路，比如对业务造成损害、品牌损害等;
2. 链路出现问题会对用户（如消费者）造成重大影响的链路，比如电商购物APP;
3. 跟公司阶段考核（如KPI）挂钩的业务链路，比如订单团队肯定要保障订单链路的稳定;

二.构造压测流量

1 第一种人工构造

压测并发量不大的时候，比如并发只有几百，这种情况建议通过编写sql从数据库中导出一批线上数据，然后对这批数据进行清洗，去除敏感信息，比如客户地址、客户账号等信息，然后根据数据去准备压测脚本。

当压测并发量很大，比如并发上万，此时建议通过将数据同步到大数据平台，通过MapReduce任务的方式去清洗、导出数据。可能有人会问为什么选择从线上环境导出压测数据呢？

因为真实业务数据代表的是真实发生的业务，数据之间的关系也已经生成，通过这种方式构造的压测数据能够最真实地还原业务场景并且构造数据的效率也能够大大提升。

2.第二种录制回放

录制回放就是收集某个时间段的正常业务数据，然后通过清洗敏感信息，最后加上压测标记去运行，达到最高程度的模拟正式业务场景，确保数据的真实性、多元化，以及场景覆盖的完整性。

三.如何保障数据的隔离

1.流量染色

构造压测流量时，将压测标记加入到压测流量中进行流量染色，比如页面发起的http请求，我们会在http请求的消息头里面加入压测标记。

2.压测标记传递

当压测流量流经业务链路时，会经过很多事先被植入过压测探针的应用。
当压测流量经过这些应用时，会被应用里的探针识别出来，并且会携带这些压测标记继续传递下去。比如压测流量经过Dubbo服务时，探针会把压测标记放到Dubbo的上下文中。

3.压测数据存储

压测流量最终会持久化到数据库、缓存、消息中间件等，当压测探针识别到压测流量要持久化，就会将压测流量持久化到对应的影子区域。

比如数据库会持久化到影子库或者影子表中、消息会写到影子topic中。

四.如何构建全链路压测模型（请求的逻辑）

由于使用了影子库/表的方式，即使直接使用生产环境压测也并不代表能获得与真实业务完全一致的压测环境，里面还涉及到对压测数据模型的建立.

要保证压测流量和正式流量保持 “一致”，影子库/表与生产环境保持“一致”，这里的“一致”包含几个方面：

1.数据量一致

通常是数据库，搜索索引等数据量的变化会导致响应时间变化的中间件，如果使用影子库来替代正式库，那么需要全量拷贝一份正式库的全量数据来保证压测结果，一些无法直接使用正式库数据的情况。

诸如新业务上线/正式库数据增减变化大/业务增长迅猛需要增加数据量等情况，则需要根据目标数据量以及业务特征构造压测数据来准备数据脚本。

一些只读的链路涉及的库/表，可以根据压测时间/压测目的/压测量等因素评估是否可以直接使用正式库作为压测库。

2.数据分布一致

数据在使用的时候会有频繁访问/ *** 作的热点数据，几乎不会用到的历史归档数据。

两者在mq/缓存/数据库的分布比例会影响接口的读写 *** 作性能，需要根据生产的实际情况构建压测数据模型。

3.数据 *** 作一致

对于缓存，定时处理的一些数据，构造数据的时候要注意数据失效/刷新/定时处理的批次和每批数据处理量的大小。

五.构造监控

全链路压测监控体系是由基础监控，应用监控、业务监控三部分构成。

1.基础监控

是指压测产品或者压测应用系统的集群基础性能监控，比如CPU性能、磁盘性能、网络性能等。

2.应用监控

是指从应用层对应用的性能、进行实时监控、分析，比如端到端链路调用节点性能情况。

3.业务监控

是指在站在业务角度的监控，它是由一些列业务指标构成，这些业务指标有特定的业务含义，比如5分钟内交易订单成功率持续为0。

整个全链路压测过程中，开发人员在压力发起之后紧盯基础监控、应用监控、业务监控大盘，任何监控如有异常，第一时间执行对应的紧急预案，确保压测正常运行。

六.问题分析

1.请求流量是否达标
2.响应超时
3.消息堆积

其他：

• 网络
• 内存
• mq分发
• redis缓存