CN112559301A - 业务处理方法、存储介质、处理器及电子装置 - Google Patents

Abstract

本发明公开了一种业务处理方法、存储介质、处理器及电子装置。该方法包括：获取多个服务节点的业务日志数据；根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路。本发明解决了相关技术中无法在不改造或修改现有系统的情况下，基于现有系统所产生的数据来分析串联追踪业务的技术问题。

Description

业务处理方法、存储介质、处理器及电子装置

技术领域

本发明涉及计算机领域，具体而言，涉及一种业务处理方法、存储介质、处理器及电子装置。

背景技术

目前，在业务追踪领域中，相关技术已经提出较多业务追踪和系统追踪的相关标准，例如：OpenTracing相关标准。然而，在已经提出的大部分标准中，均需要投入大量的系统改造或者对系统进行嵌入式修改才能够满足相关标准的需求，由此会显著增加系统改造与修改的工作量。尤其是对于一些旧有系统或者停止维护的系统，为实现改造与修改所需投入的成本将会更加巨大。

由此可见，相关技术中无法在不改造或修改现有系统的情况下，基于现有系统所产生的数据(包括但不限于：系统日志、数据库)以此来分析串联追踪业务。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明至少部分实施例提供了一种业务处理方法、存储介质、处理器及电子装置，以至少解决相关技术中无法在不改造或修改现有系统的情况下，基于现有系统所产生的数据来分析串联追踪业务的技术问题。

根据本发明其中一实施例，提供了一种业务处理方法，包括：

获取多个服务节点的业务日志数据，其中，业务日志数据中记录与不同类型业务动作对应的日志记录；根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构。

可选地，上述方法还包括：在通过同一个业务事件集合中的每两个业务事件之间的关联程度信息确定多个业务事件集合中存在发生冲突的局部关联关系的情况下，对发生冲突的局部关联关系进行链路分解处理，以得到至少一条业务链路。

可选地，获取多个服务节点的业务日志数据包括：从第一预设存储区域获取业务日志数据，其中，第一预设存储区域为分布式的消息系统。

可选地，根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合包括：采用第一约束条件和第二约束条件将多个业务事件划分为多个子集合，其中，第一约束条件用于描述属于同一业务流程的不同类型的多个业务事件，第二约束条件用于描述在同一业务流程中不存在同种类型的多个业务事件；采用多个业务事件之间的至少一业务信息对多个子集合进行聚簇归并处理，得到多个业务事件集合。

可选地，在采用多个业务事件之间的至少一业务信息对多个子集合进行聚簇归并处理，得到多个业务事件集合之后，还包括：分别为每个业务事件集合中采用同一业务信息连接的不同类型业务事件之间的连接赋予对应级别的权重因子，其中，权重因子用于描述相邻两个不同类型业务事件之间连接的紧密程度。

可选地，上述方法还包括：获取同一个业务事件集合中各个业务事件之间的路径可达表，其中，路径可达表用于记录存在连接关系的每两个业务事件之间的连通路径；基于路径可达表中每条连通路径上相邻两个不同类型业务事件之间连接对应级别的权重因子计算同一个业务事件集合中的每两个业务事件之间的关联程度信息。

可选地，依据链路模板分别对多个业务事件集合中每个业务事件集合进行链路渲染处理，得到至少一条业务链路包括：获取与多个业务事件集合对应的链路模板；根据每个业务事件集合中各个业务事件类型，通过遍历链路模板逐级串联得到至少一条业务链路。

可选地，在得到至少一条业务链路之后，还包括：对至少一条业务链路中每条业务链路所包含的各个业务事件的业务信息进行汇总，得到汇总结果；将汇总结果存储至第二预设存储区域，其中，第二预设存储区域为分布式图类型数据库。

根据本发明其中一实施例，还提供了一种业务处理装置，包括：

获取模块，用于获取多个服务节点的业务日志数据，其中，业务日志数据中记录与不同类型业务动作对应的日志记录；第一处理模块，用于根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；第二处理模块，用于根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；第三处理模块，用于根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构。

可选地，上述装置还包括：第四处理模块，用于在通过同一个业务事件集合中的每两个业务事件之间的关联程度信息确定多个业务事件集合中存在发生冲突的局部关联关系的情况下，对发生冲突的局部关联关系进行链路分解处理，以得到至少一条业务链路。

可选地，获取模块，用于从第一预设存储区域获取业务日志数据，其中，第一预设存储区域为分布式的消息系统。

可选地，第二处理模块包括：划分单元，用于采用第一约束条件和第二约束条件将多个业务事件划分为多个子集合，其中，第一约束条件用于描述属于同一业务流程的不同类型的多个业务事件，第二约束条件用于描述在同一业务流程中不存在同种类型的多个业务事件；第一处理单元，用于采用多个业务事件之间的至少一业务信息对多个子集合进行聚簇归并处理，得到多个业务事件集合。

可选地，第二处理模块还包括：第二处理单元，用于分别为每个业务事件集合中采用同一业务信息连接的不同类型业务事件之间的连接赋予对应级别的权重因子，其中，权重因子用于描述相邻两个不同类型业务事件之间连接的紧密程度。

可选地，上述装置还包括：第五处理模块，用于获取同一个业务事件集合中各个业务事件之间的路径可达表，其中，路径可达表用于记录存在连接关系的每两个业务事件之间的连通路径；以及基于路径可达表中每条连通路径上相邻两个不同类型业务事件之间连接对应级别的权重因子计算同一个业务事件集合中的每两个业务事件之间的关联程度信息。

可选地，第三处理模块包括：获取单元，用于获取与多个业务事件集合对应的链路模板；第三处理单元，用于根据每个业务事件集合中各个业务事件类型，通过遍历链路模板逐级串联得到至少一条业务链路。

可选地，上述装置还包括：汇总模块，用于对至少一条业务链路中每条业务链路所包含的各个业务事件的业务信息进行汇总，得到汇总结果；存储模块，用于将汇总结果存储至第二预设存储区域，其中，第二预设存储区域为分布式图类型数据库。

根据本发明其中一实施例，还提供了一种存储介质，存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述任一项中的业务处理方法。

根据本发明其中一实施例，还提供了一种处理器，处理器用于运行程序，其中，程序被设置为运行时执行上述任一项中的业务处理方法。

根据本发明其中一实施例，还提供了一种电子装置，包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为运行计算机程序以执行上述任一项中的业务处理方法。

在本发明至少部分实施例中，采用获取多个服务节点的业务日志数据，该业务日志数据中记录与不同类型业务动作对应的日志记录，以及根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息的方式，通过根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同，以及根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构，达到了基于现有系统所产生的数据，多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合的实时串联方式实时串联业务链路，以便分析和追踪业务状态的目的，从而针对较为全面的客户端到服务器各个节点业务日志，通过至少一业务信息实现全链路通用的实时串联、实时追踪、实时分析业务链路数据的技术效果，进而解决了相关技术中无法在不改造或修改现有系统的情况下，基于现有系统所产生的数据来分析串联追踪业务的技术问题。

附图说明

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

图1是本发明实施例的一种全链路追踪系统的应用场景示意图；

图2是根据本发明其中一实施例的业务处理方法的流程图；

图3是根据本发明其中一可选实施例的实时聚类处理过程的示意图；

图4是根据本发明其中一实施例的业务处理装置的结构框图；

图5是根据本发明其中一可选实施例的业务处理装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明其中一实施例，提供了一种业务处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

该方法实施例可以在全链路追踪系统中执行。图1是本发明实施例的一种全链路追踪系统的应用场景示意图。如图1所示，微服务体系是围绕以计费业务为核心的综合服务体系。该微服务体系由负载均衡器、计费系统、风控系统、数据中心等多个微小的单体功能服务所组成。微服务之间采用标准的网络通信协议来交换信息。微服务数据的存储层通常是由关系型数据库组成的。

监控系统是一套用于监控单体微服务运行状态的系统。该监控系统由消息管道、时序数据库、仪表盘等部分所组成。监控系统通常采用爬虫采集数据策略，实时采集各个业务系统的基础监控数据，并存储至时序数据库中。然后，再通过告警管理器执行告警信息的汇总操作，并最终采用仪表盘的形式进行数据的可视化展示。

区别于监控系统，全链路追踪系统主要负责描述系统服务本身运行健康描述信息，侧重于在业务数据的基础上实现全网信息的打通，从而更全面地保障全网分布式服务的服务质量。

上述全链路追踪系统可以运行在服务器端。该服务器可以包括一个或多个处理器(处理器可以包括但不限于中央处理器(CPU)、图形处理器(GPU)、数字信号处理(DSP)芯片、微处理器(MCU)或可编程逻辑器件(FPGA)等的处理装置)和用于存储数据的存储器。可选地，上述服务器还可以包括用于通信功能的传输设备、输入输出设备以及显示设备。本领域普通技术人员可以理解，上述结构描述仅为示意，其并不对上述服务器的结构造成限定。例如，服务器还可包括比上述结构描述更多或者更少的组件，或者具有与上述结构描述不同的配置。

存储器可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的业务处理方法对应的计算机程序，处理器通过运行存储在存储器内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的业务处理方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器的通信供应商提供的无线网络。在一个实例中，传输设备包括一个网络适配器(NetworkInterface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

显示设备可以例如触摸屏式的液晶显示器(LCD)和触摸显示器(也被称为“触摸屏”或“触摸显示屏”)。该液晶显示器可使得用户能够与服务器的用户界面进行交互。在一些实施例中，上述图1所示的服务器具有图像用户界面(GUI)，用户可以通过触摸触敏表面上的手指接触和/或手势来与GUI进行人机交互，此处的人机交互功能可选的包括如下交互：创建网页、绘图、文字处理、制作电子文档、游戏、视频会议、即时通信、收发电子邮件、通话界面、播放数字视频、播放数字音乐和/或网络浏览等、用于执行上述人机交互功能的可执行指令被配置/存储在一个或多个处理器可执行的计算机程序产品或可读存储介质中。

在本实施例中提供了一种运行于上述全链路追踪系统的业务处理方法，图2是根据本发明其中一实施例的业务处理方法的流程图，如图2所示，该方法包括如下步骤：

步骤S20，获取多个服务节点的业务日志数据，其中，业务日志数据中记录与不同类型业务动作对应的日志记录；

步骤S22，根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；

步骤S24，根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；

步骤S26，根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构。

通过上述步骤，可以采用获取多个服务节点的业务日志数据，该业务日志数据中记录与不同类型业务动作对应的日志记录，以及根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息的方式，通过根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同，以及根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构，达到了基于现有系统所产生的数据，多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合的实时串联方式实时串联业务链路，以便分析和追踪业务状态的目的，从而针对较为全面的客户端到服务器各个节点业务日志，通过至少一业务信息实现全链路通用的实时串联、实时追踪、实时分析业务链路数据的技术效果，进而解决了相关技术中无法在不改造或修改现有系统的情况下，基于现有系统所产生的数据来分析串联追踪业务的技术问题。

业务日志数据中所记录的与不同类型业务动作对应的日志记录可以按照业务事件的元素构成(即五元组)解析成不同类型的多个业务事件。多个业务事件中的每个业务事件所包含的业务信息可以包括但不限于：业务请求标识(RequestId)、业务流程流水号标识(TransactionId)、用户设备号标识(Udid)、映射表标识(MappingId)。

在本实施例中，上述多个业务事件集合可以针对于同一用户在不同阶段的业务行为集合。例如：在用户网上购物的搜索阶段的业务行为可以构成一个业务事件集合，在用户网上购物的下单阶段的业务行为又可以构成一个业务事件集合，在用户网上购物的支付阶段的业务行为还可以构成一个业务事件集合，由此得到多个业务事件集合。在同时存在多用户行为的情况下，可以将多个用户拆解为单个用户，并且按照上述方式分别对单个用户的业务行为进行处理。在以下各个可选实施例中对于用户的业务行为描述既可以包括单个用户的业务行为描述，也可以包括多个用户的业务行为描述。

在全链路追踪系统中获取到当前待处理的多个业务请求之后，需要针对多个业务请求采用实时聚类处理过程，从而得到与每个业务请求之间存在一对一关系的业务链路。实时聚类处理过程主要可以分为“半监督图聚类”，“计算路径可达表”以及“链路渲染”三个必经阶段以及“链路分解”一个可选阶段。前一阶段的输出数据将被设置为后续阶段的输入数据，因此，整个实时聚类处理过程采用串行执行方式来完成，在本发明实施例中又被称之为Semi-Gtrace。“半监督图聚类”阶段用于实现上述步骤S24所涉及的根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合。“计算路径可达表”阶段用于对步骤S24所涉及的聚类处理的结果进行优化。“链路渲染”阶段用于实现上述步骤S26所涉及的根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路。上述各个阶段的具体实施过程将会在后续可选实施例中逐步展开描述。

可选地，在步骤S20中，获取多个服务节点的业务日志数据可以包括以下执行步骤：

步骤S201，从第一预设存储区域获取业务日志数据，其中，第一预设存储区域为分布式的消息系统。

第一预设存储区域可以是一个分布式的、基于发布或订阅的消息系统，其为提供业务日志数据来源的数据库。业务日志数据可以包括但不限于：网上购物请求日志、网上缴费请求日志、网上搜索请求日志、网上转账请求日志等多种不同类型的网络行为。

可选地，在步骤S24中，根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合可以包括以下执行步骤：

步骤S241，采用第一约束条件和第二约束条件将多个业务事件划分为多个子集合，其中，第一约束条件用于描述属于同一业务流程的不同类型的多个业务事件，第二约束条件用于描述在同一业务流程中不存在同种类型的多个业务事件；

步骤S242，采用多个业务事件之间的至少一业务信息对多个子集合进行聚簇归并处理，得到多个业务事件集合。

上述第一约束条件用于描述属于同一业务流程的不同类型的多个业务事件，即，“必连连接”聚类约束条件。所谓必连连接是指必定属于一次业务流程中的两个业务事件关系。上述第二约束条件用于描述在同一业务流程中不存在同种类型的多个业务事件，即，“勿连连接”约束条件。

图3是根据本发明其中一可选实施例的实时聚类处理过程的示意图，如图3所示，方框表示数据源或存储结果的数据库，椭圆形表示依次处理过程，箭头表示数据的流向。图中左侧部分主要用于描述各个阶段的执行步骤，图中右侧部分主要用于描述每次处理之后当前数据集的状态形式。request-1、request-2和request-3可以分别表示不同用户分别使用相同类型或不同类型应用客户端发起的业务请求，例如：request-1为用户A发起的网上购物业务请求，request-2为用户B发起的网上缴费业务请求，request-3为用户C发起的网上转账业务请求。request-1、request-2和request-3还可以表示同一用户在不同时刻使用相同类型或不同类型应用客户端发起的业务请求。例如：request-1为用户A在第一时刻发起的网上购物业务请求，request-2为用户A在第二时刻发起的网上缴费业务请求，request-3为用户A在第三时刻发起的网上转账业务请求。图中出现的不同几何形状可以分别用于表示不同的事件类型。例如：采用圆形表示下单业务事件类型，采用三角形表示支付业务事件类型。

在Semi-Gtrace的基本过程的第一个阶段中，通过局部两两连接、全局连接两阶段处理，将业务事件转换成若干个局部子图。而能够关联在一个子图中的关键信息是业务事件的“线索(即上述多个业务事件之间的至少一业务信息)”。例如：采用空白五角星作为在不同业务事件之间建立关联的线索。以request-3为例，request-3下的D类型业务事件，可能会因为不同的“线索”而在不同的子图连接中，从而串联成一个大的子图，由此符合“必连连接”聚类约束条件。其次，同样的事件类型，例如：“用户下单”类型的两次业务事件，在request-1和request-2中是不能够连接在一起的，由此满足“勿连连接”约束条件。通过上述两个约束条件使得形成如图所示的状态。最后，使用流式计算框架实时计算框架中的“滑动窗口”、“会话窗口”两阶段完成聚簇的归并过程，从而将原先两个不同的子图内事件规约到一个全联通子图中。

需要说明的是，上述线索通常包括能够在不同业务事件之间建立关联的多种提示信息。假设类型A为下单业务事件类型，类型B支付业务事件类型，那么下单业务事件与支付业务事件之间的线索可以包括但不限于：用户标识、业务订单号、业务流水号。并且，每相邻两个不同类型业务事件之间的线索互不相同。例如：A类型业务事件与B类型业务事件之间的线索不同于B类型业务事件到C类型业务事件之间的线索。

可选地，在步骤S242，采用多个业务事件之间的至少一业务信息对多个子集合进行聚簇归并处理，得到多个业务事件集合之后，还可以包括以下执行步骤：

步骤S243，分别为每个业务事件集合中采用同一业务信息连接的不同类型业务事件之间的连接赋予对应级别的权重因子，其中，权重因子用于描述相邻两个不同类型业务事件之间连接的紧密程度。

在不同类型的业务事件建立连接之后，并不表示业务事件之间的链路依赖关系，而只是探测到存在某种潜在的关系。为此，可以采用连接之间附带的权重信息来描述连接的紧密性，即权重越小，关联性越强。在本发明的一个可选实施例中，针对实际业务场景，定义三个级别权重因子：

第一级别权重因子0：满足必连约束，即必定属于同一个串联上下文当中，例如：在一次下单流程中，用户所执行的“下单动作”与“支付动作”之间会通过订单号线索而建立连接。

第二级别权重因子1：弱连接，有可能属于一个串联上下文当中，例如：通过设备唯一标识udid线索建立的连接，会存在单一用户在短时间内多次发起登陆可能，但是却并不能由此定性为一次串联过程。

第三级别权重因子∞：满足勿连约束，即必定不属于同一个串联上下文中，例如：两个不同用户分别使用两个不同客户端所执行的下单动作必定不属于同一个串联上下文当中。

可选地，上述方法还可以包括以下执行步骤：

步骤S27，获取同一个业务事件集合中各个业务事件之间的路径可达表，其中，路径可达表用于记录存在连接关系的每两个业务事件之间的连通路径；

步骤S28，基于路径可达表中每条连通路径上相邻两个不同类型业务事件之间连接对应级别的权重因子计算同一个业务事件集合中的每两个业务事件之间的关联程度信息。

在Semi-GTrace的基本过程的第二个阶段中，基于多个全联通子图生成多个业务事件集合，并将同一个业务事件集合中的事件两两计算其路径可达距离权重。该阶段计算路径可达权重的意义在于：在整个事件空间中，两个事件可能会通过不同的线索而获得不同的路径权重。假定“必连约束”和“勿连约束”不会自相矛盾，那么由“必连约束”而连接的“线索”影响因子将会大于由“弱连接”所带来的影响因子，因此，两个事件连接性将会强化。

在计算不同业务事件之间的路径可达距离权重时，可以对不同业务事件之间的路径上的权重因子进行求和运算，由此得到同一个业务事件集合中各个业务事件之间的路径可达表(即上述关联程度信息)。例如：如果从A类型业务事件到B类型业务事件之间路径上的权重因子为1，从B类型业务事件到C类型业务事件之间路径上的权重因子为1，则A类型业务事件与C类型业务事件之间的路径可达距离权重即为2。

可选地，在步骤S26中，依据链路模板分别对多个业务事件集合中每个业务事件集合进行链路渲染处理，得到至少一条业务链路可以包括以下执行步骤：

步骤S261，获取与多个业务事件集合对应的链路模板；

步骤S262，根据每个业务事件集合中各个业务事件类型，通过遍历链路模板逐级串联得到至少一条业务链路。

在Semi-GTrace的基本过程的第三个阶段中，主要实施链路的渲染过程，由于计算所生成的是多个独立的业务事件集合，业务事件集合内所包含的事件并不具备关联关系，而业务规则能够很好地指导事件之间的关联关系，因此通过遍历“链路模板(即预设业务流程描述信息，通常为树形结构)”将生成链路真实有效的实例信息(即按照链路模板执行多种不同类型业务事件的填充操作所得到的业务链路)。

可选地，上述方法还可以包括以下处理步骤：

步骤S29，在通过同一个业务事件集合中的每两个业务事件之间的关联程度信息确定多个业务事件集合中存在发生冲突的局部关联关系的情况下，对发生冲突的局部关联关系进行链路分解处理，以得到至少一条业务链路。

在Semi-GTrace的基本过程的第四个阶段中，实施链路分解过程，考虑到“弱连接”和“必连约束”之间的关系，将会导致在一个簇过程当中存在两个同样类型事件违背“勿连约束”，为此需要解决冲突。冲突的产生通常处于局部连接关系中，而局部连接关系的冲突解决满足“二分图”关系，故而采用二分图冲突解决策略作为链路分解的最优策略。例如：用户在第一时刻先后执行下单类型业务事件A1和支付类型业务事件B1，然后又在第二时刻先后执行下单类型业务事件A2和支付类型业务事件B2，为了避免将下单类型业务事件A1和支付类型业务事件B2混淆在一起发生冲突或者将下单类型业务事件A2和支付类型业务事件B1混淆在一起发生冲突，为此，需要执行链路分解操作将两个不同的网上购物请求进行分离。

需要说明的是，只有在通过关联程度信息确定多个业务事件集合中存在发生冲突的局部关联关系的情况下，才会执行链路分解过程。如果通过关联程度信息确定多个业务事件集合中未存在发生冲突的局部关联关系，则通常只需执行“半监督图聚类”，“计算路径可达表”以及“链路渲染”三个阶段便可以得到业务请求对应的业务链路。

可选地，在步骤S26，得到至少一条业务链路之后，还可以包括以下执行步骤：

步骤S30，对至少一条业务链路中每条业务链路所包含的各个业务事件的业务信息进行汇总，得到汇总结果；

步骤S31，将汇总结果存储至第二预设存储区域，其中，第二预设存储区域为分布式图类型数据库。

上述第二预设存储区域可以是一个分布式图类型数据库，其为存储最终处理结果的数据库。

在串联过程当中，伴随着标签传播的存在，随着全链路信息的逐级串联，超级事件中的信息将会变得愈加丰富，从而形成如图所示的超级节点(例如：黑色五角星所示节点)。超级事件的作用在于：如果将超级事件节点视为树形结构的根节点，那么该超级事件节点将会对所有子节点的业务信息进行汇总，并将汇总结果通过索引方式存储至图类型数据库中，以便于用户进行数据查询。例如：如果执行A类型业务事件得到的业务信息包括购买商品数量信息和购买商品金额信息，执行C类型业务事件得到的业务信息包括购买商品支付金额信息和购买商品优惠信息，那么最终这些业务信息都将被汇总至超级事件节点中。然后，用户在数据查询过程中，可以从超级事件节点开始逐级展开查询各种类型业务事件得到的业务信息。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

在本实施例中还提供了一种业务处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图4是根据本发明其中一实施例的业务处理装置的结构框图，如图4所示，该装置包括：获取模块10，用于获取多个服务节点的业务日志数据，其中，业务日志数据中记录与不同类型业务动作对应的日志记录；第一处理模块20，用于根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；第二处理模块30，用于根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；第三处理模块40，用于根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构。

可选地，图5是根据本发明其中一可选实施例的业务处理装置的结构框图，如图5所示，该装置除包括图4所示的所有模块外，上述装置还包括：第四处理模块50，用于在通过同一个业务事件集合中的每两个业务事件之间的关联程度信息确定多个业务事件集合中存在发生冲突的局部关联关系的情况下，对发生冲突的局部关联关系进行链路分解处理，以得到至少一条业务链路。

可选地，获取模块10，用于从第一预设存储区域获取业务日志数据，其中，第一预设存储区域为分布式的消息系统。

可选地，第二处理模块30包括：划分单元(图中未示出)，用于采用第一约束条件和第二约束条件将多个业务事件划分为多个子集合，其中，第一约束条件用于描述属于同一业务流程的不同类型的多个业务事件，第二约束条件用于描述在同一业务流程中不存在同种类型的多个业务事件；第一处理单元(图中未示出)，用于采用多个业务事件之间的至少一业务信息对多个子集合进行聚簇归并处理，得到多个业务事件集合。

可选地，第二处理模块30还包括：第二处理单元(图中未示出)，用于分别为每个业务事件集合中采用同一业务信息连接的不同类型业务事件之间的连接赋予对应级别的权重因子，其中，权重因子用于描述相邻两个不同类型业务事件之间连接的紧密程度。

可选地，该装置除包括图4所示的所有模块外，上述装置还包括：第五处理模块60，用于获取同一个业务事件集合中各个业务事件之间的路径可达表，其中，路径可达表用于记录存在连接关系的每两个业务事件之间的连通路径；以及基于路径可达表中每条连通路径上相邻两个不同类型业务事件之间连接对应级别的权重因子计算同一个业务事件集合中的每两个业务事件之间的关联程度信息。

可选地，第三处理模块40包括：获取单元(图中未示出)，用于获取与多个业务事件集合对应的链路模板；第三处理单元(图中未示出)，用于根据每个业务事件集合中各个业务事件类型，通过遍历链路模板逐级串联得到至少一条业务链路。

可选地，如图5所示，该装置除包括图4所示的所有模块外，上述装置还包括：汇总模块70，用于对至少一条业务链路中每条业务链路所包含的各个业务事件的业务信息进行汇总，得到汇总结果；存储模块80，用于将汇总结果存储至第二预设存储区域，其中，第二预设存储区域为分布式图类型数据库。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，获取多个服务节点的业务日志数据，其中，业务日志数据中记录与不同类型业务动作对应的日志记录；

S2，根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；

S3，根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；

S4，根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，获取多个服务节点的业务日志数据，其中，业务日志数据中记录与不同类型业务动作对应的日志记录；

S2，根据日志记录解析成不同类型的多个业务事件，其中，多个业务事件中的每个业务事件包括至少一业务信息；

S3，根据多个业务事件之间的至少一业务信息对业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的同一业务信息彼此之间不同；

S4，根据链路模板分别对多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，链路模板根据业务流程预先建立的数据结构。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (12)

1.一种业务处理方法，其特征在于，包括：

获取多个服务节点的业务日志数据，其中，所述业务日志数据中记录与不同类型业务动作对应的日志记录；

根据所述日志记录解析成不同类型的多个业务事件，其中，所述多个业务事件中的每个业务事件包括至少一业务信息；

根据所述多个业务事件之间的至少一业务信息对所述业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的所述同一业务信息彼此之间不同；

根据链路模板分别对所述多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，所述链路模板根据业务流程预先建立的数据结构。

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

在通过同一个业务事件集合中的每两个业务事件之间的关联程度信息确定所述多个业务事件集合中存在发生冲突的局部关联关系的情况下，对发生冲突的局部关联关系进行链路分解处理，以得到所述至少一条业务链路。

3.根据权利要求1所述的方法，其特征在于，获取所述多个服务节点的所述业务日志数据包括：

从第一预设存储区域获取所述业务日志数据，其中，所述第一预设存储区域为分布式的消息系统。

4.根据权利要求1所述的方法，其特征在于，根据所述多个业务事件之间的至少一业务信息对所述业务事件进行聚类处理形成所述多个业务事件集合包括：

采用第一约束条件和第二约束条件将所述多个业务事件划分为多个子集合，其中，所述第一约束条件用于描述属于同一业务流程的不同类型的多个业务事件，所述第二约束条件用于描述在同一业务流程中不存在同种类型的多个业务事件；

采用所述多个业务事件之间的至少一业务信息对所述多个子集合进行聚簇归并处理，得到所述多个业务事件集合。

5.根据权利要求4所述的方法，其特征在于，在采用所述多个业务事件之间的至少一业务信息对所述多个子集合进行聚簇归并处理，得到所述多个业务事件集合之后，还包括：

分别为每个业务事件集合中采用同一业务信息连接的不同类型业务事件之间的连接赋予对应级别的权重因子，其中，所述权重因子用于描述相邻两个不同类型业务事件之间连接的紧密程度。

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

获取同一个业务事件集合中各个业务事件之间的路径可达表，其中，所述路径可达表用于记录存在连接关系的每两个业务事件之间的连通路径；

基于所述路径可达表中每条连通路径上相邻两个不同类型业务事件之间连接对应级别的权重因子计算同一个业务事件集合中的每两个业务事件之间的关联程度信息。

7.根据权利要求1所述的方法，其特征在于，依据所述链路模板分别对所述多个业务事件集合中每个业务事件集合进行链路渲染处理，得到所述至少一条业务链路包括：

获取与所述多个业务事件集合对应的所述链路模板；

根据每个业务事件集合中各个业务事件类型，通过遍历所述链路模板逐级串联得到所述至少一条业务链路。

8.根据权利要求1或2所述的方法，其特征在于，在得到所述至少一条业务链路之后，还包括：

对所述至少一条业务链路中每条业务链路所包含的各个业务事件的业务信息进行汇总，得到汇总结果；

将所述汇总结果存储至第二预设存储区域，其中，所述第二预设存储区域为分布式图类型数据库。

9.一种业务处理装置，其特征在于，包括：

获取模块，用于获取多个服务节点的业务日志数据，其中，所述业务日志数据中记录与不同类型业务动作对应的日志记录；

第一处理模块，用于根据所述日志记录解析成不同类型的多个业务事件，其中，所述多个业务事件中的每个业务事件包括至少一业务信息；

第二处理模块，用于根据所述多个业务事件之间的至少一业务信息对所述业务事件进行聚类处理形成多个业务事件集合，其中，每个业务事件集合通过同一业务信息实现聚合，并且多个业务事件集合对应的所述同一业务信息彼此之间不同；

第三处理模块，用于根据链路模板分别对所述多个业务事件集合进行链路渲染处理得到至少一条业务链路，其中，所述链路模板根据业务流程预先建立的数据结构。

10.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至8任一项中所述的业务处理方法。

11.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序被设置为运行时执行所述权利要求1至8中任一项中所述的业务处理方法。

12.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至8任一项中所述的业务处理方法。

Images