CN112491650B - 动态分析服务之间调用环路情况的方法及相关设备 - Google Patents

Abstract

本申请实施例属于***资源监控技术领域，涉及一种动态分析服务之间调用环路情况的方法，包括为各所述http子请求生成第一标识和第二标识；基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路；通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路；基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系；将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。采用本方法使得可以快速定位服务之间的调用关系。

Description

动态分析服务之间调用环路情况的方法及相关设备

技术领域

本申请涉及***资源监控领域，特别是涉及一种动态分析服务之间调用环路情况的方法、装置、计算机设备和存储介质。

背景技术

在包括多个微服务，且各个微服务之间存在相互调用的***中，如果服务之间的功能边界未正确划分好，会导致服务直接存在大量环路调用，导致整个***架构混乱，功能界定不清晰，各个微服务之间的耦合性高，出错率高，从而影响整个服务的可靠性。

当在这种***下，用户需要查看某微服务之间的调用环路关系时，又因为上述原因，无法进行准确、实时的获取。

发明内容

基于此，针对上述技术问题，本申请提供一种动态分析服务之间调用环路情况的方法、装置、计算机设备及存储介质，以解决现有技术中用户无法准确获知服务之间调用的情况的技术问题。

一种动态分析服务之间调用环路情况的方法，应用于包括多个微服务，且各微服务之间存在调用的服务***，其中，当响应用户的业务请求时，服务***会为每一次微服务之间的调用生成一个http子请求，其中，业务请求包括业务标识，一个所述业务请求中包括至少两个http子请求，所述方法包括：

为各所述http子请求生成第一标识和第二标识，其中，所述第一标识用于标识各所述http子请求在所述业务请求中的唯一性，所述第二标识用于标识所述http子请求中微服务之间的调用关系；

基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路；

通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路；

基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系；

将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。

一种动态分析服务之间调用环路情况的装置，应用于包括多个微服务，且各微服务之间存在调用的服务***，其中，当响应用户的业务请求时，服务***会为每一次微服务之间的调用生成一个http子请求，其中，业务请求包括业务标识，一个所述业务请求中包括至少两个http子请求，所述装置包括：

标识模块，用于为各所述http子请求生成第一标识和第二标识，其中，所述第一标识用于标识各所述http子请求在所述业务请求中的唯一性，所述第二标识用于标识所述http子请求中微服务之间的调用关系；

聚合模块，用于基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路；

去重模块，用于通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路；

关系模块，用于基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系；

分析模块，用于将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。

一种计算机设备，包括存储器和处理器，以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现上述动态分析服务之间调用环路情况的方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令被处理器执行时实现上述动态分析服务之间调用环路情况的方法的步骤。

上述动态分析服务之间调用环路情况的方法、装置、计算机设备和存储介质，通过为各http子请求生成第一标识和第二标识，再根据业务标识对子请求进行链路聚合处理，最后通过第一标识和第二标识获取各微服务之间的调用关系，并基于这种调用关系，通过深度优先算法获取各微服务之间是否存在环路关系，如果存在则将调用关系与环路关系一起存储到环路列表中，当用户需要时可以直接输入服务名称，快速得到服务之间的调用关系；通过这种方式可以及时得到这些环路调用信息快速定位服务之间的调用情况，提升***服务之间的可靠性，降低了运维成本。

附图说明

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

图1为动态分析服务之间调用环路情况的方法的应用环境示意图；

图2为动态分析服务之间调用环路情况的方法的流程示意图；

图3为微服务调用示意图；

图4为动态分析服务之间调用环路情况的装置的示意图；

图5为一个实施例中计算机设备的示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了使本申请的目的、技术方案及优点更加清楚明白，下面结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供的动态分析服务之间调用环路情况的方法，可以应用于如图1所示的应用环境中。其中，该应用环境可以包括终端102、网络以及服务端104，网络用于在终端102和服务端104之间提供通信链路介质，网络可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端102通过网络与服务端104交互，以接收或发送消息等。终端102上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端102可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts GroupAudio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务端104可以是提供各种服务的服务器，例如对终端102上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的动态分析服务之间调用环路情况的方法一般由服务端/终端执行，相应地，动态分析服务之间调用环路情况的装置一般设置于服务端/终端设备中。

本申请可用于众多通用或专用的计算机***环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器***、基于微处理器的***、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何***或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

应该理解，图1中的终端、网络和服务端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

其中，终端102通过网络与服务端104进行通信。服务端104时间监控服务***中各微服务之间的调用情况，并为各http子请求生成第一标识和第二标识，再通过业务标识将http子请求进行聚合得到请求链路，之后再对其进行去重处理，并根据第一标识和第二标识确定各请求链路之间的各微服务之间的调用关系和环路关系，并将其存储到Redis，当接收到用户通过终端102发送的查询请求时，获取查询请求中的微服务名称，获取对应的环路调用情况返回。其中，终端102和服务端104之间通过网络进行连接，该网络可以是有线网络或者无线网络，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务端104可以用独立的服务器或者是多个组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种动态分析服务之间调用环路情况的方法，以该方法应用于图1中的服务端为例进行说明，包括以下步骤：

步骤202，为各所述http子请求生成第一标识和第二标识，其中，所述第一标识用于标识各所述http子请求在所述业务请求中的唯一性，所述第二标识用于标识所述http子请求中微服务之间的调用关系。

在一些实施例中，本申请的技术方案可以应用于包括多个微服务，且各微服务之间存在调用的服务***，其中，当响应用户的业务请求时，服务***会为每一次微服务之间的调用生成一个http子请求，其中，业务请求包括业务标识，一个所述业务请求中包括至少两个http子请求。

传统技术中的问题就在于，由于微服务在公司中大量使用，而各个微服务之间又存在大量的调用，在一些微服务之间的功能边界未正确划分化的***中，会导致各微服务直接存在大量的环路调用，会导致整个***架构混乱，功能界定不清晰，各个微服务之间的耦合性高，出错率高，从而影响整个服务的可靠性。当在这种***下，用户需要查看某微服务之间的调用环路关系时，又因为上述原因，无法进行准确、实时的获取。

所以，本申请基于移动脚手架对环路***的调用环路关系进行处理，以实现微服务环路发现功能，使得用户可以动态实时获取微服务的历史环路情况，而且能够清洗得到是哪些微服务之间的不规范调用导致的，为用户提供快速有效的定位环路帮助。

其中，移动互联脚手架是移动互联基础组在springboot脚手架进行增强，主要利用springboot提供的各种埋点完成对集成的微服务进行监控。具体地，将脚手架集成到项目中，这里的集成可能是引入脚手架jar包，如果是maven管理的项目则添加maven依赖；由于脚手架是基于springboot项目，其通过spring框架提供的切入点handleInterceptor会在http业务请求前后收集该请求相关信息(这里包括URL地址，请求方法，请求参数解析，结果参数解析)，然后将http业务请求前后收集的数据整合到一起，由于移动互联网脚手架本身集成了kafka客户端，在完成整个http请求后会将收集的数据异步上报到broker中(kafka服务器)。其中，Spring框架是Java平台上的一种开源应用框架，提供具有控制反转特性的容器。handleInterceptor是spring框架中的***。

http子请求比如可以是用户领券操作的http请求，本实施例以包括会员中心服务、领券服务以及用户基础服务这三个微服务的***为例：当用户的业务请求为用户领券时，会先向“会员中心服务”发起http子请求调用会员中心服务，然后会员中心服务发起另一个http子请求调用会员中心服务获取用户等级，最后，领券中心服务根据用户会员等级查询出满足当前等级卡券进行展示。

每一个http子请求都会利用spring框架的***将，采用非阻塞模式将其上报到kafka中等待消费；根据业务请求具有唯一性的业务标识，可以很方便的知道某些http子请求是属于哪个http业务请求完整的请求流程；但是很难得知谁是http子请求的调用发起方，谁调用了谁，为了解决这个问题，所以在http子请求生成之始，上报kafka之前，就需要为每次http子请求添加标记，这里的标记就是指第一标识和第二标识。

具体地，当检测到微服务发起的http子请求，则根据所述业务标识确定当前http子请求是否存在上一http子请求；若存在，则为当前http子请求生成第一标识，并将上一http子请求的第一标识与当前http子请求的第二标识进行整合，作为当前http子请求新的第二标识；若不存在，则为当前http子请求生成第一标识，并将当前http子请求的第二标识设为空。

业务标识是traceId一次http业务请求只会在最开始生成一次，向下调用都会在http子请求头中携带业务标识traceId。

第一标识每次http子请求都会生成一次，每次都不同，向下调用时，当前生成的第一标识会作为下一http子请求的第二标识，并继续向下传递，且每次向下调用，第二标识都会继续累加，以记录http子请求的服务调用路径。需要注意的是，第二标识在http业务请求之始是空的。

步骤204，基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路。

移动互联网中，一个完整的http业务请求不再是简单的调用某一个服务，而是会涉及N多个微服务，其深度和广度也不会固定，例如服务中调用服务。所以就需要对http业务请求进行标记，以实现标识某些http子请求是输入哪一个http业务请求流程。本实施例可以通过为每一个http业务请求流程生成一个业务标识实现记录和跟踪。该业务标识具有以下特点：

1)用户每次进行http业务请求都不相同，以包括会员中心服务、领券服务以及用户基础服务这三个微服务的***为例，如图3所示，虚线箭头为领券的服务之间调用路径，实线箭头为查询的服务之间调用路径：

用户领券的业务请求(领券)：

a.用户发起领券的http业务请求(/hczlife-coupon/showCoupon)调用领券中心服务；

b.领券中心服务发起http子请求(/member-center/queryLevel)调用会员中心服务获取用户等级；

c.领券中心服务根据得到的用户会员等级查询出满足当前等级卡券进行展示。

用户在会员中心查看基本信息的业务请求(查询):

a.用户发起查询的http业务请求(/member-center/userInfo)调用会员中心服务；

b.会员中心服务的http子请求(/hczlife-coupon/userInfo)调用领券中心服务，领券中心服务的http子请求(/user-info/getInfo)发送至用户基础服务获取用户基本信息【出现这种情况，可能是由于开发人用错接口等原因导致的】；

c.会员中心服务进行基本包装，返回相关信息。

从图3可以获知，在多种http业务请求下，会员中心服务和领券中心服务形成一个环路调用(互相之间有调用)，这种情况下，如果不对http子请求进行限定和整理，当操作执行失败后，用户很难得知是哪些服务之间的接口不规范调用导致的问题。一次完整的http业务请求无论其调用深度多深，广度多大，业务标识都不会随之改变，即具有唯一性；这个业务标识在移动互联网中被称为traceID，但在一次http业务请求流程中，可能会出现多次的微服务之间的调用。

由于收集的http子请求数据是各个节点异步上报的，整个请求链路调用完需要一段时间，为了获取完整的请求链路，方便存储，本实施例引入滑动窗口。这里滑动窗口定义比一个大多数业务请求时间都小的时间。

所以在一些实施例中，本申请可以通过利用flink上的滑动窗口功能对http子请求进行聚合处理：根据预设窗口配置数据设定滑动窗口，其中，所述滑动窗口包括窗口起点、窗口长度以及移动步长；从所述窗口起点开始，按照所述移动步长移动窗口长度为预设值的滑动窗口，其中，所述滑动窗口每移动一次，则根据业务标识对在所述滑动窗口内的http子请求进行聚合，直到滑动窗口的移动次数达到预设次数。

具体地，以具有会员中心服务、领券服务以及权益服务的***为例，用户领取卡券的http请求流程如下：

1)用户通过http业务请求发起领券卡券；

2)领券服务会调用会员中心服务获取当前用户会员信息；

3)领券服务根据领券卡券ID判断是否满足当前会员等级，如果满足则进行下一步；

4)领券服务再通过http请求调用权益服务，实现用户权益；

上面这个http业务请求流程，上报的数据存在三个时间段，由于采用kafka异步上报，其上报的http子请求数据到达flink的顺序可能存在不一致。所以，为了得到完整的http请求链路，本实施例可以通过滑动窗口的方式实现，滑动窗口是由窗口起点、窗口长度以及移动步长这几个基本要素组成。Flink在接受到上报数据后，会为当前上报的数据添加一个当前时间标记，比如这里会以第一次接受上报的http子请求的时间为窗口起点，将窗口长度设为2分钟，每隔一分钟滑动窗口就移动一次。

即，根据预设窗口配置数据设定滑动窗口，其中，所述滑动窗口包括窗口起点、窗口长度以及移动步长；从所述窗口起点开始，按照所述移动步长移动窗口长度为预设值的滑动窗口，其中，所述滑动窗口每移动一次，则根据业务标识对在所述滑动窗口内的http子请求进行聚合，直到滑动窗口的移动次数达到预设次数。在进行聚合时，获取在所述滑动窗口内的http子请求的业务标识；按照将具有相同业务标识的http子请求保存到同一个链路列表中，得到所述请求链路。

具体示例如下：

比如我们以当前滑动窗口起点时间为2020-10-26 10:22:40，窗口长度为2分钟，窗口移动步长为1分钟(当前窗口可接受最晚的时间为2020-10-26 10:35:40)

第一个窗口时间【起点：2020-10-26 10:33:40、结束：2020-10-26 10:35:40】

第二个窗口时间【起点：2020-10-26 10:34:40、结束：2020-10-26 10:36:40】

第三个窗口时间【起点：2020-10-26 10:35:40、结束：2020-10-26 10:37:40】

通过上面我们知道滑动窗口如果滑动步长小于窗口长度会出现重叠部分，这时的数据上报异常情况为：

上报数据1、接口：/hczlife-coupon/draw、服务：hczlife-coupon、traceId:t_2315678、spanId:coupon_1234、时间：2020-10-26 10:34:50

上报数据2、

接口：/member-center/queryLevel服务：member-center、traceId:t_2315678、spanId:member_1234、pSpanId:coupon_1234、时间：2020-10-26 10:35:00

上报数据3、(由于权益网络问题上报到kafka中数据比较延迟)

接口：/hczlife-benefit/sendBenefit、服务：icore-common-benefit、traceId:t_2315678、pSpanId:member_1234、spanId:benefit_1234、时间：2020-10-2610:36:30

从上面可知，上报数据1和上报数据2会在滑动窗口一中，同时上报数据1和上报数据2也会在滑动窗口二中，上报数据3也在滑动窗口二中，滑动窗口一的请求链路聚合流程如下：其会将相同的业务标识(traceID)的http子请求存放在一个列表中，我们可以理解为将其存放在一个Map<String,List<Object>>中，其中，键为traceId、值如下)：

[{"url":"/hczlife-coupon/draw","name":"hczlife-coupon","spanId":"coupon_1234"},{"url":"/member-center/queryLevel","name":"member-center","spanId":"member_1234","pSpanId":"coupon_1234"}]

窗口二的链路聚合流程如下其和窗口一流程基本一致，只是因为数据上报3也在滑动窗口二中，所以滑动窗口二中聚合的请求链路也更长，如下：

[{"url":"/hczlife-coupon/draw","name":"hczlife-coupon","spanId":"coupon_1234"},{"url":"/member-center/queryLevel","name":"member-center","spanId":"member_1234","pSpanId":"coupon_1234"},{"url":"/hczlife-benefit/sendBenefit","name":"icore-common-benefit","spanId":"benefit_1234","pSpanId":"coupon_1234"}]

滑动窗口是指使用一定区间范围整体移动。由于普通的http请求会在两分钟内完成请求，如果使用过大的时间窗口会导致flink聚合时数据过多影响***的整体性能。将滑动窗口以1分钟滑动是为了减少http请求链路聚合频率。Flink消费kafka中的请求数据，每次消费的数据量是前后消息的最大时间差在2分钟；flink在2分中内的消息通过业务标识进行一个map统计(其中，键是traceID，值是链路列表)；flink会依次遍历kafka中的请求数据，可以获取同一链路的列表。其中，得到的请求链路包括请求的微服务的URL地址、服务名称。

步骤206，通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路。

进一步地，Flink会根据预设的消费策略，实时消费上报到kafka中的http子请求，由于某些微服务的请求在短时间内会有大量的请求，例如秒杀时抢购请求，为了保证一段时间内相同的请求只需要一条即可，会使用到布隆算法，将整理好的请求链路进行去重处理。其中，布隆算法是一种空间效率很高的随机数据结构，它利用位数组很简洁地表示一个集合，并能判断一个元素是否属于这个集合。

去除所述链路列表中各http子请求的第一标识和第二标识，得到待去重链路列表；计算所述待去重链路列表的hash值；并判断所述hash值在Redis中是否存在，得到判断结果；若判断结果为所述hash值不存在，则将所述待去重链路列表对应的请求链路，作为去重后的请求链路上传到Redis；若判断结果为所述hash值存在，则将所述待去重链路列表对应的请求链路删除。

具体地，对于这样一条请求链路：

[{"url":"/hczlife-coupon/draw","name":"hczlife-coupon","spanId":"coupon_1234"},{"url":"/member-center/queryLevel","name":"member-center","spanId":"member_1234","pSpanId":"coupon_1234"}]

在计算其是否已经在Redis中存在时，具体地，我们将上面字符串中第一标识(spanid)和第二标识(pspanid)去掉，然后对去掉后的字符串进行多次hash计算，再到Redis中进行去重判断。如果Redis中不存在，则开始整理调用关系，由于pSpanId会指明其父节点数据(是哪个服务调用的它)。

进一步地，若Redis中存在命中的请求链路，则删除该请求链路。其中，删除该条请求链路的意思是指不会将该http请求链路发送到kafka中继续对其进行处理。通过这种方式来判断当前的请求链路是否已经与之前的相同，若相同则直接结束，若不同，则将其上报到kafka中等待消费。

步骤208，基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系。

深度优先算法是采用递归和回溯的方式来实现的。从flink消费任务完之后，服务端会整理出两两微服务之间的调用关系，并将两两微服务之间的调用关系记录下来，例如以map数据结构的方式进行存储:键(服务名称)，值(向下调用的服务列表),例如：

键为member-center值为:[activity-doctor-battle,icore-aops-activity-module,icore-hczlife-present-share,icore-hczlife-nci]

遍历上面的map数据结构中的键，并获取其对应的值，这里会获取服务列表中的第一个名称，并开启下一轮的递归。直到下一个服务名称为自己本身或者深度已经大于指定的数字，本实施例中指定的数字可以取20。如果递归下去服务名称为当前开始服务名称，则记录下来，如果深度大于指定数字也进行结束，回溯到上一层，并获取服务列表中另一个服务名称再开始下一轮递归。

步骤210，将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。

一般用户通过终端向服务端发起环路调用请求，环路调用请求中包括用户的想要查看的某个微服务的名称数据，服务端会根据该为服务名称在Redis中查询与该微服务对应的环路列表。若存在环路调用，则环路列表中包括某个服务在大量http业务请求是存在闭环调用，环路情况还涉及环长深度、服务调用闭环所涉及的服务接口。通过这种方式可以快速查看某个服务环路中涉及哪些接口，为服务功能边界拆分提供数据支持。

上述动态分析服务之间调用环路情况的方法中，通过为各http子请求生成第一标识和第二标识，再根据业务标识对子请求进行链路聚合处理，最后通过第一标识和第二标识获取各微服务之间的调用关系，并基于这种调用关系，通过深度优先算法获取各微服务之间是否存在环路关系，如果存在则将调用关系与环路关系一起存储到环路列表中，当用户需要时可以直接输入服务名称，快速得到服务之间的调用关系；通过这种方式可以及时得到这些环路调用信息，并快速定位服务之间的调用情况，提升了***服务之间的可靠性，降低了运维成本。

应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图4所示，提供了一种动态分析服务之间调用环路情况的装置，该动态分析服务之间调用环路情况的装置与上述实施例中动态分析服务之间调用环路情况的方法一一对应。该动态分析服务之间调用环路情况的装置，应用于包括多个微服务，且各微服务之间存在调用的服务***，其中，当响应用户的业务请求时，服务***会为每一次微服务之间的调用生成一个http子请求，其中，业务请求包括业务标识，一个所述业务请求中包括至少两个http子请求，包括：

标识模块402，用于为各所述http子请求生成第一标识和第二标识，其中，所述第一标识用于标识各所述http子请求在所述业务请求中的唯一性，所述第二标识用于标识所述http子请求中微服务之间的调用关系；

聚合模块404，用于基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路；

去重模块406，用于通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路；

关系模块408，用于基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系；

分析模块410，用于将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。

进一步地，标识模块，包括：

检测子模块，用于当检测到微服务发起的http子请求，则根据所述业务标识确定当前http子请求是否存在上一http子请求；

第一标识子模块，用于若存在，则为当前http子请求生成第一标识，并将上一http子请求的第一标识与当前http子请求的第二标识进行整合，作为当前http子请求新的第二标识；

第二标识子模块，用于若不存在，则为当前http子请求生成第一标识，并将当前http子请求的第二标识设为空。

进一步地，聚合模块404，包括：

配置子模块，用于根据预设窗口配置数据设定滑动窗口，其中，所述滑动窗口包括窗口起点、窗口长度以及移动步长；

聚合子模块，用于从所述窗口起点开始，按照所述移动步长移动窗口长度为预设值的滑动窗口，其中，所述滑动窗口每移动一次，则根据业务标识对在所述滑动窗口内的http子请求进行聚合，直到滑动窗口的移动次数达到预设次数。

进一步地，聚合子模块，包括：

标识单元，用于获取在所述滑动窗口内的http子请求的业务标识；

聚合单元，用于按照将具有相同业务标识的http子请求保存到同一个链路列表中，得到所述请求链路。

进一步地，所述http子请求还包括微服务的名称和URL地址，所述通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路，去重模块406，包括：

去除子模块，用于去除所述链路列表中各http子请求的第一标识和第二标识，得到待去重链路列表；

计算子模块，用于计算所述待去重链路列表的hash值；并

判断子模块，用于判断所述hash值在Redis中是否存在，得到判断结果；

第一结果子模块，用于若判断结果为所述hash值不存在，则将所述待去重链路列表对应的请求链路，作为去重后的请求链路上传到Redis；

第二结果子模块，用于若判断结果为所述hash值存在，则将所述待去重链路列表对应的请求链路删除。

进一步地，关系模块408，包括：

调用子模块，用于根据各http子请求的第二标识确定各请求链路中微服务之间的调用关系；

初始子模块，用于根据所述第一标识和所述第二标识确定所述请求链路中的初始微服务，其中，所述初始微服务为所述业务请求发起后第一个调用的微服务；

深度子模块，用于根据所述初始微服务以及所述调用关系，得到各所述请求链路的调用深度；

环路子模块，用于基于所述调用深度确定各所述请求链路的微服务之间的环路关系。

上述动态分析服务之间调用环路情况的装置，通过为各http子请求生成第一标识和第二标识，再根据业务标识对子请求进行链路聚合处理，最后通过第一标识和第二标识获取各微服务之间的调用关系，并基于这种调用关系，通过深度优先算法获取各微服务之间是否存在环路关系，如果存在则将调用关系与环路关系一起存储到环路列表中，当用户需要时可以直接输入服务名称，快速得到服务之间的调用关系；通过这种方式可以及时得到这些环路调用信息快速定位服务之间的调用情况，提升***服务之间的可靠性，降低了运维成本。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图5所示。该计算机设备包括通过***总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***、计算机可读指令和数据库。该内存储器为非易失性存储介质中的操作***和计算机可读指令的运行提供环境。该计算机设备的数据库用于存储http子请求。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机可读指令被处理器执行时以实现一种动态分析服务之间调用环路情况的方法。通过为各http子请求生成第一标识和第二标识，再根据业务标识对子请求进行链路聚合处理，最后通过第一标识和第二标识获取各微服务之间的调用关系，并基于这种调用关系，通过深度优先算法获取各微服务之间是否存在环路关系，如果存在则将调用关系与环路关系一起存储到环路列表中，当用户需要时可以直接输入服务名称，快速得到服务之间的调用关系；通过这种方式可以及时得到这些环路调用信息快速定位服务之间的调用情况，提升***服务之间的可靠性，降低了运维成本。

其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机可读指令，计算机可读指令被处理器执行时实现上述实施例中动态分析服务之间调用环路情况的方法的步骤，例如图2所示的步骤202至步骤210，或者，处理器执行计算机可读指令时实现上述实施例中动态分析服务之间调用环路情况的装置的各模块/单元的功能，例如图4所示模块402至模块410的功能。

通过为各http子请求生成第一标识和第二标识，再根据业务标识对子请求进行链路聚合处理，最后通过第一标识和第二标识获取各微服务之间的调用关系，并基于这种调用关系，通过深度优先算法获取各微服务之间是否存在环路关系，如果存在则将调用关系与环路关系一起存储到环路列表中，当用户需要时可以直接输入服务名称，快速得到服务之间的调用关系；通过这种方式可以及时得到这些环路调用信息快速定位服务之间的调用情况，提升***服务之间的可靠性，降低了运维成本。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一非易失性计算机可读取存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形、改进或者对部分技术特征进行等同替换，而这些修改或者替换，并不使相同技术方案的本质脱离本发明个实施例技术方案地精神和范畴，都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种动态分析服务之间调用环路情况的方法，应用于包括多个微服务，且各微服务之间存在调用的服务***，其中，当响应用户的业务请求时，服务***会为每一次微服务之间的调用生成一个http子请求，其中，业务请求包括业务标识，一个所述业务请求中包括至少两个http子请求，其特征在于，所述方法包括：

为各所述http子请求生成第一标识和第二标识，其中，所述第一标识用于标识各所述http子请求在所述业务请求中的唯一性，所述第二标识用于标识所述http子请求中微服务之间的调用关系；

基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路；

通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路；

基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系；

将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。

2.根据权利要求1所述的方法，其特征在于，所述为各所述http子请求生成第一标识和第二标识，包括：

当检测到微服务发起的http子请求，则根据所述业务标识确定当前http子请求是否存在上一http子请求；

若存在，则为当前http子请求生成第一标识，并将上一http子请求的第一标识与当前http子请求的第二标识进行整合，作为当前http子请求新的第二标识；

若不存在，则为当前http子请求生成第一标识，并将当前http子请求的第二标识设为空。

3.根据权利要求1所述的方法，其特征在于，所述基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路，包括：

根据预设窗口配置数据设定滑动窗口，其中，所述滑动窗口包括窗口起点、窗口长度以及移动步长；

从所述窗口起点开始，按照所述移动步长移动窗口长度为预设值的滑动窗口，其中，所述滑动窗口每移动一次，则根据业务标识对在所述滑动窗口内的http子请求进行聚合，直到滑动窗口的移动次数达到预设次数。

4.根据权利要求3所述的方法，其特征在于，所述根据业务标识对在所述滑动窗口内的http子请求进行聚合，包括：

获取在所述滑动窗口内的http子请求的业务标识；

按照将具有相同业务标识的http子请求保存到同一个链路列表中，得到所述请求链路。

5.根据权利要求1所述的方法，其特征在于，所述http子请求还包括微服务的名称和URL地址，所述通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路，包括：

去除所述链路列表中各http子请求的第一标识和第二标识，得到待去重链路列表；

计算所述待去重链路列表的hash值；并

判断所述hash值在Redis中是否存在，得到判断结果；

若判断结果为所述hash值不存在，则将所述待去重链路列表对应的请求链路，作为去重后的请求链路上传到Redis；

若判断结果为所述hash值存在，则将所述待去重链路列表对应的请求链路删除。

6.根据权利要求1所述的方法，其特征在于，所述基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系，包括：

根据各http子请求的第二标识确定各请求链路中微服务之间的调用关系；

根据所述第一标识和所述第二标识确定所述请求链路中的初始微服务，其中，所述初始微服务为所述业务请求发起后第一个调用的微服务；

根据所述初始微服务以及所述调用关系，得到各所述请求链路的调用关系；

基于所述调用关系确定各所述请求链路的微服务之间的环路关系。

7.一种动态分析服务之间调用环路情况的装置，应用于包括多个微服务，且各微服务之间存在调用的服务***，其中，当响应用户的业务请求时，服务***会为每一次微服务之间的调用生成一个http子请求，其中，业务请求包括业务标识，一个所述业务请求中包括至少两个http子请求，其特征在于，包括：

标识模块，用于为各所述http子请求生成第一标识和第二标识，其中，所述第一标识用于标识各所述http子请求在所述业务请求中的唯一性，所述第二标识用于标识所述http子请求中微服务之间的调用关系；

聚合模块，用于基于预设聚合策略与业务标识对各所述http子请求进行聚合，得到对应所述业务请求的请求链路；

去重模块，用于通过布隆算法对所述请求链路进行去重处理，得到去重后的请求链路；

关系模块，用于基于所述第一标识和所述第二标识，确定去重后的请求链路中各http子请求对应的微服务之间的调用关系，并基于所述调用关系，通过深度优先算法获取各微服务之间的环路关系；

分析模块，用于将所述调用关系和所述环路关系以环路列表的方式保存到Redis中，并根据用户输入的微服务名称获取对应的环路列表，得到环路分析情况。

8.根据权利要求7所述的装置，其特征在于，所述标识模块，包括：

检测子模块，用于当检测到微服务发起的http子请求，则根据所述业务标识确定当前http子请求是否存在上一http子请求；

第一标识子模块，用于若存在，则为当前http子请求生成第一标识，并将上一http子请求的第一标识与当前http子请求的第二标识进行整合，作为当前http子请求新的第二标识；

第二标识子模块，用于若不存在，则为当前http子请求生成第一标识，并将当前http子请求的第二标识设为空。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现权利要求1至6中任一项所述方法的步骤。

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

Images