服务全链路压测设计

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

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

目的：

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

压测极限标准

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

压测方案

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

方案一

复用线上环境压测，在低峰期，好比凌晨3点钟，回放读请求，写请求没法压测，由于写请求会致使数据污染。

压测能够采用本地平常环境，或者采用线上环境：

• 平常环境：要求低，若是想要效果然实，能够构建与线上服务如出一辙的配套设施，缺点是成本高

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

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

流量复用工具：TCPcopy

方案二

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

• 尽量构造真实数据

• 压测线上真实环境

• 核心技术

  • 压测标识透传

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

  • 压测服务隔离，不能由于压测影响正常服务

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

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

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

最后

附录中给了不少互联网大厂的真实案例，能够一块儿学习

参考

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