介绍美团外卖日均300万单的访问下，如何探寻线上系统业务处理能力，排查性能瓶颈，验证线上降级机制，对相关报警和响应机制进行演练。我们如何通过线上压测实现，线上压测有哪些具体方案，以及线上压测的操作难点和最终成果。

1. 16/4/29
美团外卖全链路线上压测实践
lutao02@meituan.com
2016年04月24日

2. 关于我
老虎地图
（测试经理）
去哪⼉⽹
（QA）
新美⼤
（QA）
路涛 在互联网，唯一不变的是拥抱变化的能力

3. 3
线上压测业务特点
美团外卖线上压测的背景和目的
外卖全链路线上压测方案
线上压测方法
经典案例分析
目录

4. 4
线上压测业务特点

5. 5
线上压测业务特点
美团外卖线上压测的背景和目的
外卖全链路线上压测方案
线上压测方法
经典案例分析
目录

6. 美团外卖业务
用户
• 下单
• 收单
商家
• 接单
• 发配
送
骑手
• 取餐
• 送餐
客服
• 用户
反馈
• 商家
反馈
370w 日订单量
1亿 日交易额

7. 外卖业务特点
长链
条
• 用户-商家-骑手
-客服
• 任何环节出现问
题阻塞整体业务
高并
发
• 集中在午饭和晚
饭时间
实时
性
• 要求交易在40分
钟内完成

8. 外卖业务压测背景
线下性能环境数据参考有偏差
性能测试环境搭建成本高
外卖链条长，依赖系统复杂
业务特点决定
ü 上探外卖全平台系统处理能力
ü 排查性能瓶颈
ü 验证降级机制
ü 相关报警机制和响应机制演练
ü 报警标准和应对措施（未雨绸
缪）

9. 线上性能问题回顾
• 线上Tair集群大面积超时导致线
上服务异常
• 根因：流量双倍，某一核心服
务达到性能瓶颈，进而雪崩
• 最终导致服务宕机
• 持续时间：10:55-12:58期间，
损失巨大
基础服务
• 核心服务的load过高导致无法
提供服务
• 根因：某一核心服务高峰期间
load超载，jvm线程数飙升
• 产生线程等待死锁，造成系统
宕机
• 持续时间：10:00-14:00，损
失巨大
核⼼业务
2015年4月内的两次性能事故

10. 线上QPS预估
美团外卖
线上支持日订单数 XXXW
1.整体QPS达到要求，根据目前的QPS计算
2.单模块QPS达到要求，根据每天高峰时间拆解
核算出API、订单、POI等核心业务需要承担的QPS
预估下单QPS =
预计订单数/（高峰持续时间*3600）/（真实成单数/真实下单请求数）
满足目标qps的情况下，线上监控不报警
预值会存在偏差，像更高的要求方向偏移

11. 11
线上压测业务特点
美团外卖线上压测的背景和目的
外卖全链路线上压测方案
线上压测方法
经典案例分析
目录

12. 门店搜
索
选择菜
品
下单&
选择支
付⽅式
商家登
录
商家获
取订单
接单
系统级压测方案
模拟请求
流量回放
模拟请求
流量回放
写请求
支付Mock
写请求
流量回放
写请求
流量回放
写请求
流量回放
Web服务 底层服务
实时引流 写请求事务模拟 流量回放 写请求
模拟请求
（Thrift）
流量切换
模块级压测方案
全链路业务压测方案
外
卖
线
上
监
控
平
台
第
三
方
调
用
屏
蔽
线上报警机制（基础服务、系统监控、业务监控）
读数据处理 写数据清理 低谷执行

13. 13
线上压测业务特点
美团外卖线上压测的背景和目的
外卖全链路线上压测方案
线上压测方法
经典案例分析
目录

14. 压测方法
流量
回放
读业务
pTest进行线
上日志读取，
构造请求
pTest
Thrift
压测
读业务
主要针对
Thrift服务化
pTest
写请
求
写业务
模拟用户、商
户真实操作，
下单、接单
pTest
实时
引流
读写业务
完全真实的请
求，适合单机
压力测试
RD

15. 前端控制
性能测
试配置 client接口
读取配置（默
认词表）
选择压力机器2
启动压力
前端接口
日志处理成词
表（测试标识）
定时导出外卖
日志
（10:00-20:00）
选择压力机器1
存在词
表
采用默认词表否
是
流量回放设计与实现

16. 流量回放特征
优势
劣势
优化
• 完全真实的请求，从线上
日志中提出
• 可测单机和集群
• 不会对线上用户产生影响
（服务器正常服务下）
• 无法进行写操作
• 更切合用户请求

17. 线上日志获取
制成词表
（JSON格式）
pTest性能测试
配置
pTest生成Client把
JSON转换成Client
对象，建立与
Server的连接
选择压测机器
（指定IP和端口）
动态传输Thrift
Server可识别的对
象
启动压力
执行压力测试
Thrift压测设计与实现

18. Thrift压测特征
优势
劣势
优化
• 适合做模块压力测试
• 读请求压测，不会对
线上用户造成影响
• 单模块写操作成本较
高
• 与上下游解耦，支持
写操作

19. 测试门店构造
（地址、配送范围）
pTest请求构造
建立请求间关联关
系
启动压力
执行压力测试
用户数据准备
（账号、userid、
token、uuid）
测试安全准备（数据
统计、结算统计、收
发短信）
压力结束
数据清理
写请求设计与实现

20. API
submit
测试门
店
下单
Thrift
线上逻辑
否
是
生成view_id
模拟真实延迟
返回view_id
代码逻辑修改
提交密钥和view_id
http 密钥正
确
是
测试门
店
是
写入消息队列与
线上一致
MockServer
支付Mock的设计与实现

21. 写请求特征
优势
劣势
优化
• 适合做模块、集群压
力测试
• 请求场景自定义
• 更接近真实请求
• 脏数据处理
• 数据准备
• 人工参与成本较高
• 线上数据处理有风险

22. 功能点 pTest JMeter PTS（阿里云）
易用性 平台化
HTTP快速支持
Thrift快速支持
聚合测试结果
易扩展
稳定性 万级大并发
大流量回放
压测工具选择

23. 23
线上压测业务特点
美团外卖线上压测的背景和目的
外卖全链路线上压测方案
线上压测方法
经典案例分析
目录

24. 外卖全平台压测过程
典型案例剖析

25. 目标分析
XXX万单/
日
用户端读请求
XXXQPS
用户端写请求
XXXQPS
商家端读请求
XXXQPS
商家端写请求
XXXQPS
读QPS:
峰值等比例换算
写QPS:
预估下单QPS =
预计订单数/（高峰持续时间*3600）/（真实成单数/真实下单请求数）

26. 数据准备
人员周知
全链路读
流量
• 用户端端读
流量回放
• 商家端读流
量回放
下单接单
压测
• 用户下单测
试
• 商家接单测
试
全链路压
测
• 用户 商家
流量回放
• 用户下单，
商家接单
人员周知
数据清理
• 写数据清理
• 统计数据清
理
确定方案
压测过程

27. 准备工作
用户
数据
商家
数据
回放
日志
数据准备
场景验
证
脚本准备
开关验
证
接口
验证
相关
QA
人员准备
业务
RD
基础
服务
业务
RD
人员周知
基础
服务
三方
依赖
美团
风控
Check流程
Check机制
Check责任

28. 事后处理
直接!
数据
关联
数据
清理
方案
数据清理
场景验
证
脚本验证
开关验
证
接口
验证
业务
RD
人员周知
基础
服务
三方
依赖
美团
风控
Check流程
Check机制
Check责任

29. 结果分析
29
序号 项目 压测验
证的能
力
午高峰
峰值
1 整体 预计峰
值处理
订单
XXW
XXW
2 用户读 XK XK
3 商家读 XK XK
4 下单 XK XK
序号 项目 瓶颈
1 用户端
API
Tair缓存使用较
重，XkQPS请求，
对应了XXW的
Tair QPS，需要
优化
2 商家端
订单消
息队列
在每分钟提单XX
万左右，消息队
列开始堆积，堆
积后不报警
3 用户端
API
调用GIS服务，
导致提供方
Load高警告

30. 那些年踩过的坑
• XX个测试账号发送了
大量（XXw）的短信
• 解决方案：黑名单
⾦钱损失
• 内网lvs流量打满，影
响同机房其他服务
• 解决方案：扩容
业务影响
压测期间两次引发的两次线上事故

31. 未来规划
线上问题驱动 线上常态化
线上无人值守
线下CI集成
线上线下结合主动跟踪线上问题
线上压力测试演进
线上全链路压测
线上模块级压测
常规、流程、规范化
压力弹性控制
规范、责任机制
监控、报警全面自动化
定期全链路压测
定期单模块
线下应用级对比
数据渗透、优化
监控自动化

32. Q&A