CN112463562A

CN112463562A - 一种全业务追踪实现方法、装置、设备及可读存储介质

Info

Publication number: CN112463562A
Application number: CN202011337607.0A
Authority: CN
Inventors: 黄展鹏; 曾林; 易峰
Original assignee: Zhengcaiyun Co ltd
Current assignee: Zhengcaiyun Co ltd
Priority date: 2020-11-25
Filing date: 2020-11-25
Publication date: 2021-03-09

Abstract

本申请公开了一种全业务追踪实现方法，应用于入口节点，该方法在首次接收到业务请求时，生成全局唯一的追踪码，后续在处理同笔业务的每条业务请求时，都将追踪码传递给相关业务节点，从而保证该笔业务涉及到的全部业务节点均能够获得该追踪码。最终，在打印请求日志时，各个业务节点将追踪码追加至请求日志中。实现了一次性追踪一笔业务中全部业务请求的目的，且将该笔业务中的全部请求日志通过追踪码关联起来，简化了追踪过程，提升了追踪效率，有利于后续数据分析工作的进行。此外，本申请还提供了一种全业务追踪实现装置、设备及可读存储介质，其技术效果与上述方法相对应。

Description

一种全业务追踪实现方法、装置、设备及可读存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种全业务追踪实现方法、装置、设备及可读存储介质。

背景技术

业务追踪就是将一次业务请求还原成一条业务节点的调用链路，集中展示这次业务请求中各业务节点的请求状态和请求日志，如各个业务节点上的请求状态和请求耗时、处理过程打印的请求日志、异常状态下打印的错误日志等。

业务追踪技术已经被广泛用于问题排查、数据统计，但其也存在着一定的局限性。目前的业务追踪技术实现的仅仅是对单次业务请求的追踪，在碰到需要多次业务请求的复杂业务流程时，就会显得力不从心，需要通过多次业务追踪才能实现，而且这多次业务追踪的结果还是分散的，无法合并到一起，无形中增加了问题排查和数据分析的难度。

可见，当前的业务追踪方案只能对单次业务请求进行追踪，由于一笔完整的业务往往涉及多次业务请求，因此当前的业务追踪方案需要多次追踪，追踪过程复杂，效率低下，而且，不同业务请求的追踪结果是分散的，不利于进行数据分析。如何克服上述缺陷，是亟待本领域技术人员解决的问题。

发明内容

本申请的目的是提供一种全业务追踪实现方法、装置、设备及可读存储介质，用以解决以下技术问题：当前的业务追踪方案只能对单次业务请求进行追踪，在面对复杂的业务流程时，追踪过程复杂且追踪结果分散。其具体方案如下：

第一方面，本申请提供了一种全业务追踪实现方法，应用于入口节点，包括：

S1、获取请求方发起的业务请求；

S2、判断所述业务请求是否携带追踪码，若携带，进入S4，否则进入S3；

S3、生成全局唯一的追踪码，对所述追踪码进行缓存；将所述追踪码存储至业务请求cookie，以便于所述请求方发起的同笔业务中的后续业务请求携带所述追踪码；

S4、生成携带所述追踪码的节点间请求，将所述节点间请求发送至目标业务节点，以便所述目标业务节点缓存所述追踪码；

S5、在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中。

优选的，在所述将所述节点间请求发送至目标业务节点，以便所述目标业务节点缓存所述追踪码之后，还包括：

在打印请求日志时，所述目标业务节点将缓存中的所述追踪码追加至所述请求日志中。

优选的，所述生成携带所述追踪码的节点间请求，包括：

将所述追踪码存入节点间请求的请求header或dubbo上下文中，得到携带所述追踪码的节点间请求。

优选的，所述在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中，包括：

在以日志文件或kafka方式打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中。

优选的，所述生成全局唯一的追踪码，包括：

通过预设算法，生成64位全局唯一的追踪码。

优选的，所述将所述节点间请求发送至目标业务节点，包括：

确定所述业务请求对应的识别码，将所述识别码记录至***变量中，其中所述识别码为预先定义的用于区分不同业务类型的代码；

根据所述识别码确定目标业务节点；

将所述节点间请求发送至目标业务节点。

在打印请求日志时，读取缓存中的所述追踪码，并读取所述***变量记录的所述识别码；

将所述追踪码和所述识别码一并追加至所述请求日志中。

第二方面，本申请提供了一种全业务追踪实现装置，应用于入口节点，包括：

请求获取模块：用于获取请求方发起的业务请求；

判断模块：用于判断所述业务请求是否携带追踪码，若携带，进入节点间调用模块，否则进入追踪码生成模块；

追踪码生成模块：用于生成全局唯一的追踪码，对所述追踪码进行缓存；将所述追踪码存储至业务请求cookie，以便于所述请求方发起的同笔业务中的后续业务请求携带所述追踪码；

节点间调用模块：用于生成携带所述追踪码的节点间请求，将所述节点间请求发送至目标业务节点，以便所述目标业务节点缓存所述追踪码；

日志打印模块：用于在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中。

第三方面，本申请提供了一种全业务追踪实现设备，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如上所述的全业务追踪实现方法。

第四方面，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如上所述的全业务追踪实现方法。

本申请所提供的一种全业务追踪实现方法，应用于入口节点，包括：在首次接收到请求方发起的业务请求时，生成全局唯一的追踪码，对追踪码进行缓存；将追踪码存储至业务请求cookie，以便于请求方发起的同笔业务中的后续业务请求携带追踪码；生成携带追踪码的节点间请求，将节点间请求发送至目标业务节点，以便目标业务节点缓存追踪码；在打印请求日志时，将缓存中的追踪码追加至请求日志中。

可见，由于一笔业务的业务流程往往涉及多个业务节点，且需要经过多次业务请求才能完成，因此，该方法在首次接收到业务请求时，生成全局唯一的追踪码，后续在处理同笔业务的每条业务请求时，都将追踪码传递给相关业务节点，从而保证该笔业务涉及到的全部业务节点均能够获得该追踪码。最终，在打印请求日志时，各个业务节点将追踪码追加至请求日志中。实现了一次性追踪一笔业务中全部业务请求的目的，且将该笔业务中的全部请求日志通过追踪码关联起来，简化了追踪过程，提升了追踪效率，有利于后续数据分析工作的进行。

此外，本申请还提供了一种全业务追踪实现装置、设备及可读存储介质，其技术效果与上述方法相对应，这里不再赘述。

附图说明

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

图1为本申请所提供的一种全业务追踪实现方法实施例一的流程图；

图2为本申请所提供的一种全业务追踪实现方法实施例一的时序图；

图3为本申请所提供的一种全业务追踪实现方法实施例二的流程图；

图4为本申请所提供的一种全业务追踪实现方法实施例二中S303的细化流程图；

图5为本申请所提供的一种全业务追踪实现装置实施例的功能框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的核心是提供一种全业务追踪实现方法、装置、设备及可读存储介质，面对复杂的业务流程，实现了一次性追踪一笔业务中全部业务请求的目的，且将该笔业务中的全部请求日志通过追踪码关联起来，简化了追踪过程，提升了追踪效率。

首先，对本申请提及的一些概念进行介绍：

业务请求：请求方向业务***提交信息或查询数据的过程。

业务流程：一笔业务的整个处理过程称为业务流程，一个复杂的业务流程需要经历多次业务请求，由多个业务节点进行处理。

业务节点：业务流程会经过多个业务模块，每个业务模块都是一个业务节点，一次业务请求可能会由多个业务节点进行处理。

入口节点：业务流程中第一个业务节点。

请求日志：业务节点处理业务请求时打印的日志。

追踪码：用来唯一标识一笔业务。

下面对本申请提供的一种全业务追踪实现方法实施例一进行介绍，参见图1和图2，实施例一应用于入口节点，包括：

S101、获取请求方发起的业务请求。

S102、判断所述业务请求是否携带追踪码，若携带，进入S104，否则进入S103。

如图2所示，本实施例在请求方首次发起业务请求时，生成追踪码，追踪码用于标识一笔业务，后续请求方发起的同笔业务的业务请求均会携带该追踪码。

因此，上述S102实际上是判断一条业务请求是否为一笔业务中的第一条业务请求的过程，本实施例将业务请求是否携带追踪码作为判断依据，实际应用中，也可以根据其他判断依据进行判断，本实施例对此不做限定。

S103、生成全局唯一的追踪码，对所述追踪码进行缓存；将所述追踪码存储至业务请求cookie，以便于所述请求方发起的同笔业务中的后续业务请求携带所述追踪码。

S104、生成携带所述追踪码的节点间请求，将所述节点间请求发送至目标业务节点，以便所述目标业务节点缓存所述追踪码。

作为一种具体的实施方式，通过将所述追踪码存入节点间请求的请求header或dubbo上下文中，得到携带所述追踪码的节点间请求。

上述目标业务节点是根据业务需求确定的入口节点需要调用的业务节点。可以理解的是，实际业务流程中，目标业务节点可能还需要继续调用其他业务节点，具体的，每次调用业务节点时，均需要将携带追踪码的节点间请求发送至被调用的业务节点。

S105、在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中。

步骤S105对入口节点的日志打印过程进行了说明，可以理解的是，如图2所示，在一个业务流程中，除入口节点之外的其他业务节点也会缓存追踪码，并按照以下方式进行日志打印：在打印请求日志时，所述目标业务节点将缓存中的所述追踪码追加至所述请求日志中。

在实际应用中，业务节点(包括但不限于入口节点)可以以日志文件或kafka方式打印请求日志。此外，除了打印请求日志，还可以打印错误日志。

本实施例所提供一种全业务追踪实现方法，应用于入口节点，该方法在首次接收到业务请求时，生成全局唯一的追踪码，后续在处理同笔业务的每条业务请求时，都将追踪码传递给相关业务节点，从而保证该笔业务涉及到的全部业务节点均能够获得该追踪码。最终，在打印请求日志时，各个业务节点将追踪码追加至请求日志中。实现了一次性追踪一笔业务中全部业务请求的目的，且将该笔业务中的全部请求日志通过追踪码关联起来，简化了追踪过程，提升了追踪效率，有利于后续数据分析工作的进行。

下面开始详细介绍本申请提供的一种全业务追踪实现方法实施例二，实施例二以实施例一为基础，并在实施例一基础上进行了一定程度上的拓展。

具体的，实施例二在实施例一的基础上增加了识别码，用于区分不同业务类型，其至少具备以下两项功能：第一，用来定义一种业务的业务流程，方便业务***知道后续流转过程；第二，将识别码追加在请求日志中，不仅利于用户获知请求日志的业务类型，还能实现根据识别码查询某种业务的全部请求日志。

参见图3，实施例二具体包括：

S301、请求方首次发起业务请求。

S302、入口节点确定业务请求对应的识别码，将识别码记录至***变量中；利用预设算法生成64位全局唯一的追踪码，并将识别码和追踪码存储到业务请求cookie和本地缓存中。

由于将识别码和追踪码存储到业务请求cookie中，因此，同一笔业务的后续业务请求也能够携带识别码和追踪码。由于将识别码和追踪码存储到本地缓存中，因此，业务节点间相互调用时能够携带识别码和追踪码。

S303、根据业务请求，实现业务节点之间的调度过程，每次调度过程中，将识别码和追踪码传递给被调度的业务节点。

具体的，业务流程中的每个业务节点都会校验识别码，确保流程按预期流转。

S304、同笔业务中，请求方再次发起业务请求，此时的业务请求携带识别码和追踪码，直接进入S303。

S305、在业务节点(包括但不限于入口节点)以日志文件或kafka方式打印请求日志时，读取本地缓存中的追踪码，并读取***变量记录的所述识别码，追加识别码和追踪码。

S306、日志服务收集并汇总请求日志及识别码和追踪码，提供请求日志查询服务，可根据追踪码查询一笔业务的所有请求日志，还可根据识别码查询一种业务的所有请求日志。

日志服务通过收集日志文件或kafka消息来得到一笔业务涉及的全部请求日志，并对请求日志进行汇总，提取出请求日志中的识别码和追踪码，因此可根据追踪码查询一笔业务的所有请求日志，还可根据识别码查询一种业务的所有请求日志，方便问题快速定位及排查。

实际应用中，日志服务还可以将请求日志按照实现先后顺序进行排列。

如图4所示，上述S303具体包括：

S401、当前业务节点确定被调度的下一业务节点；

具体的，本实施例中识别码用于区别不同的业务类型，因此根据识别码也可以唯一确定一种业务的业务流程，所以具体可以根据识别码确定被调度的下一业务节点。

S402、当前业务节点生成携带识别码和追踪码的节点间请求，将节点间请求发送至下一业务节点；

具体将识别码和追踪码放进节点间请求的请求header或dubbo上下文中。

S403、下一业务节点被调用时，识别识别码和追踪码，并缓存在本地缓存中；

S404、判断当前的业务请求是否执行结束，如未结束，则将下一业务节点作为当前业务节点，进入S401，否则结束流程。

可见，本实施例提供的一种全业务追踪实现方法，至少具备以下优点：

(1)自行编写算法生成追踪码，具有高性能、超大容量、全局唯一的特性。使用该算法生成海量64位全局唯一的追踪码，能够避免出现重复追踪码，为全业务追踪提供了基础性保障，而且能够生成海量追踪码，支持大量业务流程全业务追踪需求。

(2)实现了基于识别码和追踪码的业务追踪机制。使用识别码定义业务流程，使用追踪码串联各业务节点请求日志，识别码和追踪码结合，实现真正意义上的全业务追踪。

(3)提高了全业务追踪效率。一个业务流程往往包含多个业务节点，需要经过多次业务请求才能完成，本实施例通过一个追踪码将一笔业务的多次业务请求产生的分散请求日志串联到一起，方便进行问题排查和数据分析，和传统链路追踪***相对，大大提高了追踪效率。

对于普通的业务追踪方案而言，其仅仅能够实现单次业务请求的追踪，因此，其日志收集量和日志查询耗时计算过程如下：

业务追踪日志收集量计算公式为：日志收集量＝单次业务请求*业务请求各节点打印日志量。

一笔完整业务日志查询耗时计算公式为：日志查询耗时＝一笔业务包含的N次业务请求*查询一次请求追踪日志耗时+所有请求追踪日志手动串联耗时。

基于上述公式，假设“单次业务请求”值为1，“业务请求各节点打印日志量”值为100，“一笔业务包含的N次业务请求”值为10，“查询一次请求追踪日志耗时”值为100，“所有请求追踪日志手动串联耗时”值为500，则日志收集量和日志查询耗时如下：

日志收集量＝1*100＝100。

日志查询耗时＝100*10+500＝1500。

不同于普通的业务追踪方案，本申请能够同时实现对一笔业务中多次业务请求的追踪，其日志收集量和日志查询耗时计算过程如下：

全业务追踪日志收集量计算公式为：日志收集量＝一笔业务包含的N次业务请求*单次业务请求*业务请求各节点打印日志量。

一笔完整业务日志查询耗时计算公式为：日志查询耗时＝查询一次全业务追踪日志耗时。

基于上述公式，假设“单次业务请求”值为1，“业务请求各节点打印日志量”值为100，“一笔业务包含的N次业务请求”值为10，“查询一次请求追踪日志耗时”值为100，则日志收集量和日志查询耗时如下：

日志收集量＝10*1*100＝1000。

日志查询耗时＝100。

可见，普通的业务追踪方案中，日志收集量为100，本申请的日志收集量为1000，提升了900％，日志收集量大幅提升，方便了问题排查及定位。

而且，普通的业务追踪方案中，日志查询耗时为1500，本申请的日志查询耗时为100，下降了93.3％，节省了大量问题排查及定位耗时，节省了人员成本，大大加快了问题排查及定位速度，对问题的快速解决提供了强有力的基础能力支持。

综上，与普通的业务追踪方案相比，本申请能够收集一笔业务中全部业务请求的日志，显著提升日志收集量，且日志查询更简便，一次查询即可查到所有日志，大大降低了多个请求追踪码查找和多次日志查询结果串联的耗时，总耗时降低95％以上。

下面对本申请实施例提供的一种全业务追踪实现装置进行介绍，下文描述的一种全业务追踪实现装置与上文描述的一种全业务追踪实现方法可相互对应参照。

如图5所示，本实施例的全业务追踪实现装置，应用于入口节点，包括：

请求获取模块501：用于获取请求方发起的业务请求；

判断模块502：用于判断所述业务请求是否携带追踪码，若携带，进入节点间调用模块504，否则进入追踪码生成模块503；

追踪码生成模块503：用于生成全局唯一的追踪码，对所述追踪码进行缓存；将所述追踪码存储至业务请求cookie，以便于所述请求方发起的同笔业务中的后续业务请求携带所述追踪码；

节点间调用模块504：用于生成携带所述追踪码的节点间请求，将所述节点间请求发送至目标业务节点，以便所述目标业务节点缓存所述追踪码；

日志打印模块505：用于在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中。

本实施例的全业务追踪实现装置用于实现前述的全业务追踪实现方法，因此该装置中的具体实施方式可见前文中的全业务追踪实现方法的实施例部分，例如，请求获取模块501、判断模块502、追踪码生成模块503、节点间调用模块504、日志打印模块505，分别用于实现上述全业务追踪实现方法中步骤S101，S102，S103，S104，S105。所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再展开介绍。

另外，由于本实施例的全业务追踪实现装置用于实现前述的全业务追踪实现方法，因此其作用与上述方法的作用相对应，这里不再赘述。

此外，本申请还提供了一种全业务追踪实现设备，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如上文所述的全业务追踪实现方法。

最后，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如上文所述的全业务追踪实现方法。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的方案进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种全业务追踪实现方法，其特征在于，应用于入口节点，包括：

S1、获取请求方发起的业务请求；

2.如权利要求1所述的方法，其特征在于，在所述将所述节点间请求发送至目标业务节点，以便所述目标业务节点缓存所述追踪码之后，还包括：

3.如权利要求1所述的方法，其特征在于，所述生成携带所述追踪码的节点间请求，包括：

4.如权利要求1所述的方法，其特征在于，所述在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中，包括：

5.如权利要求1所述的方法，其特征在于，所述生成全局唯一的追踪码，包括：

通过预设算法，生成64位全局唯一的追踪码。

6.如权利要求1-5任意一项所述的方法，其特征在于，所述将所述节点间请求发送至目标业务节点，包括：

根据所述识别码确定目标业务节点；

将所述节点间请求发送至目标业务节点。

7.如权利要求6所述的方法，其特征在于，所述在打印请求日志时，将缓存中的所述追踪码追加至所述请求日志中，包括：

将所述追踪码和所述识别码一并追加至所述请求日志中。

8.一种全业务追踪实现装置，其特征在于，应用于入口节点，包括：

请求获取模块：用于获取请求方发起的业务请求；

9.一种全业务追踪实现设备，其特征在于，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如权利要求1-7任意一项所述的全业务追踪实现方法。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如权利要求1-7任意一项所述的全业务追踪实现方法。