全链路性能压测是什么？全链路性能压测解决哪些问题？

本文关于全链路性能压测是什么？全链路性能压测解决哪些问题？

一、什么是全链路压测？

基于实际的生产业务场景和系统环境，模拟大量的用户请求和数据，测试整个业务链的压力，并不断优化。

例如，金融系统涉及许多部门。例如，当我做性能测试时，我接触了银行的金融产品和金融电子商务项目涉及的相关系统：NDS(核心交易系统，本行金钱交易系统)，CII(公安网验证，网上验证身份证信息系统)，ESB(银行对外金融业务电商平台)，ICS，BPH(其行卡转账系统)，SMS(短信系统)，BLN(黑名单系统)、通联(第三方支付平台、五要素验证)、邦盛(第三方反欺诈平台验证)、鹏源(第三方信用平台)、ANF(东亚反欺诈系统)、商汤OCR(人脸识别系统)，ICA(银联综合认证，四要素认证)，BDP(银行内部大数据平台)、网跨平台、清算平台等，

像这么多相关系统，如果是自己的内部系统，可以与相关部门沟通，营造个性化的压力测试环境，进行全环节演练。另外，如果是外部第三方平台，在基本的全环节压力测试中做挡板服务器(丢失第三方)api设置返回时间，然后在实际范围内随机模拟第三方。一般来说，第三方服务不一定配合压力测试。即使配合，压力测试服务器也一般，不能作为压力测试环境

二、全链路压力测试解决了哪些问题

鉴于业务场景越来越复杂，整个业务系统链在海量数据冲击下的可用性和服务能力瓶颈，技术可以更好地服务业务，创造更多的价值。

三、问题点及解决方案

1、业务模型梳理

首先要明确的是，全链路压力测试针对的是现代越来越复杂的业务场景和全链路的系统依赖。因此，首先要将核心业务和非核心业务分开，确认流量高峰针对哪些业务场景和模块

2、数据模型构建

在数据构建和准备中，应考虑以下问题：

①、数据的真实性和可用性

可以从生产环境中完全移植当量数据包作为压力测量的基础数据，然后根据基础数据分析历史数据的增长趋势，估计当前可能的数据量；

②、数据脱敏

基于生产环境的全环节压力测试，必须考虑不产生脏数据，以免影响生产和用户体验，因此数据准备时需要脱敏；

③、数据隔离

同样，为避免脏数据写入，可考虑通过压测数据隔离处理，落入影子库，mock防止数据污染的对象等手段；

3、压测工具选型

全链路压力测试处理大量用户请求冲击，可使用分布式压力测试模拟用户请求。目前，有许多开源工具可以提供分布式压力测试，如jmeter、Ngrinder、locust等。

它可以基于这些压力测试工具进行二次开发。考虑到压力测量较大，回传测试结果将是agent造成一定资源占用的，可以考虑异步上传甚至事务补偿机制。

4、压测环境建设

全环节压力测试基于生产环境，解决了业务模型和数据以及压力测试工具的选择和开发，考虑系统扩展和风险规避，如压力测试不能影响实际生产业务运行和资源申请。

5、系统容量规划

前面提到了业务拆分和流量估计。在系统容量规划阶段，首先要对单个接口、单个服务进行基准测试，调整配置参数，得到基准线，然后进行分布式集群部署nginx负载均衡。

至于扩容，要考虑服务扩容和DB资源扩张和服务扩张带来的递减效应。

至于大流量冲击，可以考虑队列等待、容器锁、长连接回调、事务降级等方式。

6、测试集群部署

能够进行全链路压力测试的业务系统基本上是分布式系统架构、服务集群部署和负载平衡。

需要解决的问题有：

①、服务间通信问题

一般有两种通信方式：同步和异步。

同步调用：

REST（JAX-RS，Spring Boot）

RPC（Thrift, Dubbo）

异步调用：

(Kafka, Notify, MetaQ)

同步调用一致性强，但要考虑性能和调用失败。

异步调用可以减少服务之间的耦合，提高性能体验，但需要解决一致性（分布式架构有一个分布式架构）CAP理论上，感兴趣的可以查询相关信息)。

②、负载平衡问题

需要将大流量冲击均匀分发给集群上的每台机器。目前，优秀的负载平衡服务器是nginx，但nginx部署似乎也有一些问题，我们公司以前也遇到过重复订单的问题。

③、容灾问题

需要保证的是，当服务中的某一部分或某一部分停止时，服务可以及时转发，而不会在连锁反应下挂断整个系统链接的服务（请参考我之前的博客：灾难容忍测试）。

2.容灾试验遵循标准

①、模拟极端错误，测试业务恢复功能和业务连续性流程；

②、发现平台潜在隐患，确保平台在出线突发情况下能正常运行；

③、在极端流量的影响下，牺牲一小部分非主要业务功能或一小部分用户体验，确保整个系统的稳定性和主要功能的正常运行（转移和服务降级）；

④、测试时，需要同步分析日志（确认当前显示前显示的结果是否是由于灾难容量试验用例的有效性）。

3、容灾试验要点

①、核心原则：基于业务影响分析，全面完善IT系统的抗风险能力；

②、注意两个重要指标：RTO(恢复时间)和RPO(数据丢失量)；

③、做好三件事：数据传输、业务切换、灾难演练和监控；

④、恢复操作系统、文件、数据库和应用。

7、数据收集监控

压测数据收集，需要由agent机回送给Contorller机器，但数据量过大会占用一定的资源，可以考虑异步实现测试结果回送。

至于监控，现在有很多优秀的专业监控工具，比如Nmon、Zabbix，全链路监控工具Zipkin、PinPoint以及携程开源的全链路监控工具CAT。

或者可以针对需要，二次开发JVM自带的一些监控工具，做到实时全方位监控。