bilibili全链路压测改造之全链自动化测试实践

01 背景与意义

B站直播营收送礼业务有着高写、在跨晚和S赛等大型活动下流量陡增、数据实时性要求高等特性，传统压测对于写场景为了避免影响线上数据做了各种屏蔽和黑名单处理，有着无法逼近线上真实情况的问题，因此业务对全链路压测有着较大的诉求，需要通过全链路压测来系统性地评估服务容量，发现瓶颈和隐患。
对于该诉求，直播技术侧结合公司的全链路压测方案，对营收送礼业务进行了全链路压测的服务改造。整个过程涉及到营收核心服务、底层中间件、压测sdk、压测控制台、施压平台等多处改造，链路长、配置多、影响的业务广，对质量方面的要求非常高，测试面临了比较大的挑战。一方面，要保障全链路压测安全可控，各个改造节点均需确保正确可靠，另一方面因底层改动带来的上层业务测试回归量巨大，测试效率难以保证。基于以上痛点，我们设计了全链自动化的测试方案，并与项目一起实践落地。接下来，我们来详细介绍下该方案的设计，希望能对一些正在或即将进行全链路压测建设的团队在质量保障工作上带来一些灵感和参考。

首先，我们先来介绍下业内普遍的全链路压测方案以及B站采用的方案，再基于具体的改造点来看测试范围。

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

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

对线上服务压测，压测前根据容量预估和压测目标，对线上服务进行扩容和cpu、mem等相关配置的变更。

压测产生的数据与线上真实数据做隔离，采用影子库表的方式，防止污染线上真实存储。

需构造压测数据和压测流量，通过压测标记来区分流量属性。

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

对线上服务施压，与方案一的区别在于数据隔离上，不是通过影子库表，而是在原表上增加标记，做逻辑隔离。

业务需要做适配工作来识别流量属性。

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

此方案在线下进行压测，部署线下测试环境或镜像环境。

线下环境稳定性不高，硬件资源和压测数据线上线下差异大，压测结果参考价值有限。

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

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

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

流量混部

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

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

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

线上压测

• 通过公司的压测平台，进行压测任务和场景设计、压测数据构造以及压测结果分析等，具体压测平台的设计及原理在B站压