Microservice invocation data processing method, apparatus, medium, and device

Abstract

The application discloses a micro-service calling data processing method and device, medium and equipment, relates to the technical field of micro-service, and comprises the following steps: acquiring current calling data generated in a current micro-service calling process, the current micro-service being a micro-service called in response to a service request for a business service; determining a cache historical calling data set corresponding to the business service; the calling relationship of a historical micro-service corresponding to each historical calling data in the historical calling data set is in a first preset state; according to the current calling data and the historical calling data set, a target micro-service with a calling relationship in the first preset state is subjected to calling relationship state updating; and the target micro-service comprises the current micro-service and the historical micro-service. The application continuously updates the micro-service calling tree of the business service by processing the current calling data of a single current micro-service in real time, and more quickly displays the determined calling relationship.

Description

Technical Field

[0001] This application relates to the field of microservices technology, specifically to a method, apparatus, medium, and device for processing microservice call data. Background Technology

[0002] To support ever-increasing business volumes, microservice architecture is widely used in distributed systems. Internet applications are built on different sets of software modules, which may be developed by different teams, implemented using different programming languages, and deployed on thousands of servers across multiple data centers, making distributed systems increasingly complex.

[0003] Furthermore, as business services become more complex, the number of microservices involved also increases. For backend developers of distributed systems, it becomes more difficult to sort out the call relationships of the microservices corresponding to each business service, thus making it impossible to efficiently track the microservice call process. Summary of the Invention

[0004] To improve the efficiency of determining microservice call relationships and achieve real-time determination of microservice call relationships, this application provides a microservice call data processing method, apparatus, medium, and device. The technical solution is as follows:

[0005] Firstly, this application provides a microservice call data processing method, the method comprising:

[0006] Obtain the current call data generated during the current microservice call process, wherein the current microservice is the microservice that is called in response to a service request for a business service;

[0007] Determine the historical call data set corresponding to the cached business service; the call relationship of the historical microservices corresponding to each historical call data in the historical call data set is in a first preset state;

[0008] Based on the current call data and the historical call data set, the call relationship status of the target microservice in the first preset state is updated; the target microservice includes the current microservice and the historical microservice.

[0009] Secondly, this application provides a microservice call data processing apparatus, the apparatus comprising:

[0010] The current call data acquisition module is used to acquire the current call data generated during the current microservice call process, wherein the current microservice is the microservice that is called in response to a service request for a business service;

[0011] The historical call data determination module is used to determine the historical call data set corresponding to the cached business service; the call relationship of the historical microservices corresponding to each historical call data in the historical call data set is in a first preset state.

[0012] The call relationship determination module is used to update the call relationship status of a target microservice whose call relationship is in a first preset state based on the current call data and the historical call data set; the target microservice includes the current microservice and the historical microservice.

[0013] Thirdly, this application provides a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement a microservice call data processing method as described in the first aspect.

[0014] Fourthly, this application provides a computer device including a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement a microservice call data processing method as described in the first aspect.

[0015] Fifthly, this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform a microservice call data processing method as described in the first aspect.

[0016] This application provides a microservice call data processing method, apparatus, medium, and device, which have the following technical effects:

[0017] This application provides a method for determining microservice call relationships in real time. For the current call data of a single current microservice, combined with a cached set of historical call data (the call relationships of the historical microservices corresponding to each historical call data in the historical call data set are unknown), the method determines the possible call relationships between the current microservice and the historical microservices. That is, by processing the call data of a newly acquired single microservice in real time and continuously updating the microservice call tree of the business service, the method can more quickly display the partial or complete call chain of the business service, avoiding the low processing efficiency caused by waiting for call data to be collected. At the same time, it can quickly record the call status of the same microservice. Furthermore, it can be combined with offline methods to determine the call status between different microservice clusters, which is convenient for backend personnel to supervise and maintain.

[0018] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0019] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the implementation environment of a microservice call data processing method provided in an embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating a microservice call data processing method provided in an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of a process for determining the call data of the current microservice, provided in an embodiment of this application.

[0023] Figure 4 This is a flowchart illustrating a method for determining a calling relationship, provided in an embodiment of this application.

[0024] Figure 5 This is a schematic diagram of another process for determining the calling relationship provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of another process for determining the calling relationship provided in an embodiment of this application;

[0026] Figure 7 This is a schematic diagram of another structure for determining the calling relationship provided in an embodiment of this application;

[0027] Figure 8 This is a flowchart illustrating a process for determining the call tree of a business service, provided in an embodiment of this application.

[0028] Figure 9 This is a schematic diagram illustrating the effect of displaying a call tree for business services, provided in an embodiment of this application.

[0029] Figure 10 This is a schematic diagram of the architecture of a microservice call monitoring system provided in an embodiment of this application;

[0030] Figure 11 This is a schematic diagram of a process for generating call data provided in an embodiment of this application;

[0031] Figure 12 This is a schematic diagram illustrating the splitting of a microservice call tree provided in an embodiment of this application;

[0032] Figure 13 This is a schematic diagram of a microservice invocation relationship provided in an embodiment of this application;

[0033] Figure 14 This is a flowchart illustrating a method for determining a calling relationship, provided in an embodiment of this application.

[0034] Figure 15 This is a schematic diagram illustrating a cross-regional data retrieval method provided in an embodiment of this application;

[0035] Figure 16 This is a schematic diagram illustrating the effect of microservice call relationships provided in an embodiment of this application;

[0036] Figure 17 This is a schematic diagram of a microservice call data processing device provided in an embodiment of this application;

[0037] Figure 18 This is a schematic diagram of the hardware structure of a device for implementing a microservice call data processing method, provided in an embodiment of this application. Detailed Implementation

[0038] To determine the invocation relationships of microservices in real time, embodiments of this application provide a microservice invocation data processing method, apparatus, medium, and device. The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout.

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0040] To facilitate understanding of the technical solutions and their effects described in the embodiments of this application, the relevant technical terms are explained in the embodiments of this application:

[0041] Microservices: A software development technique that is a variation of the service-oriented architecture style, constructing an application as a set of loosely coupled services. In a microservices architecture, services are fine-grained, and protocols are lightweight.

[0042] RPC: Remote Procedure Call; Remote Procedure Call crosses the transport and application layers in the Open Systems Interconnection (OSI) network communication model, making application development easier.

[0043] Please see Figure 1 This is a schematic diagram illustrating the implementation environment of a microservice call data processing method provided in an embodiment of this application, such as... Figure 1 As shown, the implementation environment may include at least client 01, server 02, and server 03.

[0044] Specifically, the client 01 may include devices such as smartphones, desktop computers, tablets, laptops, digital assistants, smart wearable devices, monitoring devices, and voice interaction devices. It may also include software running on the device, such as web pages provided to users by service providers, or applications provided by those service providers. Specifically, the client 01 can be used to initiate service requests for business services to the server 02 to invoke the corresponding microservices.

[0045] Specifically, server 02 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Server 02 may include network communication units, processors, and memory, etc. Terminals and servers can be connected directly or indirectly via wired or wireless communication, which is not limited herein. Specifically, server 02 can be used to respond to user service requests, remotely invoke microservices, and report the invoked data to server 03.

[0046] Specifically, the server 03 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The server 03 may include a network communication unit, a processor, and memory, etc. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein. Specifically, the server 03 can be used to collect and process reported call data in real time, determining the call relationships of one or more microservices related to the reported call data.

[0047] This application embodiment can also be implemented using cloud technology. Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It can also be understood as a general term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on cloud computing business models. Cloud technology requires cloud computing as its support. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." Specifically, server 02, server 03, and the database are located in the cloud. Server 02 and server 03 can be physical machines or virtualized machines.

[0048] The following describes a microservice call data processing method provided in this application. Figure 2 This is a flowchart illustrating a microservice call data processing method provided in this application. This application provides the operational steps described in the embodiments or flowchart, but based on conventional or non-inventive methods, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Please refer to... Figure 2 The microservice call data processing method provided in this application embodiment may include the following steps:

[0049] S210: Obtain the current call data generated during the current microservice call process, wherein the current microservice is the microservice that is called in response to a service request for a business service.

[0050] Understandably, in a microservice architecture, a business service often involves calls to multiple microservices. Since these microservices may be deployed on different servers, a remote procedure call (RPC) framework can be used to invoke each microservice to complete the response to service requests. To effectively monitor distributed systems using a microservice architecture, such as for fault location, call chain analysis, capacity assessment, or performance analysis, it is necessary to record the microservices called within the system in response to each service request, as well as the call relationships between these microservices—a process also known as call chain tracing. For example, live streaming functionality includes: a broadcasting system, a live chat system, a competitive system, a bullet screen system, a leaderboard system, a payment system, and a VIP system. As live streaming functionality becomes increasingly complex, the deployment of microservices in multiple locations or clusters makes call chain analysis difficult.

[0051] In this embodiment, each microservice in the microservice architecture is configured with an interface component. When a microservice is invoked, the invocation information is reported through the interface component to determine the corresponding invocation data. The invocation data may include a business identifier corresponding to the service request (or business service), a span identifier representing the invocation span, and may also include the span identifier of the previous span, the microservice interface name, the time consumption information, business extension information, etc.

[0052] In one embodiment of this application, before step S210, as follows: Figure 3 As shown, the method may further include the following steps:

[0053] S201: In response to a service request for a business service, execute a target remote procedure call on the current microservice.

[0054] Understandably, for each service request, the system assigns a business identifier. For example, when a microservice involved in a service request makes a call, the remote procedure call framework passes the business identifier to the downstream microservice via in-band data. For each microservice called in response to a service request for a business service, the business identifier in its call data is the same. Therefore, the call data set corresponding to the business service and the corresponding set of microservices can be determined based on the business identifier.

[0055] S203: At the start and end times of executing the target remote procedure call, first call data and second call data are generated accordingly.

[0056] In one feasible implementation, based on a remote procedure call (RPC) framework, first call data and second call data are generated at the start and end times of each RPC. For example, when microservice A remotely calls microservice B, where microservice A is the calling microservice and microservice B is the called microservice, first call data is generated when microservice A initiates the call, and second call data is generated when microservice B receives the call information. Both the first and second call data include the same span identifier representing the call span.

[0057] S205: Determine the current call data of the current microservice based on the first call data and the second call data; the current call data includes a business identifier corresponding to the service request and a span identifier representing the call span.

[0058] In one feasible implementation, since the first call data and the second call data include the same span identifier representing the call span, the first call data and the second call data can be merged, and the resulting call data can be used as the call data of the called microservice. For example, in the above embodiment, the first call data and the second call data are merged and used as the call data of microservice B.

[0059] In another embodiment of this application, if the current microservice is the first microservice to be called in the business service, then when calling the current microservice, the current call data is directly generated.

[0060] S230: Determine the set of historical call data corresponding to the cached business service; the call relationship of the historical microservices corresponding to each historical call data in the set of historical call data is in a first preset state.

[0061] Understandably, in a microservice architecture, a business service often involves calls to multiple microservices. Since these microservices may be deployed on different servers or server clusters, the order in which the call data for each microservice is obtained may not match the actual call order. Therefore, some microservices may have their call relationships temporarily uncertain. A common method for generating call relationships offline involves waiting for a certain period to gather call data from all the microservices involved in the business service, thus determining the call relationships between them. However, this method is inefficient and time-consuming.

[0062] In this embodiment, local microservice call data can be used to determine local call relationships within a business service in real time and continuously update the microservice call tree of the business service. This allows for rapid identification of the call chain within the business service and rapid, real-time updates to the call status of individual microservices, enabling efficient monitoring of the microservice framework. Before obtaining the current call data of the current microservice, call data of a portion of the microservices within the business service may have already been obtained. Unlike offline call relationship generation methods, if the call relationship of a certain microservice within this portion of microservices can be determined first, then the call relationship of that microservice is directly added to the microservice call tree of the business service. The remaining microservices whose call relationships are not yet fully determined are treated as historical microservices, and their corresponding call data constitutes a historical call data set. That is, the call relationship being in a first preset state indicates that the call relationship is not fully determined. In one embodiment of this application, the call relationship may include forward call relationships and backward call relationships. The first preset state can characterize that the forward call relationship and backward call relationship are not fully determined; it may be that only one of them is determined or both are unknown.

[0063] For example, for microservice A, the forward call relationship of microservice A in the business service can be represented by the starting microservice (i.e., the root node microservice), the preceding microservice (i.e., the parent node microservice), and the microservice identifier of microservice A. The backward call relationship of microservice A in the business service can be represented by the starting microservice, microservice A, and the microservice identifier of the following microservice (i.e., the child node microservice). When a set of forward and backward call relationships for microservice A is determined, that is, the link position of microservice A is uniquely determined in the microservice call tree of the business service. Preferably, for the starting microservice (i.e., the root node microservice) of the business service, only the backward call relationship needs to be determined. If the backward call relationship of the starting microservice has been determined before the current call data of the current microservice is obtained, in order to facilitate the determination of the call relationship of historical microservices or the current microservice, the starting microservice can still be regarded as a special historical microservice, but the starting microservice can be skipped when determining the call relationship of historical microservices in the later stage.

[0064] S250: Based on the current call data and the historical call data set, update the call relationship status of the target microservice whose call relationship is in a first preset state; the target microservice includes the current microservice and the historical microservice.

[0065] In this embodiment, when the current call data of the current microservice is obtained, the current call data can be processed in real time. Specifically, by combining the historical call data set, it is possible to attempt to determine the forward or backward call relationship of the current microservice, or to attempt to determine the forward or backward call relationship of one or more historical microservices.

[0066] In the embodiments of this application, the call chain of microservices in the business service is stored in the form of a call tree, where each microservice is a node in the call tree. In another feasible implementation, a call interface of a microservice can also be used as a node in the call tree, which belongs to the same concept as the embodiments provided in this application and will not be described in detail here.

[0067] For a microservice (which is not the root microservice in this case), identifying the root, parent, and child microservices of the business service is equivalent to determining the microservice's forward and backward call relationships within the business service, thus uniquely determining its position in the microservice call tree of the business service. Therefore, the call relationships can be determined based on the node types of the current microservice and each historical microservice within the business service.

[0068] Specifically, such as Figure 4 As shown, step S250 may include the following steps:

[0069] S400: Based on the historical call data set, determine the historical microservices without root nodes to obtain the first historical microservice set.

[0070] It is understood that in the historical call data set corresponding to the business service, the historical microservices corresponding to each historical call data are all microservices involved in the business service.

[0071] S410: Determine the first service node type of the current microservice in the business service.

[0072] For example, based on a tree structure, the current microservice can be the root node microservice of the call tree, the parent node microservice of a certain microservice, or the child node microservice of a certain microservice.

[0073] S430: When the first service node type is a root node, find the parent node microservice and child node microservice corresponding to each first historical microservice in the first historical microservice set according to the historical call data set.

[0074] In other words, for each first historical microservice, now that the root node microservice has been determined, to determine the calling relationship of each first historical microservice, it is also necessary to determine the parent node microservice and child node microservice corresponding to each first historical microservice.

[0075] S450: If found, the call relationship corresponding to each of the first historical microservices is determined based on the current microservice and the parent node microservice and child node microservice corresponding to each of the first historical microservices; the call relationship includes forward call relationship and backward call relationship.

[0076] In one feasible implementation, for a certain first historical microservice, if no corresponding parent node microservice is found, the child node microservice of the first historical microservice can be searched in the second historical microservice set, which consists of historical microservices without parent nodes; if a parent node microservice is found, the backward call relationship of the first historical microservice can be determined, and the first historical microservice can be added as a second historical microservice to the second historical microservice set.

[0077] Specifically, such as Figure 5 As shown, step S250 may further include the following steps:

[0078] S410: Determine the first service node type of the current microservice in the business service.

[0079] S420: When the first service node type is not the root node, determine the second service node type of each historical microservice in the business service.

[0080] S440: When none of the second service node types are root nodes, update the historical call data set according to the current call data.

[0081] In the above embodiments, since it is determined that neither the current microservice nor any of the historical microservices are the root node microservices of the business service, the call relationships between the current microservice and each of the historical microservices are yet to be determined. Furthermore, because the call relationship of the current microservice is unknown, the current microservice can be considered a historical microservice, and the current call data can be considered historical call data, thereby updating the historical call data set. Further, in this case, since no root node microservice has yet emerged, the current microservice is also still the first historical microservice.

[0082] Specifically, such as Figure 6 As shown, step S250 may further include the following steps:

[0083] S410: Determine the first service node type of the current microservice in the business service.

[0084] S420: When the first service node type is not the root node, determine the second service node type of each historical microservice in the business service.

[0085] S421: When the second service node type includes a root node, the parent node microservice corresponding to the current microservice is found according to the historical call data set.

[0086] S423: If found, then determine the forward call relationship of the current microservice based on the root node microservice corresponding to the root node, the current microservice, and the parent node microservice corresponding to the current microservice.

[0087] In another feasible implementation, such as Figure 7 As shown, when searching for the parent node microservice corresponding to the current microservice based on the historical call data set, the method may further include the following steps:

[0088] S424: If not found, determine the historical microservices without parent nodes based on the historical call data set, and obtain a second set of historical microservices based on the historical microservices without parent nodes.

[0089] S425: Search for the child node microservice corresponding to the current microservice in the second set of historical microservices.

[0090] S426: If found, then determine the backward call relationship of the current microservice based on the root node microservice corresponding to the root node, the current microservice, and the child node microservices corresponding to the current microservice.

[0091] S427: Update the historical call data set based on the current call data and the call data corresponding to the sub-node microservice.

[0092] In other words, in this scenario, the parent node microservice of the current microservice does not exist, but the child node microservice of the current microservice exists and also belongs to the second historical microservice set. Therefore, once the backward call relationship of the current microservice is determined, it is equivalent to determining the parent node microservice of the child node microservice (that is, determining the forward call relationship of the child node microservice). Thus, the child node microservice needs to be removed from the second historical microservice set. Furthermore, if the backward call data of the child node microservice has also been determined, the call data of the child node microservice also needs to be removed from the historical call data set. At the same time, the current microservice is added as a second historical microservice to the second historical microservice set, that is, the current microservice is treated as a historical microservice, and the current call data is correspondingly added to the historical call data set.

[0093] In this embodiment, local microservice call data can be used to determine local call relationships within business services in real time and continuously update the microservice call tree of the business services. Simultaneously, the approach of generating call relationships offline can be combined with this method. For example, for a distributed cluster, call data within the same microservice cluster can be reported to the nearest computing cluster for real-time processing. For call data across microservice clusters, the offline approach can be referenced, aggregating call data by cluster and processing it separately by the corresponding asynchronous computing cluster of each cluster, thereby determining the call relationships between microservice clusters.

[0094] In one embodiment of this application, such as Figure 8 As shown, the method may further include the following steps:

[0095] S271: Determine the microservice call tree corresponding to the business service.

[0096] The microservice call tree stores data on the call chain of the business services.

[0097] S272: Update the microservice call tree according to the call relationship of the microservice with unknown call relationship in the business service.

[0098] S273: In response to a request to view the call chain for the business service, display the microservice call chain for the business service according to the microservice call tree corresponding to the business service.

[0099] For example, the microservice call chain of the business service demonstrated by the method provided in the embodiments of this application can be as follows: Figure 9 As shown, Figure 9 The "Name" column lists the microservices invoked for the information flow monetization business service. GetAds is the root microservice for this business service, and the following are microservices at different invocation levels. Furthermore, based on the invocation data of each microservice, information such as the backend API calls, call ratios, success rates, and execution times can be displayed. This allows backend personnel to familiarize themselves with and understand the distributed system architecture, identify the corresponding service call chains, and further facilitates viewing the call relationships between microservice clusters or locating faults related to unreasonable calls within the microservice cluster.

[0100] Figure 10 This is a schematic diagram of the architecture of a microservice call monitoring system provided in an embodiment of this application, such as... Figure 10As shown, the system is mainly divided into four modules: a microservice API (Application Programming Interface) module (embedded in the user service), a real-time computing cluster, an offline compensation cluster, and a management terminal. The microservice API module generates call data during the RPC process and the proxy connects to the nearest real-time computing cluster. For call data written to Ckafka (Cloud Kafka, a distributed, high-throughput, highly scalable messaging system), the Flink (an open-source stream processing framework) cluster processes the call data in real time, storing the determined call relationships in HBase (a distributed, column-oriented open-source database) according to the corresponding data storage format. Simultaneously, some data used for retrieval, such as microservice names and business identifiers, are stored in ES (Elasticsearch, a distributed, multi-user full-text search engine).

[0101] Specifically, such as Figure 11 As shown, the microservice API module is embedded in the user service's microservice framework to construct the data that needs to be reported to the real-time computing cluster. Referring to the OpenTracing specification, for each service request issued by the user targeting the business service, a trace_id is first generated, and simultaneously, a data span for reporting is generated for each RPC. Specifically:

[0102] A trace represents a complete request chain process. The trace_id can be composed of an IP address (Internet Protocol Address), a random number, a tid (thread identifier), and a seq (incrementing sequence of the request's RPC).

[0103] span_ctx represents the context information for cross-service transmission, containing information such as trace_id, span_id, parent_id, and sampling flags. span_id is the span identifier that represents the span of the call, and parent_id is the span_id of the previous span of the current span.

[0104] `span` represents the data structure for event tracking reports, which can contain information such as `trace_id`, `span_id`, `parent_id`, `caller` (the calling microservice), `callee` (the called microservice), `ifc_name` (the microservice's interface name), `result` (the call result), `time` (the time), and business extensions.

[0105] In one feasible implementation, the link data is generated in the microservice API module, such as... Figure 11The Span1c, Span1s, Span1.1c, and Span1.1s shown.

[0106] Specifically, the real-time computing cluster is mainly used to process the reported link data locally. First, the link data is summarized according to the span identifier (span_id) to obtain a call data, which corresponds to a called microservice.

[0107] In the method provided in the embodiments of this application, in order to process microservice call data, the microservice call relationship is configured as follows: Figure 12 The splitting method shown is as follows: For the ultimate goal of generating a microservice call tree for business services, the tree structure can be split into multiple independent edges based on the tree structure of the call tree, where each edge requires a maximum of only three call data. Figure 12 In the example, SvrA:ifc1 represents interface 1 of microservice A. In the embodiments of this application, ifc is equivalent to interface.

[0108] If the final stored structure is a forward call tree, it is commonly stored using the structure [root, (a, b)], where root, a, and b are nodes of the tree. Figure 13 The two sides shown can be represented as:

[0109] [appid_Svr1:interface_1, (Svr1:interface_1, Svr2:interface_1) ];

[0110] [appid_Svr1:interface_1, (Svr1:interface_1, Svr3:interface_1) ];

[0111] Among them, appid_Svr1:interface_1 represents the root node microservice of the call tree of the business service named appid.

[0112] In the method provided in the embodiments of this application, the storage structure of the forward call tree is optimized to consist of [root, (A, B)] in combination with the data storage format in HBase;

[0113] In storage such as Figure 13 The two sides shown can be represented as:

[0114] Day_appid_Svr1_interface_1:[(Svr1:interface_1,Svr2:interface_1),(Svr1:interface_1, Svr3:interface_1)];

[0115] The root (such as Day_appid_Svr1_interface_1) can point to a unique call tree, and A and B are call chains respectively; the two call chains starting from Svr1:interface_1 are stored in the same ColumnFamilies, and the column key can be if:Svr1_interface1.

[0116] When recording the call details of a specific microservice node, a structure similar to the following can be used for storage:

[0117] Day_appid_Svr1_interface_1_tree:

[0118] [Day_appid_Svr1_interface_1, Day_ appid_Svr1_interface2]

[0119] The above structure can both identify which microservice nodes a call tree contains and query which call trees have invoked a specific microservice node.

[0120] If the final stored data is a reverse call tree, you can retrieve the data from the forward call tree and then reverse the edge processing.

[0121] The above is the design for splitting the tree structure. Figure 14 The diagram shows the specific real-time computing flowchart algorithm, which is essentially the reverse of the design process. Cache A is used to cache call data where the root node was not found, and cache B is used to cache call data where the parent node was not found. For a detailed explanation, please refer to [link / reference]. Figure 2 The method provided in the illustrated embodiment will not be described in detail here. It should be noted that when traversing the microservice nodes corresponding to cache A, the microservice nodes corresponding to cache A are treated as... Figure 14 The curSpan shown in the figure determines the forward and backward call relationships of the microservice node corresponding to cache A. When traversing the microservice node corresponding to cache B, the microservice node corresponding to the new span (i.e., curRoot) is used as curSpan, which is the determination of the current microservice call relationship as described in the method embodiment.

[0122] Specifically, asynchronous offline computing clusters are primarily used to handle cross-regional data calls. Real-time computing effectively manages RPC calls within the same region, but for a small number of cross-cluster calls, data from different regions needs to be aggregated. Asynchronous computing clusters identify this cross-cluster data and process it separately. For example... Figure 15 As shown, cross-cluster call data can also be divided into two categories: those for which a corresponding root node has not yet been found, and those for which a corresponding parent node has not yet been found. For example, Span2 and Span2.1 in the Shanghai cluster have no corresponding root node, while Span2.1.1 in the Shenzhen cluster has no corresponding parent node. Furthermore, cross-cluster call data can be filtered, such as using an LRU (Least Recently Used) eviction algorithm. If cross-cluster call data is evicted, an offline compensation mechanism is triggered, asynchronously calculating the call tree by aggregating call data within a certain time period.

[0123] Specifically, the management interface primarily facilitates backend personnel in viewing the call chain of business services and the call status of individual microservices. For example, such as... Figure 16 As shown, you can query the call chain of multiple microservices within a specific business service based on the trace_id, as well as the word call relationships and call status of each microservice within that business service. For example, you can also... Figure 9 The call relationships at the microservice interface level are shown.

[0124] This application also provides a microservice call data processing device 1700, such as... Figure 17 As shown, the device 1700 may include:

[0125] The current call data acquisition module 1710 is used to acquire the current call data generated during the current microservice call process, wherein the current microservice is the microservice that is called in response to a service request for a business service;

[0126] The historical call data determination module 1720 is used to determine the historical call data set corresponding to the cached business service; the call relationship of the historical microservices corresponding to each historical call data in the historical call data set is in a first preset state.

[0127] The call relationship determination module 1730 is used to update the call relationship status of a target microservice whose call relationship is in a first preset state based on the current call data and the historical call data set; the target microservice includes the current microservice and the historical microservice.

[0128] In one embodiment of this application, the current call data acquisition module 1710 may include:

[0129] The invocation unit is used to execute a target remote procedure call on the current microservice in response to a service request for a business service.

[0130] The data generation unit is used to generate first call data and second call data at the start and end times of executing the target remote procedure call, respectively.

[0131] The data reporting unit is used to determine the current call data of the current microservice based on the first call data and the second call data; the current call data includes a business identifier corresponding to the service request and a span identifier representing the call span.

[0132] In one embodiment of this application, the call relationship determination module 1730 may include:

[0133] The first set determination unit is used to determine the historical microservices without root nodes based on the historical call data set, and obtain the first historical microservice set;

[0134] The first service node type determination unit is used to determine the first service node type of the current microservice in the business service;

[0135] The parent-child node determination unit is used to find the parent node microservice and child node microservice corresponding to each first historical microservice in the first historical microservice set according to the historical call data set when the first service node type is a root node.

[0136] The first unit for determining the call relationship is used to determine the call relationship corresponding to each of the first historical microservices if a match is found, based on the current microservice and the parent and child microservices corresponding to each of the first historical microservices; the call relationship includes a forward call relationship and a backward call relationship.

[0137] In one embodiment of this application, the call relationship determination module 1730 may include:

[0138] The second service node type determination unit is used to determine the second service node type of each historical microservice in the business service when the first service node type is not the root node.

[0139] The first update unit for the historical call data set is used to update the historical call data set according to the current call data when none of the second service node types are root nodes.

[0140] In one embodiment of this application, the call relationship determination module 1730 may include:

[0141] The parent node determination unit is used to find the parent node microservice corresponding to the current microservice based on the historical call data set when the second service node type includes the root node.

[0142] The forward call relationship determination unit is used to determine the forward call relationship of the current microservice based on the root node microservice corresponding to the root node, the current microservice, and the parent node microservice corresponding to the current microservice if the relationship is found.

[0143] In one embodiment of this application, the call relationship determination module 1730 may include:

[0144] The second set determination unit is used to determine the historical microservices without parent nodes based on the historical call data set if no parent node is found, and to obtain the second historical microservice set based on the historical microservices without parent nodes.

[0145] The child node determination unit is used to find the child node microservice corresponding to the current microservice in the second historical microservice set;

[0146] The backward call relationship determination unit is used to determine the backward call relationship of the current microservice based on the root node microservice corresponding to the root node, the current microservice, and the child node microservice corresponding to the current microservice if the relationship is found.

[0147] The historical call data set update unit is used to update the historical call data set based on the current call data and the call data corresponding to the sub-node microservice.

[0148] In one embodiment of this application, the device 1700 may further include:

[0149] The microservice call tree determination unit is used to determine the microservice call tree corresponding to the business service;

[0150] The microservice call tree update unit is used to update the microservice call tree according to the call relationship of microservices with unknown call relationships in the business service.

[0151] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0152] This application provides a computer device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement a microservice call data processing method as provided in the above method embodiments.

[0153] Figure 18 A schematic diagram of the hardware structure of a device for implementing a microservice call data processing method provided in the embodiments of this application is shown. This device may participate in or include the apparatus or system provided in the embodiments of this application. Figure 18 As shown, device 18 may include one or more processors 1802 (shown as 1802a, 1802b, ..., 1802n in the figure) 1802 (processor 1802 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 1804 for storing data, and a transmission device 1806 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 18 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 18 may also include a... Figure 18 The more or fewer components shown, or having the same Figure 18 The different configurations shown.

[0154] It should be noted that the aforementioned one or more processors 1802 and / or other data processing circuitry are generally referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within device 18 (or mobile device). As involved in the embodiments of this application, this data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0155] The memory 1804 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this application. The processor 1802 executes various functional applications and data processing by running the software programs and modules stored in the memory 1804, thereby realizing the microservice call data processing method described above. The memory 1804 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1804 may further include memory remotely located relative to the processor 1802, and these remote memories can be connected to the device 18 via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0156] The transmission device 1806 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 18. In one example, the transmission device 1806 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 1806 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0157] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of device 18 (or mobile device).

[0158] This application also provides a computer-readable storage medium, which can be disposed in a server to store at least one instruction or at least one program related to implementing a microservice call data processing method in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the microservice call data processing method provided in the above method embodiment.

[0159] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0160] This invention also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional embodiments described above.

[0161] As can be seen from the embodiments of the microservice call data processing method, apparatus, medium and device provided in this application above,

[0162] This application provides a method for determining microservice call relationships in real time. For the current call data of a single current microservice, combined with a cached set of historical call data (the call relationships of the historical microservices corresponding to each historical call data in the historical call data set are unknown), the method determines the possible call relationships between the current microservice and the historical microservices. That is, by processing the call data of a single microservice in real time, the microservice call tree of the business service is continuously updated, which can more quickly display the partial or complete call chain of the business service, avoiding the low processing efficiency caused by waiting for call data to be collected. At the same time, it can quickly record the call status of the same microservice. Furthermore, it can be combined with offline methods to determine the call status between different microservice clusters, which is convenient for backend personnel to supervise and maintain.

[0163] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0164] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0165] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0166] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A microservice call data processing method, characterized in that, The method includes: Obtain the current call data generated during the current microservice call process, wherein the current microservice is the microservice that is called in response to a service request for a business service; Determine the historical call data set corresponding to the cached business service; the call relationship of the historical microservices corresponding to each historical call data in the historical call data set is in a first preset state; Based on the current call data and the historical call data set, the call relationship status of the target microservice in a first preset state is updated; the target microservice includes the current microservice and the historical microservice. The step of updating the call relationship status of the target microservice whose call relationship is in a first preset state based on the current call data and the historical call data set includes: Based on the historical call data set, identify the historical microservices without root nodes to obtain the first set of historical microservices; Determine the type of the first service node of the current microservice within the business service; When the first service node type is a root node, the parent node microservice and child node microservice corresponding to each first historical microservice in the first historical microservice set are found according to the historical call data set. If found, the call relationship corresponding to each of the first historical microservices is determined based on the current microservice and the parent and child microservices corresponding to each of the first historical microservices; the call relationship includes forward call relationship and backward call relationship.

2. The method according to claim 1, characterized in that, The method further includes: When the first service node type is not a root node, and the second service node type of each historical microservice in the business service is not a root node, the historical call data set is updated according to the current call data.

3. The method according to claim 1, characterized in that, The step of updating the call relationship status of the target microservice whose call relationship is in a first preset state based on the current call data and the historical call data set further includes: When the first service node type of the current microservice in the business service is not the root node, and the second service node type of each of the historical microservices in the business service includes the root node, the parent node microservice corresponding to the current microservice is found according to the historical call data set. If found, the forward call relationship of the current microservice is determined based on the root node microservice corresponding to the root node, the current microservice, and the parent node microservice corresponding to the current microservice.

4. The method according to claim 3, characterized in that, The method further includes: If not found, then based on the historical call data set, determine the historical microservices without parent nodes, and obtain a second set of historical microservices based on the historical microservices without parent nodes; Search for the child node microservice corresponding to the current microservice in the second historical microservice set; If found, the backward call relationship of the current microservice is determined based on the root node microservice corresponding to the root node, the current microservice, and the child node microservices corresponding to the current microservice. Update the historical call data set based on the current call data and the call data corresponding to the sub-node microservice.

5. The method according to claim 1, characterized in that, The method further includes: Determine the microservice call tree corresponding to the business service; Update the microservice call tree based on the call relationships of microservices with unknown call relationships within the business service.

6. The method according to claim 1, characterized in that, The step of obtaining the current call data generated during the current microservice call includes: In response to a service request for a business service, execute a target remote procedure call on the current microservice; At the start and end times of the execution of the target remote procedure call, first call data and second call data are generated accordingly. Based on the first call data and the second call data, the current call data of the current microservice is determined; the current call data includes a business identifier corresponding to the service request and a span identifier representing the call span.

7. A microservice call data processing device, characterized in that, The device includes: The current call data acquisition module is used to acquire the current call data generated during the current microservice call process, wherein the current microservice is the microservice that is called in response to a service request for a business service; The historical call data determination module is used to determine the historical call data set corresponding to the cached business service; the call relationship of the historical microservices corresponding to each historical call data in the historical call data set is in a first preset state. The call relationship determination module is used to update the call relationship status of a target microservice whose call relationship is in a first preset state based on the current call data and the historical call data set; the target microservice includes the current microservice and the historical microservice; The call relationship determination module includes: The first set determination unit is used to determine the historical microservices without root nodes based on the historical call data set, and obtain the first historical microservice set; The first service node type determination unit is used to determine the first service node type of the current microservice in the business service; The parent-child node determination unit is used to find the parent node microservice and child node microservice corresponding to each first historical microservice in the first historical microservice set according to the historical call data set when the first service node type is a root node. The first unit for determining the call relationship is used to determine the call relationship corresponding to each of the first historical microservices if a match is found, based on the current microservice and the parent and child microservices corresponding to each of the first historical microservices; the call relationship includes a forward call relationship and a backward call relationship.

8. The apparatus according to claim 7, characterized in that, The call relationship determination module also includes: The second service node type determination unit is used to determine the second service node type of each historical microservice in the business service when the first service node type is not the root node. The first update unit for the historical call data set is used to update the historical call data set according to the current call data when none of the second service node types are root nodes.

9. The apparatus according to claim 8, characterized in that, The call relationship determination module includes: The parent node determination unit is used to find the parent node microservice corresponding to the current microservice based on the historical call data set when the second service node type includes the root node. The forward call relationship determination unit is used to determine the forward call relationship of the current microservice based on the root node microservice corresponding to the root node, the current microservice, and the parent node microservice corresponding to the current microservice if the relationship is found.

10. The apparatus according to claim 9, characterized in that, The call relationship determination module includes: The second set determination unit is used to determine the historical microservices without parent nodes based on the historical call data set if no parent node is found, and to obtain the second historical microservice set based on the historical microservices without parent nodes. The child node determination unit is used to find the child node microservice corresponding to the current microservice in the second historical microservice set; The backward call relationship determination unit is used to determine the backward call relationship of the current microservice based on the root node microservice corresponding to the root node, the current microservice, and the child node microservice corresponding to the current microservice if the relationship is found. The historical call data set update unit is used to update the historical call data set based on the current call data and the call data corresponding to the sub-node microservice.

11. The apparatus according to claim 7, characterized in that, The device further includes: The microservice call tree determination unit is used to determine the microservice call tree corresponding to the business service; The microservice call tree update unit is used to update the microservice call tree according to the call relationship of microservices with unknown call relationships in the business service.

12. The apparatus according to claim 7, characterized in that, The currently invoked data acquisition module includes: The invocation unit is used to execute a target remote procedure call on the current microservice in response to a service request for a business service. The data generation unit is used to generate first call data and second call data at the start and end times of executing the target remote procedure call, respectively. The data reporting unit is used to determine the current call data of the current microservice based on the first call data and the second call data; the current call data includes a business identifier corresponding to the service request and a span identifier representing the call span.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement a microservice call data processing method as described in any one of claims 1 to 6.

14. A computer device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor as a microservice call data processing method as described in any one of claims 1 to 6.

Images