压测的一些思路

时机

首先要清楚的一点就是，何时开始作全链路压测？咱们有另一个业务线，如今就没有打算作，那个业务线的日均单不到十万，而要压测的业务线的日均单到了200万，但这并不意味着200万是一个标准，我以为能够从下面几点考虑：

• 业务发展速度。在能够预期的一段时间（最好是半年，一个季度有点晚）内，业务会有较快速的发展，线上机器必需要大幅度扩容；可是，扩容有的时候并非线性的，从两台扩展到四台，你得服务能力或者能提升两倍，可是在继续扩容，服务能力就有可能提升不上去了，由于要受限于其余的模块，好比，DB，公共组建，中间件等等
• 链路的复杂程度在扩张。通常而言，随着业务的发展，咱们的接口会愈来愈多，系统会逐渐的作分布式，业务线内部的模块越抽象越多，业务线跟其余业务线的交互也也愈来愈多，咱们没法单纯的根据本身系统的处理能力来评估接口的服务能力。
• 对单机压测结果愈来愈没有自信。这也是一个很好的指标，通常而言，咱们都会压一下咱们本身的模块，可是身为模块的owner，本身愈来愈清楚，单机的压测不表明真实的场景，心里会愈来愈虚，这个时候，就要考虑全链路了。

方法

下面具体看看要作全链路须要哪些工做。

梳理核心链路的流程和边界

由于全链路必定会设计多个流程，多种技术，多个依赖，因此，要作全链路压测，首先要梳理核心链路的流程，明确链路的边界，我以为梳理这个是比较简单的，由于一个业务再复杂，它的核心链路确定有限，例如，咱们的核心链路就包括：

• 建立订单
• 开始造成
• 获取行程费用
• 结束订单
• 支付订单
• 完单

核心链路是一个业务的核心，这一块应该能够很快梳理清楚，可是，难点在于梳理清楚链路的边界。例如：

• 开始订单要作风控
• 结束订单要发券
• 结束订单要通知用户费用
• 完单后要通知营销
• 。。。

在核心链路的基础上，咱们会有不少的分支业务，而这些分支业务有的能够参与压测，有的不能参与压测：缘由多种多样，好比，这个分支业务不是咱们本身公司的，或者这个分支业务自己就不怎么重要，能够降级掉，甚至有的业务就是不能压测，好比给用户下放push消息。

在具体实施的时候，业务反复跟整个链路的每一个业务owner反复确认，哪些是核心业务，哪些是分支业务，哪些参与压测，哪些不参与压测，把这些造成文档，逐个跟进。

提供全链路压测的底层支持

要作全链路，要实现非核心链路的降级，就必须对底层的产品，例如中间件，数据库访问，MQ等作改动，让这些中间件支持全链路压测。咱们总体看看，通常须要哪些改动。

咱们把模型简化一下，以下图，虽然是简化的，可是基本上包括主流的分布式业务的技术栈。

能够看到，底层主要须要提供下面的支持：

• 全链路透传压测标志：必须有一种在全链路透传压测标志的能力，而且必须基于一次请求，也就是同一个traceId，如今，大部分分布式业务都会接入trace系统，例如，google的dapper，阿里的鹰眼等，对trace系统进行改造，使其可以透传压测标志，须要透传的路径大概有：
  • HTTP,RPC(DUBBO),MQ,线程池等
• 影子表：参与压测的业务，要逐个排查本身依赖的数据库，而后建立影子表，影子表必须跟正常表的schema保持一致，能够在每次压测时候手动建立，也能够推进DBA自动建立。建立好影子表后，若是当前流量是压测流量，那么写入和读取都走影子表。若是有本身的数据库中间件最好，没有的话能够借助于Mybatis的Interceptor机制。
• 日志-影子目录：为了防止压测流程的日志对正常日志形成干扰，须要改造日志组件，将压测流量产生的日志落入到影子目录。影子目录能够有日志组件自动建立。
• MQ支持是否消费压测流量：有的时候，全链路会经过MQ进行传递，因此，必须在消费MQ的时候进行选择：是否选择消费压测流量的MQ消息。这就须要对MQ系统进行改造，一方面使其能够透传压测流量，另外一方面，须要支持配置是否消费压测的MQ消息
• 缓存，大数据隔离：还有一些场景，好比，缓存层，大数据层对压测流量的处理也要考虑隔离。缓存可使用不一样的集群；大数据能够直接不收集压测的数据。

思考全链路压测的数据怎么mock

流程支持以后，还有关键的一步，就是考虑如何构造压测的mock数据。在使用影子表以后，能够比较轻松的实现跟正常数据隔离，那剩下的就是好构造好mock数据，有几点须要考虑：

• 用户数据要提早作好认证等准备工做
• Mock数据要尽量跟真实数据保持一致，好比，价格水平，图片数量，地址信息等等
• Mock数据有些限制须要放开，好比，库存，一些运营性质的活动能够取消等
• 千万不要污染正常数据：认真梳理数据处理的每个环节，确保mock数据的处理结果不会写入到正常库里面

作好压测流量的降级预案

这一点尤为重要，特别当业务特别的复杂的时候，必定要确认好，第三方依赖能不能接收压测流量，因此，只要依赖第三方的服务，咱们都要接入压测流量降级的开关，防止对第三方服务的污染。实现上，能够集成到RPC机制上，也能够提供相似于单独的限流组件。

梳理监控体系

确认好流程的技术支持和Mock数据的支持后，还要让每一个业务梳理本身的监控，确保压测时候可以准确，及时的发现问题。

• 核心接口和核心依赖的流量和耗时监控
• 中间件组件，缓存，数据库的监控报警
• 机器的指标报警

线下作好预演

真实的压测以前，确定要进行预演，预演主要确认：

• 压测流程是否写入到了正确的目的地，例如，写入到影子表，影子目录，压测cache等等
• 压测流量的降级是否完备和有效
• 进一步确保监控都已到位

尽可能模拟现实

咱们压测的脚步要尽量的模拟现实，好比：

• 购买的行为：不是下单后当即购买，而是要等一会儿
• 骑车子的行为：开锁后并非里面换车，而是骑一会
• 用户付款的行为：压测时候确定不会真的让用户付款，因此咱们得模拟用户付款
• 购买商品的数据
• 。。。

压测的脚步要跟各个业务确认，尽可能跟线上真实的用户行为保持一致

逐步平滑加压

压测的时候，逐步加压，而且要保持平滑加压，不要把一秒的流量都在前面几毫秒内都压出去。

造成报告

每次压测后进行复盘，总结压测中的问题，压测结果，机器的指标等数据造成报告发给你们，制订好后续的Action以及跟进的负责人。

推动

全链路压测的技术难点很少，除了要花时间梳理流程和思考如何处理数据以外，最难的就是整个链路跨多个业务，甚至部门，须要跟进每一个业务线的进度，确保你们可以在给定的时间点进行联调以及进行压测。在推动的时候，按照核心链路所在的模块进行跟进，每一个模块出一个owner，各个owner跟进核心的接口和依赖，每周你们碰一下同步下整体的进度。