随便聊聊，说说自己的认识。
自己水平有限，还望大家多多批评。

全链路压测平台（Quake）在美团中的实践：[https://tech.meituan.com/quake_introduction.html]

背景

相信各位关心测试技术的，都会被这篇文章刷屏，没错，美团也开始说自己的全链路压测平台 Quake 了。
全链路压测平台不是新概念，滴滴说过，阿里说过（介绍 PTS 有广告的嫌疑），这次美团又说了。

我自己也写了一个基于 Jmeter 的全链路压测平台：

基于 Jmeter 的轻量级云压测平台的原理与实现 (一)：开篇：[https://testerhome.com/topics/15612]

当然这个跟美团是没法比了，不是妄自菲薄，大环境就不一样，面对的流量就不一样，人力也不一样，当然技术也不一样。

美团这次技术解密真的是最到位的，真的是技术分享的态度，这和阿里的广告嫌疑，滴滴的欲言又止是不一样的。
美团的技术分享，真的干货挺多的，我经常看。

下面我想通过几个方面聊聊美团的全链路压测平台。

定义

全链路压测平台主要有两个核心的也是最顶级的要求：

• 全业务
• 全链路

这导致了，必须线上搞压测，必须用线上的真实数据搞压测。
那么线上搞就容易搞出事情，所以技术含量还是要有的，还是很高的。

技术

聊聊技术。
美团推广有很多技术关键点，说一些最关键的。

流量是怎么来的。

全业务要求流量必须是真实的，美团的做法是：

• http 服务的，通过 nginx 日志把请求内容导出来，处理一下，放到数据库池子里。
• rpc 服务的，通过美团内部已有的 rpc 框架录制功能，把请求数据导出来，处理一下，放到数据库池子里。

然后压测流量从数据库池子里来。

线上数据是怎么避免污染的

其实这个最早也是阿里提出来的，当然美团也提了，借鉴阿里的方式。

• 单系统的用 ThreadLocal，Java 是因为一次请求就会分配一个线程，所以用 ThreadLocal 针对线程的，非 Java 体系的应该也有类似方案，给每一次请求来增加测试标识。
• 跨服务间的透传（可以简单理解成跨进程），是用美团内部已有的 Mtrace，增加的测试标识。

以上都不用改一行业务端代码，都是改的中间件如 Tomcat，改的是数据库和缓存连接池的代码，对业务代码的侵入性几乎没有。
然后压测数据根据测试标识，访问被隔离出来的 MySQL，Redis，RebbitMQ 等等这些测试数据库。
还可以进一步把隔离出来的（即带测试标识的）流量，只访问隔离出来的服务器，这样就不会污染整个线上服务器集群。

这里可能有同学会有思考了，测试标识加在哪？

• http 服务的，可以直接加在 header 里（不污染代码，仅测试引擎添加即可）。
• rpc 服务的，不清楚，应该也类似，毕竟人家内部协议。

那这一套线上压测，压测数据到底要准备什么？
主要准备两个地方：

• 流量怎么来的上面说了，要提炼日志入库等。
• 持久层需要备份出来一套，MySQL 服务器可以是主备出来一套，Redis，RebbitMQ 之类的直接全新的就好。持久层这部分是有成本的。

那么还会有同学问，线上有几百上千台持久层集群，你都要备份一套，那得多少？
这地方美团没仔细提，是吧，成本还是有的不好提。我认为原因还是有几点：

• 线上的服务器都是隔离出来的，这量其实也没那么夸张，所以也不会全部备份所有持久层数据。
• 缓存一般性能比较好，换句话说，连缓存都有问题，那是加机器的范畴，是提高系统容量的问题。
• 如果数据库 MySQL 出问题，那属于透传，还是代码的问题。
• 不知道美团是不是搞的自己的持久层技术，比如自己二次开发的 MySQL 等等（阿里就这么变态），这样会需要好好测测。

所以持久层的备份不用那么膨胀，还行。
再谈谈影子区一般的技术：

• MySQL，Redis 可以直接主备出来一套新的集群，新增进程，当然 IP 端口都是全新的。
• 也可以在原来库的基础上，复制一个库或者表，就是还是在原进程内复制，复用 IP 端口。

美团用的是第二个，好处不少：

• 为了 MySQL 的内存也是共用的，最接近真实场景。
• 这样其实成本也省不少，除了磁盘空间都能省。
• 在实现方式上，也会更简单，比如只把主库增加表就好了，会自然同步到从库上，确实高明！
• IP 端口不用变，配置也省了一套。

压测核心

如果说上面两点和 Jmeter 其实没啥关系，那么压测核心实现这一点，真就是超越 Jmeter 的地方了。
美团用的是 NIO，悲剧的是，Jmeter 用的是 BIO。
好处不解释了，美团已经把 BIO 喷了一遍了，阿里的 PTS 也用的 NIO。
做法也不解释了，美团应该是探了不少坑的，自己写的时候再说吧。
有几点吧：

• 美团真是自己实现的这个压测 NIO 核心，说的很自信。
• 是不是用到 Netty 还不清楚。

链路诊断

比较重要，核心还是依赖 Mtrace 提供的数据。

机器管理

资源就是成本，但是也是项目的筹码。
一般机器管理都是运维的势力范围，但是文章中没提运维两字，可能是平台自己管理。
我比较倾向于是运维提供的 API，Quake 自己调用的，同时是运维给的权限。

服务端监控

依赖 CAT，依赖 Falcon（应该二次开发过）

其他

JVM 调优什么的就不说了，JDK 发展很快，CMS 已经要被淘汰了。
客户端监控也是 Echarts 写的。

业务

什么公司要搞全链路压测

至少目前来看，得是有追求，有余力的公司吧。
阿里，滴滴，饿了么，云集微店，美团，这些公司有一个共性，都是支付场景比较高并发的公司，就是对钱非常敏感的公司。
支付场景，也就是支付相关的各个服务（订单，派送，入库出库等很多），相连密切，这样的场景比较复杂，还是高并发，自然对性能测试有高要求。
同时支付场景，是会改变库的数据的，这也要求线上测试必须做数据隔离，这也是全链路压测的核心。

什么阶段的公司搞全链路压测

• 微服务的架构。
• 需要架构组，得有 Mtrace 的这种微服务 RPC 消息跟踪体系架构，能改中间件。
• 各部门能配合全链路压测调试及部署，运维的机器资源部署。
• 简单性能测试要通过，即单点的性能测试要没问题。
• 有更高的技术追求。

什么时间搞全链路压测

文中有提到的：

• 压力小的白天就行，要错过高峰期，这也是得益于数据隔离，服务器隔离。
• 压力大的一般凌晨进行，要错过高峰期。

Quake 没提到的

测试报告

没提测试报告是如何生成的，里面包含了什么，是什么形式的。
我觉得这反应了，美团内部的技术氛围真的浓厚，为什么这么讲？
意思就是大家各部门看压测图形，就都知道咋回事了，不用什么报告！
或者说，压测结果都是有留底的，直接线上查就可以了，真的方便可靠。

测试脚本写法和保存

这个我也没看到，不过以它数据库存储压测数据来看，其实脚本是 SQL 语句就行了，我一点儿也不意外。

聊聊大环境

我一直在提大环境，说说大环境对这个工具的作用吧。

推广

Quake 的脚本貌似很简单，但那也是分对谁，在美团，不用跟谁解释什么叫 RPC，什么是 Mtrace。
简单说就是工具推广不用考虑技术阻碍，这得省多少事儿。

已有的技术支持

文章后面一直强调各部门的支持，这是肯定的，没有 Mtrace，跨服务的真得从头来。
还有 CAT，rpc 框架等等成熟的技术。
同时，美团也提了，之前也有一个平台叫 Ptest ，至少也有帮助吧。

使用频率

月平均压测次数达上万次，这样工具的投入才有意义，这才是真正的用户支持，这样才能发现问题。

不是测试开发的

负责人不是高级测试工程师，而是高级工程师，有理由相信，至少人家是想撇掉测试头衔的。
测试真的很尴尬，一亩三分地还被开发染指，抢走责任田。

工作强度

整个团队（之前提是 4 个人）一个月开发出来核心，两周一个迭代，这开发强度不小啊。

写在最后

真是有些感慨了，大公司的能量真的很大。
之前这里也有人提测试职业生涯规划什么的，我觉得 Quake 就是一个很好的说明例子。
测试的职业生涯真的不要那些毒鸡汤，什么推动了这个，推动了那个，成为核心竞争力，太毒了。
就说小公司能搞定这个 Quake 吗？
你能推动 Quake 吗？
前期要准备 Mtrace，要搞中间件。实现要搞数据转储 hive，搞 NIO，等等。
工具运营要搞各部门配合。
服务器上需要运维有成熟的灰度体系。
服务端开发要有熔断机制，消费降级等等。
工具使用上，需要架构组的配合。
别说你能推动了，CTO 能推动吗？
一个小公司，是微服务吗？分前台，中台，后台吗？有架构组吗？
你能搞定 Quake 技术栈，公司开发都围着你转，你认为可能吗？人心叵测啊少年！
就算推动了之后，还要 2 周一个迭代，累死累活啊！
最后的最后，公司给你多少 package 搞这些啊，你谁啊？

不是我负能量爆表，这真的都是事实。
就算你都搞定了，去面试的时候也是看你背景，还是看你年龄的兄 die，现实还是那么残忍！

一些明明是大公司大平台的功劳，非要记成是自己的能力，这真的不对。
就算退一步说，美团没有现在这个牵头人搞全链路压测平台，美团就没有 Quake 了？
真的很遗憾，没有你，美团可能会做的更好。

就不多说了。我不是想怼谁，而是自己要有分辨能力。
工作还是要一步一个脚印啊，共勉吧。