全链路压测之全链自动化

1.1 行业内全链路压测方案对比

方案一：流量混布, 存储隔离, 线上施压

对线上服务压测，压测前根据容量预估和压测目标，对线上服务进行扩容和cpu、mem等相关配置的变更。
压测产生的数据与线上真实数据做隔离，采用影子库表的方式，防止污染线上真实存储。
需构造压测数据和压测流量，通过压测标记来区分流量属性。

方案二：对数据本身做标记, 逻辑隔离，线上施压

对线上服务施压，与方案一的区别在于数据隔离上，不是通过影子库表，而是在原表上增加标记，做逻辑隔离。
业务需要做适配工作来识别流量属性。

方案三：镜像环境 OR 线下压测

此方案在线下进行压测，部署线下测试环境或镜像环境。
线下环境稳定性不高，硬件资源和压测数据线上线下差异大，压测结果参考价值有限。

技术同学经过调研，基于当前业务的语言栈较统一、基础组件较统一以及服务治理较完善等特点，选择了方案一作为B站的全链路压测方案。

1.2 B站全链路压测方案介绍

B站的全链路压测方案在B站在全链路压测上的实践一文中有详细介绍，简单来说主要为流量混部、线上压测和存储隔离三个部分：

流量混部

- 与线上集群资源共用，在深夜低峰时期进行线上压测

- 通过流量打标的方式对流量进行区分，压测流量均带有压测标识，支持对http请求和grpc请求打标进行全链路压测

- 服务接入压测sdk，对压测流量进行识别、拦截和处理
线上压测

- 通过公司的压测平台，进行压测任务和场景设计、压测数据构造以及压测结果分析等，具体压测平台的设计及原理在B站压测实践一文中有详细介绍。
存储隔离

- 我们采用存储隔离的手段，对db创建影子表，redis创建影子key，mq创建影子topic，将压测流量完全隔离

- 搭建全链路压测配置控制台，管理压测规则，主要涉及对已接入全链路压测的服务的以下几点配置：

△ 需要压测的接口

△ 压测接口依赖的下游接口的透传/镜像/Mock规则

△ 数据库表的透传/镜像/写丢弃规则

△ 缓存的透传/镜像规则

△ 消息队列的透传/拦截/镜像规则

可以看到整体链路，由压测平台施压，被压测的服务接入压测sdk，获取到由压测规则控制台下发的压测配置信息，根据配置信息对接收到的压测流量做处理，如配置了镜像规则的数据表，压测数据写入影子表，对配置了镜像规则的redis,压测的缓存数据写入影子key等等。

针对此链路上如此多的服务改造点（SQL改造、redis改造、databus改造、job改造、context改造、go channel改造、sync/pipeline改造...），如何能又快又好又全面的测试覆盖，是我们设计全链自动化测试方案的初衷，我们将其主要分为三个阶段。

第一阶段，我们对各个新增节点分别做了测试保障，如mirror sdk、压测配置控制台等，保正底层基础能力的正确性。

第二阶段，当基础建设已完成，进入到了业务接入及全流程验证阶段。业务是不停迭代的，其中随着基架的不断演进，业务所涉及的服务也包含了部分历史债，当此套框架真正接入业务后，我们往往在业务实际使用中会发现很多不适配的地方，包括框架设计不够健壮或者业务的使用姿势不规范等原因，需要修复或兼容。这个阶段的测试也是最繁琐、测试量最大、重复性很高的地方，为此全链自动化测试全面应用于此阶段，来提升效率及业务覆盖度。

第三阶段，主要应对于未来的拓展，随着全链路压测覆盖的业务越来越多，当”常态化“的全链路压测计划提上日程，重复的工作和人力成本随之增加。此时测试工具更需要平台化及可视化，为压测前、压测中、压测后各个阶段的重复工作提供有效的自动化支持。

接下来，我们详细介绍在第一和第二阶段中，测试方案的设计及应用。

注释：

压测配置控制台：全链路压测配置中心，配置被测服务、被测接口、下游依赖接口、被测接口涉及到的缓存、数据库、消息队列。
mirror sdk：为大仓提供的压测控制sdk，通过配置文件可以直接控制数据库、缓存、消息队列等组件对压测流量进行处理。

1.3 全链自动化测试方案

我们主要遇到的测试难点如下：

改造均为核心业务，涉及改造的服务数多、接口数多，测试量大。
改造非常底层，涉及mysql、tidb、redis、databus等中间件，业务逻辑分支多，传统手动测试很难高效全面覆盖。
改造的服务涉及的依赖和配置多，中间任何节点的错误均可能导致在压测实施时影响到线上，如配置遗漏可能导致数据写到线上库、sdk故障可能导致压测标失效等，需要在压测前的进行“扫雷”。

设计方向思考

广度：借助接口自动化测试平台来保障业务的覆盖度
效率：人工校验转为工具自动校验，自动化校验业务逻辑

全链自动化方案设计主要包含以下三个部分：

链路分析
配置确认
自动化校验

02 主要测试过程与实施

2.1 链路梳理分析

链路梳理是保障全链路压测安全实施的前提，服务改造、压测配置、自动化校验等工作都强依赖链路梳理与分析，梳理工作非常繁琐，使用传统翻代码的手段不仅低效，而且容易遗漏而引发安全事故。这里我们主要采用动静结合的方式来完成链路梳理工作。

工具：

trace追踪：全链路跟踪系统，提供分布式环境下服务调用链监控，还原请求调用关系。
自动化代码规范扫描与检查工具bilicontextcheck lint：检查代码中不规范使用context的地方以及是否有context传递中断的场景。

静态扫描：调用链中容易出现因ctx使用不规范导致调用链断裂的情况，对此使用bilicontextcheck lint工具用来检查业务代码中ctx不规范的地方，确保调用链不会断，压测标识能完整传递。

链路追踪：依赖链路追踪工具可视化的返回服务链路的依赖关系，各节点对数据库、缓存、消息队列的调用信息等，以下是使用示例。

2.2 压测配置确认

通过对业务的链路分析，我们明确了具体的压测范围，业务的服务依赖关系，接着需要在压测控制台进行整个链路的压测规则配置，涉及服务的接口配置、依赖接口配置、数据库配置、缓存配置、消息队列配置，根据实际业务场景配置透传、镜像、写丢弃、Mock等规则。

2.3 自动化校验

测试覆盖率和效率的提升，均离不开自动化测试，因此，测试改造工作也基本围绕"自动化"来展开。在基架改造、业务服务改造、压测配置、服务部署等工作都完成后，将进入测试验证阶段。本阶段主要通过自动化的手段对业务进行正确性验证，两套流量均需包含以下内容的检查：

接口返回校验：response结果需符合业务预期，输入/输出参数检验、格式校验、容错处理、安全检验等
接口存储校验：mysql、tidb、redis的读写符合业务预期
业务异步流程校验：确认压测标识全链路透传，压测流量和正常流量在异步流程下trace均能正常关联，比如送礼链路的异步结算流程，在送礼接口调用完成后，可通过订单id查询结算表数据来验证结算是否异步调用成功
链路完备性校验：结合压测控制台规则，对接口的调用链路进行自动校验

自动化实施的关键key

自动化case需支持切换环境，支持正常流量和压测流量两套流量的构造、识别和检测
数据流能自动化检验，保证调用链路各节点符合预期，包括下游接口调用、数据库、缓存、消息队列等节点

要实现以上功能，我们需要对已有的自动化框架进行改造，保持原自动化case能复用的基础上，增加压测流量构造、链路完备性检测等功能，以下是我们团队自动化框架的分层设计图，红色部分为本次的框架改造点。

自动化框架分层设计：

通过上图，可以看到我们的自动化测试框架分为三层结构设计，最上层为case层，按业务做单接口用例和场景用例的编排，中间层为invoker层，做请求封装(http&grpc)、配置管理、断言、中间件连接等基础功能封装和聚合，最底层coverage层包含grpc和php服务测试覆盖率统计功能，本次改造在原有测试框架上进行，对框架的核心改造如下：

增加压测标识“mirror”，通过全局变量 config.mirror 控制流量入口，设计压测标识的从上到下透传。
在invoker层封装链路检测工具集“trace_toolset”，进行链路完备性检查。
在invoker层封装http/grpc请求，request header中增加压测标识mirror。

自动化框架改造 — 入口改造：

使框架能支持压测流量的构造，在流量构造层使用全局变量控制流量入口，能一键切换流量指向正常环境还是全链路压测环境。
改造点：在配置文件config中增加压测标识：config.mirror，默认值为空（若值为空则识别为正常流量）。

自动化框架改造 — 压测数据构造

压测写场景，往往涉及到要对压测的上游数据进行构造，如送礼场景，需要压测用户的钱包有余额，压测前需要在相关的影子表插入数据，这类型case属于压测前的数据准备工作，需识别并进行构造。

自动化框架改造 — 自动化链路完备性校验

链路完备：需要确保调用链路完整且染色标不能中断，保障方案分静态收敛和动态收敛两种策略，基于业务验证占据80%+工作量，此验证过程必须尽可能的自动化，为此我们引入链路检测工具集“trace_toolset”，自动进行链路完备性检查。

trace_toolset

基于接口链路的唯一标识traceid，从链路追踪工具中获取链路的各个节点，结合压测规则配置控制台的配置，依次检查调用链中的mysql、tidb、redis、databus的调用是否符合预期，分别对正常流量和压测流量两套规则进行检测，对于校验结果回传至上层case，输出测试报告，以下是链路检查工具与自动化框架结合下的调用流程。

自动化case改造复用

基于服务改造范围大、涉及的接口多、链路长的特性，怎么提升测试效率以及回归效率（底层bugfix回归）是需要解决的一大难题，本次方案主要采用case复用的思路来解决效率问题，复用已有业务沉淀的自动化case，在此基础上，保持case中间部分业务结构不变，通过mirror识别，仅修改头部流量入口和尾部规则校验方法，让case能复用于压测流量，快速将case翻倍。