目录
实时链路拓扑图构建
在负载集群阶段、SOA阶段、微服务架构阶段的模式下，可以利用前期推送所描述的链路标识透传、字节码增强等技术，将应用之间的调用逻辑关系以及调用方、被调用方进行完整呈现，甚至对调用次数、调用耗时等数据进行呈现。
如下图所示，这是一个简单的登录业务逻辑。用户请求通过互联网进行一次登录接口访问(/login)进入防火墙后，会依次经过网关应用、用户中心、应用A、应用B，同时会在Redis和MySQL中进行数据查询，最后返回一个登录成功或失败状态的结果。
在这样的业务场景下。使用链路分析技术，可以自动构建出对应的链路拓扑图。在日常使用过程中，一般会构建3个层级的拓扑图：应用层级拓扑、实例层级拓扑和接口层级拓扑。
不同层级的拓扑所展示的内容及可分析的颗拉度各不相同。接下来以上文描述的登录业务为案例，对性能测试环节中的数据量规进行详细说明。
一、应用层级拓扑
主要关注在某个时间段内被测业务中应用的调用关系、调用耗时以及调用次数等信息、假设在前文介绍的登曼业务中。1分钟内有60个登录请求发起，那么链路分析系统则会自动构建如下图所示的应用拓扑。
应用层级拓扑主要呈现如下两个方面内容。
1)调用关系。如上图所示，这60个请求的入口端为网关应用，网关应用处理完成后会调用用户中心其中用户中心根据不同的业务参数或逻辑会进行10次Redis调用和50次MYSQL调用。它后续会调用应用A，而应用A调用应用B进行最终处理。待应用B处理完成，且各节点均无异常后，则正常进行响应。
当然，在实际系统中调用关系更为复杂，这里仅展示了同步调用，系统中还会存在大量的异步训用场，但所展示的逻辅及内容大致类似，通过探针等技术自动化构建并可视化展示。通过调用关系的展示，测试工程师能快速了解被测事务的入口及相关应用的关系。
一方面，通过应用节点信息(例如应用名称、IP地址)，性能测试工程师能够进行范围确认，确保本次压测的内容与范围是符合预期的。另一方面，通过拓扑图直观地了解系统内部的处理逻辑，测试工程师可以梳理应用之间的调用关系。在实际的性能分析过程中，尤其是在执行混合场景压测时，被测事务宴杂，后端应用节点繁多，展示调用关系对测试工程师来说至关重要。
2)性能指标。除了链路调用关系外，性能指标也是非常重要的分析数据，如上图所示，在示例测试场景下，以网关应用为入口进行分析，经过自身代码处理后，网关应用往下游用户中心也同步发起60个请求，平均每个请求的响应时间为900毫秒，若从压力发起端看平均响应时间为1000毫秒，那么可以初步判断关应用本身代码耗时约为100毫秒，整体性能表现相对健康，剩余的900毫秒需要按调用拓扑往下游进行分析，即查看用户中心的表现及其下游调用情况。
以用户中心为核心，通过拓扑链路的性能指标，初步分析如下：用户中心内部逻辑会触发50次MySQL调用及10次Redis调用，其中Redls调用平均耗时10毫秒，表现良好；数据语句执行平均耗时100毫秒，表现良好。应用自身代码执行平均耗时为900-10-100-600=190秒，表现良好。大量时间花费在下游应用A的调用上，因此需要继续针对应用A进行分析。
以此类推，通过层层分析，可以初步判断当前耗时较长的过程为应用B的代码执行，平均为500毫秒，导致整体响应时间为1000毫秒。需要针对应用B进行深度的代码级分析。
以上分析是基于同步调用模式下的链路进行的。在实际业务中会存在步调用的情况，但是分析思路一致，即通过上下游的性能指标层层下钻分析。
通过性能指标数据，测试工程师能直观地了解当前应用的性能表现。通过调用次数，测试工程师可以初步判断是否存在架构级问题，如60个用户请求可能会触发上千次MYSQL调用，那么可以初步判断数据库调用可能会成为业务瓶颈，需要反馈给开发工程师进行业务代码修改，减少调用次数。类似这样的异常频繁调用问题，就可以通过性能指标和拓扑图快速发现和定位。
通过平均响应时间，测试工程师可以快速判断性能瓶强在哪个应用或组件中。以上图为例，测试工程师可以快速从6个节点中判断瓶颈在应用B中，减少了针对单个节点逐步分析的成本投入，其排查效率大幅提升，测试工程师则可以将更多的时间分配在丰富测试场景的工作中。
二、实例展级拓扑
实例层级拓扑在展示界面和性能指标上与应用层级拓扑类似，其核心区别在于应用节点展示的颗拉度不同。这种场景主要出现在负载集群中，某个业务节点有两个实例进行支撑，通过Nginx进行负载量分发，应用层级拓扑会将两个实例进行整体统计，测试工程师如果希望看到单个实例的性能，则建议以实例层级拓扑呈现。如下图所示。
在上图中，应用B实际为两个实例来支撑业务，通过拓扑图及性能指标可以发现，应用A发出的90%的请求调用被负载均衡设备转发至应用B1节点进行处理，而应用B2节点仅处理10%的业务请求，其量压力较小，因此响应也较快。
对于分析人员来说，此时的调优建议可能不是对业务代码进行修改，而是需要针对负都逻辅进行检查和优化，平均分配流量至各个实例，充分利用每个实例的计算资源，降低用户的平均响应时间，提升性能表现。
除了以上负载问题，单实例的资源配置问题也可以通过这样的方式进行发现。例如，在流量相同的情况下应用B节点的平均处理耗时较长，若排除代码发布版本问题，那么其实例资源配置可能存在异常，导致应用B节点的处理能力较差。
类似的性能缺陷还有很多，实例级别拓扑通过更细颗粒维度的数据呈现方式，将性能指标可视化地呈现给测试工程师，从而能快速地进行分析及调优。
三、接口层级拓扑
以上介绍了颗粒度更小的实例展级拓扑，那么是否有更细颗粒度展级呢？的确，在实例层级拓扑下，还可以细化至接口层级拓扑。
接口层级拓扑主要展示的是各个节点实际在接口层的互相调用关系。还是以登录场最为例，用户访问的是网关应用，对外基露接口为xx/login，网关应用经过内部代码辑处理后，请用下游用户中心的xx/user报口，用户中心调用的是应用A的xA接口。通过报口层级的调用信息，自动构建如下图所示的拓扑结构。
在上图中，标准情况下一个应用存在大量对外暴漏接口，而测试工程师仅能知道入口的接口信息。接口的调用关系主要依赖于开发方提供的接口文档，可能存在时效性、准确性等方面问题，需要测试工程师进行多次验证才能得出准确、有效的结果。通过接口层级的拓扑，性能测试工程师可以快速进行接口调用关系的梳理，针对遗漏的调用关系进行补充，针对出错的调用关系进行修订，减少无效的测试执行、从而达到提升测试效率的目标。
同时，针对性能测试过程中出现的异常，测试工程师也可通过接口层级拓扑快速发现缺陷，性能测试工程师与开发工程师进行沟通的时候，可通过接口层级拓扑提供完整的接口调用路径，提升开发工程师定位问题的效率，加快缺陷修复的速度，让性能测试的执行更为顺畅。
以上介绍了3种链路拓扑，读者在日常工作中可能会接触其他类型的拓扑，在性能测试阶段常见的还有系统拓扑。
系统拓扑和链路拓扑的最大区别在于构建单位，系统拓扑主要是以操作系统为单位进行构建的，链路拓扑主要是以系统实例为单位进行构建的。尤其在性能测试环境下，由于资源相对短缺，可能会在一个Linux操作系统上部署多个Java应用进行测试，那么在系统拓扑上只会显示单个Linux操作系统图标而链路拓则会构建出多个Java应用图标。并生成调用关系，方便测试工程师进行更细颗粒度的分析。因此链路拓扑可以理解为系统拓扑的补充，也是提升性能测试分析效率的一个重要方法。
阅读完成后若有收获，你的关注，点赞，转发我都喜欢！！！
标签：调用,测试,性能,层级,应用,链路,拓扑 From： https://blog.csdn.net/qd_lifeng/article/details/143674198