全链路瓶颈测试方法及系统与流程

本发明涉及系统性能压力测试领域，特别是涉及一种全链路性能瓶颈定位及评估方法及系统。

背景技术：

现有技术在端到端链路压力测试定位性能瓶颈时，一般通过手工编写的shell脚本分析被测系统中各子系统经过压力测试后所产生的日志信息，并由脚本计算出各子系统的平均耗时，从而定位系统瓶颈。由于每次进行压力测试都需要测试人员逐一查找瓶颈点，因而使得全链路压力工作繁琐，且查找流程环节不紧凑不具有流动性，计算结果无法达到实时高效，无法实现动态查找，而且从效率上看，整个测试过程操作效率低下。

进一步地，现有的专利技术方法，尚不能全面解决超大规模架构的需求，对于超大型复杂的系统架构，由于涉及环境复杂，节点繁多等客观因素，使用该方法分析每一层，每一个节点，势必工作量巨大，会产生很多的分析过程产出物文档，这些分析文档的整合和综合性分析，对于人员能力的要求也提出更高的标准。

本申请主要名词解释：

bp：本专利申请中，bp指中信银行电子渠道对私业务处理平台，为多个电子渠道系统提供统一的客户管理等功能，简称“对私bp”或“bp”；

外联平台：本专利申请中，外联平台指中信银行与外部系统的实现互通的平台系统；

第三方亿佰测试环境：本专利申请中，第三方亿佰测试环境指第三方企业亿佰提供的性能测试环境。

技术实现要素：

本发明的目的在于提高全链路压力性能测试的主动性及效率，希望摆脱单纯被动的接受需求的方式。

本发明的技术效果是根据文档模板实现文档条目化处理，文档格式规则可以自动生成，内容规则根据业务需求手动增加，所有规则可以自动发布，系统管理员可以在系统后台独立维护，保持管理规则的独立性、透明性。

本发明进行了二次开发，实现了文档的在线编写、实时检查、生成和持久化保存检查报告的功能，解决了文档检查，实现了审计自动化，解决了及时性问题。

本发明全链路性能测试，如图1所示，逻辑步骤如下：

步骤s101，根据业务需求，绘制生成各业务链路拓扑模型。

步骤s102，根据业务需求、历史存量的生产运维数据，以及拓扑结点中每个系统处理的性能，初始化拓扑模型中每个节点的性能容量标准。

步骤s103，基于静态数据，分析并定位拓扑模型中的性能瓶颈节点，即以静态方式分析短板。

定位性能瓶颈节点位置后，性能瓶颈流转至其他节点，即以动态方式分析流动性。

本测试压力是从前端向后端传导，将测试到的压力与预设的历史最大的处理能力做对比分析，分析该节点是否会成为瓶颈，从而找到整个链路上不能满足业务需求的瓶颈点。

步骤s104，测试人员设计多套性能优化策略，一旦发现瓶颈点，从预备策略中选择与瓶颈点相匹配的策略，对当前瓶颈点做优化分析，在应用到瓶颈点后，如果性能有所提升，且能够满足要求，则继续往后传导，依次进行，即动态变化瓶颈测试。

步骤s105，定位拓扑模型中的性能瓶颈节点位置后，根据性能瓶颈节点是否具备明确的性能优化方案，区分路径：

如果不具备可优化的方案，则重点关注拓扑模型中系统性能短板，进行专项验证。当传导到某一个节点时，需评估该节点是否为整个链路上最后的一个性能瓶颈点，即粘性问题，所述粘性问题就是通过测试进行专项验证，保证最短的板不是最重要的那块，再结合监控予以防范。

如果具备可优化得方案，则对测试到的瓶颈节点进行优化，

步骤s106，按照步骤五进行优化后，更新拓扑模型中各节点的性能容量信息，性能瓶颈动态流动至其他节点。

当测试进行到最后一个节点，完成后，性能测试继续流动，从而实现循环测试。

可选的或优选的，步骤二所述的分析拓扑模型中的性能瓶颈节点，为结合需求和拓扑模型进行分析。

可选的或优选的，本发明的系统集成了文档web在线编写工具，在线编写仅提供数据库的条目化信息即可，在线编写工具仅支持了在线编写文档的易用性，本技术方案还进行了二次开发，实现了文档的在线编写、实时检查、生成和持久化保存检查报告的功能，解决了文档检查(审计)的自动化、及时性等问题。

可选的或优选的，本发明方法采用elasticsearch存储被测业务系统的相关信息。

可选的或优选的，本发明方法通过查询所述elasticsearch获取到测试链路上各系统的信息。

可选的或优选的，本发明方法除了上述的可通过查询所述elasticsearch获取到测试链路上各系统的信息，还可通过解析系统的上下游信息，生成业务链路拓扑。

优选的，本发明方法使用python语言进行实现。

可选的或优选的，本发明方法生成的业务链路拓扑通过web展示。

本发明采用elasticsearch存储被测业务系统的相关信息，包括系统名称及标识、性能容量信息、上游系统清单及下游系统清单等信息；

本技术方案是通过压力测试来实现瓶颈点的定位，其核心在于根据测试目标录入各被测系统的测试目标，提交后，后台分析找到所有瓶颈节点，并根据系统的性能容量和测试目标的差异，对瓶颈节点进行排序，确定瓶颈节点的主次关系；后台将分析结果在web前台展现，标识业务链路拓扑的主要瓶颈节点；

对主要性能瓶颈节点选取优化方案，分析系统调优后的性能容量，在web页面更新后提交。提交后触发后台对调优后的节点进行分析，如果不再成为瓶颈，在瓶颈节点列表中移除；如果仍存在瓶颈，更新该节点在瓶颈节点中的次序。确定优化后的主要瓶颈节点后，再次执行上述迭代过程，所有瓶颈节点均被移除，或主要瓶颈节点不再发生变化。

本技术方案的基于动态和静态结合分析的全链路性能瓶颈定位方法不需要再执行测试，就能定位出最易成为瓶颈的系统上来，极大的减少全链路测试的成本投入。

本发明可以提高全链路压力性能测试的主动性及效率，摆脱单纯被动的接受需求的方式，全链路性能瓶颈定位方法不需要再执行测试，就能定位出最易成为瓶颈的系统上来，极大的减少全链路测试的成本投入。

本发明还设计有一种全链路瓶颈预测系统，包括拓扑模型生成单元、性能容量初始化单元、性能瓶颈节点定位单元、专项验证单元、优化单元、容量信息更新单元；

拓扑模型生成单元，适用于根据业务需求，绘制生成各业务链路拓扑图；

性能容量初始化单元，适用于根据业务需求、历史存量的生产运维数据，以及拓扑结点中每个系统处理的性能，初始化拓扑模型中每个节点的性能容量标准；性能瓶颈节点定位单元，适用于基于静态数据，分析定位拓扑模型中的性能瓶颈节点；

专项验证单元，适用于不具备优化方案的情形，根据拓扑模型中系统性能短板，进行专项验证；

优化单元，适用于具备优化方案的情形，对测试到的瓶颈节点进行优化；

容量信息更新单元，适应于更新拓扑模型中各节点的性能容量信息。

附图说明

图1是本发明实施例提供的一种全链路瓶颈测试方法的逻辑示意图。

图2是本发明实施例提供的一种全链路瓶颈测试方法的流程图。

图3是本发明实施例提供的一种全链路瓶颈测试系统的逻辑示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。显然，所描述的实施例实际上仅仅是说明性的或者示例性的，决不作为对本发明及其应用或使用的任何限制。在下面的详细描述中，提出了许多具体细节，以便提供对本发明的全面理解。但是，对于本领域技术人员来说很明显的是，本发明可以在不需要这些具体细节中的全部细节均已了解的情况下实施。下面对实施例的描述仅仅是为了通过展示本发明的示例来提供对本发明的更好的理解。本发明决不限于下面所提出的任何具体配置和算法，而是在不脱离本发明的精神的前提下覆盖了元素、部件和算法的任何修改、替换和改进。

下面结合具体实施例对本发明做进一步详细的描述，但本发明的实施方式不限于此。

如图2所示，本发明实施步骤如下：

步骤s101，根据业务需求，绘制生成各业务链路拓扑图。

具体地，本发明使用python语言实现，通过查询elasticsearch获取到测试链路上各系统的信息，通过解析系统的上下游信息，生成业务链路拓扑，通过web展示。

步骤s102，根据业务需求、历史存量的生产运维数据，以及拓扑结点中每个系统处理的性能，初始化拓扑模型中每个节点的性能容量标准。

步骤s103，基于静态数据，结合业务需求指示及拓扑模型，对交易路径中各系统节点进行性能瓶颈定位分析；即“静态分析短板”。

具体地，根据测试目标录入各被测系统的测试目标，提交后，后台分析找到所有瓶颈节点，并根据系统的性能容量和测试目标的差异，对瓶颈节点进行排序，确定瓶颈节点的主次关系；后台将分析结果在web前台展现，标识业务链路拓扑的主要瓶颈节点。

参照步骤二所初始化的每个节点的性能容量标准，比对分析拓扑模型中的每个节点；该过程主要描述对系统链路进行分析寻找到系统当前的瓶颈。

如表1所示，本技术方案对全链路的性能指标要求是在最前端的系统a达到90，为满足该目标，通过系统间的关系可以分析出对系统b的指标要求需要达到180，系统c的指标要求达到360(数据均为假设，假设系统a处理一次请求需要调用系统b两次，系统b处理一次请求需要调用系统c两次)。基于在前一步骤s102中初始化得到的各系统当前的性能容量，系统b和系统c均无法满足目标。根据该示例中数据的比例关系，系统c为主要瓶颈，需要优先对系统c优化(系统b性能可以支撑系统a的60次请求，而系统c仅可以支持系统a的45次请求)。通过步骤s105对系统c优化后，系统c的性能有所提升，如果系统c性能无法提升到240以上，则主要性能瓶颈依然是系统c，即进入步骤s105的左支，即不具备优化方案；如果系统c性能提升到240以上，则主要性能瓶颈流转到系统b，即进入来信中步骤s105的右支，后续循环优化，直至无法继续优化。

表1

上述过程中，在分析系统瓶颈时，是基于静态的数据进行分析的，即“静态分析短板”；系统性能优化后，性能瓶颈流转至其他节点，即“动态分析流动性”。

图2中步骤s103的分析过程之所以分为左右两个分支，主要是考虑到系统链路的多样性，在分析时需结合需求和拓扑进行分析。

步骤s104，定位拓扑模型中的性能瓶颈节点位置；性能瓶颈节点位置后，性能瓶颈流转至其他节点；即“动态分析流动性”。

本测试压力是从前端向后端传导，将测试到的压力与预设的历史最大的处理能力做对比分析，分析该节点会不会成为瓶颈，从而找到整个链路上不能满足业务需求的瓶颈点。

步骤s105，定位拓扑模型中的性能瓶颈节点位置后，根据性能瓶颈节点是否具备明确的性能优化方案，区分路径：

如果不具备优化方案，则重点关注拓扑模型中系统性能短板，进行专项验证；如果传导到某一个节点，需评估该节点是否为整个链路上最后的一个性能瓶颈点。

如果具备优化方案，则对主要性能瓶颈节点选取优化方案，对测试到的瓶颈节点进行优化。

步骤s106，优化后，更新拓扑模型中各节点的性能容量信息，在web页面更新后提交，提交后触发后台对调优后的节点进行分析，如果不再成为瓶颈，在瓶颈节点列表中移除，性能瓶颈动态流动至其他节点。

如果仍存在瓶颈，更新该节点在瓶颈节点中的次序。确定优化后的主要瓶颈节点后，再次执行上述迭代过程，所有瓶颈节点均被移除，或主要瓶颈节点不再发生变化。

测试人员会预备设计多套性能优化策略，从预备策略中选择与瓶颈点相匹配的策略，对当前瓶颈点做优化分析，在应用到瓶颈点后，如果性能有所提升，且能够满足要求，则继续往后传导。

当测试进行到最后一个节，完成后，性能测试继续流动，进行循环测试。

上述通过测试进行专项验证，保证最短的板不是最重要的那块，再结合监控予以防范的过程，称为粘性。

本发明还设计有全链路瓶颈测试系统。拓扑模型生成单元201根据业务需求，绘制生成各业务链路拓扑图。性能容量初始化单元202根据业务需求、历史存量的生产运维数据，以及拓扑结点中每个系统处理的性能，对拓扑模型中每个节点的性能容量标准进行初始化。性能瓶颈节点定位单元203，分析定位拓扑模型中的性能瓶颈节点。在根据拓扑模型中系统性能短板定位到瓶颈节点后，如果不具备优化方案，则由专项验证单元204，进行专项验证；如果具备优化方案，则通过优化单元205对测试到的瓶颈节点进行优化，在进行优化后，由容量信息更新单元206更新拓扑模型中各节点的性能容量信息。

具体实施例

本具体实施例为一例具体的应用场景，是对手机银行红抢红包项目进行的系统压力测试。

此处，首先对本技术方案中出现的主要名词做出解释：

bp：在本专利申请中，bp指中信银行电子渠道对私业务处理平台，为多个电子渠道系统提供统一的客户管理等功能，简称“对私bp”或“bp”；

外联平台：本专利申请中，外联平台指中信银行与外部系统的实现互通的平台系统；

第三方亿佰测试环境：本专利申请中，第三方亿佰测试环境指第三方企业亿佰提供的性能测试环境。

在该对手机银行红抢红包的系统测试的案例中，根据需求业务链路，首先生成业务链路系统的拓扑模型。

由手机银行组发起需求，对手机银行-bp-外联-第三方平台整体链路的性能进行测试，测试开始前，需对令牌数的大小进行设置，且根据情况考虑令牌数值的大小；

为确保应对“抢红包”业务的突发情况，应当将令牌书设置为大数值，但是，如果设置过大，后端系统可能成为瓶颈，反之，如果令牌数值设置过小，后端系统空闲，而靠近前端的客户则有可能登录不进来，因此，需要对令牌数值设置进行调试，调试出整条链路的最佳处理能力。

发明人安排了两组测试路径：

第一组测试路径：手机银行web-手机银行前置-bp-ebank5-挡板。此条链路主要是为验证渠道端突发集中登陆场景，从而获取测试数据并生产运维数据，用于初始化拓扑模型各节点性能容量的性能指标。

第二组测试路径：手机银行web-手机银行前置-bp-ebank5-外联平台-第三方亿百测试环境。该条链路主要是为验证中信红权益查询和权益兑换的性能容量场景，获取测试数据及生产运维数据初始化拓扑模型各节点性能容量的性能指标。

需要注意的是，手机银行令牌机制设置了公共令牌和针对具体交易的专用令牌，专用令牌限制了交易可使用的最大令牌数，中心红权益查询和兑换，使用了中信红专用令牌。

本实施例在测试1号链路集中登陆场景时，当单台手机银行登陆令牌设置为20时，cpu使用率达到95％，令牌扩大，tps反而下降，此现象说明系统已经达到性能拐点，增加令牌无法提升性能。

本实施例在测试2号链路进行全链路测试时，中信红权益兑换和查询需要在登陆手机银行后进行。测试环境中信红令牌数设置为45，意为最大向后端提供45个并发，生产环境单台服务器中信红令牌数设置为5，共20台服务器，即生产环境可以向后端提供100个并发。2号链路测试情况如表2所示：

表2

从表2显示的测试结果表明，分别设置40并发和60并发，手机银行登陆令牌设置20和60，tps基本没变化，该情况说明两个问题：

1、各服务器资源使用空闲，tps无法提升，链路存在瓶颈；

2、瓶颈与登陆令牌数无关；

发明人根据上述设定的业务需求测试路径提炼出本发明的瓶颈分析过程如下：

1、测试1号链路在登录令牌设置为20时，手机银行服务器cpu使用率达到95％，此时，初步分析可能成为性能瓶颈；

2、外联平台专项容量测试在单台服务器、2台集群、3台集群的架构下实测tps分别为300笔/秒、500笔/秒、700笔/秒；

3、第三方亿佰系统在测试中性能测试环境获取的并发处理能力约100笔/秒左右；

4、bp性能测试环境部署20台服务器，集中登录场景的并发处理能力达到800多tps。

针对上述各系统的处理性能，结合生产环境扩容能力分析：

1、手机银行在测试环境存在瓶颈，但测试环境仅部署1台服务器，而生产环境部署20台服务器，处理能力远高于测试环境；

2、bp在生产环境部署44台服务器，采用集群部署，易扩展，成为瓶颈的可能性较小；

3、亿佰工程师反馈其系统已经支持横向扩容，在与外联平台连接未出现不足的情况下，亿佰暂时不会成为性能瓶颈；

根据外联平台项目组反馈，外联平台三台服务器大部分压力来自于中信红交易，结合上述分析，外链平台700tps的处理能力可能成为系统链路上的瓶颈。在该项目中，需由需求方评估生产环境抢购活动是否会超过700tps；

如果不超过700tps，在亿佰不出现瓶颈的情况下，整条链路能够应对此次抢购业务；

如果超过700tps，需要手机银行减少令牌设置，对业务进行限流。

定位拓扑模型中的性能瓶颈节点时，性能测试环境最初将瓶颈定位在手机银行，通过分析生产环境部署及系统扩容能力，生产环境的性能瓶颈从手机银行流动到外联平台或亿佰，由此概括出性能瓶颈的流动性。

发明人在测试期间重点监控了外联平台和亿佰的网络延时情况，主要关注了粘在链路瓶颈。即所谓“粘性”问题。也就是说，如果不具备可优化的方案，则重点关注拓扑模型中系统性能短板，进行专项验证。当传导到某一个节点时，需评估该节点是否为整个链路上最后的一个性能瓶颈点，通过测试进行专项验证，保证最短的板不是最重要的那块，再结合监控予以防范。

如果具备优化方案时，则对测试到的瓶颈节点进行优化，优化后，更新拓扑模型中各节点的性能容量信息，性能瓶颈动态流动至其他节点。

当测试进行到最后一个节，完成后，性能测试继续流动，进行循环测试。

在一场景测试中，手机银行进行了全链路测试，该场景是把目前手机银行登录后，需要点击的按钮，制作成了登陆后直接显示的方式。

对该场景进行静态分析，当tps值最高达高值时，如达到160时，即使采用的机制是异步单工双链的方式，但是对于处理手机银行登录的大压力，其队列仍然会被撑爆，导致服务拒绝。也就是说，在业务处理中，会出现想消费的人进不来，不想消费的人不关注的情况，导致后台系统承载了大压力。由此可知，短板出现在后端业务系统。

经过对动态分析流动性问题的研究，当对后端系统进行了优化后，便能处理大压力，此时瓶颈会转移到交换平台的连接或是主控上，交换与后端系统的连接数是固定的，如果交换调大该参数，则会对交换的整体资源使用能力产生影响，所以交换的处理能力会成为瓶颈，除非交换继续扩容。通过以上两点，可分析出该需求的不合理性，因此该测试停止。

在另一测试场景中，是来自智能推荐项目的需求，类似于智能提醒，即后端系统结合中信大脑，该项目是通过识别客户日常操作行为来对客户进行产品推荐的一项业务。手机银行项目组从前端发起压力，经过bp，交换平台到智能推荐系统。

基于动态和静态结合分析的全链路性能瓶颈定位方法：

基于静态分析短板，得到分析结果为，同样是手机银行登录，会主动发起加载产品，由bp通过交换平台向智能推荐系统发起查询，查询产品id。于是分析得到，手机银行登录tps之前可以支持800，bp先前测试容量支持2000，交换平台穿透+扩容，不优先考虑瓶颈。

所以，新建系统智能推荐没有进行过性能测试，对其容量一无所知，建议对该系统进行单独的性能测试评估容量。

基于动态分析流动性，能否承受住手机银行800tps的压力有待评估，其极有可能率先成为该链路上的瓶颈，所以从高可用设计方面，我们建议增加流控或开关的机制，一旦系统承载不住，关闭对应的推荐功能，给系统降温，这也是体现我们测试粘性的点，以前的常规性能测试，我们是不会考察类似的这种异常场景的。

除非另作定义，此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明专利发明说明书以及权利要求书中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”或者“一”等类似词语也不表示数量限制，而是表示存在至少一个。

以上所述仅为本发明的示例实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。