CN114500334B - 服务端应用架构的诊断方法及装置 - Google Patents

Abstract

本说明书提供一种服务端应用架构的诊断方法及装置。所述方法包括：获取待诊断应用的服务端流量；将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系；根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

Description

服务端应用架构的诊断方法及装置

技术领域

本说明书一个或多个实施例涉及互联网技术领域，尤其涉及一种服务端应用架构的诊断方法及装置。

背景技术

在相关技术中，对于服务端应用架构的诊断需要安排专业人员主动浏览代码，从而专业人员根据经验，人为诊断所述服务端应用架构。这种人为诊断的过程需要耗费大量的时间成本和人力成本，而且容易产生误判。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种服务端应用架构的诊断方法及装置。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种服务端应用架构的诊断方法，应用于提供服务端应用架构诊断功能的规则引擎，所述方法包括：

获取待诊断应用的服务端流量；

将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系；

根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

根据本说明书一个或多个实施例的第二方面，提出了一种服务端应用架构的诊断装置，所述装置包括：

获取单元，用于获取待诊断应用的服务端流量；

匹配单元，用于将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系；

输出单元，用于根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

根据本说明书一个或多个实施例的第三方面，提出了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现第一方面所述方法的步骤。

根据本说明书一个或多个实施例的第四方面，提出了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面所述方法的步骤。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本说明书一示例性实施例提供的一种服务端应用架构诊断***的***架构示意图；

图2是本说明书一示例性实施例提供的一种服务端应用架构诊断方法的流程图；

图3是本说明书一示例性实施例提供的一种规则引擎匹配交互示意图；

图4是本说明书一示例性实施例提供的一种服务端流量诊断统计界面示意图；

图5是本说明书一示例性实施例提供的一种电子设备的示意结构图；

图6是本说明书一示例性实施例提供的一种服务端应用架构诊断装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

图1是本说明书一示例性实施例提供的一种服务端应用架构的诊断***的架构示意图。如图1所示，该***架构可以包括应用服务端10、规则引擎11和流量中心12，在本实施例中，所述服务端应用架构的诊断***的架构中，规则引擎11的输出预设对象为流量中心12，需要说明的是，预设对象也可以为其他预设对象并非只能为流量中心12，可以根据实际需求自行调整，本说明书对此不进行限制。

应用服务端10可以部署在包含一独立主机的物理服务器，或者该服务器可以为主机集群承载的虚拟服务器(如云服务器)，假设应用服务端10部署在虚拟服务器时，其应用服务端10可以为专有云服务端，也可以为私有云服务端，还可以为公有云服务端等，本说明书对此不进行限制。所述应用服务端10向所述规则引擎提供待诊断应用的服务端流量，使得所述规则引擎11对获取的待诊断应用的服务端流量进行诊断。

规则引擎11可以部署在包含一独立主机的物理服务器，或者该服务器可以为主机集群承载的虚拟服务器(如云服务器)。在所述物理服务器或虚拟服务器运行过程中，所述规则引擎11可以配置有本说明书所述的服务端应用架构诊断方法，以实现对服务端应用架构的自动诊断，从而避免了人工诊断所耗费的时间成本和人力成本，且基于所述规则引擎内自定义规则的合理性，可以有效避免人工诊断的误判，提高了服务端应用架构的诊断效率和准确率。

流量中心12可以为带有数据存储功能的数据库。需要说明的是，本说明书所述的预设对象并非只能为流量中心12，也可以是其他预设对象，可以根据实际需要进行适应调整。所述流量中心12用于接收规则引擎11输出的流量诊断结果，且流量中心12可以提供基于所述诊断结果的查询统计功能，以使得用户可以根据需求查询所述诊断结果，或者用户可以根据需求统计一段时间内的所述诊断结果。

基于上述***架构，可以配置本说明书所述的服务端应用架构诊断方法从而实现服务端应用架构的自动诊断，避免了人工诊断所耗费的大量时间成本和人力成本，也避免了人为诊断所带来的误判，提高了服务端应用架构的诊断效率和准确率。

图2是一示例性实施例提供的一种服务端应用架构的诊断方法的流程图，应用于提供服务端应用架构诊断功能的规则引擎11，该诊断方法包括以下步骤：

步骤201、获取待诊断应用的服务端流量。

在一实施例中，所述服务端流量可以为专有云服务端流量，也可以为私有云服务端流量，还可以为公有云服务端流量，本说明书对此不进行限制。

在一实施例中，所述待诊断应用的服务端应用架构定义了所述待诊断应用所涉及的多个功能组件，所述服务端流量包括所述多个功能组件之间形成的交互流量。

假定待诊断应用涉及的多个功能组件包括数据库组件和缓存组件等，若所述数据库组件调用了所述缓存组件，则所述待诊断应用的服务端流量可以为所述数据库组件和所述缓存组件之间的交互流量。

通过获取所述服务端的交互流量，可以更为直接的确定所述应用架构的各组件之间的交互状态，从而根据交互流量判断所述应用架构的调用情况，避免了其他流量的干扰，进而提升了所述应用架构诊断的效率。

但需要说明的是，本说明书所述服务端流量并非特定为多个功能组件之间形成的交互流量，所述服务端流量也可以包括其他流量如客户端向服务端上传的写入流量等，实际上，因为所述规则引擎11关联的规则库中配置有自定义的规则，本说明书所述的应用架构诊断方法可以诊断任意的服务端流量。

在一实施例中，所述服务端流量可以通过服务端运行的代理模块来采集所述服务端流量。例如，其代理模块可以为开源软件JVM-Sandbox(Java虚拟机-沙箱容器)来实现，JVM-Sandbox是一种非侵入式AOP(Aspect Oriented Programming，面向切面编程)解决方案。其可以使应用无需重启也无需感知沙箱的存在的情况下，实现流量的采集，具体采集方法可以参见现有技术中的相关内容，本说明书在此不再赘述。

通过JVM-Sandbox工具实现对服务端流量的采集，可以无侵入地、可插拔地对服务端流量进行采集，从而最大程度上减少对待检测应用的影响，且不会在所述待检测应用留下痕迹。

需要说明的是，本说明书采用开源软件JVM-Sandbox来实现流量的采集只是一种示例性的流量采集工具，并不代表只能使用所述开源软件JVM-Sandbox，本说明书对流量采集工具不进行限制。

在一实施例中，所述提供服务端应用架构诊断功能的规则引擎11配置有一个或多个拓展接口，所述拓展接口用于对接所述待诊断应用的服务端，以获取所述服务端流量。

例如，当前所述规则引擎11配置有接口A、接口B，则所述规则引擎11可以通过接口A对接第一数据源，通过接口B对接第二数据源。可选的，第一数据源为专有云服务端流量，第二数据源为公有云服务端流量。

再例如，当前所述规则引擎11配置有接口A，但第一数据源、第二数据源均可以对接接口A，则此时不需要配置额外的接口，可以仅通过接口A对接所述第一、第二数据源。可选的，第一数据源为专有云服务端流量，第二数据源为公有云服务端流量。

通过所述一个或多个拓展接口的作用下，可以使所述规则引擎11摆脱流量数据源的限制，从而可以使所述规则引擎11对接多种待诊断应用的服务端，例如专有云服务端、私有云服务端等，使得本说明书所述的服务端应用架构诊断方法具有很高的拓展性。

步骤202、将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系。

在一实施例中，所述规则库中预定义的规则可以由研发人员根据研发经验自定义编写。当所述服务端流量输入至规则引擎11后，由规则引擎11根据其所关联的规则库中预定义的诊断规则进行匹配。

通过自定义的规则编写与配置，从而使手动人工诊断应用架构变为自动机器诊断，避免了人工诊断所耗费的大量时间成本和人力成本，也避免了人为诊断所带来的误判，提高了服务端应用架构的诊断效率和准确率。

在一实施例中，所述规则引擎11逐条匹配所述规则引擎11所关联的规则库中预定义的诊断规则。通过逐条匹配所述规则引擎11所关联的规则库中预定义的诊断规则，可以避免因为匹配顺序所造成的诊断逻辑紊乱，保证了匹配的可行性。需要说明的是，逐条只是示例性的匹配顺序，当然在保证匹配确实可运行的前提下，本说明书对匹配顺序并不进行限制。

在一实施例中，所述诊断标签根据研发人员自定义编写的诊断规则确定，例如，所述诊断标签可以为“子调用重复”、“聚合SQL”、“接口异常”、“子调用入参重复”和“SQL未命中索引”等。需要说明的是，所述诊断标签并不局限于上述标签，其可以根据实际需求，基于预定义的诊断规则确定，本说明书对此不进行限制。

在所述诊断标签的作用下，可以更为直观的得到待诊断应用的服务端流量的诊断结果，使得相关人员可以根据诊断标签，及时发现、锁定应用架构所存在的问题。

在一实施例中，所述规则库中所含的诊断规则可以根据接收到的规则库更新指令而更新。

例如，当前研发人员在检查所述预定义的诊断规则时，发现其预定义的诊断规则编写有误、存在错误时，可以向规则引擎11下发更新指令，从而修正所述诊断规则，更新所述诊断规则。

例如，当前诊断规则已无法满足实际需求，则可以向规则引擎11下发更新指令，从而更新所述诊断规则，满足实际需求。

因为更新指令的存在，可以使相关人员及时更新所述规则库内所含的诊断规则，满足不同诊断的需求，避免了因为诊断规则落后或诊断规则存在错误，所造成的应用架构诊断误差，提高了应用架构的诊断准确率。

步骤203、根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

在一实施例中，所述携带诊断标签的服务端流量还携带有对应的诊断时间戳，以使所述预设对象根据所述诊断时间戳对所述携带诊断标签的服务端流量进行统计。

例如，当需要统计过去一周的已诊断的服务端流量时，仅需将统计时间设为过去一周内，则所述预设对象可以根据诊断时间戳，统计出过去一周所有已诊断服务端流量。

通过附加的时间戳的作用下，可以使诊断结果便于相关人员排查统计，避免造成统计结果的杂乱无序，从而提高了应用架构诊断结果的统计效率。

需要说明的是，所述携带诊断标签的服务端流量也可以不携带诊断时间戳，而是根据诊断标签对服务端流量进行统计，本说明书对统计方法不进行限制。

在一实施例中，所述预设对象可以为流量中心12，例如流量中心12为带有存储功能的数据库。需要说明的是，预设对象可以根据实际需求灵活决定，并非只能为流量中心12。

在一实施例中，在任一服务端流量同时匹配于所述规则库中的多条诊断规则的情况下，将匹配的多条诊断规则分别对应的诊断标签均赋予所述任一服务端流量。

例如，当前服务端流量A，同时匹配多条诊断规则，而对应的诊断标签分别为“子调用重复”和“SQL未命中索引”，则可以将所述诊断标签均赋予当前服务端流量A。

在一实施例中，若当前服务端流量未匹配所述规则库中的任何诊断规则，则可以赋予当前服务端流量诊断结果为健康的诊断标签。需要说明的是，本说明书也可以额外在规则库中自定义健康流量所表征的诊断规则，从而使得当前服务端流量至少匹配一条诊断规则。

待诊断应用的服务端流量有时经常会存在多种隐患或问题，本说明书正是考虑到这一实际情况，允许所述服务端流量被赋予多个诊断标签，从而可以一次性诊断出所述服务端流量存在的所有可能隐患或问题，进而提高了所述应用架构的诊断效率。

在一实施例中，在将携带诊断标签的服务端流量输出至流量中心12后，进一步的，所述流量中心12可以将带有非健康诊断标签的服务端流量自动推送至相关区域，如研发中心，使得相关人员可以基于诊断标签，及时快速的处理，避免因消息推送不及时或未及时查看诊断结果所造成的影响。

图3是一示例性实施例提供的一种规则引擎匹配交互示意图。如图所示，规则引擎11与规则库301所关联，其中，规则库301中配置有预定义的诊断规则，例如，其中的规则可以为“子调用重复规则”、“聚合SQL规则”、“子调用入参重复规则”等，所述规则可以由研发人员根据经验预先自定义编写。所述规则引擎11将获取的待诊断应用的服务端流量与规则库301预定义的诊断规则进行匹配，从而根据匹配结果，为匹配于所述诊断规则的服务端流量赋予对应的诊断标签。

所述规则引擎11可以根据其关联的规则库301实现诊断规则的匹配，从而实现自动机器诊断服务端应用架构，避免了人工浏览代码诊断应用架构所耗费的时间成本和人力成本，且与人工诊断相比，本说明书所述的诊断方法具有更高的效率。

专有云服务端流量302可以通过规则引擎11的拓展接口对接所述规则引擎11，使得所述规则引擎11获取专有云服务端流量302，服务端流量303也可以通过规则引擎11的拓展接口对接所述规则引擎11，使得所述规则引擎11获取服务端流量303。需要说明的是，专有云服务端流量302和服务端流量303可以使用同一个拓展接口也可以使用不同的拓展接口对接规则引擎11，本说明书对此不进行限制。

下面结合图3，以诊断服务端专有云应用架构为例，对本说明书所述的一种服务端应用架构诊断方法进行详细描述。

所述专有云应用内运行有JVM-Sandbox代理模块，所述代理模块可以非入侵式地采集所述专有云服务端流量302。

所述专有云服务端通过接口A对接所述规则引擎11，使得所述规则引擎11可以获取由代理模块采集的专有云服务端流量302。

所述规则引擎11将获取的专有云服务端流量302与规则引擎11关联的规则库301中包含的规则进行匹配。其中，所述专有云服务端流量302与“子调用重复”规则匹配成功，且未匹配其余规则库中包含的其他规则。所述规则引擎11赋予所述专有云服务端流量302“子调用重复”标签，并将所述携带有“子调用重复”标签的专有云服务端流量302及对应的诊断时间戳输出至流量中心12，此时预设对象为流量中心12。

流量中心12将接收到的携带有“子调用重复”标签的专有云服务端流量302及对应的诊断时间戳入库。并且，进一步的，因为其标签为非健康标签，所述流量中心12自动将所述携带有“子调用重复”标签的专有云服务端流量302推送给研发中心，使得运维人员可以根据标签及时对专有云应用架构进行排查，从而消除所述专有云服务端应用架构存在的问题。

服务端流量303的诊断过程与上述诊断过程类似，为了便于理解，本说明书仅描述了专有云服务端应用架构诊断的情况，且仅描述了专有云服务端流量302的诊断过程，但是多条流量的诊断或其他服务端应用架构的诊断与之类似，故本说明书在此不再赘述。

基于上述诊断方法，可以实现服务端应用架构的自动诊断，避免了人工诊断所耗费的大量时间成本和人力成本，也避免了人为诊断所带来的误判，提高了服务端应用架构的诊断效率和准确率。

示例性的，本说明书还提供一种服务端流量诊断统计界面示意图，如图4所示，在所述规则引擎11将携带诊断标签的服务端流量输出至流量中心12后，流量中心12可以提供如图4所述的统计界面，如图4所示，所述界面示意图中，可以有“刷新”标签、“导出”标签、“查询”标签。用户可以通过“刷新”标签及时刷新获得统计结果；通过“导出”标签，用户可以将所述统计结果导出至不同平台或直接以表格形式导出等，其导出功能可以根据实际需求，自行定义，本说明书对此不进行限制；通过“查询”标签，用户可以查询指定的服务端流量诊断结果；其中，还可以有“统计范围”标签，示例性的，用户可以只统计服务端流量A的统计结果，也可以只统计服务端流量B的统计结果，还可以统计所有流量的统计结果。通过“统计时间”标签，用户可以设定统计结果的时间范围，如过去一个月，过去一周等。

通过流量中心12提供的统计界面可以使相关人员方便快速地查询一定时间内的流量诊断结果，且流量中心12可以进一步将带有非健康诊断标签的服务端流量及时推送至相关区域，如研发中心，使得相关人员可以根据诊断标签及时排除修复应用架构所存在的问题或隐患，避免因消息推送不及时或未及时查看诊断结果所造成的影响。

由上述方法实施例可知，本说明书所提供的一种服务端应用架构诊断方法，避免了人工诊断所耗费的大量时间成本和人力成本，避免了人为诊断所带来的误判，可以实现服务端应用架构的自动诊断，提高了服务端应用架构的诊断效率和准确率。

相应于上述方法的实施例，本说明书还提供了装置的实施例。

图5是一示例性实施例提供的一种电子设备的示意结构图，请参考图5，在硬件层面，该电子设备包括处理器501、网络接口502、内存503、非易失性存储器504以及内部总线505，当然还可能包括其他功能所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

图6是一示例性实施例提供的一种服务端应用架构的诊断装置的框图，应用于提供服务端应用架构诊断功能的规则引擎，如图6所示，该装置包括：

获取单元601，用于获取待诊断应用的服务端流量。

匹配单元602，用于将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系。

输出单元603，用于根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

可选地，所述获取单元601具体用于：

接收所述代码模块传输的服务端流量，所述服务端流量由所述代理模块从所述待诊断应用的服务端采集。

可选地，所述待诊断应用的服务端应用架构定义了所述待诊断应用所涉及的多个功能组件，所述服务端流量包括所述多个功能组件之间形成的交互流量。

可选地，所述规则引擎配置有一个或多个拓展接口，所述拓展接口用于对接所述待诊断应用的服务端，以获取所述服务端流量。

可选地，所述输出单元603具体用于：

将所述携带诊断标签的服务端流量及对应的诊断时间戳关联输出至所述预设对象，以使所述预设对象根据所述诊断时间戳对所述携带诊断标签的服务端流量进行统计。

可选地，所述输出单元603具体用于：

在任一服务端流量同时匹配于所述规则库中的多条诊断规则的情况下，将匹配的多条诊断规则分别对应的诊断标签均赋予所述任一服务端流量；和/或，向与所述规则库中的所有诊断规则均不匹配的服务端流量赋予诊断结果为健康的诊断标签。

可选地，所述装置还包括：

更新单元604，用于根据接收到的规则库更新指令，对所述规则库中所含的诊断规则进行更新。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在相关方法的实施例中进行了详细描述，此处将不做详细阐述说明。

由以上本说明书提供的技术方案可见，通过规则引擎及规则引擎中自定义配置的规则，可以实现服务端应用架构的自动诊断，避免了人工诊断所耗费的时间成本和人力成本，且可以基于更新指令，实现规则库中规则的更新，从而确保了预设规则的合理性和及时性，避免了人工诊断的误判，进一步的，可以将存在隐患或问题的应用架构流量及对应标签推送至相关区域，从而可以使相关人员根据标签对应用架构进行排查和修复，避免了因未及时查看诊断结果或未收到推送信息而造成的延误。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (10)

1.一种服务端应用架构的诊断方法，其特征在于，应用于提供服务端应用架构诊断功能的规则引擎，所述方法包括：

获取待诊断应用的服务端流量；

将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系；

根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

2.根据权利要求1所述的方法，其特征在于，所述待诊断应用的服务端应用架构定义了所述待诊断应用所涉及的多个功能组件，所述服务端流量包括所述多个功能组件之间形成的交互流量。

3.根据权利要求1所述的方法，其特征在于，所述规则引擎配置有一个或多个拓展接口，所述拓展接口用于对接所述待诊断应用的服务端，以获取所述服务端流量。

4.根据权利要求1所述的方法，其特征在于，还包括：

根据接收到的规则库更新指令，对所述规则库中所含的诊断规则进行更新。

5.根据权利要求1所述的方法，其特征在于，所述将携带诊断标签的服务端流量输出至预设对象，包括：

将所述携带诊断标签的服务端流量及对应的诊断时间戳关联输出至所述预设对象，以使所述预设对象根据所述诊断时间戳对所述携带诊断标签的服务端流量进行统计。

6.根据权利要求1所述的方法，其特征在于，所述根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，包括：

在任一服务端流量同时匹配于所述规则库中的多条诊断规则的情况下，将匹配的多条诊断规则分别对应的诊断标签均赋予所述任一服务端流量；和/或，向与所述规则库中的所有诊断规则均不匹配的服务端流量赋予诊断结果为健康的诊断标签。

7.根据权利要求1所述的方法，其特征在于，所述待诊断应用的服务端运行有代理模块，所述获取待诊断应用架构服务端流量，包括：

接收所述代理模块传输的服务端流量，所述服务端流量由所述代理模块从所述待诊断应用的服务端采集。

8.一种服务端应用架构的诊断装置，其特征在于，应用于提供服务端应用架构诊断功能的规则引擎，所述装置包括：

获取单元，用于获取待诊断应用的服务端流量；

匹配单元，用于将获取的服务端流量与所述规则引擎所关联的规则库中预定义的诊断规则进行匹配，所述诊断规则用于表征服务端流量的流量特征与诊断标签之间的对应关系；

输出单元，用于根据匹配结果为匹配于所述诊断规则的服务端流量赋予对应的诊断标签，并将携带诊断标签的服务端流量输出至预设对象。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至7中任一所述方法的步骤。

10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至7中任一所述方法的步骤。