CN114237625A - 基于语法分析树的微服务依赖链路静态分析方法及系统 - Google Patents

Abstract

本发明公开一种基于语法分析树的微服务依赖链路静态分析方法及系统，包括：对微服务调用进行编码规约；将当前微服务源码文件转化为语法分析树对象；根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。对微服务模块的调用过程进行统一的编码规约，以此定位微服务模块间的异常依赖关系，提高项目管理质量。

Description

基于语法分析树的微服务依赖链路静态分析方法及系统

技术领域

本发明涉及计算机微服务分布式系统技术领域，特别是涉及一种基于语法分析树的微服务依赖链路静态分析方法及系统。

背景技术

本部分的陈述仅仅是提供了与本发明相关的背景技术信息，不必然构成在先技术。

微服务架构模式将传统单一应用程序划分成一组相互独立的、小的服务模块，服务模块之间互相协调、互相配合，服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协议的RESTful API)。随着系统业务需求复杂度的提高，分布式服务架构下服务之间的调用链路依赖关系也更加复杂。

为了实现链路跟踪采集，Google发表了分布式链路跟踪论文《Dapper,a Large-Scale Distributed Systems Tracing Infrastructure》，随后Google发布了分布式链路跟踪系统Dapper，提出基于Google-Dapper的分布式链路数据动态分析采集技术，可以构建微服务链路跟踪数据模型，能够识别出微服务之间的调用依赖关系；但是目前基于Dapper的微服务链路跟踪动态分析技术方案还面临以下不足：1)无法在系统开发阶段实时获取微服务模块间的调用依赖信息。2)获取到的调用链路信息完整度及准确度低。3)获取调用链路信息的时间及人力成本高。4)获取到的调用链路信息对开发人员、测试人员以及运维人员来说有滞后性，影响开发、测试及运维效率。

因此需要一种改进的或全新的分布式链路跟踪分析技术，能够在系统上线部署前就可以实时获取各个微服务模块间的调用链路依赖数据，即微服务链路静态分析技术。中国专利CN112948137A公开了一种微服务关联分析与预测方法，该发明将关联分析技术应用到微服务调用依赖分析中，通过复杂严谨的数学模型推导计算出微服务模块间的链路依赖关系，能够在系统开发完毕后、上线部署测试前就可以对系统进行全方位静态分析，从而获取到各个微服务模块间的依赖关系，解决了基于Google-Dapper的微服务链路动态分析技术的一些不足之处，但是其仍存在以下几点问题：

1)基于正则表达式匹配的微服务直接关联结论可能不准确、不全面。该类技术方案中对源代码进行静态扫描，通过预定的代码模式采用正则表达式匹配技术来提取和识别微服务间的直接关联，如上述发明中指定的模式为：{协议}[分割符]{关联服务名}[分割符]{服务操作}[分隔符]，只要符合上述模式就认为当前微服务对“{关联服务名}”位置的微服务有直接依赖。这种分析和处理方式当遇到以下情况时就会导致分析处理结论不准确或不全面，具体为：

A.代码中存在一些临时注释代码块，注释代码块中正好有满足上述模式的对其它微服务的调用代码。这样识别出的对微服务的依赖可能实际上是并不存在的，而识别出的这个被依赖的服务可能又依赖其它服务，这样最终识别出的整个系统各个微服务间的依赖关系图很可能是完全异常的，失去了价值。

B.代码中存在一些满足上述模式但是可能不是微服务调用的代码块，如一些指向第三方的URL地址，也会满足上述模式，但是很明显这不属于系统内部微服务模块间的调用依赖。

C.开发人员在代码中对微服务模块的调用并没有按照预设的正则表达式模式进行，如url是通过变量动态拼接产生的，这样就无法根据上述模式进行正确识别，从而导致该类技术识别出的整个系统各个微服务间的依赖关系中可能缺少了某些依赖关系。

2)未给出技术保障方案，完全靠开发人员自觉，管理成本高且存在技术风险。该类基于正则表达式匹配来提取微服务直接关联的方式，要求开发人员必须遵循以下相关约定进行编码才能保证最终采集的微服务链路依赖数据的正确性和全面性：

A.对于一些可能临时不需要的微服务调用，请务必直接删除，而不是临时注释代码。

B.对微服务的调用url采用静态常量方式来声明，不要通过变量拼接方式。实际项目经验中，完全靠开发人员自觉遵守某些开发规则是不现实的，一般都需要通过代码走查或其它自动化监测工具来辅助保障，这无疑会增加沟通及管理成本。

3)计算逻辑复杂，时间成本高。这种基于关联分析的微服务链路静态分析技术，需要进行大量的向量及相似度计算，并且需要建立关联知识库，计算逻辑时间复杂度高。

发明内容

为了解决上述问题，本发明提出了一种基于语法分析树的微服务依赖链路静态分析方法及系统，对微服务模块的调用过程进行统一的编码规约，以此定位微服务模块间的异常依赖关系，提高项目管理质量。

为了实现上述目的，本发明采用如下技术方案：

第一方面，本发明提供一种基于语法分析树的微服务依赖链路静态分析方法，包括：

对微服务调用进行编码规约；

将当前微服务源码文件转化为语法分析树对象；

根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；

根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；

判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。

作为可选择的实施方式，对微服务的调用进行统一API规约，统一API规约的过程包括：将被调用的微服务名称作为单独参数进行独立设计，并对该参数的格式及取值进行标准化规约；在http请求头中自动设置AMSToken请求头及对应的token值，根据http的方法类型，动态构造http请求对象。

作为可选择的实施方式，根据规约对获取的微服务调用请求采用切面埋点进行拦截校验处理，包括：从微服务调用请求中解析http消息头，判断http消息头中的微服务标记是否与规约中的微服务标记一致，从而识别微服务调用是否是标准的规约调用；若是非标准调用，则拦截处理并告警。

作为可选择的实施方式，对当前微服务源码文件采用java语法分析树工具开发包转化为语法分析树对象。

作为可选择的实施方式，所述类定义对象为格式化的java源码文件对象；所述方法声明源码是格式化且移除注释代码的方法声明源码。

作为可选择的实施方式，所述规约包括枚举类规约，判断微服务调用方法中被调用的微服务名称是否是枚举类的引用。

作为可选择的实施方式，根据判断结果，若是非标准调用，则将当前微服务名称、当前微服务调用方法、代码行号、异常类型存入异常依赖数据库；若是标准调用，则提取对应的枚举值，将当前微服务名称、被调用的微服务名称、所在微服务调用方法、所在代码行号存入正常依赖数据库。

第二方面，本发明提供一种基于语法分析树的微服务依赖链路静态分析系统，包括：

微服务编码规约模块，被配置为对微服务调用进行编码规约；

第一源码分析模块，被配置为将当前微服务源码文件转化为语法分析树对象；

第二源码分析模块，被配置为根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；

第三源码分析模块，被配置为根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；

依赖链路告警模块，被配置为判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。

第三方面，本发明提供一种电子设备，包括存储器和处理器以及存储在存储器上并在处理器上运行的计算机指令，所述计算机指令被处理器运行时，完成第一方面所述的方法。

第四方面，本发明提供一种计算机可读存储介质，用于存储计算机指令，所述计算机指令被处理器执行时，完成第一方面所述的方法。

与现有技术相比，本发明的有益效果为：

本发明提出一种基于语法分析树的微服务依赖链路静态分析方法及系统，实现在系统开发过程中实时项目所有微服务模块间的依赖关系数据，通过比较实际开发的微服务模块的依赖关系与初期设计的依赖关系的差异，定位依赖异常，及时对开发人员作出纠偏指导或对原有设计及时完善，提高大型复杂式微服务架构系统的信息化管理效率和水平。

本发明提出一种基于语法分析树的微服务依赖链路静态分析方法及系统，实现在开发测试过程中快速、精准定位模异常依赖、模块循环依赖等问题，提高开发和测试效率。

本发明提出一种基于语法分析树的微服务依赖链路静态分析方法及系统，在运维过程中，及时、全面、准确的了解系统微服务模块的依赖关系，为微服务模块的运维规划、部署实施提供精确而全面的技术支撑，提高部署运维的效率。

本发明提出一种基于语法分析树的微服务依赖链路静态分析方法及系统，对微服务模块的调用过程封装成统一的API，使得开发人员访问远程微服务API时不用再处理HTTP协议细节，不用再处理远程调用时的网络超时、网络连接异常等网络细节，使得开发人员像调用本地方法一样简单高效地调用远程微服务模块，显著提高开发效率，通过统一的代码封装保证开发质量。

本发明附加方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

构成本发明的一部分的说明书附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。

图1为本发明实施例1提供的微服务调用关系图；

图2为本发明实施例1提供的Dapper动态分析方案示意图；

图3为本发明实施例1提供的基于语法分析树的微服务依赖链路静态分析方法流程图；

图4为本发明实施例1提供的开发规约核心类图；

图5为本发明实施例1提供的规约拦截校验处理流程图；

图6为本发明实施例1提供的规约封装处理流程图；

图7为本发明实施例1提供的基于语法分析树的微服务依赖链路静态分析系统示意图。

具体实施方式

下面结合附图与实施例对本发明做进一步说明。

应该指出，以下详细说明都是示例性的，旨在对本发明提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本发明的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

实施例1

微服务架构模式将传统单一应用程序划分成一组相互独立的、小的服务模块，服务模块之间互相协调、互相配合，服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协议的RESTful API)。每个服务模块围绕具体业务选择最适合的技术栈进行构建，并且能够被独立的部署到生产环境中。随着系统业务需求越来越复杂，采用微服务架构进行设计的大型信息系统，看似简单的业务场景，后台可能有几十个甚至几百个微服务在支撑，当系统拆分的微服务越多时，这种分布式服务架构下服务之间的调用链路依赖关系也就更加复杂，如图1所示。

微服务之间的依赖链路信息对系统设计师、开发人员、测试人员，以及运维人员都是十分重要的数据，尤其是基于微服务架构的大型复杂分布式系统，设计人员可以通过服务模块的调用依赖链路数据来规划模块间的设计边界，及时发现设计上导致的模块间的循环依赖、异常依赖问题，极大提高设计效率。开发人员和测试人员可以通过服务模块的调用依赖链路数据，快速发现和定位依赖异常导致的代码缺陷问题。运维人员可以通过服务模块的调用依赖链路数据，合理规划系统的部署架构及实施步骤，提高运维效率。

基于微服务架构的复杂分布式系统中，微服务模块间的依赖调用关系成为了系统架构中的重要基础数据，因此研究和分析微服务架构中的服务模块间的调用依赖数据的采集机制，使得服务依赖数据采集更全面、准确和高效具有十分重要的现实意义。

为了实现链路跟踪采集，Google发表分布式链路跟踪论文《Dapper,a Large-Scale Distributed Systems Tracing Infrastructure》，随后发布分布式链路跟踪系统Dapper，截止到目前业内出现了非常多优秀的分布式链路跟踪技术及产品来追踪微服务的调用链路信息，比如SkyWalking、Istio、Zipkin等，都是启发于Google发表的Dapper。Dapper阐述了分布式系统，特别是微服务架构中链路追踪的概念、数据表示、埋点、传递、收集、存储与展示等技术细节，并提出了Trace和Span的概念：

Trace是调用链路，指一个前端请求经过后端所有微服务的路径，每一条链路都用一个全局唯一的TraceID来标识；Span代表调用链路中的中间服务节点，每个Span都有一个唯一的标识SpanID，而且Span之间存在着父子关系，上游的Span是下游的父Span(用ParentID标识)，这样每个Span就有SpanID和ParentID两个标识，分别标识当前Span的标识及其父节点的Span标识，SpanID在一条链路中唯一。

Dapper通过埋点技术在服务运行过程中动态生产上述数据模型的结构数据，这样就可以采集到每一条服务调用链路信息，如图2所示。Dapper可以很好地构建微服务链路跟踪数据模型，能够识别出微服务之间的调用依赖关系，但是目前基于Dapper的微服务链路跟踪动态分析技术方案还面临以下不足：

1)无法在系统开发阶段实时获取微服务模块间的调用依赖信息。Google的Dapper提出的链路跟踪技术方案是一种动态链路分析技术，即要求微服务系统中的各个模块必须已经开发并且部署完毕，并且各个业务流程必须至少成功运行一次，才可以将链路数据进行动态采集和展示。因此目前Google的Dapper以及基于Dapper扩展衍生的其它链路跟踪技术及产品都无法在系统开发阶段获取到微服务模块之间的调用链路信息。

2)获取到的调用链路信息完整度及准确度低。Dapper的动态链路分析技术是基于动态埋点来采集链路信息的，因此该类技术方案不但要求整个系统必须部署运行起来，而且还要求系统的业务流程至少完整且正确地执行一遍才可以采集到相关链路数据，这也就意味着如果系统流程执行的不全面，那么采集的链路依赖数据就可能不完整；如果某些流程因为开发缺陷导致无法正常运行，那么就可能导致链路依赖数据无法采集或采集不准确。

3)获取调用链路信息的时间及人力成本高。Dapper的动态链路分析技术要在系统开发完毕部署运行后才可以获取到服务的调用依赖链路信息，时间周期长，时间成本高；并且系统的部署以及测试过程需要运维及测试人员配合，需要多部门参与，提高了人力及沟通成本。

4)获取到的调用链路信息对开发人员、测试人员以及运维人员来说有滞后性，影响开发、测试及运维效率。Dapper的动态链路分析技术要在系统开发完毕部署运行并测试完毕后才可以获取到服务间的调用依赖关系，这意味着开发人员、测试人员及运维人员无法在系统上线部署之前的开发阶段去发现一些服务依赖问题，比如依赖异常、循环依赖等，从而无法在第一时间内发现和避免非法服务依赖导致的问题，只能等上线部署、测试人员进行测试或生产环境问题暴露才可以对问题进行捕获和解决，这种滞后性，严重影响了系统的开发、测试及运维效率。

因此微服务链路静态分析技术被提出，能够在系统上线部署前就可以实时获取各个微服务模块间的调用链路依赖数据。同时结合如背景技术中所述的微服务关联分析与预测方法中存在的不足，本实施例提出一种基于语法分析树的微服务依赖链路静态分析方法，如图3所示，包括：

S1：对微服务调用进行编码规约；

S2：将当前微服务源码文件转化为语法分析树对象；

S3：根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；

S4：根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；

S5：判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。

在本实施例中，所述步骤S1具体包括对微服务的开发和调用访问进行统一规约，同时对所有微服务后端代码的执行进行埋点处理；

作为可选择的一种实施方式，对微服务的开发和调用方式进行统一API规约。

更进一步地，统一API规约中格式设计包括：将被调用的微服务名称作为单独的参数进行独立设计，并对该参数的格式及取值进行标准化规约，比如通过枚举类方式等。

更进一步地，统一API规约中封装处理过程包括：除了封装标准的微服务http调用请求逻辑外，还在http请求头中追加特殊token字段及对应的值，并且该token及值对开发人员是透明的，开发人员不需要也不必知道该技术细节。

作为可选择的一种实施方式，通过切面埋点对规约的有效执行进行自动校验，对不满足规约的调用请求进行拦截，为规约的有效执行提供自动化技术方案。

更进一步地，微服务后端的埋点处理过程包括：在所有微服务代码逻辑执行前，对http请求头进行token字段及值的有效性校验，以确保只有满足服务编码规约的客户端请求才会被成功处理，而未按照编码规约的统一API进行微服务访问的请求都会被拦截处理并告警，从技术上保障编码规约的有效执行，实现微服务编码规约有效性的自动化校验。

如图4所示开发的规约框架中，根据服务提供者和调用者的不同，规约框架包括不同的核心类，具体为BaseController、MSAop、MSEnum、MSClientTool，BaseController、MSAop属于服务提供者相关规约类，MSEnum、MSClientTool属于服务调用者规约类；

其中，BaseController是所有微服务实现类的顶层类，所有微服务类必须继承自该类；

MSAop是微服务实现类的切面拦截器类，用于根据规约对微服务调用请求进行拦截校验处理，如图5所示，具体包括：拦截微服务调用请求，从微服务调用请求中解析http消息头，判断http消息头中的微服务标记是否与规约中的微服务标记一致，从而识别微服务调用是否是标准的规约调用；若是非标准调用，则将微服务调用请求按照异常返回，同时标记该次异常调用相关信息，并进行告警。实现对未按照规约要求的微服务调用的拦截和标记，实现开发规约的自动化校验。

该规约类从技术上保障开发人员在开发微服务调用时必须按照规约框架要求进行统一调用，为规约的有效执行提供技术保障，提高微服务调用的代码质量，同时降低管理成本。

MSEnum是所有微服务的枚举类，记录每个微服务的名字、端口等信息。微服务调用者在调用其它微服务时，必须引用该枚举类来指定被调用的微服务的名称。

MSClientTool是微服务调用者用来调用其它微服务的工具类，提供统一的微服务调用规约API，微服务调用规约API中第一个参数是被调用的微服务名称，被调用的微服务名称必须引用自MSEnum类。

如图6所示的规约封装处理包括：微服务调用规约API在http请求头中自动设置AMSToken请求头以及对应的token值，根据http的方法类型(get/post/put/delete)，动态构造http请求对象，以便于标记微服务调用请求是否满足规约要求。

上述开发框架规约从技术上保障了开发的微服务源码符合相应的设计约定，进而保证依赖链路静态分析方法得出的依赖链路数据结论的正确性和全面性。

在本实施例中，利用语法分析树技术，对微服务源码工程进行源码解析，得到高质量方法声明源码；提取源码中微服务间的直接调用依赖数据，自动识别不满足规约的调用请求，并将异常标记告警。

具体地，所述步骤S2包括：

加载扫描微服务源码工程，按照标准SpringCloudBoot微服务工程的代码结构解析当前微服务的服务名称信息，将源码工程下的每个源码文件的url信息加载到内存数据库Redis中；

遍历内存数据库Redis中的源码文件url集合，利用java语法分析树工具开发包JDT将每个源码文件转化为语法分析树AST对象CompilationUnit。

所述步骤S3包括：

从CompilationUnit中获取类定义对象TypeDeclaration，所述类定义对象TypeDeclaration为格式化的java源码文件对象；

从TypeDeclaration中获取类的所有声明对象数组bodyDeclarations，声明对象数组包含当前源码中的所有属性声明及方法声明，由于微服务调用发生在方法声明对象中，因此本实施例只需要遍历bodyDeclarations数组，过滤出方法声明对象MethodDeclaration即可。

所述步骤S4包括：

从MethodDeclaration对象中获取方法声明的源码内容；方法声明源码是JDT已经格式化且移除各种注释代码后的方法声明源码，格式化处理为自动逐语句分行；

从方法声明源码中检索规约中MSClientTool工具方法的调用情况，如果检索到发生了调用，则提取微服务调用方法中的第一个参数，即提取被调用的微服务名称，对被调用的微服务名称进行判断。

更进一步地，高质量方法声明源码移除原有代码中的各种注释代码，使得注释代码不影响解析结果，从而使得开发人员根据自己习惯及项目实际需要保留任何需要的注释代码或说明，无需担心注释代码对链路依赖静态分析结果的影响，提高代码开发效率和质量。

更进一步地，基于高质量方法声明源码对编码规约API进行匹配提取，精确识别被调用的微服务模块名字，从而消除传统的基于正则表达式模式匹配方式提取微服务名字可能导致的识别不准确问题。

在本实施例中，所述步骤S5包括：

校验被调用的微服务名称是否是枚举类MSEnum的引用；

若是非标准调用，则将当前微服务名称以及当前调用方法名称、代码行号、异常类型(微服务名字引用格式非法)等信息存入异常依赖数据库(MySql数据库)；

若是标准调用，则提取对应的枚举值，作为被调用的微服务名称信息，同时将当前微服务名称、被调用微服务名称、所在方法声明的名字、所在代码行号等调用依赖数据存入正常依赖数据库(MySql数据库)。

重复上述过程，直到把所有方法声明源码及所有源码文件分析完毕。

在本实施例中，源码文件分析完毕后，将得到的微服务间的全部调用依赖数据进行归并处理，得到所有微服务模块间的全局依赖关系数据；并在归并过程中自动识别模块间的循环依赖问题，若发现微服务间的循环依赖调用的情况，则将该种情况自动标记为循环依赖异常，并将相关信息存入异常依赖数据库。

在本实施例中，将得到的微服务间的正常依赖数据和违反编码规约的异常调用告警数据进行存储，同时还存储归并得到的全局依赖关系数据至全局依赖数据库(MySql数据库)，以便于展示模块进行图形化展示。

在本实施例中，采用图形化方式展示所有微服务模块间的依赖关系图，并可以自动高亮标记其中的循环依赖；链路依赖数据告警和展示模块可以精细分类展示各种异常数据，如：

(1)未使用编码规约规定的API进行微服务调用的异常工程、异常代码所在类名字以及行号等信息；

(2)使用编码规约规定的API进行了微服务的调用，但是传入的参数格式或内容不合法的异常工程、异常代码所在类名字以及行号等信息；

(3)产生循环依赖的各个微服务模块的名字信息，同时点击每个微服务，可以看到产生服务依赖的代码类及行号信息。

在本实施例中，不但对微服务调用的方式进行统一规约：而且同步设计对应的技术保障措施，在开发人员因为有意或无意的原因，没有遵循统一规约，而是擅自采用其它方式(如原生httpclient的API)进行微服务访问的调用编码的情况下，保证代码不管是在开发阶段还是在测试、生产阶段都无法通过单元及功能测试，降低项目管理的时间及人力成本，同时显著提高项目管理质量。

实施例2

如图7所示，本实施例提出一种基于语法分析树的微服务依赖链路静态分析系统，包括：

微服务编码规约模块，被配置为对微服务调用进行编码规约；

第一源码分析模块，被配置为将当前微服务源码文件转化为语法分析树对象；

第二源码分析模块，被配置为根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；

第三源码分析模块，被配置为根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；

依赖链路告警模块，被配置为判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。

此处需要说明的是，上述模块对应于实施例1中所述的步骤，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为系统的一部分可以在诸如一组计算机可执行指令的计算机系统中执行。

在本实施例中，所述微服务编码规约模块用于对微服务的开发和调用访问进行统一规约，同时对所有微服务后端代码的执行进行埋点处理；

更进一步地，对微服务的开发和调用方式进行统一API规约；通过切面埋点对规约的有效执行进行自动校验，对不满足规约的调用请求进行拦截，为规约的有效执行提供自动化技术方案。

更进一步地，统一API规约中格式设计包括，将被调用的微服务名称作为单独的参数进行独立设计，并对该参数的格式及取值进行标准化规约，比如通过枚举类方式等。

更进一步地，统一API规约中封装处理过程包括，除了封装标准的微服务http调用请求逻辑外，还在http请求头中追加特殊token字段及对应的值，并且该token及值对开发人员是透明的，开发人员不需要也不必知道该技术细节。

更进一步地，微服务后端的埋点处理过程包括，在所有微服务代码逻辑执行前，对http请求头进行token字段及值的有效性校验，以确保只有满足服务编码规约的客户端请求才会被成功处理，而未按照编码规约的统一API进行微服务访问的请求都会被拦截处理并告警，从技术上保障编码规约的有效执行，实现微服务编码规约有效性的自动化校验。

在本实施例中，源码分析模块利用语法分析树对微服务源码工程进行源码解析，得到高质量方法声明源码；提取源码中微服务间的直接调用依赖数据，自动识别不满足规约的调用请求，并将异常标记告警。

更进一步地，高质量方法声明源码移除原有代码中的各种注释代码，使得注释代码不影响解析结果，从而可以让开发人员放心的使用代码注释功能，提高代码开发效率和质量。

更进一步地，基于高质量方法声明源码对编码规约API进行匹配提取，精确识别被调用的微服务模块名字，从而消除传统的基于正则表达式模式匹配方式提取微服务名字可能导致的识别不准确问题。

更进一步地，被调用的微服务名字的提取过程包括当发现编码规约API中的微服务名字参数格式不满足规约要求时(不是指定枚举类引用)，自动识别为异常调用，并进行告警标记。

在本实施例中，所述该系统还包括数据归并处理模块，所述数据归并处理模块用于将语法分析得到的微服务间的直接依赖数据进行统一归并处理，得到所有微服务模块间的全局依赖关系数据；并在归并过程中自动识别模块间的循环依赖问题，若发现微服务间的循环依赖，则生成相应告警数据。

在本实施例中，所述该系统还包括数据存储模块，所述数据存储模块用于存储源码分析模块中分析出的微服务间的正常依赖数据和违反编码规约的异常调用告警数据，同时还存储数据归并处理模块归并得到的全局依赖关系数据；

更进一步地，所述数据存储模块分类存储微服务间正常的直接依赖数据、异常依赖数据以及所有微服务的全局依赖树数据，方便进行各种数据展示。

在本实施例中，所述依赖链路告警模块还包括展示过程，用于对违反编码规约的异常调用数据、循环依赖数据等进行自动告警，同时采用图形化方式展示所有微服务模块间的依赖关系图，并可以自动高亮标记其中的循环依赖。

更进一步地，链路依赖数据告警和展示可以精细分类展示各种异常数据，如：

(1)未使用编码规约规定的API进行微服务调用的异常工程、异常代码所在类名字以及行号等信息；

(2)使用编码规约规定的API进行了微服务的调用，但是传入的参数格式或内容不合法的异常工程、异常代码所在类名字以及行号等信息；

(3)产生循环依赖的各个微服务模块的名字信息，同时点击每个微服务，可以看到产生服务依赖的代码类及行号信息。

在更多实施例中，还提供：

一种电子设备，包括存储器和处理器以及存储在存储器上并在处理器上运行的计算机指令，所述计算机指令被处理器运行时，完成实施例1中所述的方法。为了简洁，在此不再赘述。

应理解，本实施例中，处理器可以是中央处理单元CPU，处理器还可以是其他通用处理器、数字信号处理器DSP、专用集成电路ASIC，现成可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据、存储器的一部分还可以包括非易失性随机存储器。例如，存储器还可以存储设备类型的信息。

一种计算机可读存储介质，用于存储计算机指令，所述计算机指令被处理器执行时，完成实施例1中所述的方法。

实施例1中的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器、闪存、只读存储器、可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

本领域普通技术人员可以意识到，结合本实施例描述的各示例的单元即算法步骤，能够以电子硬件或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

上述虽然结合附图对本发明的具体实施方式进行了描述，但并非对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。

Claims (10)

1.基于语法分析树的微服务依赖链路静态分析方法，其特征在于，包括：

对微服务调用进行编码规约；

将当前微服务源码文件转化为语法分析树对象；

根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；

根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；

判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。

2.如权利要求1所述的基于语法分析树的微服务依赖链路静态分析方法，其特征在于，对微服务的调用进行统一API规约，统一API规约的过程包括：将被调用的微服务名称作为单独参数进行独立设计，并对该参数的格式及取值进行标准化规约；在http请求头中自动设置AMSToken请求头及对应的token值，根据http的方法类型，动态构造http请求对象。

3.如权利要求1所述的基于语法分析树的微服务依赖链路静态分析方法，其特征在于，根据规约对获取的微服务调用请求采用切面埋点进行拦截校验处理，包括：从微服务调用请求中解析http消息头，判断http消息头中的微服务标记是否与规约中的微服务标记一致，从而识别微服务调用是否是标准的规约调用；若是非标准调用，则拦截处理并告警。

4.如权利要求1所述的基于语法分析树的微服务依赖链路静态分析方法，其特征在于，对当前微服务源码文件采用java语法分析树工具开发包转化为语法分析树对象。

5.如权利要求1所述的基于语法分析树的微服务依赖链路静态分析方法，其特征在于，所述类定义对象为格式化的java源码文件对象；所述方法声明源码是格式化且移除注释代码的方法声明源码。

6.如权利要求1所述的基于语法分析树的微服务依赖链路静态分析方法，其特征在于，所述规约包括枚举类规约，判断微服务调用方法中被调用的微服务名称是否是枚举类的引用。

7.如权利要求1所述的基于语法分析树的微服务依赖链路静态分析方法，其特征在于，根据判断结果，若是非标准调用，则将当前微服务名称、当前微服务调用方法、代码行号、异常类型存入异常依赖数据库；若是标准调用，则提取对应的枚举值，将当前微服务名称、被调用的微服务名称、所在微服务调用方法、所在代码行号存入正常依赖数据库。

8.一种基于语法分析树的微服务依赖链路静态分析系统，其特征在于，包括：

微服务编码规约模块，被配置为对微服务调用进行编码规约；

第一源码分析模块，被配置为将当前微服务源码文件转化为语法分析树对象；

第二源码分析模块，被配置为根据语法分析树对象获取类定义对象，根据类定义对象获取类的声明对象数组，遍历声明对象数组，得到方法声明对象；

第三源码分析模块，被配置为根据方法声明对象获取方法声明源码，在方法声明源码中检索规约中定义的微服务调用方法；

依赖链路告警模块，被配置为判断微服务调用方法中被调用的微服务名称是否符合规约要求，根据判断结果，定位异常依赖链路。

9.一种电子设备，其特征在于，包括存储器和处理器以及存储在存储器上并在处理器上运行的计算机指令，所述计算机指令被处理器运行时，完成权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，用于存储计算机指令，所述计算机指令被处理器执行时，完成权利要求1-7任一项所述的方法。

Images