随着公司交易体量的不断增长，以及围绕“服务千万商家，全能生意帮手”的理念不断拼装的业务版图，曾经在某一段时间内发生了一些故障，给用户和商户带来非常不好的体验，也给公司带来较大损失。

上面类似的问题，相信很多同学都碰到过，解决办法业界也有比较成熟的方案，就是全链路压测。

在全链路压测之前，我们线上环境压测，往往采用如下方式进行：

上述的压测方式有以下问题：

基于上述问题以及收钱吧具体业务需求，我们设计开发了全链路压测系统Havok。作为公司层级的全链路压测平台，主要设计目标就是为公司业务提供真实、安全的仿真流量输出，同时给业务团队提供准确的容量评估数据，所以我们主要提供如下能力：

1）真实重现用户行为，持续输出真实压测流量

真实复现线上用户行为，按时间轮回放真实流量，同时不污染线上数据，用户无感。

2）提供按速率和倍数来放大流量

在上一步的基础能力上，可以按照预设的速率或者倍数来放大流量，进而探测线上容量。

3）具备“开箱及测”的能力

不需要前期花费过多精力构造测试数据等准备工作，做到想什么时候压测就什么时候开始；同时不污染生产数据。

4）支持多种压测类型

支持普遍的http接口压测，支持收钱吧内部的rpc请求压测以及移动设备的特殊协议压测

5）提供压测过程中实时的监控和过载保护能力

提供实时监控数据收集查看的能力，同时根据预定规则提供自动停止压测来保护线上环境的能力。

我们采取的方式是回放生产服务日志来实现压测，包括读和写操作，同时根据日志的时间戳来控制阻塞/放行请求，来达到高仿真压测的目的，整体架构如下：

调度中心核心功能是日志抽取以及请求下发，支持多个数据源、支持维度筛选、保序日志分发、增益能力、监控数据查看上送、压测引擎的管理调度。整体设计如下图：

1）为什么采取回放方式

假设有这么一个外卖下单接口: POST /api/order，需要传入商户ID、菜品ID等参数，如果计划用100并发线程去压这个接口，你肯定会考虑以下几个问题：

场景设置外，还有其他诸如：

这么多场景构造，很麻烦...

日志回放方式就相对较好的解决上面的困扰，因为压测请求场景的构造，日志里已经告诉我了，要做的就是塞到压测请求里回放就行了，我不需要考虑如何设计。同时利用好现有的数据库表、缓存等设施，我也就不需要考虑数据多样性等问题。

2）如何做到高仿真

除了如实的回放请求内容外，我们还得控制好回放的节奏，就像一首歌，同样的磁带，播放的速度不一样那出来的节奏肯定不一样。所以我们还严格按照日志的时间戳来控制好回放的节奏，做到回放出的不仅歌词一样，同时节奏也一样。timewheel模块就承担了这样的职责，支持快放、慢放。

3）增益能力

为了满足业务容量探测设计，提供了请求的增益（倍率）能力，能将一个请求复制出多份，从而实现对业务增长的模拟。另外，即便一比一等量回放，我们依然要面对回放型压测中不得不解决的一个问题：幂等性。

f(x) = f(f(x))

举个例子：我们的创建商户接口 POST: /api/createMch，要求传入的商户名称是唯一的（业务要求），这个时候日志里包含了一个创建商户的动作，创建了一家小吃店：XX小吃。如果你从日志中提取后，重放这个请求，必然创建失败：数据库中已经存在该商户。

因此不但需要实现请求增益能力还需要解决接口幂等性的问题。目前我们两个思路：

压测引擎主要功能有：

1）支持分布式容器化部署

容器化部署，可以快速扩展压测引擎能力。

2）异步发送/接收消息

采用异步请求方式处理请求和响应，提高并发能力，Havok基于goroutine来实现,如下好处：

3）接口请求和响应字段的过滤调整

针对敏感数据统一处理；根据预定规则偏移数据以方便压测；针对响应进行定制化assert。

4）接口层级各个维度的统计

统计接口错误率、吞吐量、P95等指标并上报给调度中心。

5）响应调度中心事件下发处理

处理调度中心下发的开始压测、停止压测、熔断等指令。

传统的压测很大一部分工作就是前期的数据构造，面临如下等问题：

所以我们基于阿里的canal[1]增量同步服务定制开发了符合我们压测要求的功能，比如偏移数据等功能。达到想什么时候压测就什么开始，相比以往大大提高了执行周期效率。

针对第三方服务，我们采取的是mock处理，mock支持延时抖动等特性，同时通过事后的正态分布分析调整mock相关配置，尽量匹配生产相关处理的生命周期模拟；

线上压测肯定会线上服务产生一定影响，所以我们需要做到对相关链路秒级的监控，以及针对异常快速做出熔断等反应,架构如下：

1）施压端监控

压测引擎会每秒汇总好接口层级的监控数据上送给调度中心再处理，指标包括接口错误率、吞吐量、top90、top95、avg响应时间等。

2）服务端监控

由于公司服务设施基本部署在云上，所以服务端监控基本依赖现有云端监控设施，包括中间件监控。

线上压测要保证压测行为真实、安全且可控，不会影响正常用户的使用，并且不会对线上环境造成任何数据的污染。要做到这一点，首先需要解决的是压测流量的识别与透传问题。有了压测标识后，各服务与中间件就可以依据标识来进行压测服务是否隔离、流量是否透传以及影子表等方案的实施。

1）压测标识透传

压测标识，目前我们采取的key:value方式染色压测流量，同时我们相关链路的服务以及基础RPC框架等中间件都已配合改造以识别。

改造原理是将压测标识的 kv 值存入 Context 中，然后发往下游的请求中都带上该 Context，下游服务可以根据 Context 中的压测标识完成对压测流量的识别和处理。在实际业务中，代码改造也非常简单，只需要透传 Context 即可。

线上压测相对比较复杂的就是如何确保压测产生的写数据不污染线上数据，业界常见做法比如影子表、影子库，以及数据偏移等。

我们针对不同存储，采取不同策略：

1）施压端熔断

Havok会实时分析监控指标数据，根据业务配置阈值，实时给压测引擎下发降低QPS或者停止压测事件，防止压垮线上系统。

2）服务端熔断

线上业务自身具备熔断能力，基于相应中间件实现，根据阈值，比如错误率自动熔断。

目前公司部分核心业务已经接入，包括门店码支付、被扫支付、小程序支付等等，后续业务也在陆续推进接入中，随着业务线压测的推进，我们从中也学到了大量的业务知识，架构知识，接收到不少反馈，持续推动我们不断演进和优化Havok。目前已经开源Havok[3]，欢迎志同道合者提出宝贵意见或者PR。

从项目立项到成功投产压测，得到了产研同学的大力支持和帮助，尤其是各个业务线配合改造，真心感谢，正是在大家的配合下，才能够初具规模。展望未来我们还有较长路需要走，期望能够帮助大家提高研发效率，及时发现性能问题。

由于多种因素影响，目前我们在用户易用性上还有待提高，期望后续在可视化操作上投入更多精力，尽量降低研发同学使用难度，傻瓜式操作。

如何精准评估业务线的容量规划？按照目前的压测数据，动态评估还能支撑多久的业务规模增长？线上机器资源是否可以优化，进一步降低成本？如何配合公司层级的混沌测试？这些问题都需要我们推进和解决中。