摘要：2015年牛市行情，沪深两市一天的交易量超过两万亿，当时就有数家券商交易系统出现短暂宕机。2019年两市交易持续火爆， 2月28日早开盘不足一小时，两市成交量就超过4000亿，多家券商交易系统出现短暂登录故障。另外这些年各家券商的系统技术变化非常大，新建系统还没有经受大行情的考验。随着交易量提升，系统异常或者性能压力问题也逐渐暴露出来，甚至在部分场合会遇到一些突发的行情利好，访问量和交易量暴涨，可能会引起系统的瘫痪。

  我们意识到，全链路压力测试在总系统稳定性建设中占有核心重要的位置，也是最有效的方案。结合实际业务的频率（比如1次/月），若能够把它作为稳定性保障的常规手段，系统运行质量也能获得很好的保障。同时，未解决周期常态化压力测试过程中人力成本高、多个团队重复工作、压力测试安全不可控，风险高等痛点，我们提出了全链路压力测试自动化的设想。

  最近几年互联网公司的“全链路压力测试”这个词经常印入我们眼帘。全链路压力测试被众多IT工作者定义为核武器。传统性能测试更多的是以事务为核心，更多的是由单个或者多个事务构成业务场景进行压力测试。那全链路压力测试到底是什么？一般指完全引入相关联的系统真实模拟线上硬件环境，更多的是以请求为核心，完全模拟真实请求流量，通过引流等方式来进行场景的模拟进行压力测试，更多的适用于业务链路较长的交易。

  随着业务发展，证券交易系统日益庞大复杂，涉及的系统也慢慢变得多，业务链路也慢慢变得长。证券交易系统全链路压力测试就是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

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

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

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

  全链路测试在实际在做的工作中，我们是当作大项目来考虑，那么这个大项目从大方面需要仔细考虑哪些呢？

  1） 涉及的系统多、团队多，业务模型梳理难度高 。全链路的压力测试涉及到大量的系统，在整个压力测试过程中，光各个系统的的人员协调就是一个比较大的工程。在这基础上，业务模型梳理难度，需要各团队的配合。

  2） 压力测试数据构造与处理，分布式测试工具选择与部署难度系数大等问题。

  3） 压力测试环境搭建环境成本高，重新搭建一套完全匹配生产环境的压力测试环境，成本过高，且需求频次较低，投入成本太大。

  4） 在全链路压力测试过程中，压力测试数据可能会影响到生产环境的真实数据，需要将请求和访问、业务数据处理都进行隔离，防止影响到生产环境。

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

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

  全链路压力测试平台的总体逻辑架构如上图所示，一个典型的Master＋Slave结构：Master作为压力测试管控台管理着Slave节点；Slave节点作为压力测试引擎，负责具体的请求发送。Master作为整个压力测试平台的大脑，负责整个平台的运转控制、命令发送、数据收集、决策等。

  指标监控模块：对压力测试过程中各个系统的cpu、内存、磁盘I/O以及各业务节点的耗时进行监控。

  压力测试报告：自动生成报告，收集链路入口和告警信息，提供问题记录和跟进功能。

  对单个系统的优化，其实方法有很多，但是万变不离其宗，就是在压力测试过程中监控系统各项指标，从中挑出慢的模块，针对慢模块来优化，对于联机系统大部分是由于各种IO问题导致性能上不去。能够准确的通过各种介质IO访问的性能来优化基本上通过缓存和异步处理这两颗银弹就能解决80%的性能问题。当链路上的单个系统性能提升了，整体的全链路性能自然就提升了。

  通过全链路监控不难发现整个业务流程在哪个节点耗时最长，那么这个耗时最长的节点就是我们应该优化的地方，只要这些关键路径的性能提升上来以后整体的性能就上来了。关键节点的优化方式和单系统优化思路一致。

  业务层面的优化主要是从分散IO的角度去考虑，将实际业务场景中的用户请求进行分散，这类业务流程的优化首先要梳理清楚整个业务流程，包括所有的细节。然后针对每个环节在保证使用者真实的体验的情况下分散用户请求，从而提升效果。

  整个压力测试优化过程就是一个一直在优化一直在改进的过程，通过长期的循序渐进的改进不断察觉缺陷，优化系统，才能让系统的稳定性和性能都得到质的提升。。本篇的全链路压力测试仅是基于券商特性进行的压力测试方案探索，其中涉及到的问题远远不止文中提到的这些，而且问题的处理方法也远远不是说的那么简单，因为证券交易系统全链路压力测试除了涉及到系统架构和组织架构，而且还涉及到金融监督管理。实际开展过程远比本文介绍的难度大，后续我们大家都希望全链路压力测试能实现以下梦想：