Micro-service management method and related equipment

Abstract

The invention provides a micro-service management method, which is applied to a micro-service management system, the system comprises a registration device, a first micro-service and at least one second micro-service, and the method comprises the following steps: the first micro-service sends a query request to the registration device to obtain a query result, and sends a detection message to the at least one second micro-service to obtain a detection state, the detection message comprises an instance identifier of a second micro-service acquired from the registration device, the detection state is used for identifying whether the instance identifier of the second micro-service in the detection message is consistent with a current instance identifier of the second micro-service, and the first micro-service determines a target micro-service from the at least one second micro-service according to the query result and the detection state, and the first micro-service calls the target micro-service to communicate with the target micro-service. The instance state information is autonomously maintained among the micro-services, and large-scale communication faults among the micro-services caused by the fact that a registration center feeds back available instance list information by mistake after a network isolation fault occurs are avoided.

Description

[0001] This application claims the priority of the Chinese patent application filed with the State Intellectual Property Office on July 20, 2023, with application number 202310896427.3 and invention name “A Microservice Management Method and Related System”, all contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of microservice technology, and in particular to a microservice management method, system, computing device cluster, computer-readable storage medium, and computer program product. Background Art

[0003] Microservice architecture refers to a loosely coupled distributed architecture used to develop applications (especially large applications). Through the microservice architecture, large applications can be decomposed into multiple independent components, also called microservices, and different microservices can implement different functions. Different microservices can communicate with each other through well-defined application programming interfaces (APIs).

[0004] As a registration and discovery mechanism that supports the microservice architecture, it plays a vital role in the reliable operation of microservices. Specifically, multiple microservices of an application can be divided into microservice providers and microservice consumers according to the provision of microservices or the invocation of microservices. Microservice providers send metadata information (such as host and port number) to the registration center for registration, and microservice consumers initiate queries to the registration center to obtain a list of available microservices (for example, a list of available microservice providers). Accordingly, microservice consumers can call microservices based on the metadata information of the microservice provider in the microservice list returned by the registration.

[0005] However, the above registration discovery mechanism has natural defects in network partition isolation, which brings great challenges to the reliability of microservices in high-availability scenarios such as cross-availability zone (AZ) disaster recovery and cross-region disaster recovery. For example, the microservice provider and microservice consumer may be located in different AZs. When the network between the microservice provider and the registration center fails, while the network between the microservice consumer and the registration center is normal, the registration center will mistakenly believe that the microservice provider has gone offline. After the microservice consumer obtains this information, the microservice consumer will not access the microservice provider in subsequent requests, which brings potential risks to system functions or performance. Summary of the invention

[0006] The present application provides a microservice management method, in which directly communicating microservice providers and microservice consumers autonomously maintain instance status information, avoiding the registration center's incorrect feedback of available instance list information after a network isolation failure occurs, resulting in large-scale communication failures between microservices, solving the reliability problem of requests between microservices in the scenario of network partition isolation failure of the registration center, and reducing the potential risk of system functions or performance. The present application also provides a microservice management system, a computer-readable storage medium, and a computer program product corresponding to the above method.

[0007] In the first aspect, the present application provides a microservice management method. The method is applied to a microservice management system. The microservice management system may be a software system, which may be deployed in a computing device cluster, and the computing device cluster executes the program code of the microservice management system, thereby executing the microservice management method of the present application. The microservice management system may also be a hardware system, such as a computing device cluster with microservice management functions. When the hardware system is running, the microservice management method of the present application is executed.

[0008] The microservice management system includes a registration device, a first microservice and at least one second microservice. The registration device is used to receive a registration request of at least one second microservice, and register an instance identifier of at least one second microservice according to the registration request. Specifically, the first microservice sends a query request to the registration device to obtain a query result, and sends a detection message to at least one second microservice to obtain a detection state, the detection message includes an instance identifier (identifier, ID) of the second microservice obtained from the registration device, and the detection state is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice. The first microservice determines a target microservice from at least one second microservice based on the query result and the detection state. The first microservice calls the target microservice to communicate with the target microservice.

[0009] In this method, a microservice provider (such as the second microservice) registers an instance ID, which is bound to the execution unit (such as a process) of the microservice. When the process is restarted, the instance ID will also change. The instance ID can uniquely identify the process, so that in large-scale instance, virtualization and other deployment scenarios, it can prevent microservice consumers (such as the first microservice) from sending detection messages (such as PING messages) to the wrong microservice provider. In this way, in the network partition isolation failure scenario, the microservice provider and microservice consumer that communicate directly can independently maintain the instance status information to avoid the registration center from incorrectly feeding back the available instance list information after the network isolation failure occurs, resulting in large-scale communication failures between microservices. This method solves the reliability problem of requests between microservices in the registration center network partition isolation failure scenario, especially the reliability problem of requests in high-availability and high-reliability scenarios such as multi-AZ and cross-Region deployment of microservice applications, as well as microservice containerization, large-scale instance deployment and other scenarios.

[0010] In some possible implementations, the first microservice determines the priority of at least one second microservice based on the query result and the detection status, and then the first microservice determines a target microservice from the at least one second microservice based on the priority of the at least one second microservice, and the priority of the target microservice meets the set condition.

[0011] The method comprehensively determines the priority of the second microservice by combining the query result from the registration center and the detection status, and selects the target microservice for calling based on the priority. It can select a microservice with high reliability for calling, thereby ensuring high availability and high reliability.

[0012] In some possible implementations, the first microservice determines the priority of at least one second microservice based on the query result and the detection state. When the query result represents the instance identifier of the second microservice queried from the registration device, and the detection state represents that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines the priority of the second microservice to be the first priority. Alternatively, when the query result represents that the instance identifier of the second microservice is not queried from the registration device, and the detection state represents that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines the priority of the second microservice to be the second priority. Alternatively, when the query result represents the instance identifier of the second microservice queried from the registration device, and the detection state represents that the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice, the first microservice determines the priority of the second microservice to be the third priority. Among them, the first priority is higher than the second priority, and the second priority is higher than the third priority.

[0013] For example, the first priority can be a high priority, the second priority can be a normal priority, and the third priority can be a low priority. If an instance of a microservice is found from the registration center and the PING is normal, the instance can be assigned to the high priority group; if an instance of a microservice is not found from the registration center, but the PING is normal, the instance can be assigned to the normal priority group; if an instance of a microservice is found from the registration center, but the PING is abnormal, the instance can be assigned to the low priority group.

[0014] Since the decision on the microservice to call is made by combining information such as the detection status of autonomous detection between services, it can avoid the registration center incorrectly feeding back the list of available instances after a network isolation failure occurs, resulting in large-scale communication failures between microservices. This solves the reliability problem of requests between microservices in the scenario of network partition isolation failure of the registration center.

[0015] In some possible implementations, the instance identifier of the second microservice is bound to the execution unit of the second microservice. When the execution unit of the second microservice is restarted, the instance identifier of the second microservice is updated along with the restart of the execution unit. The instance identifier can uniquely identify the execution unit (such as a process), so that in deployment scenarios such as large-scale instances and virtualization, it can prevent microservice consumers (such as the first microservice) from sending detection messages (such as PING messages) to the wrong microservice provider.

[0016] In some possible implementations, the execution unit includes a process or a thread. The process or thread usually has a unique identifier that can identify the execution unit. When the execution unit is restarted, the above identifier can also be updated accordingly. In this way, in deployment scenarios such as large-scale instances and virtualization, it can prevent the microservice consumer (such as the first microservice) from sending a detection message to the wrong microservice provider.

[0017] In some possible implementations, the microservice management system further includes a first sidecar and a second sidecar. Accordingly, when the first microservice sends a query request to the registration device to obtain a query result, the query result can be obtained by sending a query request to the registration device through the first sidecar (the sidecar of the first microservice). Similarly, when the first microservice sends a detection message to the at least one second microservice to obtain a detection status, the detection status can be obtained by sending a detection message to the second sidecar (the sidecar of the second microservice) of the at least one second microservice through the first sidecar. In this way, the control plane and the business plane can be separated, further improving reliability.

[0018] In some possible implementations, the first microservice and the second microservice are deployed in different availability zones or different regions, so that network partition isolation can be achieved and overall availability and reliability can be guaranteed.

[0019] In a second aspect, the present application provides a microservice management system. The microservice management system includes a registration device, a first microservice, and at least one second microservice;

[0020] The registration device is used to receive a registration request for the at least one second microservice, and register an instance identifier of the at least one second microservice according to the registration request;

[0021] The first microservice is used to send a query request to the registration device to obtain a query result, and send a detection message to the at least one second microservice to obtain a detection status, wherein the detection message includes an instance identifier of the second microservice obtained from the registration device, and the detection status is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, and then determine a target microservice from the at least one second microservice according to the query result and the detection status, and call the target microservice to communicate with the target microservice.

[0022] In some possible implementations, the first microservice is specifically used to:

[0023] The first microservice determines the priority of the at least one second microservice according to the query result and the detection status;

[0024] The first microservice determines a target microservice from the at least one second microservice according to a priority of the at least one second microservice, and the priority of the target microservice satisfies a set condition.

[0025] In some possible implementations, the first microservice is specifically used to:

[0026] When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the first priority; or,

[0027] When the query result indicates that the instance identifier of the second microservice is not found from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the second priority; or,

[0028] When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the third priority;

[0029] The first priority is higher than the second priority, and the second priority is higher than the third priority.

[0030] In some possible implementations, the instance identifier of the second microservice is bound to the execution unit of the second microservice. When the execution unit of the second microservice is restarted, the instance identifier of the second microservice is updated along with the restart of the execution unit.

[0031] In some possible implementations, the execution unit includes a process or a thread.

[0032] In some possible implementations, the microservice management system further includes a first sidecar and a second sidecar;

[0033] The first microservice is specifically used for:

[0034] The first side car sends a query request to the registration device to obtain a query result, and the first side car sends a detection message to the second side car of the at least one second microservice to obtain a detection status.

[0035] In some possible implementations, the first microservice and the second microservice are deployed in different availability zones or different regions.

[0036] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory, so that the computing device or the computing device cluster executes the microservice management method as described in the first aspect or any one of the implementations of the first aspect.

[0037] In a fourth aspect, the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, wherein the instructions instruct a computing device or a computing device cluster to execute the microservice management method described in the first aspect or any one of the implementations of the first aspect.

[0038] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computing device or a computing device cluster, enables the computing device or the computing device cluster to execute the microservice management method described in the first aspect or any one of the implementations of the first aspect.

[0039] Based on the implementations provided in the above aspects, the present application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings required for use in the embodiments are briefly introduced below.

[0041] Figure 1 A schematic diagram of a working mechanism of registration discovery in a classic mode and a sidecar mode provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of network partition fault isolation provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram of a compensation mechanism for service registration discovery provided in an embodiment of the present application;

[0044] Figure 4 A flowchart of a microservice management method provided in an embodiment of the present application;

[0045] Figure 5 A schematic diagram of a scenario in which a microservice management method provided in an embodiment of the present application is applied to disaster recovery in an availability zone;

[0046] Figure 6 A schematic diagram of a scenario in which a microservice management method provided in an embodiment of the present application is applied to disaster recovery in an availability zone;

[0047] Figure 7 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0048] Figure 8 A schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application;

[0049] Fig. 9 A schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application;

[0050] Fig.10 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The terms "first" and "second" in the embodiments of the present application are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.

[0052] First, some technical terms involved in the embodiments of the present application are introduced.

[0053] Registration discovery refers to service registration and service discovery. Service registration refers to registering the metadata information of the service (usually the IP and port of the service) to a public component; service discovery means that newly registered services can be discovered by service callers in a timely manner. It should be noted that service discovery can include automatic discovery of new services or service deletions. The called service is also called a service provider (if it is a microservice, it can also be called a microservice provider), and the service that calls other services is also called a service consumer (if it is a microservice, it can also be called a microservice consumer).

[0054] In a microservice architecture, registration discovery usually works in two ways: classic mode and sidecar mode. Figure 1 The working mechanism of registration discovery in classic mode and sidecar mode is shown. In classic mode, the microservice provider registers its own metadata information with the registration center, and the microservice consumer queries the registration center for the metadata information of the microservice provider, and accesses the microservice provider based on the metadata information of the microservice provider, such as IP and port. In sidecar mode, the above process can be completed by the sidecar. For example, the sidecar of the microservice provider can register the metadata information of the microservice provider with the registration center, and the sidecar of the microservice consumer queries the registration center for the metadata information of the microservice provider, and accesses the microservice provider based on the metadata information of the microservice provider, such as IP and port.

[0055] In a disaster recovery scenario, microservice providers and microservice consumers may be located in different regions or different availability zones (AZs). Different AZs have different network structures with the registry center. It is possible that the network between the microservice provider and the registry center fails, while the network between the microservice consumer and the registry center is normal. Figure 2 shown.

[0056] The above registration discovery mechanism has natural defects in network partition isolation failure scenarios (such as disaster recovery scenarios). When a failure occurs, the registration center will mistakenly believe that the microservice provider has gone offline. This information is obtained by the microservice consumer, and in the subsequent request process, the microservice provider will not be accessed, which brings potential risks to system functions or performance.

[0057] There are two ways for a microservice (such as a microservice provider) and a registration center to detect the online status of the microservice.

[0058] The first method is a one-way message. Specifically, the microservice sends a Heartbeat message to the registration center regularly. The Heartbeat message is used for application A (such as a microservice) to send a message to application B (such as a registration center). After application B receives the message, it determines whether application A can provide services normally based on the message content. Based on this, the registration center determines whether the microservice is online based on factors such as the frequency of the Heartbeat message and the interval time between consecutive messages.

[0059] The second method is two-way messaging. Specifically, a long connection is established between the microservice and the registration center. The long connection is used to establish a channel for message exchange between applications. There are many different protocols for long connections, such as Transmission Control Protocol (TCP), Remote Procedure Call (RPC), etc. Applications A and B that establish long connections can identify whether the other party can provide services normally through the status of the long connection channel. Based on this, the registration center can monitor the connection status of the long connection. If the long connection is disconnected and cannot be reconnected for a certain period of time, the microservice will be considered offline.

[0060] In the network partition isolation failure scenario, when the network between the microservice provider and the registration center fails, the registration center mistakenly tasks the microservice provider as offline. The industry has proposed a compensation measure. Figure 3 As shown, a PING message detection is added between microservices (for example, between a microservice provider and a microservice consumer). The Ping message is used for application A to send a message to application B. After application B receives the message, it needs to reply a message to application A. The reply message indicates whether application B can provide the service normally. Based on this, the microservice consumer can judge whether the microservice provider is normal based on the PING result returned by the microservice provider. The compensation measure generally identifies the target service based on the [IP:port] combination of the microservice provider. This measure usually works well under a static network structure. With the development of virtualization technology, especially container technology, microservices have begun to deploy thousands of instances. The [IP:port] combination of the target service often changes, and the compensation measure can lead to incorrect detection results. For example, forwarding a request to the wrong microservice instance.

[0061] In view of this, the present application provides a microservice management method. The method can be executed by a microservice management system. Among them, the microservice management system can be a software system, and the software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the microservice management system, thereby executing the microservice management method of the present application. The microservice management system can also be a hardware system, for example, a computing device cluster with microservice management functions. When the hardware system is running, the microservice management method of the present application is executed.

[0062] The microservice management system includes a registration device (also called a registration center), a first microservice and at least one second microservice. The registration device is used to receive a registration request for at least one second microservice and register an instance identifier of the at least one second microservice according to the registration request. The at least one second microservice can be discovered by the first microservice and then called by the first microservice. Based on this, the first microservice is a microservice consumer and the second microservice is a microservice provider.

[0063] Specifically, the first microservice sends a query request to the registration device to obtain a query result, and sends a detection message to at least one second microservice to obtain a detection state, the detection message includes an instance identifier (ID) of the second microservice obtained from the registration device, and the detection state is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice. The first microservice determines a target microservice from the at least one second microservice according to the query result and the detection state, and then the first microservice can call the above target microservice to communicate with the target microservice.

[0064] In this method, a microservice provider (such as the second microservice) registers an instance ID, which is bound to the execution unit (such as a process) of the microservice. When the process is restarted, the instance ID will also change. The instance ID can uniquely identify the process, so that in large-scale instance, virtualization and other deployment scenarios, it can prevent microservice consumers (such as the first microservice) from sending detection messages (such as PING messages) to the wrong microservice provider. In this way, in the network partition isolation failure scenario, the microservice provider and microservice consumer that communicate directly can independently maintain the instance status information to avoid the registration center from incorrectly feeding back the available instance list information after the network isolation failure occurs, resulting in large-scale communication failures between microservices. This method solves the reliability problem of requests between microservices in the registration center network partition isolation failure scenario, especially the reliability problem of requests in high-availability and high-reliability scenarios such as multi-AZ and cross-Region deployment of microservice applications, as well as microservice containerization, large-scale instance deployment and other scenarios.

[0065] The microservice management method of this application can be applied to Figure 1Specifically, the microservice architecture includes a microservice management system, and the microservice management system includes a registration device ( Figure 1 The registration center in the first microservice ( Figure 1 microservice consumer) and at least one second microservice ( Figure 1 microservice provider).

[0066] The registration device is used to receive a registration request for the at least one second microservice, and register the instance ID of the at least one second microservice according to the registration request. The first microservice is used to send a query request to the registration device to obtain a query result, and to send a detection message to at least one second microservice to obtain a detection status, wherein the detection message includes an instance identifier of the second microservice obtained from the registration device, and the detection status is used to identify whether the instance ID of the second microservice in the detection message is consistent with the current instance ID of the second microservice. The first microservice is also used to determine a target microservice from the at least one second microservice according to the query result and the detection status, and then call the target microservice to communicate with the target microservice.

[0067] The first microservice and the second microservice may be deployed on different computing devices, such as servers deployed in different regions or servers deployed in different AZs. In addition, the registration device may also be deployed in other regions outside the region where the microservice is located, or in other AZs outside the AZ where the microservice is located, which is not limited in this embodiment.

[0068] Based on the aforementioned microservice management system, the present application also provides a microservice management method. The microservice management method of the present application is introduced below in conjunction with an embodiment.

[0069] See also Figure 4 The flowchart of a microservice management method shown in the figure is applied to a microservice management system, wherein the microservice management system includes a registration device, a first microservice and at least one second microservice, wherein the registration device is used to receive a registration request of at least one second microservice and register an instance ID of at least one second microservice according to the registration request. The method includes the following steps:

[0070] S402: The first microservice sends a query request to the registration device to obtain a query result.

[0071] When the first microservice needs to call other microservices, service discovery can be triggered to obtain metadata information of the callable microservices. Specifically, the first microservice can send a query request to the registration device, and the query request is used to query the metadata information of the available microservices. The metadata information may include the instance ID of the microservice. The registration center can respond to the above query request to query the metadata information of the microservice that is still connected to the registration center and obtain the query result. The query result may include the instance ID of the microservice that is still connected to the registration center in at least one second microservice.

[0072] S404: The first microservice sends a detection message to at least one second microservice to obtain a detection status.

[0073] The detection message includes an instance identifier of the second microservice obtained from the registration device, and the detection state is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice. Wherein, if the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the detection state is normal; if the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice, the detection state is abnormal.

[0074] Specifically, the detection message may be a PING message. The PING message may carry the instance ID of the second microservice that was most recently obtained. The first microservice sends a Ping message to at least one second microservice, and determines the detection status of at least one second microservice based on the reply of the at least one second microservice. For example, if the first microservice does not receive a reply message from the second microservice within the set time, or the reply message indicates that the detection status is abnormal, it means that the detection status of the second microservice is abnormal. Among them, when receiving the PING message, the second microservice can detect the instance ID of the second microservice in the PING message and the current instance ID of the second microservice. If they are inconsistent, the second microservice can reply to the message, indicating that the detection status is abnormal. If they are consistent, the message can be replied to report that the detection status is normal.

[0075] In some possible implementations, the instance ID of the second microservice is bound to the execution unit of the second microservice. When the execution unit of the second microservice is restarted, the instance ID of the second microservice is updated along with the restart of the execution unit. The execution unit is used to execute code to provide microservices. In some examples, the execution unit can be a process, that is, the instance ID of the second microservice is bound to the process of the second microservice. When the process of the second microservice is restarted, the instance ID of the second microservice is also updated. In other examples, the execution unit can also be a thread. Based on this, the second microservice can detect that the instance ID of the second microservice in the PING message is inconsistent with the current instance ID of the second microservice.

[0076] It should be noted that the above S402 and S404 can be executed in parallel, or executed successively according to a set order, and the embodiment of the present application does not limit this.

[0077] S406: The first microservice determines a target microservice from at least one second microservice according to the query result and the detection status.

[0078] The query result may include the instance ID of the available microservice. The first microservice may determine the target microservice from at least one second microservice according to the instance ID of the available microservice and the detection status of at least one second microservice detected based on the instance ID. The first microservice may group at least one microservice according to the instance ID of the available microservice and the detection status of at least one second microservice detected based on the instance ID, and select the target microservice from at least one second microservice according to the grouping result.

[0079] In some possible implementations, the first microservice may determine the priority of at least one second microservice based on the query result (such as the instance ID of the available microservice) and the detection status (such as the result of the PING message). The first microservice may group at least one second microservice (specifically an instance of the microservice) based on the query result and the detection status, and determine the priority of at least one second microservice based on the grouping. Then, the first microservice may determine the target microservice from the at least one second microservice based on the priority of the at least one second microservice. The priority of the target microservice satisfies the set condition. For example, the priority satisfying the set condition may be the highest priority or the priority reaching the set priority.

[0080] The following is an example of the priority determination process under different query results and different detection states.

[0081] When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice (that is, the detection state is normal), the first microservice can determine that the priority of the second microservice is the first priority. The first priority can be a high priority, for example, the highest priority.

[0082] When the query result indicates that the instance identifier of the second microservice is not found from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice (i.e., the detection state is normal), the first microservice may determine that the priority of the second microservice is the second priority. The second priority (also referred to as the normal priority) may be lower than the first priority.

[0083] When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice (i.e., the detection state is abnormal), the first microservice determines that the priority of the second microservice is the third priority. The third priority may be lower than the second priority. The third priority may be a low priority.

[0084] S408: The first microservice calls the target microservice to communicate with the target microservice.

[0085] Specifically, the first microservice can obtain the IP and port of the target microservice, for example, by obtaining the IP and port of the target microservice from the metadata information of the available microservices queried from the registration center, and sending a call request to the target microservice according to the IP and port of the target microservice, thereby calling the target microservice and communicating with the target microservice.

[0086] In some possible implementations, the first microservice and the second microservice can be deployed in different availability zones (AZs) or different regions. In a network partition isolation failure scenario, if the network between the second microservice and the registration device (such as a registration center) fails, the microservice provider and microservice consumer that communicate directly can maintain the instance status information themselves to avoid the registration center's incorrect feedback of the available instance list information after the network isolation failure occurs, resulting in a large-scale communication failure between microservices.

[0087] It should be noted that the first microservice can interact with the registration center and the second microservice directly, or can interact with the registration center and the second microservice through a sidecar. Specifically, the microservice management system also includes a first sidecar and a second sidecar. Accordingly, when the first microservice obtains the query result, it can send a query request to the registration device through the first sidecar to obtain the query result. When the first microservice obtains the detection status, it can send a detection message to at least one second sidecar of the second microservice through the first sidecar to obtain the detection status.

[0088] Based on the above description, the present application provides a microservice management method. In this method, a microservice provider (such as a second microservice) registers an instance ID, and the instance ID can uniquely identify a process, so that in large-scale instance, virtualization and other deployment scenarios, it can prevent a microservice consumer (such as a first microservice) from sending a detection message (such as a PING message) to the wrong microservice provider. In this way, in a network partition isolation failure scenario, the microservice provider and microservice consumer that communicate directly can independently maintain the instance status information, avoiding the registration center from incorrectly feeding back the available instance list information after a network isolation failure occurs, resulting in a large-scale communication failure between microservices, thereby solving the reliability problem of requests between microservices in the registration center network partition isolation failure scenario.

[0089] For ease of understanding, the technical solutions of the present application are described below in combination with different application scenarios.

[0090] First, see Figure 5 The following is a schematic diagram of a microservice management method applied to AZ disaster recovery. Figure 5 This is a typical 2AZ disaster recovery microservice architecture scenario. AZ1 and AZ2 deploy multi-active microservices. The multi-active microservices can register instances in the registration center to act as microservice providers. The multi-active microservices can also act as microservice consumers and send query requests to the registration center to discover instances. Multi-active microservices can detect each other's status (i.e., detection status) through detection messages (such as PING messages).

[0091] When the registry sends a network partition fault isolation to a certain AZ, the multi-active microservice in another AZ can determine the target microservice from the isolated AZ based on the metadata information of the available microservices queried from the registry center and the detection status obtained through the ping message between the multi-active microservices, and then call the target microservice to communicate with the target microservice. In this way, when the registry and a certain AZ are isolated due to a network partition fault, the communication between the multi-active microservices in different AZs is not affected.

[0092] Usually, when the network structure is different, partition network isolation failure is more likely to occur. However, even under the same network condition (such as the same network structure), network partition isolation failure may occur between different hosts and servers. In non-multi-active scenarios, the microservice management method of the present application still has the function of reliability protection.

[0093] Specifically, the user's business request can first reach the Elastic Load Balancing (ELB), which can dispatch the business request to the corresponding microservice for processing based on the load of the microservices in different availability zones. Figure 5 In the example, the user's business request can be dispatched to the microservice consumer in availability zone 2 for processing. When processing the business request, the microservice consumer can also call the microservice provider in availability zone 1. Among them, when the microservice consumer calls the microservice provider in availability zone 1, the microservice consumer can execute the aforementioned microservice management method, specifically, querying the metadata information of the available microservices from the registration center, and obtaining the detection status through ping messages between multi-active microservices, determining the target microservice from availability zone 1 according to the above metadata information and the detection status, and then calling the target microservice to communicate with the target microservice.

[0094] Next, see Figure 6The following is a schematic diagram of a microservice management method applied to AZ disaster recovery. Figure 6 This is also a typical 2AZ disaster recovery microservice architecture scenario. AZ1 and AZ2 are deployed with multi-active microservices. The multi-active microservices can register instances in the registration center to act as microservice providers. The multi-active microservices can also act as microservice consumers and send query requests to the registration center to discover instances.

[0095] Different from Figure 5 The embodiment shown, Figure 6 The illustrated embodiment implements indirect communication of multi-active microservices through sidecars. Specifically, multi-active microservices can register instances in a registration center through sidecars, thereby acting as microservice providers. Multi-active microservices can also act as microservice consumers and send query requests to the registration center through sidecars to discover instances. The sidecars of multi-active microservices detect each other's status (i.e., detection status) through detection messages (such as PING messages). It should be noted that Figure 6 The registration center in can be implemented through the sidecar management system. For example, the registration center can be a sidecar management system, which has functions such as service registration.

[0096] When the registry sends a network partition fault isolation to a certain AZ, the sidecar of the multi-active microservice in another AZ can determine the target microservice from the isolated AZ based on the metadata information of the available microservices queried from the registry center and the detection status obtained through the ping message between the multi-active microservices, and then call the target microservice to communicate with the target microservice. In this way, when the registry and a certain AZ are isolated due to network partition fault, the communication between the multi-active microservices in different AZs is not affected.

[0097] This application also provides a microservice management system, such as Figure 1 (or Figure 5 , Figure 6 ), the microservice management system includes a registration device (for example, Figure 1 The first microservice (for example, Figure 1 ) and at least one second microservice (e.g. Figure 1 Microservice providers in ).

[0098] The registration device is used to receive a registration request for the at least one second microservice, and register an instance identifier of the at least one second microservice according to the registration request;

[0099] The first microservice is used to send a query request to the registration device to obtain a query result, and send a detection message to the at least one second microservice to obtain a detection status, wherein the detection message includes an instance identifier of the second microservice obtained from the registration device, and the detection status is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, and then determine a target microservice from the at least one second microservice according to the query result and the detection status, and call the target microservice to communicate with the target microservice.

[0100] Exemplarily, the registration device, the first microservice, and the second microservice may be implemented by hardware or by software.

[0101] Among them, when implemented by software, the registration device, the first microservice, and the second microservice can be applications running on a computer device, such as a computing engine, etc. Among them, the application can be provided in the form of a virtualization service. The virtualization service can be a container service. The container service is a service that virtualizes a container resource pool on multiple physical hosts to provide containers for users to use on demand. Containers are a kernel virtualization technology that can provide lightweight virtualization to achieve the purpose of isolating user space, processes, and resources. It should be understood that the container service in the above-mentioned virtualization service is only used as a specific example. In actual applications, the virtualization service can also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0102] When implemented by hardware, the registration device, the first microservice, and the second microservice may include at least one computing device, such as a server, etc. Alternatively, the registration device, the first microservice, and the second microservice may also be implemented by using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0103] In some possible implementations, the first microservice is specifically used to:

[0104] The first microservice determines the priority of the at least one second microservice according to the query result and the detection status;

[0105] The first microservice determines a target microservice from the at least one second microservice according to a priority of the at least one second microservice, and the priority of the target microservice satisfies a set condition.

[0106] In some possible implementations, the first microservice is specifically used to:

[0107] When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the first priority; or,

[0108] When the query result indicates that the instance identifier of the second microservice is not found from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the second priority; or,

[0109] When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the third priority;

[0110] The first priority is higher than the second priority, and the second priority is higher than the third priority.

[0111] In some possible implementations, the instance identifier of the second microservice is bound to the execution unit of the second microservice. When the execution unit of the second microservice is restarted, the instance identifier of the second microservice is updated along with the restart of the execution unit.

[0112] In some possible implementations, the execution unit includes a process or a thread.

[0113] In some possible implementations, the microservice management system further includes a first sidecar and a second sidecar;

[0114] The first microservice is specifically used for:

[0115] The first side car sends a query request to the registration device to obtain a query result, and the first side car sends a detection message to the second side car of the at least one second microservice to obtain a detection status.

[0116] In some possible implementations, the first microservice and the second microservice are deployed in different availability zones or different regions.

[0117] The present application also provides a computing device 700. Figure 7 As shown, computing device 700 includes: bus 702, processor 704, memory 706 and communication interface 708. Processor 704, memory 706 and communication interface 708 communicate through bus 702. Computing device 700 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 700.

[0118] The bus 702 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The bus 702 may include a path for transmitting information between various components of the computing device 700 (eg, the memory 706, the processor 704, and the communication interface 708).

[0119] The processor 704 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0120] The memory 706 may include a volatile memory, such as a random access memory (RAM). The memory 706 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid state drive (SSD). The memory 706 stores executable program code, and the processor 704 executes the executable program code to implement the aforementioned microservice management method. Specifically, the memory 706 stores instructions for the microservice management system to execute the microservice management method. For example, the memory 706 stores instructions for the registration device, the first microservice or the second microservice in the microservice management system to execute the microservice management method.

[0121] The communication interface 708 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 700 and other devices or communication networks.

[0122] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0123] like Figure 8 As shown, the computing device cluster includes at least one computing device 700. The memory 706 in one or more computing devices 700 in the computing device cluster may store the same microservice management system for executing instructions of the microservice management method.

[0124] In some possible implementations, one or more computing devices 700 in the computing device cluster may also be used to execute some instructions of the microservice management system for executing the microservice management method. In other words, a combination of one or more computing devices 700 may jointly execute instructions of the microservice management system for executing the microservice management method.

[0125] It should be noted that the memory 706 in different computing devices 700 in the computing device cluster may store different instructions for executing partial functions of the microservice management system.

[0126] Fig. 9 A possible implementation is shown. Fig. 9As shown, three computing devices 700A, 700B, and 700C are connected via a communication interface 708. The memory in computing device 700A stores instructions for executing the function of the registration device. The memory in computing device 700B stores instructions for executing the function of the first microservice. The memory in computing device 700C stores instructions for executing the function of the second microservice. In other words, the memory 706 of computing devices 700A, 700B, and 700C jointly stores instructions for the microservice management system to execute the microservice management method.

[0127] Fig. 9 The connection method between the computing device clusters shown may be that the registration device, the first microservice, and the second microservice are respectively deployed on different computing devices 700, for example, computing devices deployed in different availability zones, considering that the microservice management method provided by the present application needs to ensure the reliability of the entire application. Therefore, it is considered that the functions implemented by the registration device, the first microservice, and the second microservice are respectively executed by computing devices 700A, 700B, and 700C.

[0128] It should be understood that Fig. 9 The functions of the computing device 700A shown in FIG. 7 may also be completed by multiple computing devices 700. Similarly, the functions of the computing device 700B may also be completed by multiple computing devices 700.

[0129] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.10 A possible implementation is shown. Fig.10 As shown, three computing devices 700D, 700E and 700F are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 706 in the computing device 700D stores instructions for executing the function of the registration device. The memory 706 in the computing device 700E stores instructions for executing the function of the first microservice. The memory in the computing device 700F stores instructions for executing the function of the second microservice.

[0130] Fig.10 The connection method between the computing device clusters shown may be that the registration device, the first microservice, and the second microservice are respectively deployed on different computing devices, such as computing devices deployed in different availability zones, considering that the microservice management method provided by the present application needs to ensure the reliability of the entire application. Therefore, it is considered that the functions implemented by the registration device, the first microservice, and the second microservice are respectively executed by computing devices 700D, 700E, and 700F.

[0131] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned application to the microservice management system for executing the microservice management method.

[0132] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above-mentioned microservice management method.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A microservice management method, characterized in that: Applied to a microservice management system, the microservice management system includes a registration device, a first microservice and at least one second microservice, the registration device is used to receive a registration request of the at least one second microservice, and register an instance identifier of the at least one second microservice according to the registration request, the method includes: The first microservice sends a query request to the registration device to obtain a query result, and sends a detection message to the at least one second microservice to obtain a detection status, wherein the detection message includes an instance identifier of the second microservice obtained from the registration device, and the detection status is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice; The first microservice determines a target microservice from the at least one second microservice according to the query result and the detection status; The first microservice calls the target microservice to communicate with the target microservice.

2. The method according to claim 1, characterized in that The first microservice determines a target microservice from the at least one second microservice according to the query result and the detection status, including: The first microservice determines the priority of the at least one second microservice according to the query result and the detection status; The first microservice determines a target microservice from the at least one second microservice according to a priority of the at least one second microservice, and the priority of the target microservice satisfies a set condition.

3. The method according to claim 2, characterized in that The first microservice determines the priority of the at least one second microservice according to the query result and the detection status, including: When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the first priority; or, When the query result indicates that the instance identifier of the second microservice is not found from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the second priority; or, When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the third priority; The first priority is higher than the second priority, and the second priority is higher than the third priority.

4. The method according to any one of claims 1 to 3, characterized in that: The instance identifier of the second microservice is bound to the execution unit of the second microservice. When the execution unit of the second microservice is restarted, the instance identifier of the second microservice is updated along with the restart of the execution unit.

5. The method according to claim 4, characterized in that The execution unit includes a process or a thread.

6. The method according to any one of claims 1 to 5, characterized in that: The microservice management system further includes a first sidecar and a second sidecar; The first microservice sends a query request to the registration device to obtain a query result, including: The first microservice sends a query request to the registration device through the first sidecar to obtain a query result; The first microservice sends a detection message to the at least one second microservice to obtain a detection status, including: The first microservice sends a detection message to the second sidecar of the at least one second microservice through the first sidecar to obtain a detection status.

7. The method according to any one of claims 1 to 6, characterized in that: The first microservice and the second microservice are deployed in different availability zones or different regions.

8. A microservice management system, characterized in that: The microservice management system includes a registration device, a first microservice and at least one second microservice; The registration device is used to receive a registration request for the at least one second microservice, and register an instance identifier of the at least one second microservice according to the registration request; The first microservice is used to send a query request to the registration device to obtain a query result, and send a detection message to the at least one second microservice to obtain a detection status, wherein the detection message includes an instance identifier of the second microservice obtained from the registration device, and the detection status is used to identify whether the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, and then determine a target microservice from the at least one second microservice according to the query result and the detection status, and call the target microservice to communicate with the target microservice.

9. The system according to claim 8, characterized in that The first microservice is specifically used for: The first microservice determines the priority of the at least one second microservice according to the query result and the detection status; The first microservice determines a target microservice from the at least one second microservice according to a priority of the at least one second microservice, and the priority of the target microservice satisfies a set condition.

10. The system according to claim 9, characterized in that The first microservice is specifically used for: When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the first priority; or, When the query result indicates that the instance identifier of the second microservice is not found from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is consistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the second priority; or, When the query result indicates that the instance identifier of the second microservice is queried from the registration device, and the detection state indicates that the instance identifier of the second microservice in the detection message is inconsistent with the current instance identifier of the second microservice, the first microservice determines that the priority of the second microservice is the third priority; The first priority is higher than the second priority, and the second priority is higher than the third priority.

11. The system according to any one of claims 8 to 10, characterized in that: The instance identifier of the second microservice is bound to the execution unit of the second microservice. When the execution unit of the second microservice is restarted, the instance identifier of the second microservice is updated along with the restart of the execution unit.

12. The system according to claim 11, characterized in that The execution unit includes a process or a thread.

13. The system according to any one of claims 8 to 12, characterized in that The microservice management system further includes a first sidecar and a second sidecar; The first microservice is specifically used for: The first side car sends a query request to the registration device to obtain a query result, and the first side car sends a detection message to the second side car of the at least one second microservice to obtain a detection status.

14. The system according to any one of claims 8 to 13, characterized in that The first microservice and the second microservice are deployed in different availability zones or different regions.

15. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the microservice management method according to any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that: Comprises computer-readable instructions; the computer-readable instructions are used to implement the microservice management method described in any one of claims 1 to 7.

17. A computer program product, characterized in that Comprises computer-readable instructions; the computer-readable instructions are used to implement the microservice management method described in any one of claims 1 to 7.

Images