全链路压测在信用卡行业的实践

目前互联网、电商行业普遍采用全链路方式对业务系统开展性能验证、活动预演和稳定性演练，但全链路压测在传统银行业应用较少，本文以传统金融系统为立足点，谈谈全链路压测在信用卡行业的实践应用。

一、为什么要做全链路压测

我司的压测体系经过多年建设，已建立线下压测为基础，生产压测为支撑的综合性能保障体系。借助线下压测，尽早发现各类代码问题，及时开展低成本的性能优化；通过生产压测，弥补测试环境差异，验证生产系统容量，识别系统稳定性风险。随着 IT 行业的快速发展，尤其是开源生态的不断完善，应用技术层出不穷，实现形式丰富多样，服务方式快速迭代，应用层和基础层的架构日趋复杂，在技术升级的驱动下，业务服务往细分领域不断延展，用户行为模型愈发多样，现有测试策略无法完全模拟真实业务场景，难以有效捕捉复杂业务链路下的真实性能。

针对贷后业务开展全链路压测，以生产全链路为抓手，对业务链路和技术链路进行全面覆盖，组织高度仿真的性能测试，全面评估系统服务性能，整体识别场景链路风险，有效提高用户性能体验，通过“完整化、自动化、精细化”的性能服务，完善服务体系配套，推动科技体系治理，切实提高科技引领作用。

二、全链路压测的主要目标

1、助力应用服务治理，在开展贷后业务全链路压测前，贷后业务通过 socket 通信接入企业消息总线，贷后业务的关联系统间存在 HTTP、socket 多种通信方式，服务间的扩展性、通用性受到极大制约；贷后业务全链路压测课题的开展，顺利完成贷后业务通过 HTTP 接入企业消息总线的技术验证，后续该贷后业务全链路的关联系统间将全部采用 HTTP 进行通信，全链路压测课题的开展推动了贷后业务系统间的应用服务治理；

2、降低综合保障成本，全链路压测可有效回避主备库切换、对外屏蔽、业务协调等工作，有效简化团队协作，降低保障成本，贷后业务在实施全链路压测前，曾组织关联团队，通过中断业务切换主备库的模式，开展了五轮生产压测，完成线上水位的局部探知；在实施全链路压测的技术验证时，单轮压测即可完成整体链路的性能采集；

3、全面探知系统水位，通过全链路压测对系统性能进行整体测试，从业务链路、基础链路、数据链路等多个维度，对系统性能进行充分探知，保障全链路的整体性能。

4、充分预演业务高峰，借助全链路压测实现不停机的线上压测，可随时对各类业务高峰进行预演，充分评估系统性能，做好容量规划，保障活动开展；

5、及时演练生产变更，在线开展的全链路压测，可结合需要随时对各类生产变更进行演练，丰富生产保障方法，维护线上运行的稳定；

6、有效提升服务时长，借助全链路压测，实现压测流量和正常流量的分离，在不停止对外服务的同时，随时开展线上压测，消除压测带来的业务中断影响，业务服务时长得到有效提升；

三、全链路压测的关键策略

全链路压测技术在一些头部互联网企业已经有较为成熟的运用。这一技术在重大活动备战工作中，对于容量评估、稳定性保障都发挥着至关重要的作用。

要达到在生产环境进行全链路压测而不影响真实业务，需要对系统进行一定的改造，使其具备生产全链路压测所需的几大核心能力：

1.全链路流量染色能力，通过压测平台对输出的压力请求打上标识，在业务系统中提取压测标识，确保完整的调用链路上下文都持有该标识。

2.全链路数据隔离能力，数据隔离的手段有多种，比如影子数据、影子表、影子库，三种方案的隔离粒度有差异，相应的仿真程度和维护复杂度也有差异。

3.全链路日志隔离能力，当应用系统向磁盘或 ELK 系统输出日志时，若流量是被标记的压测流量，则将日志隔离输出，避免影响生产日志分析。

4.全链路风险熔断能力，需要具备跟生产监控系统自动联动的能力，当达到容量瓶颈或出现预期外情况时，从施压端到被压端都可以自动熔断。还应具备压测流量准入机制，非压测窗口不允许压测流量进入，以最大程度避免风险隐患。

四、全链路压测的整体设计

全链路压测的整体设计需要围绕系统业务特点，开展针对性的流量染色能力设计、数据隔离能力改造、日志隔离能力改造和风险熔断能力改造等，主要设计要点如下：

1、全链路流量染色能力设计

流量染色能力主要设计流量染色和染色标透传，具体设计要点如下。

流量染色技术的核心思想是，从压测流量发起端加入特定的请求头，将压测流量与真实生产流量区分开来。在 HTTP 请求头加入 PublicHead 字段，值的格式如 {"pDyeingContext":{"pDyeingFlag":"1"}}，表示压测流量。

压测平台发起的压测请求头打上染色标识后，后续的所有业务请求链路中，都要确保压测标识正确透传下去，具体透传方案如下：

HTTP 服务端透传：增加 Filter，从 HTTP Header 中读取压测标识，放入 ThreadLocal 中，确保在同一个请求内透明传递；

HTTP 客户端透传：针对 RestTemplate 组件做拦截增强，从 ThreadLocal 中读取压测标识，在发往下一个节点的 HTTP 请求头中加入压测标识；

异步线程透传：在使用异步线程的情况下，ThreadLocal 中的压测标识将无法正确传递。需要对 Runnable、Callable 等类进行增强，以实现压测标识的跨线程透传；

跨系统透传：本次项目改造中，贷后业务系统调用企业消息总线的通信方式由 Socket 协议改成 HTTP 协议，以支持在 HTTP 头中透明加入染色标识，并传递到后端业务系统。同时采用 HTTP 协议也符合未来技术架构发展的方向。

为了避免压测标识透传逻辑扩散到业务代码，需要在中间件层面对改造逻辑进行统一规范和收口。这样的实现方案具备了可复制性，在试点项目验证通过之后，也可以快速地应用到其他项目中。具体的实现方式分成两种：

①使用 Java Agent 字节码增强技术，动态增加压测标识透传能力，优点是避免代码改造，方便灵活

②显式改造公共 jar 包组件的代码，增加压测标识透传能力，优点是可靠性高，避免生产环境 Java Agent 设置遗漏的风险。从风险控制的角度出发，建议采用此方式改造。

2、全链路数据隔离能力设计

数据隔离能力涉及数据库、Redis 等组件的改造，主要目的是确保压测流量数据和业务数据的有效分离，确保压测数据不影响实际业务，数据隔离能力是全链路压测的核心基础。

(一)隔离设计-数据库

数据库隔离技术从隔离程度由浅到深，有影子数据、影子表、影子库等方案。

（1）影子数据方案，测试数据直接存放于生产表中，通过字段区分。这种方案不需要准备铺底数据，不需要额外增加存储资源。但是这种方式隔离性最弱，应用系统代码也需要做相应逻辑改造来识别压测字段。

（2）影子表方案，影子表方案是增加一个 SQL 转换拦截层，根据 ThreadLocal 中的透传标识，将压测请求的 SQL 中的表名进行替换，增加特定的后缀，路由到影子表。影子表方案隔离性中等，需要生产数据库中增加一倍的容量冗余，还需要额外增加 SQL 解析转换层。

（3）影子库方案，影子库方案是在数据源上层封装一层代理路由数据源，应用层感知到的是一个数据源，在代理路由数据源内部，根据 ThreadLocal 中的压测标识，决定路由到压测库还是生产库。影子库方案需要额外增加独立的数据库资源，相应地，隔离性也是最好的。目前委外催收已经基于 Spring 提供的 AbstractRoutingDataSource 实现了 Master-Slave 数据源自动路由，只需在其之上增加影子数据源路由逻辑即可。从隔离性和改造侵入性等方面综合考虑，建议采用影子库方案。

(二)Redis 缓存隔离

除了持久化数据需要做隔离之外，分布式缓存（如 Redis）的数据也需要做相应的隔离，以防测试流量污染生产缓存数据。缓存隔离技术总体上可以分为影子键与影子集群两类方案。

（1）影子键方案，是在缓存客户端上封装一个键转换层，根据 ThreadLocal 中的透传标识，将压测请求读写的缓存键进行替换，增加特定的后缀（例如_t），以跟生产数据逻辑隔离。

（2）影子集群方案，是在缓存客户端上层封装一层代理客户端，应用层感知到的是一个缓存集群，在代理客户端内部，根据 ThreadLocal 中的压测标识，决定路由到压测集群还是生产集群。隔离性和改造侵入性等方面综合考虑，建议采用影子集群方案。

3、全链路日志隔离设计

压测请求所产生的日志，也需要跟生产流量产生的真实日志进行隔离。以免压测流量干扰正常的问题排查、数据分析、日志监控指标。比如通过 slf4j 的 MDC 技术，将压测标识放入 MDC 上下文中，并结合 Logback 的 Filter 机制，可以实现日志内容字段、日志文件目录、Kafka Topic 的区分。

4、全链路风险熔断设计

全链路压测的核心基础是数据隔离，关键策略是风险熔断，要充分考虑隔离能力失效、压测流量过载或失控等异常情况对线上系统的影响。风险熔断有几个关键点，一是确保自主可控，二是兜底保障数据，三是自动降级响应，

五、全链路压测的总结和展望

此次贷后业务全链路压测课题的顺利实施，完成了全链路压测在传统金融的应用试点，在应用过程中，整体体系工程还存在进一步提升空间，后续将借助全链路压测逐步完善性能体系工程，统筹推进业务保障和技术升级。

保障高并发活动的顺利开展，将全链路压测技术应用到高并发营销活动，整体评估活动业务性能，确保各类营销活动的顺利开展；

构建标准的性能技术工程，对标头部互联网，以技术中台为依托，实现全链路压测技术的标准化，构建标准的性能技术工程；

实现性能保障的转型升级，借助全链路压测开展容量规划和灰度验证，赋能周边职能团队，将性能保障体系由单纯的测试验证，转变为系统的质量保障，实现性能保障体系的转型升级；