发明内容
本公开实施例至少提供一种链路追踪方法及装置。
第一方面,本公开实施例提供了一种链路追踪方法,包括:
响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合;
基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的;
基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。
一种可选的实施方式中,所述方法还包括:
对所述目标数据库进行监测,获取所述目标数据库中产生的与当前调用请求对应的数据更新日志;
基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,并基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新。
一种可选的实施方式中,所述数据更新日志为二进制日志binlog。
一种可选的实施方式中,所述基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,包括:
从所述多个业务场景分别对应的业务ID集合中查找所述数据更新日志中包含的业务ID;
若从任一业务ID集合中查找到所述数据更新日志中包含的任一业务ID,则将所述任一业务ID集合对应的业务场景作为所述数据更新日志对应的目标业务场景。
一种可选的实施方式中,所述基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,还包括:
若从所述多个业务ID集合中未找到所述数据更新日志中包含的任一业务ID,则建立对应的业务ID集合为空集的新的业务场景,并将建立的新的业务场景作为所述目标业务场景。
一种可选的实施方式中,所述基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新,包括:
基于所述目标业务ID集合中包含的业务ID,从所述数据更新日志中包含的业务ID中确定出至少一个新增业务ID;
将所述新增业务ID添加至所述目标业务ID集合中。
一种可选的实施方式中,所述基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志,包括:
从所述多个数据更新日志中查找具有所述目标业务ID集合中任一业务ID的数据更新日志,并将具有所述目标业务ID集合中任一业务ID的数据更新日志作为所述目标数据更新日志。
一种可选的实施方式中,所述基于所述目标数据更新日志,生成所述目标业务场景对应的业务链路信息,包括:
从所述目标业务场景下的至少一条目标数据更新日志中,获取至少一个调用请求对应的业务数据;
基于所述至少一个所述调用请求对应的业务数据,生成所述目标业务场景的业务链路信息。
一种可选的实施方式中,生成所述目标业务场景的业务链路信息之后,包括:
对比所述业务链路信息以及预设的标准业务链路信息,基于所述业务链路信息与所述标准业务链路信息之间的差异对所述目标业务场景进行问题定位,并展示问题定位结果。
一种可选的实施方式中,在响应所述链路信息查询请求之前,所述方法还包括:
基于所述链路信息查询请求中携带的用户标识,确定所述链路信息查询请求对应的目标用户;
在所述目标用户满足预设的查询条件时,响应所述链路信息查询请求。
一种可选的实施方式中,所述预设的查询条件包括以下至少一种:
所述目标用户针对所述目标业务场景的剩余查询次数大于预设阈值;所述目标用户的查询等级高于或等于所述目标业务场景对应的查询等级。
第二方面,本公开实施例还提供一种链路追踪装置,包括:
响应模块,用于响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合;
筛选模块,用于基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的;
生成模块,用于基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。
一种可选的实施方式中,所述装置还包括更新模块,用于:
对所述目标数据库进行监测,获取所述目标数据库中产生的与当前调用请求对应的数据更新日志;
基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,并基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新。
一种可选的实施方式中,所述数据更新日志为二进制日志binlog。
一种可选的实施方式中,所述更新模块在基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景时,具体用于:
从所述多个业务场景分别对应的业务ID集合中查找所述数据更新日志中包含的业务ID;
若从任一业务ID集合中查找到所述数据更新日志中包含的任一业务ID,则将所述任一业务ID集合对应的业务场景作为所述数据更新日志对应的目标业务场景。
一种可选的实施方式中,所述更新模块还用于:
若从所述多个业务ID集合中未找到所述数据更新日志中包含的任一业务ID,则建立对应的业务ID集合为空集的新的业务场景,并将建立的新的业务场景作为所述目标业务场景。
一种可选的实施方式中,所述更新模块在基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新时,具体用于:
基于所述目标业务ID集合中包含的业务ID,从所述数据更新日志中包含的业务ID中确定出至少一个新增业务ID;
将所述新增业务ID添加至所述目标业务ID集合中。
一种可选的实施方式中,所述筛选模块具体用于:
从所述多个数据更新日志中查找具有所述目标业务ID集合中任一业务ID的数据更新日志,并将具有所述目标业务ID集合中任一业务ID的数据更新日志作为所述目标数据更新日志。
一种可选的实施方式中,所述生成模块具体用于:
从所述目标业务场景下的至少一条目标数据更新日志中,获取至少一个调用请求对应的业务数据;
基于所述至少一个所述调用请求对应的业务数据,生成所述目标业务场景的业务链路信息。
一种可选的实施方式中,所述装置还包括定位模块,用于:
对比所述业务链路信息以及预设的标准业务链路信息,基于所述业务链路信息与所述标准业务链路信息之间的差异对所述目标业务场景进行问题定位,并展示问题定位结果。
一种可选的实施方式中,所述响应模块还用于:
基于所述链路信息查询请求中携带的用户标识,确定所述链路信息查询请求对应的目标用户;
在所述目标用户满足预设的查询条件时,响应所述链路信息查询请求。
一种可选的实施方式中,所述预设的查询条件包括以下至少一种:
所述目标用户针对所述目标业务场景的剩余查询次数大于预设阈值;所述目标用户的查询等级高于或等于所述目标业务场景对应的查询等级。
第三方面,本公开实施例还提供一种计算机设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当计算机设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
第四方面,本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
本公开实施例提供的链路追踪方法及装置,首先响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合;然后,基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的;最后,基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。这样,可以通过维护不同业务场景对应的业务ID集合,根据业务ID集合筛选出目标业务场景关联的目标数据更新日志,并基于目标数据更新日志生成目标业务场景对应的业务链路信息,信息覆盖面更广,且业务ID集合的存储空间占用较低,易于维护。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
经研究发现,在针对微服务架构的链路追踪方案中,通常是针对一次服务的链路追踪,只能得到包含所针对的服务的链路信息,然而,在进行微服务架构的问题定位时,针对一次服务的链路信息可能不足以进行问题定位,需要整个业务场景下所有的服务的链路信息。
基于上述研究,本公开提供了一种链路追踪方法,可以通过维护不同业务场景对应的业务ID集合,根据业务ID集合确定不属于同一服务,但属于同一业务场景的调用请求,并生成能够反映各个调用请求在业务场景下关系的业务链路信息。
针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案,都应该是发明人在本公开过程中对本公开做出的贡献。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
为便于对本实施例进行理解,首先对本公开实施例所公开的一种链路追踪方法进行详细介绍,本公开实施例所提供的链路最终方法的执行主体一般为具有一定计算能力的计算机设备,该计算机设备例如包括:终端设备或服务器或其它处理设备,其中,服务器可以是分布式服务器。
参见图1所示,为本公开实施例提供的链路追踪方法的流程图,所述方法包括步骤S101~S103,其中:
S101、响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合。
该步骤中,用户可以通过终端设备提交链路信息查询请求,链路信息查询请求中可以指示有业务场景,若指示的业务场景为目标业务场景,则可以从数据库中查询目标业务场景对应的目标业务ID集合。
其中,数据库可以为Elasticsearch、MongoDB等类型,数据库中可以包含多个业务ID集合,每个业务ID集合可以对应至少一个业务场景,业务ID集合中可以包括多个业务ID,且多个业务ID属于同一业务场景。
这里,业务ID集合中的业务ID能够随着微服务端口的调用请求的响应而更新,具体参见以下步骤:
对所述目标数据库进行监测,获取所述目标数据库中产生的与当前调用请求对应的数据更新日志;基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,并基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新。
该步骤中,目标数据库可以是微服务端口对应的数据库,微服务端口可以是微服务架构中的服务端口,一个服务端口可以对应一个调用请求,当用户在通过前端服务提交一个服务请求后,前端服务可以向对应的一个或多个微服务端口提交调用请求,微服务端口可以向前端服务返回调用结果,还可以向其他微服务端口提交调用请求,当一个微服务端口响应调用请求时,会对微服务端口对应的目标数据库中的数据进行修改,在目标数据库中的数据发生修改时,目标数据库可以生成一个数据更新日志,记载有发生变更的数据。
其中,数据更新日志可以为二进制日志binlog,binlog是记录所有数据库表结构变更以及表数据修改的二进制日志。
示例性的,数据更新日志可以为如下格式的日志:
{"database":"test","table":"order","type":"insert"…}
具体的,在目标数据库生成一个数据更新日志后,可以将数据更新日志按照时间顺序依次添加到一个队列中。队列是具有先进先出特性的线性表。
这里,在获取数据更新日志时,可以由分布式服务器的进行并行获取,同时获取多个子服务器的数据。
在获取到数据更新日志后,可以识别出数据更新日志中的业务ID,这里,业务ID可以是预设类型的数据,比如,对于付款业务来说,业务ID可以包括“request_id”、“merchant_id”、“parent_merchant_id”、“logid”、“channel_router_id”、“payer_user_id”等与付款业务相关的ID。
示例性的,若业务ID中包含类型“request_id”,且数据更新日志中存在“"request_id":"13"”这一字段,则“13”即为一个业务ID,其类型为“request_id”。
一种可选的实施例中,在识别出数据更新日志中包含的至少一个业务ID后,可以从所述多个业务场景分别对应的业务ID集合中查找所述数据更新日志中包含的业务ID;若从任一业务ID集合中查找到所述数据更新日志中包含的任一业务ID,则将所述任一业务ID集合对应的业务场景作为所述数据更新日志对应的目标业务场景。
其中,在一个业务场景的业务ID集合中,可以包括两个或两个以上的业务ID,业务ID的类型可以与业务ID一同储存,这里,为了避免出现类型名称相同的业务ID,可以将业务ID的类型名称转换为该类型对应的数据,示例性的,若一业务ID的类型名称为“order_id”,其数据值为“withdraw_trade”,由于该业务ID为交易类的业务ID,类型名称转换后可以为“trade_order_id”,业务ID集合中储存的数据可以为“order_id-trade_order_id-withdraw_trade”。
这里,若业务ID“A”与业务ID“B”同时出现在一个数据更新日志中,则可以说明这两个业务ID在当前的业务场景中是相互关联的,在此基础上,若其他数据更新日志中也包含了业务ID“A”或业务ID“B”,则可以确定这两个数据更新日志也是相互关联的,两者对应的调用请求属于同一业务场景中。
因此,若一数据更新日志中存在任一业务ID,能够在任一业务ID集合中被搜索到,则可以确定该数据更新日志对应的调用请求属于搜索到业务ID的业务ID集合对应的业务场景。
进一步的,若从所述多个业务ID集合中未找到所述数据更新日志中包含的任一业务ID,则建立对应的业务ID集合为空集的新的业务场景,并将建立的新的业务场景作为所述目标业务场景。
该步骤中,在将建立新的业务场景作为目标业务场景后,可以对新建立的业务ID集合进行更新,将数据更新日志中的业务ID储存进目标业务ID集合中。
一种可能的实施方式中,可以基于所述目标业务ID集合中包含的业务ID,从所述数据更新日志中包含的业务ID中确定出至少一个新增业务ID;将所述新增业务ID添加至所述目标业务ID集合中,以完成对目标业务ID集合的更新。
其中,新增业务ID可以是目标业务ID集合中不包含,但数据更新日志中包含的业务ID。在将新增业务ID添加至目标业务ID集合中时,可以先对新增业务ID进行数据转换,再将其储存至目标业务ID集合中。
这里,由于在没有接收到链路信息查询操作时,只储存有业务ID集合,能够节约大量的储存空间。
其中,业务场景可以是如“支付场景”、“登录场景”、“提现场景”等的场景。示例性的,“提现场景”可以包括“预下单”、“绑卡”、“下单”、“提现”、“回调”等服务。
S102、基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的。
该步骤中,可以确定目标业务ID集合中包含的各个目标业务ID,然后从多个数据更新日志中筛选出含有上述目标业务ID的数据更新日志作为目标数据更新日志。
具体的,可以从所述多个数据更新日志中查找具有所述目标业务ID集合中任一业务ID的数据更新日志,并将具有所述目标业务ID集合中任一业务ID的数据更新日志作为所述目标数据更新日志。
S103、基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。
一种可能的实施方式中,在获取到目标数据更新日志后,可以从所述目标业务场景下的至少一条目标数据更新日志中,获取至少一个调用请求对应的业务数据;基于所述至少一个所述调用请求对应的业务数据,生成所述目标业务场景的业务链路信息。
其中,业务数据可以为目标数据更新日志中记录的数据,根据获取到的业务数据,可以生成由多个服务组成的目标业务场景的业务链路信息。
进一步的,在生成所述目标业务场景的业务链路信息之后,该方法还可以包括:
对比所述业务链路信息以及预设的标准业务链路信息,基于所述业务链路信息与所述标准业务链路信息之间的差异对所述目标业务场景进行问题定位,并展示问题定位结果。
其中,标准业务链路信息可以是微服务端口正常响应调用请求的情况下生成的业务链路信息,可以将业务链路信息和标准业务链路信息进行对比,根据两者之间的差异,以及预设的问题定位规则,确定业务链路中哪个位置出现问题,从而完成问题的定位。
在问题定位后,可以将问题定位结果通过客户端展示给用户,以使用户查看问题定位结果。
进一步的,在响应链路信息查询请求之前,可以先基于所述链路信息查询请求中携带的用户标识,确定所述链路信息查询请求对应的目标用户;然后,在所述目标用户满足预设的查询条件时,响应所述链路信息查询请求。这样,仅在用户满足查询条件时才响应链路信息查询请求,能够保障后台渲染的安全。
这里,预设的查询条件可以包括以下至少一种:
所述目标用户针对所述目标业务场景的剩余查询次数大于预设阈值;所述目标用户的查询等级高于或等于所述目标业务场景对应的查询等级。
示例性的,由于支付业务场景中包含有支付服务、绑卡服务等多种服务,得到的业务链路信息中不光包含支付服务对应的链路信息,还包括有绑卡服务对应的链路信息,因此,在绑卡服务对应的链路出现问题时,也能够准确定位问题,适用性较广。
进一步的,由于本公开实施例提供的链路追踪方法不需要对系统层级的代码进行修改,可以直接通过插件来实现,不具有代码的侵入性,便于使用。
一种可能的实施方式中,以提现业务场景为例,提现业务场景通常包括预下单、绑卡、下单、提现、回调等链路,在用户进行提现业务时,终端设备可以按照预设的流程进行微服务端口的调用,若提现业务失败,可以将提现失败提示信息展示给用户,用户能够利用客户端查询提现业务场景的链路信息,终端设备在接收到针对提现业务场景的链路信息查询请求后,可以从数据库中查找提现业务场景对应的目标业务ID集合,然后获取目标业务ID集合中的各个目标业务ID,之后,从各个目标业务ID对应的数据库中获取含有目标业务ID的目标数据更新日志binlog,将其存储至队列中,可以利用kafka分布式日志系统消费目标数据更新日志,生成业务链路信息,通过应用程序接口(Application ProgrammingInterface,API)将业务链路信息展示给用户,用户可以根据业务链路信息对业务场景中各个环节进行排查,由于目标业务ID集合中包含的业务ID存在于多条链路的数据更新日志中,根据业务ID获取到的数据更新日志则涵盖有多条链路,形成提现的业务场景,从而使获取到的业务链路信息更全面。
进一步的,终端设备可以根据预设的标准业务链路信息及展示给用户的业务链路信息进行问题定位,可以对比业务链路信息及标准业务链路信息,并根据两者之间的差异及预设的差异评价规则,确定各个差异是否为出现问题环节,得到问题定位结果,并通过终端设备将问题定位结果展示给用户,供用户参考。
本公开实施例提供的链路追踪方法,首先响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合;然后,基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的;最后,基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。这样,可以通过维护不同业务场景对应的业务ID集合,根据业务ID集合筛选出目标业务场景关联的目标数据更新日志,并基于目标数据更新日志生成目标业务场景对应的业务链路信息,信息覆盖面更广,且业务ID集合的存储空间占用较低,易于维护。
参见图2所示,为本公开实施例提供的一种链路追踪系统的示意图。该链路追踪系统包括微服务端口对应的数据库DB、储存数据更新日志binlog的队列Queue、服务器Service、储存业务ID集合的数据库ES以及查询接口API。当数据库DB发生数据更新时,会产生binlog,并将binlog发送至队列Queue中,服务器读取队列中的binlog,将binlog消费,确定binlog对应的目标业务场景,并对ES中的目标业务ID集合进行更新,当检测到针对目标业务场景的链路信息查询操作时,基于目标业务ID集合获取目标数据更新日志,并生成目标业务场景对应的业务链路信息,最后通过API将业务链路信息展示给用户。
本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思,本公开实施例中还提供了与链路追踪方法对应的链路追踪装置,由于本公开实施例中的装置解决问题的原理与本公开实施例上述链路追踪方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
参照图3所示,为本公开实施例提供的一种链路追踪装置的架构示意图,所述链路追踪装置300包括:
响应模块310,用于响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合;
筛选模块320,用于基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的;
生成模块330,用于基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。
一种可选的实施方式中,所述装置还包括更新模块,用于:
对所述目标数据库进行监测,获取所述目标数据库中产生的与当前调用请求对应的数据更新日志;
基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,并基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新。
一种可选的实施方式中,所述数据更新日志为二进制日志binlog。
一种可选的实施方式中,所述更新模块在基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景时,具体用于:
从所述多个业务场景分别对应的业务ID集合中查找所述数据更新日志中包含的业务ID;
若从任一业务ID集合中查找到所述数据更新日志中包含的任一业务ID,则将所述任一业务ID集合对应的业务场景作为所述数据更新日志对应的目标业务场景。
一种可选的实施方式中,所述更新模块还用于:
若从所述多个业务ID集合中未找到所述数据更新日志中包含的任一业务ID,则建立对应的业务ID集合为空集的新的业务场景,并将建立的新的业务场景作为所述目标业务场景。
一种可选的实施方式中,所述更新模块在基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新时,具体用于:
基于所述目标业务ID集合中包含的业务ID,从所述数据更新日志中包含的业务ID中确定出至少一个新增业务ID;
将所述新增业务ID添加至所述目标业务ID集合中。
一种可选的实施方式中,所述筛选模块320具体用于:
从所述多个数据更新日志中查找具有所述目标业务ID集合中任一业务ID的数据更新日志,并将具有所述目标业务ID集合中任一业务ID的数据更新日志作为所述目标数据更新日志。
一种可选的实施方式中,所述生成模块330具体用于:
从所述目标业务场景下的至少一条目标数据更新日志中,获取至少一个调用请求对应的业务数据;
基于所述至少一个所述调用请求对应的业务数据,生成所述目标业务场景的业务链路信息。
一种可选的实施方式中,所述装置还包括定位模块,用于:
对比所述业务链路信息以及预设的标准业务链路信息,基于所述业务链路信息与所述标准业务链路信息之间的差异对所述目标业务场景进行问题定位,并展示问题定位结果。
一种可选的实施方式中,所述响应模块310还用于:
基于所述链路信息查询请求中携带的用户标识,确定所述链路信息查询请求对应的目标用户;
在所述目标用户满足预设的查询条件时,响应所述链路信息查询请求。
一种可选的实施方式中,所述预设的查询条件包括以下至少一种:
所述目标用户针对所述目标业务场景的剩余查询次数大于预设阈值;所述目标用户的查询等级高于或等于所述目标业务场景对应的查询等级。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
基于同一技术构思,本公开实施例还提供了一种计算机设备。参照图4所示,为本公开实施例提供的计算机设备400的结构示意图,包括处理器401、存储器402、和总线403。其中,存储器402用于存储执行指令,包括内存4021和外部存储器4022;这里的内存4021也称内存储器,用于暂时存放处理器401中的运算数据,以及与硬盘等外部存储器4022交换的数据,处理器401通过内存4021与外部存储器4022进行数据交换,当计算机设备400运行时,处理器401与存储器402之间通过总线403通信,使得处理器401在执行以下指令:
响应针对目标业务场景的链路信息查询请求,确定所述目标业务场景对应的目标业务ID集合;
基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志;其中,数据更新日志为目标业务场景下多个微服务端口对应的目标数据库在响应调用请求时生成的;
基于所述目标数据更新日志,生成并展示所述目标业务场景对应的业务链路信息。
一种可选的实施方式中,所述处理器401还用于执行:
对所述目标数据库进行监测,获取所述目标数据库中产生的与当前调用请求对应的数据更新日志;
基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,并基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新。
一种可选的实施方式中,所述数据更新日志为二进制日志binlog。
一种可选的实施方式中,所述处理器401执行的指令中,所述基于所述数据更新日志中包含的至少一个业务ID,以及多个业务场景分别对应的业务ID集合,确定所述数据更新日志对应的目标业务场景,包括:
从所述多个业务场景分别对应的业务ID集合中查找所述数据更新日志中包含的业务ID;
若从任一业务ID集合中查找到所述数据更新日志中包含的任一业务ID,则将所述任一业务ID集合对应的业务场景作为所述数据更新日志对应的目标业务场景。
一种可选的实施方式中,所述处理器401还用于执行:
若从所述多个业务ID集合中未找到所述数据更新日志中包含的任一业务ID,则建立对应的业务ID集合为空集的新的业务场景,并将建立的新的业务场景作为所述目标业务场景。
一种可选的实施方式中,所述处理器401执行的指令中,所述基于所述至少一个业务ID对所述目标业务场景对应的目标业务ID集合进行更新,包括:
基于所述目标业务ID集合中包含的业务ID,从所述数据更新日志中包含的业务ID中确定出至少一个新增业务ID;
将所述新增业务ID添加至所述目标业务ID集合中。
一种可选的实施方式中,所述处理器401执行的指令中,所述基于所述目标业务ID集合中包含的目标业务ID,从多个数据更新日志中筛选出所述目标业务场景关联的目标数据更新日志,包括:
从所述多个数据更新日志中查找具有所述目标业务ID集合中任一业务ID的数据更新日志,并将具有所述目标业务ID集合中任一业务ID的数据更新日志作为所述目标数据更新日志。
一种可选的实施方式中,所述处理器401执行的指令中,所述基于所述目标数据更新日志,生成所述目标业务场景对应的业务链路信息,包括:
从所述目标业务场景下的至少一条目标数据更新日志中,获取至少一个调用请求对应的业务数据;
基于所述至少一个所述调用请求对应的业务数据,生成所述目标业务场景的业务链路信息。
一种可选的实施方式中,所述处理器401在生成所述目标业务场景的业务链路信息之后,还用于执行:
对比所述业务链路信息以及预设的标准业务链路信息,基于所述业务链路信息与所述标准业务链路信息之间的差异对所述目标业务场景进行问题定位,并展示问题定位结果。
一种可选的实施方式中,所述处理器401在响应所述链路信息查询请求之前,还用于执行:
基于所述链路信息查询请求中携带的用户标识,确定所述链路信息查询请求对应的目标用户;
在所述目标用户满足预设的查询条件时,响应所述链路信息查询请求。
一种可选的实施方式中,所述预设的查询条件包括以下至少一种:
所述目标用户针对所述目标业务场景的剩余查询次数大于预设阈值;所述目标用户的查询等级高于或等于所述目标业务场景对应的查询等级。
本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的链路追踪方法的步骤。其中,该存储介质可以是易失性或非易失的计算机可读取存储介质。
本公开实施例所提供的链路追踪方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行上述方法实施例中所述的链路追踪方法的步骤,具体可参见上述方法实施例,在此不再赘述。
本公开实施例还提供一种计算机程序,该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software DevelopmentKit,SDK)等等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。