CN112491650A

CN112491650A - Method for dynamically analyzing call loop condition between services and related equipment

Info

Publication number: CN112491650A
Application number: CN202011286324.8A
Authority: CN
Inventors: 尹冲
Original assignee: Ping An Property and Casualty Insurance Company of China Ltd
Current assignee: Ping An Property and Casualty Insurance Company of China Ltd
Priority date: 2020-11-17
Filing date: 2020-11-17
Publication date: 2021-03-12
Anticipated expiration: 2040-11-17
Also published as: CN112491650B

Abstract

The embodiment of the application belongs to the technical field of system resource monitoring, and relates to a method for dynamically analyzing the condition of a calling loop between services, which comprises the steps of generating a first identifier and a second identifier for each http sub-request; aggregating each http sub-request based on a preset aggregation strategy and a service identifier to obtain a request link corresponding to the service request; carrying out duplicate removal processing on the request link through a bloom algorithm to obtain a duplicate-removed request link; determining a calling relationship between the micro services corresponding to each http sub-request in the request link after the duplication is removed based on the first identifier and the second identifier, and acquiring a loop relationship between the micro services through a depth-first algorithm based on the calling relationship; and storing the calling relation and the loop relation into Redis in a loop list mode, and acquiring a corresponding loop list according to the micro service name input by a user to obtain a loop analysis condition. By adopting the method, the calling relationship between the services can be quickly positioned.

Description

Method for dynamically analyzing call loop condition between services and related equipment

Technical Field

The present application relates to the field of system resource monitoring, and in particular, to a method, an apparatus, a computer device, and a storage medium for dynamically analyzing a loop condition between services.

Background

In a system comprising a plurality of micro services and mutual calling among the micro services, if functional boundaries among the services are not correctly divided, a large number of loop calls can be directly existed in the services, so that the whole system architecture is disordered, the function definition is not clear, the coupling among the micro services is high, the error rate is high, and the reliability of the whole service is influenced.

In such a system, when a user needs to check a call loop relationship between certain microservices, accurate and real-time acquisition cannot be performed due to the above reasons.

Disclosure of Invention

Based on this, in order to solve the above technical problems, the present application provides a method, an apparatus, a computer device, and a storage medium for dynamically analyzing a call loop situation between services, so as to solve the technical problem in the prior art that a user cannot accurately know the call situation between services.

A method for dynamically analyzing the calling loop condition between services is applied to a service system which comprises a plurality of micro services and has calling among the micro services, wherein when responding to a service request of a user, the service system generates an http sub-request for each calling among the micro services, wherein the service request comprises a service identifier, and one service request comprises at least two http sub-requests, and the method comprises the following steps:

generating a first identifier and a second identifier for each http sub-request, wherein the first identifier is used for identifying the uniqueness of each http sub-request in the service request, and the second identifier is used for identifying the calling relationship among micro-services in the http sub-request;

aggregating each http sub-request based on a preset aggregation strategy and a service identifier to obtain a request link corresponding to the service request;

carrying out duplicate removal processing on the request link through a bloom algorithm to obtain a duplicate-removed request link;

determining a calling relationship between the micro services corresponding to each http sub-request in the request link after the duplication is removed based on the first identifier and the second identifier, and acquiring a loop relationship between the micro services through a depth-first algorithm based on the calling relationship;

and storing the calling relation and the loop relation into Redis in a loop list mode, and acquiring a corresponding loop list according to the micro service name input by a user to obtain a loop analysis condition.

A device for dynamically analyzing the calling loop condition between services is applied to a service system which comprises a plurality of micro services and has calling among the micro services, wherein when responding to a service request of a user, the service system generates an http sub-request for each calling among the micro services, wherein the service request comprises a service identifier, and one service request comprises at least two http sub-requests, and the device comprises:

the identification module is used for generating a first identification and a second identification for each http sub-request, wherein the first identification is used for identifying the uniqueness of each http sub-request in the service request, and the second identification is used for identifying the calling relationship among micro-services in the http sub-request;

the aggregation module is used for aggregating each http sub-request based on a preset aggregation strategy and a service identifier to obtain a request link corresponding to the service request;

the duplication removing module is used for carrying out duplication removing processing on the request link through a bloom algorithm to obtain a duplicated request link;

the relation module is used for determining a calling relation between micro services corresponding to each http sub-request in the request link after the duplication is removed based on the first identification and the second identification, and acquiring a loop relation between the micro services through a depth-first algorithm based on the calling relation;

and the analysis module is used for storing the calling relation and the loop relation into the Redis in a loop list mode, and acquiring a corresponding loop list according to the micro-service name input by the user to obtain a loop analysis condition.

A computer device comprising a memory and a processor, and computer readable instructions stored in the memory and executable on the processor, the processor implementing the steps of the above method for dynamically analyzing call-through loop conditions between services when executing the computer readable instructions.

A computer readable storage medium storing computer readable instructions which, when executed by a processor, implement the steps of the above method for dynamically analyzing call-loop conditions between services.

According to the method, the device, the computer equipment and the storage medium for dynamically analyzing the calling loop condition among the services, the first identification and the second identification are generated for each http sub-request, then link aggregation processing is carried out on the sub-requests according to the service identification, finally the calling relation among the micro-services is obtained through the first identification and the second identification, whether the loop relation exists among the micro-services is obtained through a depth-first algorithm based on the calling relation, if so, the calling relation and the loop relation are stored into a loop list together, and when a user needs the calling relation, the service name can be directly input, so that the calling relation among the services can be quickly obtained; by the method, the calling condition among the loop calling information quick positioning services can be obtained in time, the reliability among system services is improved, and the operation and maintenance cost is reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.

FIG. 1 is a diagram of an application environment for a method for dynamically analyzing call loop conditions between services;

FIG. 2 is a flow diagram of a method for dynamically analyzing call loop conditions between services;

FIG. 3 is a diagram illustrating micro-service invocation;

FIG. 4 is a schematic diagram of an apparatus for dynamically analyzing call loop conditions between services;

FIG. 5 is a diagram of a computer device in one embodiment.

Detailed Description

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "including" and "having," and any variations thereof, in the description and claims of this application and the description of the above figures are intended to cover non-exclusive inclusions. The terms "first," "second," and the like in the description and claims of this application or in the above-described drawings are used for distinguishing between different objects and not for describing a particular order.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The method for dynamically analyzing the loop calling condition between services provided by the embodiment of the invention can be applied to the application environment shown in FIG. 1. The application environment may include a terminal 102, a network for providing a communication link medium between the terminal 102 and the server 104, and a server 104, wherein the network may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may use the terminal 102 to interact with the server 104 over a network to receive or send messages, etc. The terminal 102 may have installed thereon various communication client applications, such as a web browser application, a shopping application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like.

The terminal 102 may be various electronic devices having a display screen and supporting web browsing, including but not limited to a smart phone, a tablet computer, an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III, mpeg compression standard Audio Layer 3), an MP4 player (Moving Picture Experts Group Audio Layer IV, mpeg compression standard Audio Layer 4), a laptop portable computer, a desktop computer, and the like.

The server 104 may be a server that provides various services, such as a background server that provides support for pages displayed on the terminal 102.

It should be noted that, the method for dynamically analyzing a loop condition between services provided in the embodiments of the present application is generally executed by a server/terminal, and accordingly, a device for dynamically analyzing a loop condition between services is generally disposed in a server/terminal device.

The application is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

It should be understood that the number of terminals, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Wherein, the terminal 102 communicates with the server 104 through the network. The server 104 monitors the calling condition among the micro services in the service system in time, generates a first identifier and a second identifier for each http sub-request, aggregates the http sub-requests through the service identifiers to obtain request links, then performs deduplication processing on the request links, determines the calling relationship and the loop relationship among the micro services among the request links according to the first identifier and the second identifier, stores the calling relationship and the loop relationship into Redis, and obtains the name of the micro service in the query request and returns the corresponding loop calling condition when receiving the query request sent by the user through the terminal 102. The terminal 102 and the server 104 are connected through a network, the network may be a wired network or a wireless network, the terminal 102 may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 may be implemented by an independent server or a server cluster formed by a plurality of servers.

In one embodiment, as shown in fig. 2, a method for dynamically analyzing a call loop situation between services is provided, which is described by taking the application of the method to the server side in fig. 1 as an example, and includes the following steps:

step 202, generating a first identifier and a second identifier for each http sub-request, where the first identifier is used to identify uniqueness of each http sub-request in the service request, and the second identifier is used to identify a call relationship between micro-services in the http sub-request.

In some embodiments, the technical solution of the present application may be applied to a service system including a plurality of micro services, and there is a call between each micro service, where when responding to a service request of a user, the service system generates an http sub-request for each call between the micro services, where the service request includes a service identifier, and one of the service requests includes at least two http sub-requests.

The problem in the conventional technology is that, because the micro-services are used in a large amount in a company, and a large amount of calls exist between the micro-services, in a system in which functional boundaries between some micro-services are not correctly divided, a large amount of loop calls directly exist in each micro-service, which causes confusion of the whole system architecture, unclear function definition, high coupling between the micro-services, and high error rate, thereby affecting the reliability of the whole service. In such a system, when a user needs to check a call loop relationship between certain microservices, accurate and real-time acquisition cannot be performed due to the above reasons.

Therefore, the method and the device for processing the micro-service loop discovery process are based on the mobile scaffold to process the loop calling relation of the loop system so as to realize the micro-service loop discovery function, enable a user to dynamically acquire the historical loop situation of the micro-service in real time, and enable the user to obtain the situation caused by the non-standard calling among the micro-services, thereby providing quick and effective positioning loop help for the user.

The mobile interconnection scaffold is used for enhancing a mobile interconnection foundation group on the springboot scaffold, and monitoring integrated micro-services is completed by mainly utilizing various embedded points provided by the springboot. Specifically, the scaffold is integrated into a project, wherein the integration can be to introduce a scaffold jar package, and if the project is managed by maven, maven dependency is added; because the scaffold is based on the springboot project, the cut-in point handlenterceptor provided by the scaffold through the springing framework can collect the relevant information of the request before and after the http service request (including the URL address, the request method, the request parameter analysis and the result parameter analysis), and then integrate the data collected before and after the http service request together, and because the mobile internet scaffold integrates the kafka client, the collected data can be asynchronously reported to the broker (kafka server) after the whole http request is completed. The Spring framework is an open source application framework on the Java platform, and provides a container with control reversal characteristics. handlenterceptor is an interceptor in the spring framework.

The http sub-request may be, for example, an http request of a user coupon operation, and the embodiment takes a system including three micro services, namely, a member center service, a coupon service, and a user basic service as an example: when the service request of the user is a user coupon, an http sub-request is initiated to a 'member center service' to call a member center service, then another http sub-request is initiated by the member center service to call the member center service to obtain the user grade, and finally, the coupon center service queries a coupon meeting the current grade according to the user member grade to display the coupon.

Each http sub-request is reported to kafka for consumption in a non-blocking mode by using an interceptor of a spring framework; according to the unique service identifier of the service request, the http sub-request can be conveniently known to belong to which http service request is a complete request flow; however, it is difficult to know who is the call initiator of the http sub-request and who calls the http sub-request, and in order to solve the problem, before reporting kafka from the generation of the http sub-request, a mark needs to be added to each http sub-request, where the marks refer to the first mark and the second mark.

Specifically, when an http sub-request initiated by a micro-service is detected, determining whether the current http sub-request exists in a previous http sub-request according to the service identifier; if the http sub-request exists, generating a first identifier for the current http sub-request, and integrating the first identifier of the previous http sub-request and a second identifier of the current http sub-request to be used as a new second identifier of the current http sub-request; and if the http sub-request does not exist, generating a first identifier for the current http sub-request, and setting a second identifier of the current http sub-request to be null.

The service identifier is that an http service request with traceId is generated only once at the beginning, and the service identifier traceId is carried in an http sub-request header when the http request is called downwards.

The first identification is generated once every http sub-request, the first identification is different every time, when the http sub-request is called downwards, the currently generated first identification is used as a second identification of the next http sub-request and is continuously transmitted downwards, and the second identification is continuously accumulated every time the http sub-request is called downwards so as to record a service calling path of the http sub-request. It is noted that the second identification is empty at the beginning of the http traffic request.

And 204, aggregating the http sub-requests based on a preset aggregation strategy and a service identifier to obtain a request link corresponding to the service request.

In the mobile internet, a complete http service request is no longer simply calling a certain service, but involves a plurality of N micro-services, and the depth and breadth of the micro-services are not fixed, for example, calling a service in a service. It is therefore necessary to mark http traffic requests in order to identify which http traffic request flow some http sub-requests are incoming. The embodiment can realize recording and tracking by generating a service identifier for each http service request flow. The service identifier has the following characteristics:

1) each time the user makes http service requests, taking a system including three micro services, namely a member center service, a coupon service and a user basic service as an example, as shown in fig. 3, a dotted arrow is a call path between services of a coupon, and a solid arrow is a call path between services of query:

service request for user coupon (coupon):

a. a user initiates an http service request (/ hczlife-coupon/showCoupon) of a coupon to call a coupon center service;

b. the coupon center service initiates an http sub-request (/ member-center/queryLevel) to call the member center service to acquire the user level;

c. and the coupon center service inquires the coupon meeting the current grade according to the obtained user member grade and displays the coupon.

Service request (query) for user to view basic information in member center:

a. the user initiates an http service request (/ member-center/userInfo) of the query to call the member center service;

b. the http sub-request (/ hczlife-coupon/userInfo) of the member center service calls the coupon center service, and the http sub-request (/ user-info/getInfo) of the coupon center service is sent to the user basic service to acquire the user basic information [ in this case, the user basic information may be caused by the wrong interface of the developer ] and the like;

c. and the member center service performs basic packaging and returns related information.

As can be known from fig. 3, under various http service requests, the member center service and the coupon center service form a loop call (there is a call between them), and in this case, if the http sub-request is not limited and sorted, it is difficult for the user to know which services have an irregular interface between them after the operation fails. No matter how deep the call depth is and how wide the call width is, the service identifier will not change, i.e. the http service request has uniqueness; this service identification is called traceID in the mobile internet, but in one http service request flow, there may be multiple invocations between microservices.

Since the collected http sub-request data is asynchronously reported by each node, a period of time is required for the whole request link to be called, and in order to obtain a complete request link and facilitate storage, a sliding window is introduced in the embodiment. Here the sliding window defines a time that is less than a majority of the service request time.

Therefore, in some embodiments, the present application may aggregate http sub-requests by using a sliding window function on the flink: setting a sliding window according to preset window configuration data, wherein the sliding window comprises a window starting point, a window length and a moving step length; and moving a sliding window with the window length being a preset value according to the moving step length from the starting point of the window, wherein each time the sliding window moves once, the http sub-requests in the sliding window are aggregated according to the service identifier until the moving times of the sliding window reach the preset times.

Specifically, taking a system with member center service, coupon service and rights service as an example, the http request flow for the user to get the coupon is as follows:

1) a user initiates a coupon card through an http service request;

2) the coupon service calls a member center service to acquire the current user member information;

3) the coupon service judges whether the current membership grade is met or not according to the coupon ID, and if the current membership grade is met, the next step is carried out;

4) the ticket leading service calls the rights and interests service through the http request to realize the rights and interests of the user;

in the http service request flow, the reported data has three time periods, and due to the adoption of kafka asynchronous reporting, the order of the reported http sub-request data reaching the flight may be inconsistent. Therefore, in order to obtain a complete http request link, this embodiment may be implemented by using a sliding window, where the sliding window is composed of several basic elements, namely a window start point, a window length, and a moving step size. After receiving the reported data, the Flink adds a current time stamp to the currently reported data, for example, the time of first receiving the reported http sub-request is taken as a window starting point, the window length is set to 2 minutes, and the sliding window is moved once every minute.

Namely, setting a sliding window according to preset window configuration data, wherein the sliding window comprises a window starting point, a window length and a moving step length; and moving a sliding window with the window length being a preset value according to the moving step length from the starting point of the window, wherein each time the sliding window moves once, the http sub-requests in the sliding window are aggregated according to the service identifier until the moving times of the sliding window reach the preset times. Acquiring a service identifier of the http sub-request in the sliding window during aggregation; and storing the http sub-requests with the same service identification into the same link list to obtain the request link.

Specific examples are as follows:

for example, we use the starting time of the current sliding window of 2020-10-2610: 22:40, the window length of 2 minutes, and the window moving step size of 1 minute (the latest time acceptable for the current window is 2020-10-2610: 35:40)

First window time [ start: 2020-10-2610: 33:40, end: 2020-10-2610: 35:40

Second window time [ start: 2020-10-2610: 34:40, end: 2020-10-2610:36: 40

Third window time [ start: 2020-10-2610: 35:40, end: 2020-10-2610: 37:40

According to the above, if the sliding step length of the sliding window is smaller than the window length, the overlapping part occurs, and the abnormal condition of data reporting at this time is as follows:

reporting data 1 and an interface: service,/hczlife-coupon/draw: hczlife-coupon, traceId: t _2315678, spanId: coupon _1234, time: 2020-10-2610:34:50

Reporting data 2,

Interface: the/member-center/queryLevel service: memer-center, traceId: t-2315678, span Id: memer-1234, pSpanId: coupon-1234, time: 2020-10-2610:35:00

Report data 3, (report data comparison delay in kafka due to equity network problems)

Interface: service,/hczlife-benefit/sendBenefit: icore-common-benefit, traceId: t-2315678, pSpanId: memer-1234, span Id: benefit-1234, time: 2020-10-2610:36:30

As can be seen from the above, the report data 1 and the report data 2 are in the first sliding window, the report data 1 and the report data 2 are also in the second sliding window, and the report data 3 is also in the second sliding window, and the request link aggregation process of the first sliding window is as follows: it will put the http sub-request of the same service identity (traceID) in a List, which we can understand as putting it in a Map < String, List < Object > > where the key is traceID and the values are as follows:

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

the link aggregation process of the window two is basically consistent with the window process as follows, but because the data report 3 is also in the sliding window two, the request link aggregated in the sliding window two is also longer, as follows:

[{"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"}]

the sliding window refers to a range of overall movement using a certain interval. Since a normal http request will complete the request within two minutes, if an excessively large time window is used, the overall performance of the system will be affected too much when flink aggregation will result. The sliding window is slid by 1 minute in order to reduce the http request link aggregation frequency. Flink consumes the requested data in kafka, and the data consumption amount is that the maximum time difference of the front message and the back message is 2 minutes; the messages of flink in 2 minutes are subjected to map statistics through service identification (wherein, the key is traceID, and the value is a link list); the flink will go through the requested data in kafka in turn and can get the list of the same link. The obtained request link comprises the URL address and the service name of the requested micro-service.

And step 206, performing deduplication processing on the request link through a bloom algorithm to obtain a deduplicated request link.

Further, Flink may consume http sub-requests reported to kafka in real time according to a preset consumption policy, and since a large number of requests, such as second-killing-time-first-purchase requests, may be requested in a short time for some requests of micro-services, in order to ensure that only one request is required for the same request in a period of time, a bloom algorithm may be used to perform deduplication processing on a sorted request link. The bloom algorithm is a space-efficient random data structure that uses bit arrays to represent a set in a compact manner and to determine whether an element belongs to the set.

Removing the first identification and the second identification of each http sub-request in the link list to obtain a list of the to-be-removed links; calculating a hash value of the to-be-deleted link list; judging whether the hash value exists in Redis to obtain a judgment result; if the judgment result is that the hash value does not exist, uploading a request link corresponding to the list of the links to be duplicated to Redis as the request link after duplication elimination; and if the judgment result is that the hash value exists, deleting the request link corresponding to the to-be-deleted link list.

Specifically, for such a request link:

when calculating whether the character string exists in Redis, specifically, the first identifier (span) and the second identifier (pspanid) in the character string are removed, and then the removed character string is subjected to hash calculation for multiple times and then is subjected to deduplication judgment in Redis. If not present in Redis, the call relationship begins to be consolidated, since pSpanId will indicate its parent node data (which service calls it).

Further, if there is a hit request link in Redis, the request link is deleted. The term deleting the request link means that the http request link is not sent to the kafka to continue processing. In this way, whether the current request link is the same as the previous one or not is judged, if so, the current request link is directly ended, and if not, the current request link is reported to the kafka to wait for consumption.

And 208, determining a calling relationship between the micro services corresponding to each http sub-request in the request link after the duplication is removed based on the first identifier and the second identifier, and acquiring a loop relationship between the micro services through a depth-first algorithm based on the calling relationship.

The depth-first algorithm is implemented in a recursive and backtracking manner. After the flink consuming task is finished, the server will sort out the calling relationship between every two microservices, and record the calling relationship between every two microservices, for example, store the calling relationship in the form of map data structure, such as key (service name), value (service list called down), for example:

the keys are represented by a value of [ activity-factor-base, icore-aops-activity-module, icore-hczlife-present-share, icore-hczlife-nci ]

Traversing the key in the map data structure above and obtaining its corresponding value, here the first name in the service list is obtained and the next round of recursion is started. The number specified in this embodiment may take 20 until the next service name is itself or the depth is greater than the specified number. If the service name is the current starting service name after recursion, recording, if the depth is larger than the specified number, ending, backtracking to the previous layer, acquiring another service name in the service list, and then starting the next recursion round.

Step 210, storing the call relationship and the loop relationship in Redis in a loop list manner, and obtaining a corresponding loop list according to a micro-service name input by a user to obtain a loop analysis condition.

A general user initiates a loop calling request to a server through a terminal, the loop calling request includes name data of a certain micro service that the user wants to view, and the server queries a loop list corresponding to the micro service in Redis according to the name of the micro service. If the loop call exists, the loop list comprises that a certain service has closed loop call in a large amount of http service requests, and the loop condition also relates to a loop length depth and a service interface related to the service call closed loop. In this way, it is possible to quickly check which interfaces are involved in a certain service loop, and provide data support for service function boundary splitting.

In the method for dynamically analyzing the loop calling condition among the services, a first identifier and a second identifier are generated for each http sub-request, then link aggregation processing is carried out on the sub-requests according to the service identifiers, finally the calling relation among the micro-services is obtained through the first identifier and the second identifier, and based on the calling relation, whether the loop relation exists among the micro-services is obtained through a depth-first algorithm, if so, the calling relation and the loop relation are stored into a loop list together, and when a user needs the method, the name of the service can be directly input, so that the calling relation among the services can be quickly obtained; by the method, the loop calling information can be obtained in time, the calling condition between services can be rapidly positioned, the reliability between system services is improved, and the operation and maintenance cost is reduced.

It should be understood that, although the steps in the flowchart of fig. 2 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a portion of the steps in fig. 2 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performance of the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

In one embodiment, as shown in fig. 4, there is provided an apparatus for dynamically analyzing a call loop condition between services, where the apparatus for dynamically analyzing a call loop condition between services corresponds to the method for dynamically analyzing a call loop condition between services in the above embodiment. The device for dynamically analyzing the loop calling condition among services is applied to a service system which comprises a plurality of micro services and has calling among the micro services, wherein when a service request of a user is responded, the service system generates an http sub-request for each calling among the micro services, wherein the service request comprises a service identifier, and one service request comprises at least two http sub-requests, and comprises the following steps:

an identification module 402, configured to generate a first identifier and a second identifier for each http sub-request, where the first identifier is used to identify uniqueness of each http sub-request in the service request, and the second identifier is used to identify a call relationship between micro services in the http sub-request;

the aggregation module 404 is configured to aggregate the http sub-requests based on a preset aggregation policy and a service identifier to obtain a request link corresponding to the service request;

a duplicate removal module 406, configured to perform duplicate removal processing on the request link through a bloom algorithm to obtain a duplicate-removed request link;

a relation module 408, configured to determine, based on the first identifier and the second identifier, a call relation between micro services corresponding to http sub-requests in the request link after deduplication, and obtain, based on the call relation, a loop relation between the micro services through a depth-first algorithm;

and the analysis module 410 is configured to store the call relationship and the loop relationship in the Redis in a manner of a loop list, and obtain a corresponding loop list according to a micro service name input by a user to obtain a loop analysis condition.

Further, an identification module comprising:

the detection submodule is used for determining whether the current http sub-request exists in the previous http sub-request or not according to the service identifier when the http sub-request initiated by the micro service is detected;

the first identification submodule is used for generating a first identification for the current http sub-request if the first identification exists, and integrating the first identification of the previous http sub-request and a second identification of the current http sub-request to be used as a new second identification of the current http sub-request;

and the second identification submodule is used for generating a first identification for the current http sub-request and setting the second identification of the current http sub-request as null if the first identification does not exist.

Further, the aggregation module 404 includes:

the configuration submodule is used for setting a sliding window according to preset window configuration data, wherein the sliding window comprises a window starting point, a window length and a moving step length;

and the aggregation submodule is used for moving the sliding window with the preset window length according to the moving step length from the starting point of the window, wherein the http sub-requests in the sliding window are aggregated according to the service identifier every time the sliding window moves once until the moving times of the sliding window reach the preset times.

Further, an aggregation submodule, comprising:

the identification unit is used for acquiring the service identification of the http sub-request in the sliding window;

and the aggregation unit is used for storing the http sub-requests with the same service identification into the same link list to obtain the request link.

Further, the http sub-request further includes a name and a URL address of the micro-service, the request link is subjected to deduplication processing by a bloom algorithm to obtain a deduplicated request link, and the deduplication module 406 includes:

the removing submodule is used for removing the first identification and the second identification of each http sub-request in the link list to obtain a to-be-removed link list;

the calculation submodule is used for calculating a hash value of the to-be-deleted link list; and are

The judgment submodule is used for judging whether the hash value exists in the Redis to obtain a judgment result;

a first result sub-module, configured to upload, as a request link after deduplication, a request link corresponding to the list of to-be-deduplicated links to Redis if the determination result is that the hash value does not exist;

and the second result submodule is used for deleting the request link corresponding to the to-be-deleted link list if the judgment result is that the hash value exists.

Further, the relationship module 408 includes:

the calling submodule is used for determining the calling relation among the micro services in each request link according to the second identifier of each http sub-request;

an initial sub-module, configured to determine an initial micro-service in the request link according to the first identifier and the second identifier, where the initial micro-service is a micro-service invoked first after the service request is initiated;

the depth submodule is used for obtaining the calling depth of each request link according to the initial micro service and the calling relation;

and the loop submodule is used for determining the loop relation among the micro services of the request links based on the calling depth.

The device for dynamically analyzing the loop calling condition among the services generates a first identifier and a second identifier for each http sub-request, then performs link aggregation processing on the sub-requests according to the service identifiers, finally obtains the calling relationship among the micro-services through the first identifier and the second identifier, and obtains whether the loop relationship exists among the micro-services through a depth-first algorithm based on the calling relationship, if so, the calling relationship and the loop relationship are stored in a loop list together, and when a user needs the device, the name of the service can be directly input, so that the calling relationship among the services can be quickly obtained; by the method, the calling condition among the loop calling information quick positioning services can be obtained in time, the reliability among system services is improved, and the operation and maintenance cost is reduced.

In one embodiment, a computer device is provided, which may be a server, the internal structure of which may be as shown in fig. 5. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer readable instructions, and a database. The internal memory provides an environment for the operating system and execution of computer-readable instructions in the non-volatile storage medium. The database of the computer device is used for storing the http sub-request. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer readable instructions, when executed by a processor, implement a method of dynamically analyzing call loop conditions between services. Generating a first identifier and a second identifier for each http sub-request, performing link aggregation processing on the sub-requests according to the service identifiers, finally obtaining a calling relationship between micro services through the first identifier and the second identifier, obtaining whether a loop relationship exists between the micro services through a depth-first algorithm based on the calling relationship, if so, storing the calling relationship and the loop relationship into a loop list together, and directly inputting a service name when a user needs to obtain the calling relationship between the services quickly; by the method, the calling condition among the loop calling information quick positioning services can be obtained in time, the reliability among system services is improved, and the operation and maintenance cost is reduced.

As will be understood by those skilled in the art, the computer device is a device capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction, and the hardware includes, but is not limited to, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), an embedded device, and the like.

Those skilled in the art will appreciate that the architecture shown in fig. 5 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer readable storage medium is provided, on which computer readable instructions are stored, and when executed by a processor, implement the steps of the method for dynamically analyzing call-loop conditions between services in the above-described embodiment, for example, the steps 202 to 210 shown in fig. 2, or implement the functions of the modules/units of the apparatus for dynamically analyzing call-loop conditions between services in the above-described embodiment, for example, the functions of the modules 402 to 410 shown in fig. 4.

Generating a first identifier and a second identifier for each http sub-request, performing link aggregation processing on the sub-requests according to the service identifiers, finally obtaining a calling relationship between micro services through the first identifier and the second identifier, obtaining whether a loop relationship exists between the micro services through a depth-first algorithm based on the calling relationship, if so, storing the calling relationship and the loop relationship into a loop list together, and directly inputting a service name when a user needs to obtain the calling relationship between the services quickly; by the method, the calling condition among the loop calling information quick positioning services can be obtained in time, the reliability among system services is improved, and the operation and maintenance cost is reduced.

It will be understood by those of ordinary skill in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware associated with computer readable instructions, which can be stored in a non-volatile computer readable storage medium, and when executed, can include processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

The block chain referred by the application is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for those skilled in the art, without departing from the spirit and scope of the present invention, several changes, modifications and equivalent substitutions of some technical features may be made, and these changes or substitutions do not make the essence of the same technical solution depart from the spirit and scope of the technical solution of the embodiments of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A method for dynamically analyzing the calling loop condition between services is applied to a service system which comprises a plurality of micro services and has calling among the micro services, wherein when responding to a service request of a user, the service system generates an http sub-request for each calling among the micro services, wherein the service request comprises a service identifier, and one service request comprises at least two http sub-requests, and is characterized in that the method comprises the following steps:

2. The method of claim 1, wherein generating the first identifier and the second identifier for each http sub-request comprises:

when an http sub-request initiated by the micro-service is detected, determining whether the current http sub-request is stored in a previous http sub-request according to the service identifier;

if the http sub-request exists, generating a first identifier for the current http sub-request, and integrating the first identifier of the previous http sub-request and a second identifier of the current http sub-request to be used as a new second identifier of the current http sub-request;

and if the http sub-request does not exist, generating a first identifier for the current http sub-request, and setting a second identifier of the current http sub-request to be null.

3. The method according to claim 1, wherein the aggregating each http sub-request based on a preset aggregation policy and a service identifier to obtain a request link corresponding to the service request comprises:

setting a sliding window according to preset window configuration data, wherein the sliding window comprises a window starting point, a window length and a moving step length;

and moving a sliding window with the window length being a preset value according to the moving step length from the starting point of the window, wherein each time the sliding window moves once, the http sub-requests in the sliding window are aggregated according to the service identifier until the moving times of the sliding window reach the preset times.

4. The method of claim 3, wherein the aggregating http sub-requests within the sliding window according to the service identifier comprises:

acquiring a service identifier of the http sub-request in the sliding window;

and storing the http sub-requests with the same service identification into the same link list to obtain the request link.

5. The method according to claim 1, wherein the http sub-request further includes a name and a URL address of the micro-service, and the performing deduplication processing on the request link through a bloom algorithm to obtain a deduplicated request link includes:

removing the first identification and the second identification of each http sub-request in the link list to obtain a list of the to-be-removed links;

calculating a hash value of the to-be-deleted link list; and are

Judging whether the hash value exists in Redis to obtain a judgment result;

if the judgment result is that the hash value does not exist, uploading a request link corresponding to the list of the links to be duplicated to Redis as the request link after duplication elimination;

and if the judgment result is that the hash value exists, deleting the request link corresponding to the to-be-deleted link list.

6. The method according to claim 1, wherein the determining, based on the first identifier and the second identifier, a call relationship between micro services corresponding to http sub-requests in the deduplicated request link, and obtaining, based on the call relationship, a loop relationship between the micro services through a depth-first algorithm includes:

determining a calling relation between the micro-services in each request link according to the second identifier of each http sub-request;

determining an initial micro-service in the request link according to the first identifier and the second identifier, wherein the initial micro-service is a micro-service called first after the service request is initiated;

obtaining the calling relation of each request link according to the initial micro service and the calling relation;

and determining a loop relation between the micro-services of the request links based on the calling relation.

7. A device for dynamically analyzing the call loop condition between services is applied to a service system which comprises a plurality of micro services and has calls among the micro services, wherein when responding to a service request of a user, the service system generates an http sub-request for each call among the micro services, wherein the service request comprises a service identifier, and one service request comprises at least two http sub-requests, and the device is characterized by comprising:

8. The apparatus of claim 7, wherein the identification module comprises:

9. A computer device comprising a memory and a processor, the memory storing computer readable instructions, wherein the processor when executing the computer readable instructions implements the steps of the method of any one of claims 1 to 6.

10. A computer readable storage medium having computer readable instructions stored thereon, which when executed by a processor implement the steps of the method of any one of claims 1 to 6.