CN114745295A - 数据采集方法、装置、设备和可读存储介质 - Google Patents

数据采集方法、装置、设备和可读存储介质 Download PDF

Info

Publication number
CN114745295A
CN114745295A CN202210408515.XA CN202210408515A CN114745295A CN 114745295 A CN114745295 A CN 114745295A CN 202210408515 A CN202210408515 A CN 202210408515A CN 114745295 A CN114745295 A CN 114745295A
Authority
CN
China
Prior art keywords
service
micro
link
target request
calling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210408515.XA
Other languages
English (en)
Other versions
CN114745295B (zh
Inventor
刘启翔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jingdong Technology Holding Co Ltd
Original Assignee
Jingdong Technology Holding Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jingdong Technology Holding Co Ltd filed Critical Jingdong Technology Holding Co Ltd
Priority to CN202210408515.XA priority Critical patent/CN114745295B/zh
Publication of CN114745295A publication Critical patent/CN114745295A/zh
Application granted granted Critical
Publication of CN114745295B publication Critical patent/CN114745295B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/04Processing captured monitoring data, e.g. for logfile generation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/069Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Computer And Data Communications (AREA)
  • Exchange Systems With Centralized Control (AREA)

Abstract

本申请提供一种数据采集方法、装置、设备和可读存储介质,涉及金融科技技术领域,该方法包括:获取业务系统在处理目标请求时目标请求所调用的微服务,根据目标请求所调用的至少一个微服务,构建服务调用链路,根据服务调用链路进行数据采集,获取链路数据。该技术方案中,通过对目标请求所调用的微服务进行跟踪,确定目标请求的服务调用链路以获取链路数据,能够根据链路数据来实现故障定位,避免使用日志的方式进行故障定位,提高故障定位效率以快速解决故障。

Description

数据采集方法、装置、设备和可读存储介质
技术领域
本申请涉及互联网技术领域,尤其涉及一种数据采集方法、装置、设备和可读存储介质。
背景技术
随着互联网技术的发展,基于微服务架构设计的系统得到广泛运用,微服务架构是把一个大型的单个应用程序和服务拆分为数个或数十个的微服务,旨在将系统功能分离到各个离散的服务当中,降低系统的耦合性并提供更加灵活的服务支持。
现有技术中,基于微服务架构的系统在出现故障问题时,通常是通过调用日志方式来实现问题定位和解决。
但是,由于各个服务按照不同的维度和定位进行拆分且多节点多机房部署,一次请求往往涉及到调用多个部署在不同机房的服务,现有技术的这种通过日志来来故障定位方式,日志获取困难,不能实现快速问题定位和故障影响范围的判断,导致故障排查效率低。
发明内容
本申请提供一种数据采集方法、装置、设备和可读存储介质,用于解决现有的通过日志数据定位基于微服务架构的业务系统的故障,故障排查效率低的问题。
第一方面,本申请实施例提供一种数据采集方法,应用于基于微服务架构的业务系统,所述业务系统包括有至少一个微服务,所述方法包括:
获取所述业务系统在处理目标请求时所述目标请求所调用的微服务,所述目标请求可调用至少一个微服务;
根据所述目标请求所调用的所述至少一个微服务,构建服务调用链路;
根据所述服务调用链路进行数据采集,获取链路数据,所述链路数据用于所述业务系统的故障定位,所述链路数据至少包括有所述服务调用链路的上下文信息、链路标识、调用开始时间和耗时、调用方网络协议地址和端口中的至少一种。
在第一方面的一种可能设计中,所述根据所述服务调用链路进行数据采集,获取链路数据,包括:
根据各个微服务中的埋点组件获取所述链路数据,每个微服务包括有至少一个埋点组件,所述埋点组件用于进行链路数据的采集。
在第一方面的另一种可能设计中,若所述目标请求调用至少两个微服务,所述根据所述目标请求所调用的至少一个微服务,构建服务调用链路,包括:
获取所述目标请求所调用的各个微服务之间的调用先后顺序;
根据所述目标请求所调用的各个微服务和所述调用先后顺序,构建所述服务调用链路。
在第一方面的再一种可能设计中,所述获取所述目标请求所调用的各个微服务之间的调用先后顺序,包括:
在所述目标请求调用当前微服务时,获取所述当前微服务的标识信息;
在所述目标请求完成所述当前微服务的调用并继续调用下一微服务时,将所述当前微服务的标识信息传输至下一微服务以进行记录;
在目标请求完成各个微服务的调用时,根据各个微服务记录的标识信息,确定各个微服务之间的调用先后顺序。
在第一方面的又一种可能设计中,所述方法还包括:
获取全局标识,在所述目标请求调用当前微服务时,将所述全局标识传输至当前微服务以进行记录,所述全局标识用于对所述目标请求进行标识;
在所述目标请求调用下一微服务时,将所述全局标识传输至所述下一微服务以进行记录;
根据各个微服务中记录的全局标识,确定所述目标请求所调用的微服务。
在第一方面的又一种可能设计中,所述获取全局标识,包括:
获取所述目标请求的请求时间戳和所述当前微服务的网络协议地址;
根据所述请求时间戳和所述当前微服务的网络协议地址,生成所述全局标识。
在第一方面的又一种可能设计中,所述方法还包括:
当所述业务系统发出故障提示时,根据所述链路数据进行故障排查,得到排查结果,所述排查结果用于指示所述业务系统发生故障的位置。
在第一方面的又一种可能设计中,所述方法还包括:
响应于所述业务系统中预设开关的开启或关闭,控制各个微服务中的埋点组件的启动或停止,所述埋点组件用于进行链路数据的收集。
在第一方面的又一种可能设计中,所述方法还包括:
获取所述业务系统中预设的白名单路径,所述白名单路径用于指示埋点组件进行数据采集,所述微服务中包括有埋点组件,所述埋点组件用于进行数据采集;
根据所述埋点组件在所述白名单路径中采集得到的数据,获取所述链路数据。
在第一方面的又一种可能设计中,所述方法还包括:
根据所述服务调用链路,获取各个微服务之间的拓扑关系;
根据所述拓扑关系,构建所述业务系统的服务框架,所述服务框架用于指示所述业务系统所包含的微服务以及各个微服务的关联关系。
在第一方面的又一种可能设计中,所述方法还包括:
根据消息队列机制,将所述服务调用链路异步发送存储至预设数据库中。
第二方面,本申请实施例提供一种数据采集装置,包括:
服务获取模块,用于获取业务系统在处理目标请求时所述目标请求所调用的微服务,所述目标请求可调用至少一个微服务;
链路构建模块,用于根据所述目标请求所调用的所述至少一个微服务,构建服务调用链路;
数据获取模块,用于根据所述服务调用链路进行数据采集,获取链路数据,所述链路数据至少包括有所述服务调用链路的上下文信息、链路标识、调用开始时间和耗时、调用方网络协议地址和端口中的至少一种。
第三方面,本申请实施例提供一种电子设备,包括:处理器,以及与所述处理器通信连接的存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,以实现上述的方法。
第四方面,本申请实施例提供一种可读存储介质,所述可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现上述的方法。
第五方面,本申请实施例提供一种程序产品,包括计算机指令,该计算机指令被处理器执行时实现上述的方法。
本申请实施例提供的数据采集方法、装置、设备和可读存储介质,通过对目标请求所调用的微服务进行跟踪,确定目标请求的服务调用链路以获取链路数据,能够根据链路数据来实现故障定位,避免使用日志的方式进行故障定位,提高故障定位效率以快速解决故障。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理;
图1为本申请实施例提供的数据采集方法的场景示意图;
图2为本申请实施例提供的数据采集方法的流程示意图;
图3为本申请实施例通过的业务系统的服务调用链路的示意图;
图4为本申请实施例提供的数据采集的过程示意图;
图5为本申请实施例提供的数据收集装置的结构示意图;
图6为本申请实施例提供的电子设备的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
首先对本申请所涉及的名词进行解释:
微服务:是指一种软件开发技术-面向服务的体系结构架构样式的一种变体,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建,并且能够独立地部署到生产环境、类生产环境等。
图1为本申请实施例提供的数据采集方法的场景示意图,基于微服务架构的业务系统包括有多个微服务,微服务按照不同的维度和定位进行拆分,互相组合和依赖,如图1所示,各个微服务可以由不同团队开发并部署在不同区域(例如不同城市)的机房服务器内,微服务与微服务之间采用通信机制互相沟通(例如超文本协议(HTTP)的表示性状态转移(Representation State Transfer,REST)应用程序接口(Application ProgrammingInterface,API))。
在实际生活应用中,在用户从终端设备(例如计算机设备或移动终端)的客户端发起请求时,该请求可能会调用多个微服务例如微服务A、微服务B和微服务C,通常业务系统往往有数量众多的微服务并且这些微服务可能部署在不同区域的机房中。当业务系统发生故障时,由于一个请求可能需要调用很多个服务,而服务的调用复杂性导致了故障很难去定位,现有技术通常是通过查看日志来进行故障定位和解决。这种方式由于微服务由不同团队开发并部署在不同区域的机房中,通常日志获取较为困难,即使获取到了日志,由于服务之间存在的复杂调用关系,也没有办法快速发现问题,不能判断系统发生故障产生的影响范围,不支持梳理微服务调用关系以及多模块间依赖的合理性。
针对上述问题,本申请实施例提供了一种数据采集方法、装置、设备和可读存储介质,通过跟踪微服务调用链路,将所有跨应用的所有调用链进行信息服务端埋点手机,可以得到调用链路的上下文信息、链路ID、调用开始时间、调用方IP、端口、调用耗时等,可适配任何系统度量整体和依赖关系,根据收集的信息进行统计分析,方便找到故障产生的源头,生产上可极大缩短故障排除时间,也可进一步对系统的升级优化进行全方位的检查等。
下面,通过具体实施例对本申请的技术方案进行详细说明。需要说明的是,下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图2为本申请实施例提供的数据采集方法的流程示意图,该方法具体可以应用于基于微服务架构的业务系统,该业务系统包括有至少一个微服务。
如图2所示,该方法具体可以包括如下步骤:
S201、获取业务系统在处理目标请求时目标请求所调用的至少一个微服务。
示例性的,业务系统可以是资产证券化(Asset-backed Securities,ABS)系统,其包括的微服务可以有数据处理服务、ABS资产服务、业务流程服务、基础配置服务、报表服务和调度服务等。各个微服务之间可能存在有关联依赖关系,例如ABS资产服务与数据处理服务之间存在依赖关系。其中,用户可以通过客户端发起目标请求,例如资产查询请求,业务系统基于用户发起的目标请求,确定所需调用的微服务有哪些,然后通过各个微服务对目标请求进行处理,得到最终数据反馈给用户。业务系统作为后台服务系统,可以部署在各个机房的服务器中以获取不同用户发起的请求并进行处理。
在本实施例中,当目标请求调用的微服务的数量为两个以上时,则存在有调用先后顺序,示例性的,目标请求会先发送至微服务A以进行处理,在微服务A完成请求处理之后,再将请求传送给微服务B以继续进行处理,在微服务B完成请求处理之后,可以再将请求继续传送给微服务C,由此类推,直到完成整个目标请求的处理。例如一个用户发起的请求可能会先达到前端A,然后通过远程调用达到业务系统的中间件B和C(例如负载均衡、网关),最后达到后端服务D和E,后端服务通过一系列逻辑计算最终将数据返回给用户,这个过程中用户的请求就会涉及到非常多的微服务的调用。
S202、根据目标请求所调用的至少一个微服务,构建服务调用链路。
示例性的,不同的请求所调用的微服务可能不同,例如当目标请求为查阅资产数据请求时,则其需要调用的微服务有ABS资产服务和数据处理服务。其中,ABS资产服务与数据处理服务之间可以通过API建立通信关系以实现对目标请求的处理。
在本实施例中,服务调用链路指示出了目标请求所调用的微服务以及所调用的各个微服务之间的先后顺序,通过所调用的微服务以及各个服务之间的先后顺序,即可以构建得到服务调用链路。示例性的,例如该目标请求先通过微服务A处理,在微服务A处理完之后再流转到微服务B处理,微服务B处理完之后又流转到微服务C,直到整个目标请求处理完成,得到最终的数据返回给用户,则构建得到的服务调用链路可以为A-B-C。示例性的,图3为本申请实施例通过的业务系统的服务调用链路的示意图,如图3所示,以资产证券化系统作为业务系统为例,其可以包括有数据处理服务smart、资产服务smart、业务流程服务smart、基础配置服务smart、报表服务smart和调度服务smart。其中,数据处理服务smart可以与资产服务smart之间可以进行通信以进行数据处理,资产服务smart、业务流程服务smart、调度服务smart和报表服务smart均可以与基础配置服务smart通信以获取基础配置,调度服务smart可以异步调用资产服务smart和业务流程服务smart。进一步的,ABS系统之外还可以包括视图服务,视图服务可以从资产服务smart和基础配置服务smart获取展示数据。
S203、根据服务调用链路进行数据采集,获取链路数据。
其中,链路数据用于业务系统的故障定位。链路数据至少包括有服务调用链路的上下文信息、链路标识、调用开始时间和耗时、调用方网络协议地址和端口中的至少一种。其中,上下文信息是调用过程中附带的环境信息,如方法名、参数类型、真实参数、本端/对端地址等。链路标识可以是用于标识服务调用链路,调用方网络协议地址即调用方IP。
在本实施例中,通过链路数据可以度量业务系统整体和依赖关系,当业务系统发生故障时,通过统计分析链路数据即可以找到故障产生的源头,可极大缩短故障排除时间,也可进一步对系统的升级优化进行全方位的检查等。
示例性的,可以通过前端界面功能根据链路标识ID,可实时查询发生错误的服务调用链路,然后根据发生错误的服务调用链路中所包含的微服务,定位出故障处于哪一个节点。
其中,链路数据可以通过埋点的方式采集得到,即在业务系统的各个微服务中植入埋点组件以实现数据的采集。其中,埋点又称为事件追踪,指的是针对特定用户行为或事件进行捕获,处理和发送的相关技术及其实施过程。示例性的,继续参考图3,可以在各个数据处理服务中植入数据收集装置服务smart作为埋点组件以实现数据的采集。
本申请实施例通过进行服务链路跟踪,将所有跨应用的所有调用链进行信息服务端埋点实现链路数据的收集,得到调用链路的上下文信息、链路ID、调用开始时间、调用方IP、端口、调用耗时等,可适配任何系统度量整体和依赖关系,根据收集的信息进行统计分析,在业务系统发生故障时方便找到故障产生的源头,生产上可极大缩短故障排除时间,也可进一步对业务系统的升级优化进行全方位的检查等。
在一些实施例中,上述步骤S201具体可以通过如下步骤实现:
根据各个微服务中的埋点组件获取链路数据。
其中,每个微服务包括有至少一个埋点组件,埋点组件用于进行链路数据的采集。埋点组件可以简单理解为一段程序代码,业务系统的各个微服务中均可以植入埋点组件以实现链路数据的获取。
在本实施例中,收集链路数据的埋点组件可以基于底层框架实现无侵入式部署于微服务中,并将微服务所涉及的业务逻辑和性能测量完全分离,植入的埋点组件可以收集到任意类和任意方法的执行时间、调用过程等。示例性的,在植入埋点组件至微服务时,实现的程序通过底层代码自动捕捉需要埋点的代码,无需修改业务系统其它代码即可以实现链路数据的收集。
本申请实施例通过在微服务中埋点以进行链路数据的埋点采集,能够基于底层框架实现无侵入式部署,将数据收集与微服务的业务逻辑完全分离,能够准确高效的获取到链路数据并进行上报,避免使用日志来进行信息记录,降低了数据的获取难度和所花费的时间,当业务系统出现故障时,可以直接根据上报的链路数据实现故障排查,提高故障排查的效率。
示例性的,在一些实施例中,目标请求可以调用一个或两个以上的微服务,其中,当目标请求调用的微服务为一个时,则服务调用链路中只包含有该被调用的微服务,而不包含微服务之间的调用关系。
进一步的,在一些实施例中,当目标请求调用的微服务为两个以上时,上述步骤S202具体可以通过如下步骤实现:
获取目标请求所调用的各个微服务之间的调用先后顺序;
根据目标请求所调用的各个微服务和调用先后顺序,构建服务调用链路。
在本实施例中,当目标请求调用的微服务为两个以上时,各个微服务之间存在有参与调用的先后顺序(即调用先后顺序),例如微服务A先参与对目标请求的处理,当微服务A完成处理之后再传送该目标请求给微服务B,由微服务B继续进行处理。此时,微服务A先被调用,而微服务B后被调用。
示例性的,在目标请求的处理过程中,可以通过服务链路追踪确定所调用的微服务的先后顺序。
本申请实施例通过进行服务链路跟踪,构建服务调用链路,可以从系统整体维度到局部维度展示各项指标,收集出应用服务的拓扑关系,方便快速搞清楚应用架构,在业务系统出现故障时能够结合服务调用链路快速的实现问题的定位,提高故障排查效率。
进一步的,在一些实施例中,上述“获取目标请求所调用的各个微服务之间的调用先后顺序”具体可以通过如下步骤实现:
在目标请求调用当前微服务时,获取当前微服务的标识信息;
在目标请求完成当前微服务的调用并继续调用下一微服务时,将当前微服务的标识信息传输至下一微服务以进行记录;
在目标请求完成各个微服务的调用时,根据各个微服务记录的标识信息,确定各个微服务之间的调用先后顺序。
在本实施例中,标识信息可以用span_id表示,span_id可以是一个64位ID唯一标识,即不同的微服务的标识信息不相同,span_id用于记录调用父子关系,当一次请求在各个微服务之间流转时,上一个微服务的span_id会透传至下一个微服务,每一个微服务会记录上一个微服务的span_id和自己的span_id,在目标请求完成整个处理流程之后,可以直接根据各个微服务记录下的span_pid确定出目标请求所调用的微服务和各个微服务的调用先后顺序。
本申请实施例通过记录标识信息,当目标请求在各个微服务之间流转时,能够基于标识信息确定出目标请求调用的微服务以及各个微服务之间的调用父子关系,得到完整的服务调用链路,方便后续使用服务调用链路来进行故障的排查。
进一步的,在一些实施例中,在确定目标请求所调用的微服务时,上述方法还可以包括如下步骤:
获取全局标识,在目标请求调用当前微服务时,将全局标识传输至当前微服务以进行记录;
在目标请求调用下一微服务时,将全局标识传输至下一微服务以进行记录;
根据各个微服务中记录的全局标识,确定目标请求所调用的微服务。
其中,全局标识用于对目标请求进行标识。
在本实施例中,全局标识可以通过trace_id表示,每一个请求在开始调用微服务时会生成一个全局的trace_id,当请求在各个微服务之间流转时,该trace_id也会被微服务中的埋点组件采集到,最后通过trace_id串联起整个服务调用链路。其中,每一个请求都必须透传trace_id和span_id进行上下文传输。在查看某一次完整的调用时,只需要根据trace_id即可查出所有调用记录,包括该请求所调用的微服务,然后通过span_id组织起调用父子关系即可。
其中,不同的请求所生成的trace_id不相同。示例性的,trace_id可以为64位bit。
本申请实施例通过设置唯一全局标识对服务调用链路进行标识,当业务系统出现故障时,只需要根据唯一全局标识即可实时查询到发生故障的服务调用链路,实现故障的快速定位。
进一步的,在一些实施例中,上述步骤“获取全局标识”具体可以通过如下步骤实现:
获取目标请求的请求时间戳和当前微服务的网络协议地址;
根据请求时间戳和当前微服务的网络协议地址,生成全局标识。
在本实施例中,可以采用雪花算法64位bit作为trace_id。trace_id可以通过当前的请求时间以及当前微服务的IP地址拼装得到,示例性的,在一些实施方式中,在同一个机房同一毫秒内,若存在有多个请求,则在生成每一个请求的唯一trace_id时,可以根据每个请求的序号、请求时间戳以及当前微服务的IP进行拼装得到唯一trace_id。其中,当trace_id为64位bit时,请求的序号作为最后12个bit。
本申请实施例通过利用时间戳以及IP来拼装得到全局标识,保证全局标识的唯一性,即使是在同一毫秒内存在多个请求,也可以基于请求的序号拼装得到唯一全局标识,保证不同请求的服务调用链路的全局标识不相同,避免不同服务调用链路之间发生混淆,当业务系统出现故障时,能够快速找到发生故障的服务调用链路。
在一些实施例中,上述方法还包括如下步骤:
当业务系统发出故障提示时,根据链路数据进行故障排查,得到排查结果。
其中,排查结果用于指示业务系统发生故障的位置。在本实施例中,不同的目标请求的trace_id(即全局标识)是不同的,而不同的目标请求有不同的服务调用链路,当业务系统出现故障时,可以直接根据trace_id来找到发生错误的服务调用链路,从服务调用链路中定位出发生异常的节点,实现对故障的排查。
本申请实施例通过使用链路数据进行故障排查,在业务系统出现故障时,可以实时查询发生故障的服务调用链路,定位服务调用链路中的异常节点,实现故障的快速排查定位。
在一些实施例中,上述方法还可以包括如下步骤:
响应于业务系统中预设开关的开启或关闭,控制各个微服务中的埋点组件的启动或停止。
其中,埋点组件用于进行链路数据的收集。在本实施例中,可以通过微服务程序的配置开关来控制埋点组件的启动或关闭,当开关开启时,则埋点组件启动,实现链路数据的采集,当开关关闭时,则埋点组件关闭,不进行链路数据的采集。通过设置动态开关,可以实现链路数据采集服务的可插拔式控制,实现链路数据的灵活采集。
示例性的,在一些实施例中,可以通过守护线程进行监听服务链路调用的日志收集并进行异步消息的发送,其中守护线程是指在程序运行的时候在后台提供一种通用服务的线程。
在一些实施例中,上述方法还可以包括如下步骤:
获取业务系统中预设的白名单路径;
根据埋点组件在白名单路径中采集得到的数据,获取链路数据。
其中,白名单路径用于指示埋点组件进行数据采集,微服务中包括有埋点组件,埋点组件用于进行数据采集。
在本实施例中,埋点组件在进行链路数据的采集时,只采集白名单路径目录中的数据,比如com.aaa.xxx。示例性的,可以在业务系统中预先自定义配置白名单路径和黑名单路径,实现黑名单路径和白名单路径的过滤,对白名单路径进行分类拦截,具体可以包括远程调用、消息队列和异步任务等。
示例性的,对于远程调用的白名单路径,可以实现生产者与消费者的区分,对于生产者如有多层循环链路进行深层次的追踪和记录的保存。其中,深层即多层的链路调用,每一次超文本传输协议(Hyper Text Transfer Protocol,HTTP)或远程过程调用(RemoteProcedure Call,RPC)接口的调用,异步消息队列都可以进行链路数据的收集。其中,生产者为微服务的被调用方,即为其他微服务提供服务的微服务,消费者为微服务的调用方,即依赖其他微服务的微服务。
本申请实施例通过设置白名单路径,可以支持客户端自定义选择想要收集哪些目录的埋点信息,即只采集白名单路径的目录下的埋点信息,实现数据针对性采集。
在一些实施例中,上述方法还可以包括如下步骤:
根据服务调用链路,获取各个微服务之间的拓扑关系;
根据拓扑关系,构建业务系统的服务框架。
其中,服务框架用于指示业务系统所包含的微服务以及各个微服务的关联关系。
在本实施例中,在请求调用微服务完成后,可以获取到每一个请求的服务调用链路,通过每一个请求的服务调用链路,即可以梳理得到各个微服务之间的拓扑关系。示例性的,可以参见上述图3,以ABS业务系统包含有数据处理服务smart、资产服务smart、业务流程服务smart、基础配置服务smart、调度服务smart和报表服务smart为例,通过梳理各个微服务之间的拓扑关系,即可以得到整个ABS业务系统的服务架构。
本申请实施例通过服务调用链路获取各个微服务之间的拓扑关系和服务框架,在排查业务系统的故障时,可以通过各个微服务之间的拓扑关系和服务框架,快速梳理服务调用关系,判断出业务系统故障发生的影响范围。同时也方便统计业务系统的吞吐量、相应时间和错误记录等。
在一些实施例中,上述方法还可以包括如下步骤:
根据消息队列机制,将服务调用链路异步发送存储至预设数据库中。
在本实施例中,预设数据库可以是MySQL关系型数据库,其可以通过功能实现提供接口。示例性的,可以通过接口来获取预设数据库中存储的服务调用链路,并在可视化的界面上进行显示。本申请实施例通过消息队列机制异步存储服务调用链路,能够达到不影响业务系统解耦操作,避免影响业务系统的正常运行。
图4为本申请实施例提供的数据采集的过程示意图,如图4所示,微服务通常被部署在服务器中并通过容器实现隔离。微服务包括有应用程序、服务端配置和网关等,应用程序进行包的依赖引入以实现埋点,通过服务端配置中的开关配置可以启动埋点数据采集服务,收集白名单路径的目录下的相关埋点指标数据得到链路数据,异步发送至数据库存储,在链路数据上报时可以通过链路标识span_id来确定微服务的父子调用关系,并通过唯一全局标识trace_id来对整个服务调用链路进行标识,然后通过日志服务将链路数据转发至追踪控制台,追踪控制台通过代码实现展示出来链路关系和指标并进行拓扑分析,界面产品化大屏可以实现链路关系的可视化,实现对业务系统的故障排查定位。其中,唯一全局标识trace_id可以通过雪花算法生成得到。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
图5为本申请实施例提供的数据收集装置的结构示意图,该数据采集装置可以集成在服务器中的微服务中,如图5所示,该数据采集装置50可以包括服务获取模块51、链路构建模块52、数据获取模块53。
其中,服务获取模块51用于获取业务系统在处理目标请求时目标请求所调用的微服务。链路构建模块52用于根据目标请求所调用的至少一个微服务,构建服务调用链路。数据获取模块53用于根据服务调用链路进行数据采集,获取链路数据。
其中,目标请求可调用至少一个微服务,链路数据至少包括有服务调用链路的上下文信息、链路标识、调用开始时间和耗时、调用方网络协议地址和端口中的至少一种。
在一些实施例中,上述数据获取模块具体可以用于根据各个微服务中的埋点组件获取链路数据。
其中,每个微服务包括有至少一个埋点组件,埋点组件用于进行链路数据的采集。
在一些实施例中,若目标请求调用至少两个微服务,则上述链路构建模块具体可以用于:
获取目标请求所调用的各个微服务之间的调用先后顺序;
根据目标请求所调用的各个微服务和调用先后顺序,构建服务调用链路。
可选的,在一些实施例中,上述链路构建模块具体可以用于:
在目标请求调用当前微服务时,获取当前微服务的标识信息;
在目标请求完成当前微服务的调用并继续调用下一微服务时,将当前微服务的标识信息传输至下一微服务以进行记录;
在目标请求完成各个微服务的调用时,根据各个微服务记录的标识信息,确定各个微服务之间的调用先后顺序。
可选的,在一些实施例中,上述数据采集装置还可以包括全局标识模块,用于:
获取全局标识,在目标请求调用当前微服务时,将全局标识传输至当前微服务以进行记录,全局标识用于对目标请求进行标识;
在目标请求调用下一微服务时,将全局标识传输至下一微服务以进行记录;
根据各个微服务中记录的全局标识,确定目标请求所调用的微服务。
在一些实施例中,上述全局标识模块具体还可以用于:
获取目标请求的请求时间戳和当前微服务的网络协议地址;
根据请求时间戳和当前微服务的网络协议地址,生成全局标识。
在一些实施例中,上述数据采集装置还包括故障排查模块,用于:
当业务系统发出故障提示时,根据链路数据进行故障排查,得到排查结果,排查结果用于指示业务系统发生故障的位置。
在一些实施例中,上述数据采集装置还可以包括开关控制模块,用于响应于业务系统中预设开关的开启或关闭,控制各个微服务中的埋点组件的启动或停止。
其中,埋点组件用于进行链路数据的收集。
在一些实施例中,上述数据采集装置还可以包括名单获取模块,用于:
获取业务系统中预设的白名单路径;
根据埋点组件在白名单路径中采集得到的数据,获取链路数据。
其中,白名单路径用于指示埋点组件进行数据采集,微服务中包括有埋点组件,埋点组件用于进行数据采集。
在一些实施例中,上述数据采集装置还包括关系获取模块,用于:
根据服务调用链路,获取各个微服务之间的拓扑关系;
根据拓扑关系,构建业务系统的服务框架。
其中,服务框架用于指示业务系统所包含的微服务以及各个微服务的关联关系。
在一些实施例中,上述数据采集装置还包括存储模块,用于根据消息队列机制,将服务调用链路异步发送存储至预设数据库中。
本申请实施例提供的装置,可用于执行上述实施例中的方法,其实现原理和技术效果类似,在此不再赘述。
需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。例如,服务获取模块可以以程序代码的形式存储于上述装置的存储器中,由上述装置的某一个处理元件调用并执行以上服务获取模块的功能。其它模块的实现与之类似。
图6为本申请实施例提供的电子设备的结构示意图。如图6所示,该电子设备60包括:至少一个处理器61和与处理器61连接的存储器62。示例性的,该电子设备可以是一个服务器或多个服务器组成。其中处理器61、通信接口64以及存储器62通过总线63完成相互间的通信。通信接口64用于与其它设备进行通信,该通信接口包括用于进行数据传输的通信接口。
处理器61,用于执行存储器62中存储的计算机指令,具体可以执行上述实施例中所描述的方法中的相关步骤。处理器可能是中央处理器。电子设备60包括的一个或多个处理器。
存储器62,用于存放计算机指令。存储器可能包含高速RAM存储器,也可能还包括非易失性存储器,例如至少一个磁盘存储器。
本实施例还提供一种可读存储介质,可读存储介质中存储有计算机指令,当电子设备的至少一个处理器执行该计算机指令时,电子设备执行上述的各种实施方式提供的数据采集方法。
本实施例还提供一种程序产品,该程序产品包括计算机指令,该计算机指令存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该计算机指令,至少一个处理器执行该计算机指令使得电子设备实施上述的各种实施方式提供的数据采集方法。
本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系;在公式中,字符“/”,表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中,a,b,c可以是单个,也可以是多个。
可以理解的是,在本申请实施例中涉及的各种数字编号仅为描述方便进行的区分,并不用来限制本申请的实施例的范围。在本申请的实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请的实施例的实施过程构成任何限定。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (15)

1.一种数据采集方法,其特征在于,应用于基于微服务架构的业务系统,所述业务系统包括有至少一个微服务,所述方法包括:
获取所述业务系统在处理目标请求时所述目标请求所调用的至少一个微服务;
根据所述目标请求所调用的所述至少一个微服务,构建服务调用链路;
根据所述服务调用链路进行数据采集,获取链路数据,所述链路数据用于所述业务系统的故障定位,所述链路数据至少包括有所述服务调用链路的上下文信息、链路标识、调用开始时间和耗时、调用方网络协议地址和端口中的至少一种。
2.根据权利要求1所述的方法,其特征在于,所述根据所述服务调用链路进行数据采集,获取链路数据,包括:
根据各个微服务中的埋点组件获取所述链路数据,每个微服务包括有至少一个埋点组件,所述埋点组件用于进行链路数据的采集。
3.根据权利要求1所述的方法,其特征在于,若所述目标请求调用至少两个微服务,所述根据所述目标请求所调用的至少一个微服务,构建服务调用链路,包括:
获取所述目标请求所调用的各个微服务之间的调用先后顺序;
根据所述目标请求所调用的各个微服务和所述调用先后顺序,构建所述服务调用链路。
4.根据权利要求3所述的方法,其特征在于,所述获取所述目标请求所调用的各个微服务之间的调用先后顺序,包括:
在所述目标请求调用当前微服务时,获取所述当前微服务的标识信息;
在所述目标请求完成所述当前微服务的调用并继续调用下一微服务时,将所述当前微服务的标识信息传输至下一微服务以进行记录;
在目标请求完成各个微服务的调用时,根据各个微服务记录的标识信息,确定各个微服务之间的调用先后顺序。
5.根据权利要求4所述的方法,其特征在于,所述方法还包括:
获取全局标识,在所述目标请求调用当前微服务时,将所述全局标识传输至当前微服务以进行记录,所述全局标识用于对所述目标请求进行标识;
在所述目标请求调用下一微服务时,将所述全局标识传输至所述下一微服务以进行记录;
根据各个微服务中记录的全局标识,确定所述目标请求所调用的微服务。
6.根据权利要求5所述的方法,其特征在于,所述获取全局标识,包括:
获取所述目标请求的请求时间戳和所述当前微服务的网络协议地址;
根据所述请求时间戳和所述当前微服务的网络协议地址,生成所述全局标识。
7.根据权利要求1所述的方法,其特征在于,所述方法还包括:
当所述业务系统发出故障提示时,根据所述链路数据进行故障排查,得到排查结果,所述排查结果用于指示所述业务系统发生故障的位置。
8.根据权利要求1所述的方法,其特征在于,所述方法还包括:
响应于所述业务系统中预设开关的开启或关闭,控制各个微服务中的埋点组件的启动或停止,所述埋点组件用于进行链路数据的收集。
9.根据权利要求1所述的方法,其特征在于,所述方法还包括:
获取所述业务系统中预设的白名单路径,所述白名单路径用于指示埋点组件进行数据采集,所述微服务中包括有埋点组件,所述埋点组件用于进行数据采集;
根据所述埋点组件在所述白名单路径中采集得到的数据,获取所述链路数据。
10.根据权利要求1所述的方法,其特征在于,所述方法还包括:
根据所述服务调用链路,获取各个微服务之间的拓扑关系;
根据所述拓扑关系,构建所述业务系统的服务框架,所述服务框架用于指示所述业务系统所包含的微服务以及各个微服务的关联关系。
11.根据权利要求1所述的方法,其特征在于,所述方法还包括:
根据消息队列机制,将所述服务调用链路异步发送存储至预设数据库中。
12.一种数据采集装置,其特征在于,包括:
服务获取模块,用于获取业务系统在处理目标请求时所述目标请求所调用的微服务,所述目标请求可调用至少一个微服务;
链路构建模块,用于根据所述目标请求所调用的所述至少一个微服务,构建服务调用链路;
数据获取模块,用于根据所述服务调用链路进行数据采集,获取链路数据,所述链路数据至少包括有所述服务调用链路的上下文信息、链路标识、调用开始时间和耗时、调用方网络协议地址和端口中的至少一种。
13.一种电子设备,其特征在于,包括:处理器,以及与所述处理器通信连接的存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,以实现如权利要求11中任一项所述的方法。
14.一种可读存储介质,其特征在于,所述可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现如权利要求1-11任一项所述的方法。
15.一种程序产品,包括计算机指令,其特征在于,该计算机指令被处理器执行时实现权利要求1-11任一项所述的方法。
CN202210408515.XA 2022-04-19 2022-04-19 数据采集方法、装置、设备和可读存储介质 Active CN114745295B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210408515.XA CN114745295B (zh) 2022-04-19 2022-04-19 数据采集方法、装置、设备和可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210408515.XA CN114745295B (zh) 2022-04-19 2022-04-19 数据采集方法、装置、设备和可读存储介质

Publications (2)

Publication Number Publication Date
CN114745295A true CN114745295A (zh) 2022-07-12
CN114745295B CN114745295B (zh) 2024-08-16

Family

ID=82281725

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210408515.XA Active CN114745295B (zh) 2022-04-19 2022-04-19 数据采集方法、装置、设备和可读存储介质

Country Status (1)

Country Link
CN (1) CN114745295B (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115412592A (zh) * 2022-08-19 2022-11-29 恒生电子股份有限公司 业务处理系统以及方法
CN115529313A (zh) * 2022-09-16 2022-12-27 建信金融科技有限责任公司 调用链路的确定方法、装置、电子设备和介质
CN115866056A (zh) * 2022-11-29 2023-03-28 北京达佳互联信息技术有限公司 服务调用方法和装置、电子设备、计算机可读存储介质
CN116192621A (zh) * 2022-12-27 2023-05-30 上海轻维软件有限公司 基于Opentracing链路追踪业务调用链的方法
CN117240767A (zh) * 2023-11-16 2023-12-15 国网信息通信产业集团有限公司 一种业务中台服务旁路调用监测方法及系统
CN117389792A (zh) * 2023-12-13 2024-01-12 之江实验室 一种故障排查方法、装置、存储介质及电子设备

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107580018A (zh) * 2017-07-28 2018-01-12 北京北信源软件股份有限公司 一种分布式系统的跟踪方法与装置
US20180039501A1 (en) * 2016-08-05 2018-02-08 Oracle International Corporation Tenant self-service troubleshooting for a multi-tenant identity and data security management cloud service
CN109921927A (zh) * 2019-02-20 2019-06-21 苏州人之众信息技术有限公司 基于微服务的实时调用链跟踪方法
CN110069354A (zh) * 2019-04-15 2019-07-30 必成汇(成都)科技有限公司 微服务全链路跟踪方法及微服务架构
US20200092180A1 (en) * 2018-09-14 2020-03-19 Capital One Services, Llc Methods and systems for microservices observability automation
WO2021008031A1 (zh) * 2019-07-16 2021-01-21 平安普惠企业管理有限公司 基于微服务实现监控智能化的处理方法及电子装置
CN112422335A (zh) * 2020-11-10 2021-02-26 普元信息技术股份有限公司 技术中台中基于微服务架构实现业务链路分析的方法、系统、装置及存储介质
CN112612675A (zh) * 2020-12-25 2021-04-06 山东经伟晟睿数据技术有限公司 微服务架构下的分布式大数据日志链路跟踪方法及系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180039501A1 (en) * 2016-08-05 2018-02-08 Oracle International Corporation Tenant self-service troubleshooting for a multi-tenant identity and data security management cloud service
CN107580018A (zh) * 2017-07-28 2018-01-12 北京北信源软件股份有限公司 一种分布式系统的跟踪方法与装置
US20200092180A1 (en) * 2018-09-14 2020-03-19 Capital One Services, Llc Methods and systems for microservices observability automation
CN109921927A (zh) * 2019-02-20 2019-06-21 苏州人之众信息技术有限公司 基于微服务的实时调用链跟踪方法
CN110069354A (zh) * 2019-04-15 2019-07-30 必成汇(成都)科技有限公司 微服务全链路跟踪方法及微服务架构
WO2021008031A1 (zh) * 2019-07-16 2021-01-21 平安普惠企业管理有限公司 基于微服务实现监控智能化的处理方法及电子装置
CN112422335A (zh) * 2020-11-10 2021-02-26 普元信息技术股份有限公司 技术中台中基于微服务架构实现业务链路分析的方法、系统、装置及存储介质
CN112612675A (zh) * 2020-12-25 2021-04-06 山东经伟晟睿数据技术有限公司 微服务架构下的分布式大数据日志链路跟踪方法及系统

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115412592A (zh) * 2022-08-19 2022-11-29 恒生电子股份有限公司 业务处理系统以及方法
CN115412592B (zh) * 2022-08-19 2023-08-22 恒生电子股份有限公司 业务处理系统以及方法
CN115529313A (zh) * 2022-09-16 2022-12-27 建信金融科技有限责任公司 调用链路的确定方法、装置、电子设备和介质
CN115529313B (zh) * 2022-09-16 2024-08-20 建信金融科技有限责任公司 调用链路的确定方法、装置、电子设备和介质
CN115866056A (zh) * 2022-11-29 2023-03-28 北京达佳互联信息技术有限公司 服务调用方法和装置、电子设备、计算机可读存储介质
CN116192621A (zh) * 2022-12-27 2023-05-30 上海轻维软件有限公司 基于Opentracing链路追踪业务调用链的方法
CN117240767A (zh) * 2023-11-16 2023-12-15 国网信息通信产业集团有限公司 一种业务中台服务旁路调用监测方法及系统
CN117240767B (zh) * 2023-11-16 2024-01-23 国网信息通信产业集团有限公司 一种业务中台服务旁路调用监测方法及系统
CN117389792A (zh) * 2023-12-13 2024-01-12 之江实验室 一种故障排查方法、装置、存储介质及电子设备

Also Published As

Publication number Publication date
CN114745295B (zh) 2024-08-16

Similar Documents

Publication Publication Date Title
CN114745295B (zh) 数据采集方法、装置、设备和可读存储介质
CN112910945B (zh) 请求链路跟踪方法和业务请求处理方法
Mayer et al. An approach to extract the architecture of microservice-based software systems
WO2020147419A1 (zh) 监控方法、装置、计算机设备及存储介质
CN109460307B (zh) 基于日志埋点的微服务调用跟踪方法及其系统
CN108471366A (zh) 一种面向云原生应用的立体监控系统
CN112905323B (zh) 数据处理方法、装置、电子设备及存储介质
CN114363144B (zh) 一种面向分布式系统的故障信息关联上报方法及相关设备
CN112286776A (zh) 一种微服务链路追踪的方法及系统
CN114172949A (zh) 一种微服务链路监控追踪方法和系统
CN113867600A (zh) 处理流式数据的开发方法、装置和计算机设备
WO2022028144A1 (en) Blockchain management of provisioning failures
CN110515750B (zh) 一种应用拓扑生成方法、系统及集群
CN115705190A (zh) 依赖程度的确定方法及装置
CN113806169A (zh) 业务异常处理方法及装置
CN113760562A (zh) 链路追踪方法、装置、系统、服务器和存储介质
CN109274533B (zh) 一种基于规则引擎的Web服务故障的定位装置和方法
CN116136801B (zh) 云平台的数据处理方法、装置、电子设备及存储介质
CN115391127A (zh) 一种拨测方法、装置、存储介质及芯片
CN112685252A (zh) 微服务监控方法、装置、设备和存储介质
US20200099788A1 (en) Context data management interface for contact center
CN109995617A (zh) 主机管理特性的自动化测试方法、装置、设备及存储介质
CN114884807B (zh) 链路日志生成方法、装置、物联网平台及存储介质
CN115168489B (zh) 基于区块链的数据存证方法和装置
CN109684158A (zh) 分布式协调系统的状态监控方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant