服务全链路压测设计

在服务数量增多到一定程度，出问题的可能性越来越大，现在各种常见的架构手段，高可用手段都是为了提升系统的可用性，给用户提供更好的体验。而全链路压测则相当于对服务进行一次体检，了解当前系统的状况

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

目的：

• 验证新功能的稳定性
• 验证峰值流量下服务的稳定性和伸缩性
• 对线上服务进行更准确的容量评估
• 找到系统瓶颈并且进行优化

压测极限标准

• load不超过 (机器核数* 0.6)
• 网卡流量不超过网卡容量的0.6，超过的话可能延迟比较大
• 请求超时不超过请求总量的十万分之一
• QPS不低于预估的85%，否则需要优化，或者给出合理的解释

压测方案

为模拟更真实的环境，压测机器与线上机器同等配置，仿照线上机器的部署情况部署。压测数据尽可能采用线上真实数据。

方案一

复用线上环境压测，在低峰期，比如凌晨3点钟，回放读请求，写请求无法压测，因为写请求会导致数据污染。

压测可以采用本地日常环境，或者采用线上环境：

• 日常环境：要求低，如果想要效果真实，可以构建与线上服务一模一样的配套设施，缺点是成本高

• 线上环境：完全采用线上环境，测量机器的抗压能力，流量逐渐的分配到越来越少的服务器上，观察10分钟以上，直到服务器处理的极限。

  • 需要强大的压测平台
  • 立体监控系统
  • 服务治理平台
  • 可参加各大公司的全链路压测系统，在文末参考中。

流量复用工具：TCPcopy

方案二

方案一很难对整个集群的进行压测，容易以偏概全，无法评估系统的真实性能。如果想做全链路压测：

• 尽可能构造真实数据

• 压测线上真实环境

• 核心技术

  • 压测标识透传

    • 跨线程：采用InheritableThreadLocal父线程ThreadLocal中的变量传递给子线程，保证了压测标识的传递
    • 跨进程：存储在请求的Header中，做一些标识。

  • 压测服务隔离，不能因为压测影响正常服务

    • 根据业务需求在线上对整条链路创建一个压测分组，隔离出一批机器用于压测，在请求入口处，可以将请求进行分割

  • 压测数据隔离，不影响真实数据

  • 使用影子表进行数据隔离，线上使用同一个数据库，只是在写入数据的时候将数据写入到另外一张“影子表”中。

1560781114870.png

最后

附录中给了很多互联网大厂的真实案例，可以一起学习

参考

• 全链路压测平台（Quake）在美团中的实践
• 滴滴全链路压测实践
• 有赞全链路压测实战
• 阿里中间件-全链路压测武器
• 京东全链路压测
• 逻辑思维全链路压测
• 饿了么全链路压测