关于证券交易系统全链路压力测试的一种探索

范兴元 / 兴业证券股份有限公司

摘要：2015年牛市行情，沪深两市一天的交易量超过两万亿，当时就有数家券商交易系统出现短暂宕机。2019年两市交易持续火爆， 2月28日早开盘不足一小时，两市成交量就超过4000亿，多家券商交易系统出现短暂登录故障。另外这些年各家券商的系统技术变化非常大，新建系统还没有经受大行情的考验。随着交易量提升，系统异常或者性能压力问题也逐渐暴露出来，甚至在部分场合会遇到一些突发的行情利好，访问量和交易量暴涨，可能导致系统的瘫痪。
我们意识到，全链路压力测试在整个系统稳定性建设中占有核心重要的位置，也是最有效的方案。结合实际业务的频率（比如1次/月），如果能够把它作为稳定性保障的常规手段，系统运行质量也能够得到很好的保障。同时，为了解决周期常态化压力测试过程中人力成本高、多个团队重复工作、压力测试安全不可控，风险高等痛点，我们提出了全链路压力测试自动化的设想。

一、 什么是证券交易系统全链路压力测试

最近几年互联网企业的“全链路压力测试”这个词经常印入我们眼帘。全链路压力测试被众多IT工作者定义为核武器。传统性能测试更多的是以事务为核心，更多的是由单个或者多个事务构成业务场景进行压力测试。那全链路压力测试到底是什么？一般指完全引入相关联的系统真实模拟线上硬件环境，更多的是以请求为核心，完全模拟真实请求流量，通过引流等方式进行场景的模拟进行压力测试，更多的适用于业务链路较长的交易。
随着业务发展，证券交易系统日益庞大复杂，涉及的系统也越来越多，业务链路也越来越长。证券交易系统全链路压力测试就是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

二、 为什么要做全链路压力测试

1. 验证系统的稳定性

我们在整个业务流程中，最大的困难在于评估从用户登录到完成全部交易的整个链条中，核心页面和交易关键交易的实际承载能力。就算是系统架构师对整个全交易链条上的各个环节的系统承压能力也不清楚，所以通过全链路压力测试，一方面能够让各个系统知道自己的承压极限在哪？有的人会问了通过单系统压力测试不是也可以知道各个系统的承压能力吗？但是实际情况不可能那么简单，在访问量和交易量暴涨期间，从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力，这个时候系统服务除了受自身的影响，还依赖于其他关联系统的情况，并且影响会一直蔓延，只要有一个节点出现故障，那么故障在上下游系统经过层层累加后会造成的影响不可预估，所以最好的办法就是模拟完全的真实情况来做到提前心里有数，验证的最好办法就是让事件提前发生，通过全链路压力测试就可以提早发现问题，验证交易系统的稳定性。

图1 单模块压力测试和全链路压力测试区别

2. 系统容量评估和优化

通过全链路压力测试可以清楚系统瓶颈所在。如果得到了各个系统的实际承载能力，就可以在路由网关进行相关交易限流控制，来防止在大并发来了以后系统出现宕机，我们都知道一旦系统宕机就会导致灾难性的后果，就算短时间重启恢复运行，极有可能过一段时间又会出现宕机。当系统压力达到预警时，就可以坦然的去按照压力测试指标去关闭非核心功能或者调配非核心的业务的资源来支持核心业务，等系统稳定后再归还资源；同时全链路压力测试可以让各个系统能够找到明确的优化目标，针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。

3. 灾备故障演练

另一方面也可以在灾备演练中排上用场，通过全链路压力测试压垮某个模块或者整个系统，使演练的处理过程是更加接近异常事故发生时的处理过程，最大限度的检验灾备系统在行情洪峰压力情况下的灾难恢复能力和灾难恢复预案，参演人员对整个灾难处理流程的熟悉程度和各自负责任务的熟练程度，增加灾难处理过程中各环节参加人员配合的默契程度。

三、 全链路压力测试存在问题

全链路测试在实际工作中，我们是当作大项目来考虑，那么这个大项目从大方面需要考虑哪些呢？
1） 涉及的系统多、团队多，业务模型梳理难度高 。全链路的压力测试涉及到大量的系统，在整个压力测试过程中，光各个系统的的人员协调就是一个比较大的工程。在这基础上，业务模型梳理难度，需要各团队的配合。
2） 压力测试数据构造与处理，分布式测试工具选择与部署难度系数大等问题。
3） 压力测试环境搭建环境成本高，重新搭建一套完全匹配生产环境的压力测试环境，成本太高，且需求频次较低，投入成本太大。
4） 在全链路压力测试过程中，压力测试数据可能会影响到生产环境的真实数据，需要将请求和访问、业务数据处理都进行隔离，防止影响到生产环境。
5） 压力测试指标指定和测试结果准确度。

四、 如何开展全链路压力测试

首先要考虑的是压力测试环境的问题，很多系统可能压根就没有压力测试环境，所以全链路压力测试有个和传统压力测试比较大的区别就是，全链路压力测试是在生产环境，这种做法其实是存在一定风险的。考虑到证券交易生产系统的安全性和稳定性，不同于互联网公司线上全链路压力测试，结合证券公司的核心交易系统的压力测试特点和经验，我们提出了一种证券公司交易系统的全链路压力测试思路：非交易日时段在生产系统进行全链路压力测试。既不影响证券交易的安全性和稳定性，又可以在真实的生产环境测试获得一手测试数据，同时还可以回避因测试产生的脏数据问题。
通过对全链路压力测试实施流程统一的梳理，分为以下4个步骤：

图2 全链路压力测试实施步骤

在压力测试各个阶段推进标准化和自动化，尽力提升全流程的执行效率，达到常态化的目标，最终整个流程达到闭环。

图3 全链路压力测试流程闭环

图4 全链路压力测试平台

全链路压力测试平台的总体逻辑架构如上图所示，一个典型的Master＋Slave结构：Master作为压力测试管控台管理着Slave节点；Slave节点作为压力测试引擎，负责具体的请求发送。Master作为整个压力测试平台的大脑，负责整个平台的运转控制、命令发送、数据收集、决策等。
任务管理模块：设定压力测试执行任务，自动调度整个压力测试执行过程。
链路管理模块：负责服务接口方法调用链路的构建、更新、存储。
数据配置模块：为不同业务压力测试实施准备基础和流量数据。
节点控制模块：负责压力测试节点资源调配。
指标监控模块：对压力测试过程中各个系统的cpu、内存、磁盘I/O以及各业务节点的耗时进行监控。
压力测试报告：自动生成报告，收集链路入口和告警信息，提供问题记录和跟进功能。

五、如何进行链路优化

全链路压力测试一般可以从3个层面去进行优化：
1）优化单个系统性能
对单个系统的优化，其实方法有很多，但是万变不离其宗，就是在压力测试过程中监控系统各项指标，从中挑出慢的模块，针对慢模块进行优化，对于联机系统大部分都是因为各种IO问题导致性能上不去。可以根据各种介质IO访问的性能来优化基本上通过缓存和异步处理这两颗银弹就可以解决80%的性能问题。当链路上的单个系统性能提升了，整体的全链路性能自然就提升了。
2）优化关联路径
通过全链路监控可以发现整个业务流程在哪个节点耗时最长，那么这个耗时最长的节点就是我们需要优化的地方，只要这些关键路径的性能提升上来以后整体的性能就上来了。关键节点的优化方式和单系统优化思路一致。
3）优化业务流程
业务层面的优化主要是从分散IO的角度去考虑，将实际业务场景中的用户请求进行分散，这类业务流程的优化首先要梳理清楚整个业务流程，包括所有的细节。然后针对每个环节在保证用户体验的情况下分散用户请求，从而提升效果。

六、总结

整个压力测试优化过程就是一个不断优化不断改进的过程，通过长期的循序渐进的改进不断发现问题，优化系统，才能让系统的稳定性和性能都得到质的提升。。本篇的全链路压力测试仅是基于券商特性进行的压力测试方案探索，其中涉及到的问题远远不止文中提到的这些，而且问题的解决办法也远远不是说的那么简单，因为证券交易系统全链路压力测试除了涉及到系统架构和组织架构，而且还涉及到金融监管。实际开展过程远比本文介绍的难度大，后续我们希望全链路压力测试能实现以下梦想：
1) 压力测试可以在在交易日进行，远离周末加班测试。
2) 通过监控和流量干预来保护系统，让系统更稳健的运行。
3) 压力测试可以做到智能化常规化，业务部门人也能一键运行。