美团全链路压测Quake学习笔记

今天读了美团技术团队新发布的全链路压测平台Quake在美团中的实践，做个笔记。

先说下总的读后感:

压力测试/性能测试有多种方式，从下面的几个发展阶段可以看出越来越追求真实高峰访问的模拟。

现在大公司普遍的分布式架构，云计算的应用，容器的使用也可以提供更有力的资源调度。但全链路压测最重要的工作在于需要架构，开发团队的支持和适配工作。

没有全链路的监控及相关工具支撑，没有架构的调整（压测标识）和数据库的配合（影子表），这个全链路压测就是个听起来更美的名字（你也知道技术圈喜欢造新词）。

印象中APM/Application Performance Management 前几年就挺火的，现在各大厂又都在提全链路了。

 

文章笔记摘要

1 背景

1.1 要解决的问题

• 验证峰值流量下服务的稳定性和伸缩性
• 验证新上线功能的稳定性
• 进行降级、报警等故障演练
• 对线上服务进行更准确的容量评估

1.2 压力测试方式的几个阶段

• 对线上的单机或集群发起服务调用
• 将线上流量进行录制，然后在单台机器上进行回放
• 通过修改权重的方式进行引流压测
• 全链路压测

1.3 全链路压测介绍

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

主要特征：

• 真实流量
• 线上环境
• 实时监控和过载保护

2 核心功能

2.1 数据构造

回放业务高峰期产生的流量

• HTTP： Nginx Access Log分析
• RPC：对部分机器录制

通过以上两种方式生成压测词表?（词表分片处理，方便后续批量加载）

2.2 压测隔离

添加压测标识，各服务和中间件依据标识来进行压测服务的分组和影子表方案的实施。

在请求头添加特殊标识，但需要保证线程间和跨服务间透传。

链路诊断功能方便定位问题。

2.2.1 服务隔离

通常选择深夜低峰压测，同时隔离正常流量和测试流量。 隔离策略：基于IP，机器数，百分比

2.2.2 数据隔离

影子表（阿里）：使用线上同一个数据库，包括共享数据库中的内存资源，只在写入数据时写进另一个影子表。 KV的处理类似，MQ则选择生产端或消费端忽略消息。

2.3 调度中心

2.3.1 资源计算预估

• 压测期望到达的QPS
• 压测请求的平均响应时间和请求/响应体大小
• 压测的词表大小、分片数
• 压测类型

2.3.2 事件注入机制

根据系统的实际情况对压力进行相应调整。

• 调整QPS
• 触发熔断
• 开启事故注入
• 开启代码级性能分析

代码设计：观察者模式（会触发的事件）和责任链模式（执行事件）

2.3.3 熔断保护机制

客户端熔断： 根据业务自定义的熔断阈值，实时分析监控数据，当达到熔断阈值时，任务调度器会向压测引擎发送降低QPS或者直接中断压测的指令，防止系统被压挂。

3 扩展阅读

• 全链路压测自动化实践