测试专项 - 全链路压测与故障演练
2020年4月11日大约 3 分钟
全链路压测基本流程
Step1. 目标预估
- 预估票房区间 => 大数据
- 压测目标值 = 预估值 * X
核心链路梳理 + 历史同期 Top 接口 + 近期 Top 接口 => 系统范围、接口 QPS/占比
Step2. 压测方案与准备
压测方案制定
- 压测时间
- 压测场景（单接口/链路）
- 接口 QPS 配比
- 监控情况
- 停止压测的标准（正向/负向）
- ......
压测改造
- 新增/改动服务
- 新增/改动中间件/DB （影子表）
- 新增/改动外部调用
- ......
压测数据
- 是否符合实际场景
Step3. 压测执行
3.1 小流量试压
- 验证是否走通
- 配比是否正确
3.2 正式压测
- 压测周知
- 压测执行与监控
- 查看监控异常（用户反馈/服务/机器...）
- 收集数据
- 记录异常问题&原因
- 判断是否需要终止压测
- 压测后：重启服务，回归核心功能
Step4. 结果分析
- 压测结论
- 指标数据
- 压测过程
- 问题和解决方案
- TODO
主流压测方案
美团 Quake 压测平台
日常压测会用到 Quake 平台，公司也在自研，正好 Quake 提供了很详细的技术文档 简单了解下。
全链路压测平台（Quake）在美团中的实践
数据构造
这里主要流量录制的部分，暂不考虑 QA 自己造数据
HTTP
对于 HTTP 服务，在 Nginx 层都会产生请求的访问日志，我们对这些日志进行了统一接入，变成符合压测需要的流量数据。
- nginx->quake hive 是全量的日志
- 根据 appkey + 接口 uri 过滤 hive 日志
- 词表：压测所需的元数据，每一行代表一个请求，包含请求的 method、path、params、header、body 等等。
- 其他的方案还有 tcpCopy
RPC
由于 RPC 量级太大，无法采用 HTTP 的方案，这里使用对线上服务进行实时流量录制，结合 RPC 框架提供的录制功能，对集群中的某几台机器开启录制，根据要录制的接口和方法名，将请求数据上报到录制流量的缓冲服务（Broker）中，再由 Broker 生成最终的压测词表，上传到存储平台（S3）。
RPC 协议录制方案
- 代理模式
- 拦截器
- 中间件
- AOP
词表文件为什么需要分片，如何分片？
- 原因：后续压测肯定是由一个分布式的压测集群进行流量的打入，考虑到单机拉取词表的速度和加载词表的大小限制，如果将词表进行分片的话，可以有助于任务调度更合理的进行分配
- 怎么做？
数据隔离
- 跨线程的透传 - ThreadLocal
- 跨服务间的透传 - Mtrace
- 影子表
调度中心
大脑
性能优化
Reactor 多线程模型
业务逻辑与 IO 读写事件分离
故障演练：