聊聊互联网产品服务全链路压测设计与实践的那些事

一、全链路压测定义

基于线上真实环境和实际业务场景，通过模拟海量的用户请求，来对整个系统链路进行压测测试；

二、全链路压测目的

1、验证新上线功能的稳定性；

2、验证峰值流量下服务的稳定性和伸缩性；

3、对线上服务进行更准确的容量评估；

4、找到系统的瓶颈并针对性优化；

三、压测工具

1、JMeter

用于对服务器、网络或对象模拟巨大的负载，来在不同压力类别下测试它们的强度和分析整体性能，支持分布式压测；

2、TCPCopy

流量复制工具，能够把线上机器的流量导流到压测环境的机器上，为营造巨大压力情况，使用Tcpdump录制请求，然后使用TCPCopy回放功能产生巨大的压力

3、Apache ab

HTTP

四、压测极限标准

1、机器load average不超过CPU核数*0.6；

2、服务进程CPU占用率不超过（CPU核数*0.6）*100/机器部署的服务进程数；

3、网卡流量不超过网卡容量的60%（超过可能延时较大）；

4、请求超时不超过十万分之一；

5、QPS不低于预估的85%，否则需要优化或者给出合理解释；

五、压测实施方案条件

1、为模拟更真实的环境，压测机器与线上机器同等配置，仿照线上的部署情况部署，同时压测一个机器上的所有服务；

2、压测数据尽可能使用线上真实数据；

六、压测实施方案

1、方案一：复用线上环境压测

① 低峰期，比如凌晨3点；

② 回放只读请求；

③ 写请求无法压测，会造成数据污染问题；

2、方案二：构造全套线上环境

① 服务

② 数据（MQ，数据库，缓存）

③ 消息/短信/PUSH隔离 （要防止对用户骚扰）

④ 读写都可以压测；

⑤ 问题是成本太高；

3、方案三：基于真实流量调配进行线上压测

① 完全使用线上环境和数据；

② 把线上请求逐步分配至某一台服务器直到服务处理达到极限；

③ 服务必须具备实时调整流量分配的能力，必须有它的服务治理平台；

④ 服务运行信息从监控系统准实时获取（立体监控系统）

⑤ 不足：只能达到最大的线上流量，对于流量小的服务不能测试出真实的处理能力；

4、方案四：全链路压测方案

① 以上方式很难全面的对整个服务集群进行压测；

② 以局部结果推算整个集群的健康状况往往会“以偏概全”，无法评估整个系统的真实性能水平，主要的原因包括下面几点

（1）只关注涉及的核心系统，无法覆盖到所有环节；

（2）系统之间都是通过一些基础服务进行串联，如Nginx、Redis、数据库、磁盘、网络等等，而基础服务问题在单机压测中往往不能被暴露出来；

③ 全链路压测是准确评估整个系统性能水平的必经之路；

④ 压测数据的构造要尽可能真实；

⑤ 压测的环境要采用线上真实环境；

⑥ 压测技术

（1）压测标识透传

（2）压测服务隔离

* 压测通常选择在深夜低峰期进行；

* 在低峰期，机器基本都是处于比较空闲的状态，将根据业务的需求在线上对整条链路快速创建一个压测分组，隔出一批空闲的机器用于压测；

* 将正常流量与测试流量在机器级别上进行隔离，从而降低压测对服务集群带来的影响；

（3）压测数据隔离

* 使用“影子表”数据隔离的方案；

* “影子表”的核心思想是，使用线上同一个数据库，包括共享数据库中的内存资源，因为这样才能更接近真实场景，只是在写入数据时会写在了另一张“影子表”中，从而避免脏数据的写入；

* 对应KV存储，也是类似的思路，比如MQ的实现，MQ包括生产和消费两端，业务可以根据实际的需要选择在生产端忽略带测试标识的的消息，或者在消费端接收消息后忽略两种选择