1。背景随着公司交易量的不断增长，以及围绕“服务千万商户，商业全方位帮手”理念的商业版图不断组装，在一定时期内出现了一些故障，导致用户和商家带来了非常糟糕的体验，同时也给公司带来了很大的损失。我们明明已经在线下做了各种验证测试，比如功能、性能等等，为什么上线了还是出现各种问题？老板或者运营同学说，我们马上要搞活动了，能支持线上吗？IT环境的成本又增加了，但是业务并没有增加多少。在线IT成本能否降低？上面相信很多同学都遇到过类似的问题，解决方案行业也有比较成熟的解决方案，就是全链路压测。二、解决方案1、传统线上压测在全链路压测之前，我们的线上环境压测往往是通过以下方式进行的：线上环境提前准备好测试数据，模拟请求进行单服务或集群压测；Nginx镜像流量副本以进行压力测试。上述压力测试方法存在以下问题：费时费力，前期需要构建大量的测试数据；产生脏数据，污染在线数据库等；压力测试模型需要人工构建，导致压力测试结果不准确；只覆盖关键核心业务，压测覆盖面窄；链路上的基础设施难以覆盖，如slb、nginx、网络、数据库等。2、目前的解决方案是基于以上问题和手钱吧的具体业务需求。我们设计开发了全链路压测系统Havok。作为公司级全链路压测平台，主要设计目标是为公司业务提供真实、安全的模拟流量输出，同时为业务团队提供准确的容量评估数据，所以我们主要提供以下能力：1）真实再现用户行为，持续输出真实压测流量真实再现在线用户行为，按时间周期回放真实流量，同时不污染在线数据，用户无感知。2)按速率和倍数提供放大的流量。在上一步的基础能力基础上，可以按照预设的倍率或倍数放大流量，检测在线容量。3)具备“开箱即测”的能力，前期不需要花太多精力去构建测试数据等准备工作，想压测就压测；同时，生产数据不会被污染。4)支持多种压测类型支持通用http接口压测，支持内部rpc请求压测和移动设备特殊协议压测5)压测过程中提供实时监控和过载保护能力提供实时的收集和查看监控数据的能力，同时提供根据预定规则自动停止压力测试的能力，以保护在线环境。3、系统架构设计我们采用的方式是通过回放生产服务日志来实现压测，包括读写操作，同时根据日志的时间戳来控制阻塞/释放请求，从而达到目的高仿真压力测试。整体结构如下：Havok-dispatcher【调度中心】：负责在线服务日志数据的下载、排序（规则约束）、时间控制、请求分发、收集上传、压测引擎监控数据。Havok-replayer【压测引擎】：负责将调度器订阅的压测请求按照既定规则进行回放，支持播放请求增益调整，支持压测数据规则调整等。Havok-monitor[监控平台】：采集并展示压测引擎数据、在线服务监控数据、中间件等数据。Havok-mock[mockservice]：提供mock服务功能。Havok-canal【数据结构】：提供影子数据的实时增量清洗。四、主要模块功能介绍1、调度中心核心功能调度中心核心功能为日志抽取和请求投递，支持多数据源，支持维度过滤，日志保序分发，获取能力，监控数据查看上传、压力测试引擎管理调度。整体设计如下：1）为什么采用回放方式假设有这样一个外卖订单接口：POST/api/order，需要传入商户ID、菜品ID等参数。如果你打算用100个并发线程来压这个接口，你必须要考虑以下问题：你是用同一个商户，同一个菜做压测吗？是否使用同一个商户不同的菜品进行压力测试？你用100个商户，不同的菜品做压力测试吗？是用20个商户，每个商户用同样的菜来做压力测试吗？除了场景设置，还有其他的比如：如何控制缓存？是否需要避免缓存命中？您是否考虑命中缓存的可能性？查询请求需要考虑查询效率对股票数据的影响吗？是否考虑分库分库分表？.....这么多场景搭建，很麻烦。。。日志回放的方式比较好解决上面的问题，因为压测请求场景的搭建在日志中已经讲过了，唯一的就是要做的就是将它插入压力测试。只需要在测试请求中回放即可，不需要考虑如何设计。同时，利用好现有的数据库表、缓存等设施，我不需要考虑数据多样性等问题。2）如何实现高仿真除了忠实播放请求的内容，我们还要控制播放的节奏，就像一首歌，同一盘磁带，如果播放速度不同，节奏肯定会不同与众不同。所以我们也严格按照日志的时间戳来控制播放的节奏，做到不仅歌词一样，节奏也一样。timewheel模块承担了这样的职责，支持快放和慢放。3）增益能力为满足服务容量检测设计，提供请求增益（放大）能力，可以复制一个请求的多份，实现业务增长的模拟。另外，即使是一对一的replay，我们仍然要面对一个replay压测必须要解决的问题：幂等性。f(x)=f(f(x))例如：我们的商户创建接口POST:/api/createMch要求传入的商户名称唯一（业务需求），日志中包含一个创建商户创建的动作某小吃店：XX小吃。如果您在从日志中提取请求后重放该请求，则创建一定会失败：商家已存在于数据库中。因此，不仅要实现请求增益能力，还要解决接口幂等性问题。目前我们有两个思路：Havok接口层支持自定义关键字偏移量修改，避免冲突。在压缩服务级别做幂等处理。2.压测引擎的核心功能压测引擎的主要功能有：1)支持分布式容器化部署容器化部署可以快速扩展压测引擎的能力。2）异步发送/接收消息使用异步请求处理请求和响应以提高并发性。Havok是基于goroutine实现的。有以下好处：goroutine切换没有内核开销；内存占用小，线程栈空间通常为2M，goroutine栈空间通常为2K；G-M-P调度模型。3）接口请求和响应字段的过滤和调整，针对敏感数据统一处理；数据按预定规则移位，方便压力测试；为响应执行自定义断言。4）接口层面各维度统计统计接口误码率、吞吐量、P95等指标并上报调度中心。5)响应调度中心事件，下发处理调度中心下发的启动压测、停止压测、熔断等指令。3、数据构建传统压测工作很大一部分是前期数据构建，面临以下问题：数据样本类别分布不均，多样性不足；数据量太小；数据构建耗时过长。因此，我们基于阿里的canal[1]增量同步服务，定制开发了满足我们压测需求的功能，比如offset数据等功能。随时可以开始压测，与以往相比大大提高了执行周期的效率。敏感数据，如电话号码、身份证号码等统一脱敏偏移处理。商户号、店铺号、终端号等信息按既定规则转移，不会影响网上商户的实际使用。4、mock第三方服务接口对于第三方服务，我们采用mock处理。Mock支持延迟抖动等特性，同时通过事后正态分布分析调整mock的相关配置，尽可能匹配生产相关处理的生命周期模拟；自研通用mock服务DeepMock[2]：压力测试前，需要注入mock规则和响应规则。5.压测监控在线压测肯定会对在线服务造成一定的影响，所以我们需要实现相关链路的秒级监控监控，以及响应异常快速熔断等，架构如下:1)压力监控引擎每秒将接口层的监控数据进行汇总，发送给调度中心做进一步处理。指标包括接口错误率和吞吐量。Volume,top90,top95,avgresponsetime等。2）服务器监控由于公司的服务设施基本都部署在云端，服务器监控基本依赖现有的云端监控设施，包括中间件监控。6、测压隔离在线测压应保证测压行为真实、安全、可控，不会影响正常用户的使用，不会对线上环境造成任何数据污染。要做到这一点，首先需要解决的就是压测流量的识别和透传。通过压测标识，各个服务和中间件可以根据标识实现压测服务是否隔离、流量是否透传、影子表等解决方案。1）压测标识透传压测标识。目前我们采用key:value的方式对压测流量进行着色。同时，我们修改了相关的链接服务和中间件，比如基本的RPC框架，可以识别它们。转换原理是将压测标识的kv值存储在Context中，然后在所有发送给下游的请求中携带Context。下游服务可以根据Context中的压测标识完成对压测流量的识别和处理。在实际业务中，代码修改也很简单，只需要透传Context即可。7、数据隔离线上压测比较复杂的是如何保证压测产生的写数据不污染线上数据。业界常见的做法包括影子表、影子库、数据偏移等。我们针对不同的存储采用不同的策略：MySQL和MongoDB：使用影子表方式，应用层根据压测标识区分压测流量读影子表和写影子表；影子表数据偏移规则支持[stress_tag]前缀，随机字符串、uuid、字符反转等替换方式。Kafka或MQ：两种策略，一种在业务层面直接丢弃不下发，然后单独进行压测；或者透传压测标识，消费者根据自身业务情况改造处理。其他存储：比如ES，一个单独的压测集群，在压测的时候启用。8、熔断保护机制1）Havok会实时分析监控指标数据，根据业务配置阈值，将降低QPS或停止压测的事件实时发送给压测引擎，防止系统上线从被压碎。2）服务器端熔断在线业务有自己的熔断能力，基于相应的中间件实现，根据错误率等阈值自动熔断。5、压力测试实施目前，公司部分核心业务已经打通，包括门店码支付、扫码支付、小程序支付等，后续业务也在逐步推进中。随着业务线压测的推进，我们也会学到很多业务知识和架构知识，收到很多反馈，继续推动我们不断进化和优化Havok。目前Havok[3]已经开源，欢迎志同道合者提供宝贵意见或PR。六、总结与展望从项目立项到投产试压成功，我得到了产学研的大力支持和帮助，尤其是各业务线的合作与转型。我由衷地感谢。有了大家的配合，我们才能初具规模。展望未来，我们还有很长的路要走，希望能帮助大家提高研发效率，及时发现性能问题。1.易用性提升由于各种因素的影响，目前我们还需要提升用户的易用性。我们希望以后在可视化操作上投入更多的精力，尽可能降低研发同学的使用难度，像傻瓜一样操作。2、压力测试和SLA构建如何准确评估业务线的容量规划？根据目前的压力测试数据，动态考核能支持业务规模增长多久？能否优化线上机器资源，进一步降低成本？公司级混沌测试如何配合？这些问题需要我们去推进和解决。
