Service processing method and system in heterogeneous micro-service cluster, terminal and storage medium

Abstract

The embodiment of the application discloses a service processing system and method in a heterogeneous micro-service cluster, a terminal and a storage medium, the system comprises: a global registration center cluster, at least two registration center clusters and at least two micro-service clusters; wherein, the micro-service cluster is connected with the corresponding registration center cluster; the global registration center cluster is connected with the at least two registration center clusters respectively, and is used for acquiring a first service list of the at least one registration center cluster; and the at least one first service list is format-converted to obtain a first global service list; the global registration center cluster is connected with the at least two micro-service clusters respectively, and is used for sending the first global service list to the at least one micro-service cluster. The embodiment of the application can realize the synchronization of the first global service list in the global registration center cluster and the first service list in the micro-service cluster, and can reduce the damage to the service list of the original registration center cluster.

Description

Technical Field

[0001] This invention relates to, but is not limited to, the field of computer technology, and particularly to a service processing system and apparatus, terminal and storage medium in a heterogeneous microservice cluster. Background Technology

[0002] Among related technologies, the mainstream technical architectures of IT support systems include traditional distributed architecture, microservice architecture, and cloud-native architecture. Among them, under the requirements of service governance models for service registration, service invocation, service circuit breaking and / or configuration center, different IT industries and organizations have proposed different service governance architectures, such as Eureka, Nacos, and Consul.

[0003] When implementing system business logic, each business system chooses different service governance architectures based on its own technical characteristics. As the business grows, multiple heterogeneous microservice clusters may exist within a company. When attempting to enable services from different microservice clusters to access each other, there are drawbacks such as disrupting the original microservice clusters. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a service processing system and device, terminal and storage medium in a heterogeneous microservice cluster to solve the above-mentioned technical problems.

[0005] The technical solution of this invention is implemented as follows:

[0006] In a first aspect, embodiments of the present invention provide a service processing system in a heterogeneous microservice cluster, comprising: a global registry cluster, at least two registry clusters, and at least two microservice clusters; wherein...

[0007] The microservice cluster is connected to the corresponding registry center cluster;

[0008] The global service registry cluster is connected to at least two other service registry clusters to obtain a first service list from at least one of the service registry clusters; and performs format conversion on at least one of the first service lists to obtain a first global service list.

[0009] The global registry cluster is connected to at least two of the microservice clusters respectively, and is used to send the first global service list to at least one of the microservice clusters.

[0010] In the above scheme, the global registry cluster includes at least one global registry server and at least one global registry client; the microservice cluster includes at least one service instance client; the global registry client is set in the service instance client of the microservice cluster;

[0011] The global registry center server is used to cache the first global service list; and / or,

[0012] The global registry client is used to obtain the first global service list provided by the global registry server and cache the first global service list.

[0013] In the above scheme, the global registration center server is used to obtain at least one second service list in the registration center cluster, wherein the second service list is determined based on the first service list after being updated;

[0014] The global registration center server is used to compare at least one of the second service lists with the first global service list to obtain a first comparison result;

[0015] The global registration center server is used to update the first global service list based on the first comparison result to obtain the second global service list.

[0016] In the above scheme, the microservice cluster includes at least: at least one first microservice cluster and at least one second microservice cluster; the registry center cluster includes at least: a first registry center cluster connected to the first microservice cluster and a second registry center cluster connected to the second microservice cluster.

[0017] The global registry center server is used to obtain at least one third service list from the first registry center cluster; and to perform format conversion on the third service list to obtain a third global service list.

[0018] The global registry center server is used to update the third global service list to the service instance clients in the second microservice cluster.

[0019] In the above scheme, the microservice cluster includes at least: at least one first microservice cluster and at least one second microservice cluster; the registry center cluster includes at least: a first registry center cluster connected to the first microservice cluster and a second registry center cluster connected to the second microservice cluster; the service instance client further includes: a service invocation module; the service instance client in the first microservice cluster includes a first service invocation module, and the service implementation client in the second microservice cluster includes a second service invocation module;

[0020] The first service invocation module is used to obtain an invocation request; wherein, the invocation request includes identification information indicating the registration center cluster to be invoked and / or identification information indicating the service to be invoked;

[0021] The first service invocation module is configured to, if the registry cluster to be invoked is determined to be the first registry cluster based on the invocation request, determine that the client of the service embodiment in the first microservice cluster invokes the service to be invoked indicated by the invocation request;

[0022] Alternatively, the first service invocation module is configured to, if determined based on the invocation request that the registry cluster to be invoked is the second registry cluster, filter the first global service list based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and use the second invocation module to invoke the service to be invoked indicated by the first target service list in the second microserver cluster based on a load balancing method.

[0023] Secondly, embodiments of the present invention provide a service processing method in a heterogeneous microservice cluster, executed by a global registry center cluster, including:

[0024] Obtain the first service list of at least one registry center cluster;

[0025] Perform a format conversion on at least one of the first service lists to obtain a first global service list;

[0026] The first global service list is sent to at least one microservice cluster that is connected to at least one of the registry center clusters respectively.

[0027] In the above scheme, the global registry cluster includes: at least one global registry server and at least one global registry client; the global registry client is set in the service instance client of the microservice cluster;

[0028] The first global service list is cached in at least one of the global registry center servers;

[0029] And / or, the first global service list is used for at least one of the microservice clusters to cache in at least one of the service instance clients of the microservice cluster.

[0030] In the above scheme, the global registry center cluster is a global registry center server; the method includes:

[0031] Obtain at least one second service list from the registration center cluster, wherein the second service list is determined based on an update of the first service list;

[0032] At least one of the second service lists is compared with the first global service list to obtain a first comparison result;

[0033] The first global service list is updated based on the first comparison result to obtain the second global service list.

[0034] In the above scheme, the registry center cluster includes at least: a first registry center cluster corresponding to the first microservice cluster and a second registry center cluster corresponding to the second microservice cluster; the global registry center cluster is a global registry center server; the method includes:

[0035] Obtain at least one list of third services from the first registry center cluster;

[0036] The format of the third service list is converted to obtain a third global service list;

[0037] The third global service list is sent to the second microservice cluster, wherein the third global service list is used by the second microservice cluster to update the first global service list.

[0038] Thirdly, embodiments of the present invention provide a service processing method in a heterogeneous microservice cluster, executed by a service instance client in the microservice cluster, including:

[0039] Receive a first global service list sent by a global registry cluster; wherein the first global service list is obtained by the global registry cluster by transforming at least one first service list; the first service list is obtained by the global registry cluster from at least one registry cluster;

[0040] Cache the first global service list.

[0041] In the above scheme, the registration center cluster includes at least one first registration center cluster and at least one second registration center cluster; the method includes:

[0042] Obtain the call request sent by the first registry center cluster; wherein, the call request includes identification information indicating the registry center cluster to be called and / or identification information indicating the service to be called;

[0043] If the registry cluster to be invoked is determined to be the first registry cluster based on the invocation request, then the client of the service embodiment in the first microservice cluster is determined to invoke the service to be invoked indicated by the invocation request.

[0044] Alternatively, if the registry cluster to be invoked is determined to be the second registry cluster based on the invocation request, the first global service list is filtered based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and the service to be invoked indicated by the first target service list in the second microserver cluster is invoked based on the load balancing method.

[0045] Fourthly, embodiments of the present invention provide a service processing device in a heterogeneous microservice cluster, applied to a global registry center cluster, comprising:

[0046] The first receiving module is used to obtain the first service list of at least one registry center cluster;

[0047] A first processing module is configured to perform format conversion on at least one of the first service lists to obtain a first global service list;

[0048] The first sending module is used to send the first global service list to at least one microservice cluster that is connected to at least one of the registration center clusters respectively.

[0049] Fifthly, embodiments of the present invention provide a service processing device in a heterogeneous microservice cluster, applied to a service instance client in a microservice cluster, comprising:

[0050] The second receiving module is used to receive a first global service list sent by the global registry cluster; wherein the first global service list is obtained by the global registry cluster by transforming at least one first service list; the first service list is obtained by the global registry cluster from at least one registry cluster;

[0051] The second processing module is used to cache the first global service list.

[0052] In a sixth aspect, embodiments of the present invention provide a terminal, the terminal including a processor and a memory for storing computer programs capable of running on the processor; wherein, when the processor runs the computer program, it implements the service processing method in a heterogeneous microservice cluster as described in any embodiment of the present invention.

[0053] In a seventh aspect, embodiments of the present invention also provide a computer storage medium containing computer-executable instructions, which are executed by a processor to implement the service processing method in a heterogeneous microservice cluster as described in any embodiment of the present invention.

[0054] In this embodiment of the invention, the global registry cluster is connected to at least two registry clusters respectively, and can be used to sense changes in the first service list in each registry cluster; and the global registry cluster can be connected to at least two microservice clusters respectively, and can send the changed first service list (e.g., the first global service list) to the microservice clusters to achieve synchronization between the first global service list in the global registry cluster and the first service list in the microservice clusters.

[0055] Furthermore, the introduction of a global registry cluster does not alter the original registry architecture or the primary service list retained by the registry. Different registry clusters can also retain their original primary service lists, thus minimizing disruption to the service lists of the original registry clusters. Moreover, the primary global service list can be maintained in the service instance clients of the microservice cluster. This allows for dynamic updates of the service lists in the service instance clients through the global registry cluster, improving the accuracy of the service lists in the service instance clients. Attached Figure Description

[0056] Figure 1 This is a schematic diagram of a service processing system in a heterogeneous microservice cluster, provided as an embodiment of the present invention.

[0057] Figure 2 This is a schematic diagram of another service processing system in a heterogeneous microservice cluster provided in an embodiment of the present invention.

[0058] Figure 3 This is a schematic diagram of another service processing system in a heterogeneous microservice cluster provided in an embodiment of the present invention.

[0059] Figure 4 This is a schematic diagram illustrating the formation of a first global service list, provided as an embodiment of the present invention.

[0060] Figure 5 This is a schematic diagram of a service instance client in a service processing system of a heterogeneous microservice cluster, provided as an embodiment of the present invention.

[0061] Figure 6 This is a flowchart illustrating a service processing method in a heterogeneous microservice cluster, as provided in an embodiment of the present invention.

[0062] Figure 7 This is a schematic diagram illustrating a service call in a heterogeneous microservice cluster, as provided in an embodiment of the present invention.

[0063] Figure 8 This is a flowchart illustrating another service processing method in a heterogeneous microservice cluster provided by an embodiment of the present invention.

[0064] Figure 9This is a flowchart illustrating another service processing method in a heterogeneous microservice cluster provided in an embodiment of the present invention.

[0065] Figure 10 This is a schematic diagram of the structure of a service processing device in a heterogeneous microservice cluster, provided in an embodiment of the present invention.

[0066] Figure 11 This is a schematic diagram of the structure of a service processing device in a heterogeneous microservice cluster, as provided in an embodiment of the present invention.

[0067] Figure 12 This is a schematic diagram of the hardware structure of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0068] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0069] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably. Furthermore, in the following description, the use of prefixes such as "first" or "second" to identify information is solely for the purpose of illustrative purposes and has no specific meaning in itself. Additionally, in the following description, "a plurality of" refers to two or more; "multiple types" refers to two or more kinds.

[0070] To better understand the technical solutions described in any embodiment of the present invention, some aspects of the related technology will be described first:

[0071] In related technologies, when it is desired to enable services to access each other across different microservice clusters, the inconsistency in the technology stacks of various microservice governance frameworks leads to a lack of effective solutions for service calls under heterogeneous registry centers. Currently, there are generally two solutions: one is to publish each microservice cluster as a service to provide external access, and the other is to unify the technology stacks of heterogeneous microarchitectures; however, both solutions have certain drawbacks and limitations to some extent.

[0072] For example, one approach is to publish individual microservice clusters as services. This approach provides a system that handles the mutual registration of services from heterogeneous service registries. For instance, all services in Registry 1 are registered in Registry 2, and all services in Registry 2 are also registered in Registry 1; thus, Registry 1 and 2 simultaneously maintain service lists from all registries. This system also handles service invocation; all service invocation requests are forwarded through this system. For example, service 1 of application 1 in Registry 1 can access service 1 of application 1 in Registry 2 through this forwarding mechanism.

[0073] Another example is a unified approach to heterogeneous microarchitecture technology stacks. This approach creates different scheduled tasks based on the number of data centers. These scheduled tasks are responsible for synchronizing changes in the service lists of different registry centers. For instance, if there are three registry centers, when a registry center changes, registry center 1 will synchronize information from registry center 1 to registry centers 2 and 3 according to the created scheduled tasks. In this way, all new registration information can ultimately be synchronized.

[0074] However, the above two methods and related technologies for service discovery and / or invocation in heterogeneous microservice clusters have the following problems and / or drawbacks:

[0075] (1) In order to realize the service call of the heterogeneous microservice cluster, the service list of the original registry center is destroyed; and the data synchronization between the registry centers will also register the services of other registry centers into the registry center. This not only makes the original registry center large and bloated, but also affects the efficiency of service list acquisition and service access, and brings certain troubles to the operation and maintenance work.

[0076] (2) A better approach during service invocation is to use client-side load balancing for service access. Services in the registry should be able to directly access services in the heterogeneous microservice cluster, rather than using a centralized approach for routing or service filtering. A centralized approach would significantly reduce service invocation efficiency and introduce high availability risks to service invocation.

[0077] (3) Service access to heterogeneous microservice clusters should not have a significant impact on the existing technical implementation of microservice clusters; such as changes in the coding implementation of service call methods. In order to achieve this function, a lot of development and transformation is required, which has no obvious advantage compared with separate gateway-level service integration, but instead consumes a lot of manpower and time costs.

[0078] This invention provides a service processing system for a heterogeneous microservice cluster to at least solve some of the aforementioned technical problems. For example... Figure 1As shown, this embodiment of the invention provides a service processing system 10 in a heterogeneous microservice cluster. The service processing system 10 in the heterogeneous microservice cluster includes: a global registry cluster 110, at least two registry clusters 120, and at least two microservice clusters 130; wherein,

[0079] The microservice cluster 130 is connected to the corresponding registry center cluster 120;

[0080] The global registry cluster 110 is connected to at least two registry clusters 120 respectively, and is used to obtain a first service list of at least one registry cluster 120; and to perform format conversion on at least one first service list to obtain a first global service list.

[0081] The global registry cluster 110 is connected to at least two of the microservice clusters 130 respectively, and is used to send the first global service list to at least one of the microservice clusters 130.

[0082] In embodiments of the present invention, at least one includes one or more, and multiple refers to two or more.

[0083] In this embodiment of the invention, "connection" refers to a communication connection. For example, a connection between a microservice cluster and a registry cluster means that the microservice cluster and the registry cluster establish a communication connection; the microservice cluster can send information to the registry cluster and / or the microservice cluster can receive information sent by the registry cluster, etc.

[0084] In one embodiment, a microservice cluster is connected to a registry cluster. For example, the microservice cluster includes a first microservice cluster and a second microservice cluster; the registry cluster includes a first registry cluster and a second registry cluster; the first registry cluster is connected to the first microservice cluster and is used to manage the first microservice cluster; the second registry cluster is connected to the second microservice cluster and is used to manage the second microservice cluster. Here, the registry cluster manages the microservice cluster, including but not limited to at least one of the following: the registry cluster is used for the discovery and / or registration and / or invocation of services in the microservice cluster, etc.

[0085] In one embodiment, the global registry cluster includes at least one global registry center. For example, such as... Figure 1 As shown, the global registry center cluster includes: global registry center 1, ... and global registry center N; where N is an integer greater than 0.

[0086] In one embodiment, the service processing system in a heterogeneous microservice cluster includes at least two registry clusters; wherein, one registry cluster includes at least one registry center. For example, Figure 1As shown, the registration center cluster includes: registration center 1, ... and registration center N; where N is an integer greater than 0.

[0087] In one embodiment, the service processing system in a heterogeneous microservice cluster includes at least two microservice clusters; wherein one microservice cluster includes at least one service; and wherein one service includes at least one instance. For example, Figure 1 As shown, a microservice cluster includes: service 1, ..., and service N; where N is an integer greater than 0. A service includes: instance 1, ..., and instance N; where N is an integer greater than 0.

[0088] In one embodiment, a registry cluster includes at least one registry, and a registry includes a registry client.

[0089] In one embodiment, a microservice cluster includes at least one service; a service includes at least one instance; and an instance includes a service instance client.

[0090] In one embodiment, the global registry cluster includes at least one global registry server and at least one global registry client.

[0091] In one embodiment, the global registry server can be used to register with or integrate into at least one registry client. In this way, the global registry can act as a pseudo-node of heterogeneous registry centers (i.e., various registry centers in a registry cluster).

[0092] For example, this embodiment of the invention provides an implementation method for pseudo-node registration. For instance... Figure 2 As shown, the global registry client can act as a pseudo-node for heterogeneous registry centers (e.g., registry clients within different registry centers). This global registry client registers with different registry centers upon system startup; for example, the global registry server can register with registry cluster A and registry cluster B. Service registration specifications follow the standards and requirements of their respective microservice governance frameworks. The global registry aggregates and ensures compatibility of service registration functions across different microservice governance frameworks. This pseudo-node does not provide any business functionality to the original microservice cluster.

[0093] The registry cluster provides services to the outside world as a whole. It is generally composed of multiple registry centers to ensure the high availability of the registry cluster. In order to obtain the latest service list of each microservice cluster more accurately, the global registry center in the cluster, as a pseudo node, registers with at least two registry centers to ensure high availability. In the most stringent case, it will register with all registry centers.

[0094] In another embodiment, the global registry server may also be either not registered to or integrated into at least one registry client; the global registry server establishes a communication connection with at least one registry client.

[0095] In one embodiment, the global registry client can be used to be configured in or integrated into the service instance clients of at least one microservice cluster. For example, Figure 2 As shown, the clients included in each instance of each service in the microservice cluster are service instance clients, and the global registry client can be integrated into at least one service instance client.

[0096] In another embodiment, the global registry client may not be set in the service instance client or may be integrated into the service instance client; the global registry client establishes a communication connection with at least one service instance client.

[0097] The clients involved in the embodiments of the present invention, such as registry center clients, service instance clients, and / or global registry center clients, can be, but are not limited to, any type of client; for example, these clients can be any type of mobile terminal or fixed terminal. For example, the registry center client, service instance client, and / or global registry center client can be, but are not limited to, at least one of the following: mobile phone, computer, medical device, smart home device, vehicle networking device, industrial equipment, and / or wearable device, etc.

[0098] The server involved in these embodiments of the invention, such as a global registry center server, can be, but is not limited to, any server. For example, the global registry center server can be a local server or a cloud server, etc.

[0099] To further understand any embodiment of the present invention, the following provides a description of the relationship between services and instances, the relationship between a registry cluster and services, the relationship between a registry and a registry cluster, and the global registry cluster.

[0100] The relationship between services and instances. One service corresponds to multiple instances; for example, a service named "Order Service" can have multiple instances, namely Order Service Instance 1, Order Service Instance 2, and Order Service Instance N. Instances can serve as concrete implementations of services and have the ability to scale horizontally; all instances can provide services simultaneously, and the specific instance called is determined by the caller; in a microservice cluster architecture, it can be based on round-robin calling or configured weight calling, etc.

[0101] The relationship between the service registry cluster and services. All instances of all services can register with the service registry cluster; for example, if there are three services—orders, payments, and ride-hailing—each with 10 instances, then all 30 instances of these three services will be registered with the service registry cluster. Here, for example... Figure 3 Service cluster A and service cluster B are two physically isolated microservice clusters that have no relation to each other.

[0102] The relationship between a registry center and a registry center cluster. A registry center cluster provides services to the outside world as a whole. A registry center cluster can include one or more registry centers. Multiple registry centers ensure the high availability of the registry center cluster, so that the failure of an individual registry center will not affect the entire cluster.

[0103] A global registry cluster consists of one or more global registries, which can provide services as a whole. For high availability, a global registry cluster typically includes two or more global registries. Multiple global registries can provide services simultaneously within the cluster. Each global registry can access the corresponding registry cluster to obtain the service list, and the global registries can also synchronize their service list data.

[0104] In the embodiments of the present invention, the first service list, the first global service list, the second service list, the second global service list, the third service list, and the third global service list may be, but are not limited to, service lists that include at least one service.

[0105] In one embodiment, the service list, global service list, first service list, first global service list, second service list, second global service list, third service list, and third global service list may include, but are not limited to, at least one of the following: service name, service instance name, instance address, instance port, and instance status. Here, the instance address may be the instance's IP address or physical address, etc. The instance status includes, but is not limited to, the instance's on / off state or running state, etc.

[0106] In another embodiment, the first service list, the first global service list, the second service list, the second global service list, the third service list, and the third global service list may each include, but are not limited to, at least one of the following: the name of the registry cluster, the type of the registry cluster; the service name, the service instance name, the service address, the service port, and the service status. Here, the service address may be the IP address of the service. Here, the name of the registry cluster may be the identification information (ID) of the registry cluster; the service name may be the identification information of the service.

[0107] For example, this embodiment of the invention provides an implementation method for obtaining a service list. The global registry server acts as a pseudo-node for each registry, and can obtain service lists (e.g., a first service list) from different registry interfaces. Here, the interface specifications follow the standards and requirements of their respective microservice governance frameworks, and the global registry aggregates and ensures compatibility for obtaining service lists from different microservice governance frameworks. The first service list includes information such as service name, service instance name, instance IP address, instance port, and instance status.

[0108] Of course, in other embodiments, the global registry cluster can also directly receive the first service list sent by the registry cluster.

[0109] In one embodiment, the global registry cluster can set a format converter for the first service list of each registry cluster; the global registry cluster can use each format converter to convert the data format of the first service list of each registry cluster to form a global service list with a unified format.

[0110] In one embodiment, the first global service list sent by the global registry cluster to the microservice cluster may include the first service list of the registry cluster corresponding to the microservice cluster, or it may not include the first service list of the registry cluster corresponding to the microservice cluster.

[0111] For example, the registry cluster includes a Eureka registry cluster, a Nacos registry cluster, and a Consul registry cluster; the microservice clusters corresponding to the Eureka registry cluster are Eureka microservice clusters, the Nacos registry clusters are Nacos microservice clusters, and the Consul registry clusters are Consul microservice clusters. The first service list includes the Eureka service list of the Eureka registry cluster, the Nacos service list of the Nacos registry cluster, and the Consul service list of the Consul registry cluster. The first global service list determined by the global registry cluster may include the Eureka service list, the Nacos service list, and the Consul service list. One implementation of the global registry cluster sending the first global service list to at least one microservice cluster is as follows: the global registry cluster sends the first global service list, including the Eureka service list, the Nacos service list, and the Consul service list, to the Eureka microservice cluster, the Nacos microservice cluster, and the Consul microservice cluster, respectively.

[0112] Another implementation of the global service registry cluster sending the first global service list to at least one microservice cluster is as follows: the global service registry cluster sends the first global service list, including both Nacos and Consul service lists, to the Eureka microservice cluster; sends the first global service list, including both Eureka and Consul service lists, to the Nacos microservice cluster; and sends the first global service list, including both Eureka and Nacos service lists, to the Consul microservice cluster. This simplifies the information sent, reduces the amount of data cached in the service instance clients of each microservice cluster, and ensures that each microservice cluster retains its original service list while maintaining its accuracy.

[0113] Here, sending the first global service list to at least one microservice cluster can be done by sending the first global service list to at least one service instance client in at least one microservice cluster.

[0114] In this embodiment of the invention, the global registry cluster is connected to at least two registry clusters respectively, and can be used to sense changes in the first service list in each registry cluster; and the global registry cluster can be connected to at least two microservice clusters respectively, and can send the changed first service list (e.g., the first global service list) to the microservice clusters to achieve synchronization between the first global service list in the global registry cluster and the first service list in the microservice clusters.

[0115] Furthermore, the introduction of a global registry cluster does not alter the original registry architecture or the primary service list retained by the registry. Different registry clusters can also retain their original primary service lists, thus minimizing disruption to the service lists of the original registry clusters. Moreover, the primary global service list can be maintained in the service instance clients of the microservice cluster. This allows for dynamic updates of the service lists in the service instance clients through the global registry cluster, improving the accuracy of the service lists in the service instance clients.

[0116] Please participate again. Figure 1 and Figure 2 In some embodiments, the global registry set 110 includes at least one global registry server 1101 and at least one global registry client 1102; the microservice cluster 130 includes at least one service instance client 1301; the global registry client 1102 is set in the service instance client 1301 of the microservice cluster 130.

[0117] The global registration center server 1101 is used to cache the first global service list;

[0118] And / or,

[0119] The global registry client 1102 is used to obtain the first global service list provided by the global registry server and cache the first global service list.

[0120] For example, this embodiment of the invention provides an implementation method for service list caching. The service list caching method includes: a caching method for a first service list, a method for obtaining a first global service list based on the first service list, and a caching method for the first global service list.

[0121] The global registry cluster can obtain the first service lists of each registry center through the service list acquisition module. It also provides format converters for the first service lists from various registry centers, processing and organizing the first service lists returned by different registry centers to form the first global service list. Here, the service list acquisition module is part of the global registry center; each global registry center has equal status. The standard data structure of the first global service list is shown in Table 1 below:

[0122]

[0123] Table 1

[0124] The method to transform the first service list into the first global service list can be as follows: Figure 4As shown, the transformation of the first service list into a first global service list includes steps S21 and S22. Step S21: The service list acquisition module in the global registry cluster acquires the first service lists of different microservice clusters. The interface for acquiring the first service list is provided by each microservice cluster, and this interface is compatible with at least one global registry or registry center. Taking Eureka as an example, the global registry cluster can acquire the first service list through the Resource Representational State Transfer Application Programming Interface (REST API) of applications (APPs). Step S22: The global registry cluster can parse and process the data formats of different first service lists through a custom format converter; extract relevant service information from them; and map the relevant information to a custom data structure to form a unified format first global service list. Taking Eureka as an example, the Eureka format converter uses Dom4J to obtain relevant information such as service name, service instance name, instance IP address, instance status, and / or instance port from XML. Here, the relevant information is mapped and transformed with the fields in the standard data structure in the above embodiments, thereby converting the XML format into a general data format; for example, the transformed service list can be (Order, Order8934, 192.168.54.65, 8080, Open, ...). The data of the first service list of other types of registry center clusters is also transformed through the process in step S22, thereby constructing a first global service list in a unified format.

[0125] Here, the information of the first service list obtained from Eureka can be shown in Table 2 below:

[0126]

[0127] Table 2

[0128] Here, the data format of the first service list information can be XML format; the data format of the first service list obtained in different registry center clusters may be different.

[0129] In one embodiment, the first global service list cached by the global registry client may not include the first service list included by the service instance client where the global registry client resides.

[0130] For example, the microservice cluster includes a Eureka microservice cluster; the global registry cluster sends lists of Eureka services, Nacos services, and Consul services to the Eureka microservice cluster respectively. The global registry client or service instance client in the Eureka microservice cluster caches a first global service list including the Consul service list and the Consul service list. Here, the service instance client in the Eureka microservice cluster already caches the Eureka service list; therefore, the service instance client in the Eureka microservice cluster can cache only the first global service list including the Consul service list and the Consul service list. In this case, the first global service list and the Eureka service list can be stored in different databases or different cache spaces in the service instance client of the Eureka microservice cluster.

[0131] In this embodiment of the invention, the first global service list can be cached in the global registry client and / or the global registry server. When the first global service list is cached in the global registry server, it can be used to maintain information about instances of all services in all registry clusters; and / or when the first global service list is cached in the global registry client, it can facilitate subsequent invocation of services based on heterogeneous microservice clusters.

[0132] In this embodiment of the invention, the first global service list is also cached in the microservice cluster instance, and each instance exchanges service lists with each other through information synchronization, thereby achieving fast and dynamic updates to the first global service list.

[0133] In some embodiments, the global registry center server is used to obtain at least one second service list in the registry center cluster, wherein the second service list is determined based on an update of the first service list;

[0134] The global registration center server is used to compare at least one of the second service lists with the first global service list to obtain a first comparison result;

[0135] The global registration center server is used to update the first global service list based on the first comparison result to obtain the second global service list.

[0136] In one embodiment, the global registry server may use one of the following to obtain a second service list from at least one registry cluster:

[0137] The global registry server retrieves a second service list from at least one registry cluster at predetermined time intervals.

[0138] If the registry cluster determines that the first service list has been updated, it provides the global registry server with the second service list obtained after the update of the first service list.

[0139] In one embodiment, the second service list is determined based on an updated first service list, and may be, but is not limited to, at least one of the following:

[0140] Add information for at least one service to the first service list to obtain a second service list;

[0141] Delete information for at least one service from the first service list to obtain a second service list;

[0142] Modify the information of at least one service in the first service list to obtain the second service list.

[0143] Here, the service information may include, but is not limited to, at least one of the following: service name, at least one implementation name of the service, service address, instance address, service port, instance port, service status, and instance status.

[0144] In one embodiment, the first comparison result may be information about different services in the second service list and the first global service list; or the first comparison result may be information about different services in the second service list and the first global service list.

[0145] In one embodiment, updating the first global service list based on the first comparison result to obtain the second global service list may be: replacing the first service list in the first global service list that corresponds to the second service list with the second service list to obtain the second global service list; or modifying the first global service list based on the first comparison result to obtain the second global service list.

[0146] In one embodiment, the algorithm for comparing at least one second service list with the first global service list can be implemented by any feasible comparison algorithm, such as, but not limited to, the sorting two-pointer method.

[0147] In this embodiment of the invention, the acquisition of the second service list in each registration center cluster by the global registration center cluster (e.g., the global registration center server) can be considered as service list sniffing. The global registration center server can continuously sniff to perceive changes in the first service list in different registration center clusters (such as the addition and / or reduction and / or modification of service information, etc.), and realize service discovery and real-time updating of the first global service list to obtain the second global service list by comparing the second service list of each microservice cluster with the first global service list in the global registration center cluster.

[0148] Furthermore, the sniffing time interval (i.e., the predetermined time interval) can be flexibly selected through configuration.

[0149] In some embodiments, the microservice cluster includes at least: at least one first microservice cluster and at least one second microservice cluster; the registry cluster includes at least: a first registry cluster connected to the first microservice cluster and a second registry cluster connected to the second microservice cluster.

[0150] The global registry center server is used to obtain at least one third service list from the first registry center cluster; and to perform format conversion on the third service list to obtain a third global service list.

[0151] The global registry center server is used to update the third global service list to the service instance clients in the second microservice cluster.

[0152] In one embodiment, the global registry server may use one of the following to obtain a list of at least one third service in a first registry cluster:

[0153] The global registry center server retrieves at least one list of third services from the first registry center cluster at predetermined time intervals.

[0154] When the first service list is updated, the first registration center cluster provides the global registration center server with the third service list obtained after the first service list is updated.

[0155] In one embodiment, the third service list is determined based on an updated first service list, and may be, but is not limited to, at least one of the following:

[0156] Add information for at least one service to the first service list to obtain a third service list;

[0157] Delete information for at least one service from the first service list to obtain the third service list;

[0158] Modify the information of at least one service in the first service list to obtain the third service list.

[0159] Here, the service information may include, but is not limited to, at least one of the following: service name, at least one implementation name of the service, service address, instance address, service port, instance port, service status, and instance status.

[0160] In one embodiment, the third service list is the same as the second service list, or the third service list is different from the second service list.

[0161] In one embodiment, the global registry server does not need to update the third global service list to the first microservice cluster. This is because the third service list in the first registry cluster is determined based on the update of the first service list in the first microservice cluster, and the first microservice cluster already caches the third service list and the first global service list.

[0162] In another embodiment, the global registry server may also send the third global service list to the service instance clients of the first microservice cluster, so that the service instance clients can replace the first global service list based on the third global service list.

[0163] In one embodiment, the global registry server performs format conversion on the third service list to obtain the third global service list. This is similar to the method in the above embodiment where the global registry cluster performs format conversion on at least one first service list to obtain the first global service list. The implementation method will not be described again here.

[0164] Here, the global registry server sends the third global service list to the second microservice cluster. The third global service list is used by the service instance clients of the second microservice cluster to update the first global service list based on the third service list.

[0165] In one embodiment, the global registry server can compare the third global service list with the first global service list in the service instance client to obtain a second comparison result; when the second comparison result indicates that the third global service list is different from the first global service list, the third global service list is sent to the service client in the second microservice cluster.

[0166] Here, the global registry server is also used to update the first global service list based on the third global service list.

[0167] For example, updating the third global service list to the service instance client as described above can be considered service list synchronization. Here, a method for service list synchronization is provided: different microservice clusters may register services and / or go offline during operation. When services change in each microservice cluster, the registry cluster will detect the service changes. This mechanism is guaranteed by the characteristics of different microservice clusters themselves. In order to detect changes in the first service list in different microservice clusters, the service list acquisition module in the global registry cluster will poll at predetermined time intervals (configurable) to obtain the latest service lists (i.e., the third service list) of different registry clusters. Here, the global registry cluster mainly obtains the list through the interfaces provided by each registry cluster; for example, the global registry cluster can obtain the third service list through the REST API interface of the Eureka registry cluster's APPs, and convert the obtained third service list into a third global service list. The global registry cluster can then compare the third global service list with the existing first global service list in the global registry cluster to determine which microservice cluster to send the third global service list to. Here, a locking mechanism can be used to ensure thread safety issues caused by simultaneous updates of the third service lists of multiple registry clusters.

[0168] In this embodiment of the invention, the global registry cluster can synchronize the service list (e.g., the third global service list) using both PUSH and PULL methods. For example, the third global service list can be sent to the global registry client through the service list synchronization module in the global registry server; or, the third global service list can be obtained by querying the global registry server through the global registry client. Here, the service list synchronization using the PUSH method can provide both incremental and full synchronization methods, and different predetermined time intervals are used for service list synchronization. A configured retry mechanism is also provided to ensure data consistency. Here, the synchronization communication protocol can be, but is not limited to, the Hypertext Transfer Protocol (HTTP) protocol, and / or the message format of the service list during synchronization can be, but is not limited to, JSON format.

[0169] In this invention, the third service list synchronized between the global registry server and the global registry client does not include the service list of the registry cluster corresponding to the service instance client where the global registry client resides. For example, if the service list of the Eureka registry cluster changes, after the global registry cluster detects the change in the Eureka service list, it will not synchronize the changed Eureka service list back to the Eureka registry cluster. Instead, it will synchronize it to the service instance client (i.e., the global registry client) of other microservice clusters (such as the Nacos microservice set) besides the registry microservice cluster corresponding to the Eureka registry cluster. This avoids disrupting the service lists of heterogeneous registry clusters and also helps to isolate the calling logic for services within the local registry cluster from the calling logic for services outside the local registry cluster during service calls. Furthermore, the method and / or encoding logic for calling services within the local registry cluster remain consistent with those before the introduction of the global registry cluster, thereby reducing the impact of the introduction of the global registry cluster on the original microservice cluster.

[0170] To further understand any embodiment of the present invention, the acquisition of the service list, caching of the service list, and updating of the service list in the global registration center client are described.

[0171] For example, the service list is obtained. A global registry client is used to request and / or receive the global service list (e.g., a first global service list or a third global service list) from the global registry server. The service list can be obtained through two types of interfaces: a synchronization interface between the registry cluster and the registry cluster type, and a synchronization interface between the registry cluster and the service list.

[0172] For example, service list caching. The global registry client only stores the service list of heterogeneous microservice clusters (e.g., the first global service list or the third service list does not include the service list of this microservice cluster); the service list of this microservice cluster (e.g., the first service list or the third service list) is still uniformly managed (e.g., cached) by the original microservice cluster; the data structure of the service list cached by the global registry client is consistent with the data structure of the service list cached by the global registry server.

[0173] For example, updating the service list. When the global registry server discovers that the service list of the heterogeneous microservice cluster received and / or obtained through the service list acquisition module's interface differs from the global service list cached in the global registry client, it determines that a change in the service status of the heterogeneous microservice cluster has occurred; therefore, it needs to update the global service list (excluding the service list of this microservice cluster) in the global registry client. Here, the service list can be the first service list or the third service list, etc., in the above embodiments; the global service list can be the first global service list or the third service list, etc., in the above embodiments.

[0174] In some embodiments, the microservice cluster includes at least: at least one first microservice cluster and at least one second microservice cluster; the registry cluster includes at least: a first registry cluster connected to the first microservice cluster and a second registry cluster connected to the second microservice cluster; the service instance client further includes: a service invocation module; the service instance client in the first microservice cluster includes a first service invocation module, and the service implementation client in the second microservice cluster includes a second service invocation module;

[0175] The first service invocation module is used to obtain an invocation request; wherein, the invocation request includes identification information indicating the registration center cluster to be invoked and / or identification information indicating the service to be invoked;

[0176] The first service invocation module is configured to, if the registry cluster to be invoked is determined to be the first registry cluster based on the invocation request, determine that the client of the service embodiment in the first microservice cluster invokes the service to be invoked indicated by the invocation request;

[0177] Alternatively, the first service invocation module is configured to, if determined based on the invocation request that the registry cluster to be invoked is the second registry cluster, filter the first global service list based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and use the second invocation module to invoke the service to be invoked indicated by the first target service list in the second microserver cluster based on a load balancing method.

[0178] In one embodiment, the service instance client includes: a global registry client and a service invocation module; wherein, the global registry client is used to receive, request, process, and / or cache the global service list; and the service invocation module is used to make invocations between services in a heterogeneous microservice cluster.

[0179] In one embodiment, the call request may include information included in the service list; for example, the call request may include, but is not limited to, one of the following: service name, service instance name, service IP address, instance IP address, service port, instance port, service status, and instance status.

[0180] In another embodiment, the invocation request may also include, but is not limited to, at least one of the following: the identification information of the registry cluster, the type of the registry cluster, and the identification information of the service. Here, the identification information of the registry cluster may be the identification information of the registry cluster to be invoked; the identification information of the service may be the identification information of the service to be invoked.

[0181] For example, such as Figure 5 As shown, a service invocation module logic diagram is provided; the service instance client includes: service instance client 1 and service instance client 2; wherein, service instance client 1 includes global registry center client 1 and service invocation module 1; service instance client 2 includes global registry center client 2 and service invocation module 2; both service invocation module 1 and service invocation module 2 may include a unified interface, a data conversion module and / or a load balancing module, etc.

[0182] Here, the first service invocation module can obtain invocation requests using a unified interface. For example, the client (such as a global center client or a service instance client) writes the identification information of the registration center cluster and / or the identification information of the service into the unified interface; and carries the unified interface in the invocation request.

[0183] Here, if the first service invocation module determines, based on the invocation request, that the registry cluster to be invoked is not the first registry cluster but the second registry cluster, then it filters the first global service list based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and determines the identification information of the service to be invoked based on the invocation request, and identifies the second target service list corresponding to the identification from the first target service list; and sends the invocation request including the second target service list to the service instance client of the second microservice cluster; the service instance client of the second microservice cluster uses the second service invocation module to invoke the service to be invoked indicated by the second target service list based on load balancing.

[0184] Here, the load balancing method can be, but is not limited to, a round-robin-based invocation method or a weight-based invocation method. For example, if the second target service list includes three instances: L1, L2, and L3, then the round-robin-based invocation method could be: first call to instance L1, second call to instance L2, and third call to instance L3. As another example, if the second target service list includes three instances: L1, L2, and L3, and instance L1 has a higher weight than instance L3, and L3 has a higher weight than instance L2, then the weight-based invocation method could be: first call to L1, second call to L3, and third call to L2.

[0185] For example, the service invocation module should be able to handle service invocations from both the local registry cluster and heterogeneous registry clusters. The unified interface will uniformly encapsulate and process the service lists of both the local and heterogeneous microservice clusters, shielding the user (who can be a service instance client of the microservice cluster) from the impact of the heterogeneous microservice cluster, allowing it to be used as a single registry cluster. The unified interface includes the registry cluster's identification information and / or service name identification information; this unified interface is not limited to fixed methods and parameters; the "zone" parameter identifies the registry cluster, and the "value" parameter identifies the service; the "zone" parameter can be empty when invoking services from the local registry cluster. An example of the unified interface is shown in Table 3 below (based on the Spring Cloud framework).

[0186]

[0187] Table 3

[0188] For example, the service invocation module should be able to handle service invocations between heterogeneous microservice clusters and be compatible with the data standards of different microservice governance frameworks. When client users make service invocations to heterogeneous microservice clusters through a unified interface, the invocation request contains the identification information of the registry cluster and / or the identification information of the service. Here, because each service instance client has cached the global service list (e.g., the first global service list or the third global service list), the data conversion module needs to first filter the data in the global service list, locate the specified microservice cluster, and then perform data conversion on the filtered data according to the corresponding format converter of different microservice clusters to construct a service list (ServiceList) that satisfies the service invocation. Here, for example... Figure 6 As shown, this embodiment of the invention provides a service invocation process; the service invocation process includes the following steps:

[0189] Step S31: The service invocation module makes an invocation through the unified interface, and inputs at least one of the following information into the unified interface: the identification information of the registration center cluster and the identification information of the service;

[0190] Here, the service invocation module, when making service invocations across a heterogeneous microservice cluster via a unified interface, will receive corresponding input information. This information may include at least one of the following parameters: the identifier or name of the registry cluster, the identifier or name of the service, the instance name of the service, the address of the service, the port of the service, the address of the instance, and the port of the instance. The service invocation module performs data transformation processing on these parameters received by the data transformation module. Here, "Eureka8765" can be the identifier of the registry cluster, "PAY-FRONT" can be the name of the service, " / order / pay" can be the address of the service, and / or "order" can be the instance name of the service.

[0191] Step S32: The service call module filters the information input into the unified interface;

[0192] Here, the service invocation module transforms the information input from the unified interface through the data conversion module to determine the identification information of the registry cluster to be identified. If the identification information of the registry cluster determines that the registry cluster to be invoked is this registry cluster (this registry cluster is the registry cluster corresponding to the microservice cluster where this service invocation module resides); for example, if the "zone" parameter is empty, it means that this registry cluster is being invoked. To avoid intruding on the functionality of the original registry cluster, the service invocation is performed using the default client (registration client) provided by that registry cluster. For example, if this registry cluster is a Eureka registry cluster, and the identification information of the registry cluster determines that the invoked registry cluster is also a Eureka registry cluster, then the service invocation is performed through the Eureka registry cluster's registration client. For example, if the "zone" parameter is not empty, it means a heterogeneous registry cluster is being called. The data conversion module filters the registry clusters from the global service list using their identification information. As shown in Table 4, the identification information of the registry clusters can be filtered using the Map<Registration Center ID, Service List> data structure to obtain all instance information of the registry cluster to be called. For example, if the identification information of the registry cluster to be called is "Eureka876534", then the global service list of the called service can be obtained as (Order, Order8934, 192.168.54.65, 8080, Open, ...), (Order, Order8935, 192.168.54.65, 8081, Open, ...), and (Pay, Pay8936, 192.168.54.67, 8084, Open, ...) 3 entries.

[0193]

[0194] Table 4

[0195] Step S33: If the service invocation module determines that the registry cluster to be invoked is the current registry cluster, it will make the invocation based on the registry client of the current registry cluster; or, if it determines that the registry cluster to be invoked is not the current registry cluster, it will obtain the target service list and make the invocation.

[0196] Here, if the service invocation module determines that the registry cluster to be invoked is the local registry cluster, it determines that the registry client of the local registry cluster will make the service invocation. For example, if the local registry cluster is determined to be the Eureka registry cluster, the service list will be obtained through the registry client (Eureka client) of the Eureka registry cluster. The logic at this time is to obtain the service list through the getServer() method; this service list is implemented by the Eureka client and the registry cluster itself. The invocation of heterogeneous registry clusters is implemented through the service invocation module of the service instance client of the heterogeneous microservice cluster. In step S32, the global service list can be obtained according to the identification information of the registry cluster, and the service to be invoked can be filtered to be the Order service; then two pieces of information can be determined: (Order, Order8934, 192.168.54.65, 8080, Open, ...) and (Order, Order8935, 192.168.54.65, 8081, Open, ...). Here, the data conversion module of the service invocation module will perform specific processing on heterogeneous microservice invocation, transforming different service lists into a target service list of the service to be invoked.

[0197] For example, the service invocation module includes a load balancing module for service invocation; the load balancing module can invoke services according to a load balancing method based on a target service list. For instance, the target service list includes instances L1, L2, and L3, and services can be invoked through a specific invocation method (which could be a round-robin invocation method or a weight-based invocation method, etc.). For example, a round-robin invocation method could be: invoking instance L1 first, invoking instance L2 second, and invoking instance L3 third.

[0198] For example, such as Figure 7 As shown, the service invocation module determines the target service list; the service instance client where the service invocation module resides can invoke services based on the target service list; this target service list includes services from the Eureka microservice cluster, services from the Nacos microservice cluster, and services from other microservice clusters. For example, a Eureka client can invoke services from the Eureka microservice cluster, a Nacos client can invoke services from the Nacos microservice cluster, and so on, until the service invocation indicated by the target service list is completed.

[0199] In this embodiment of the invention, instances in one microservice registration cluster can directly access instances in another microservice cluster; and the load balancing module can support round-robin or weighted invocation methods, without going through a centralized system or device for service access and forwarding, which greatly improves the efficiency and / or cost of service access.

[0200] Furthermore, the use of the global registry client and service call module of the global registry cluster does not require extensive modifications to the microservice cluster, and can be directly interconnected with the global registry server of the global registry cluster through configuration. At the same time, it provides a unified interface for service calls of different registry clusters, which can reduce the impact on service access of the original microservice cluster, improve scalability and reduce development costs.

[0201] To further explain any embodiment of the present invention, several specific embodiments are provided below.

[0202] Example 1: An embodiment of the present invention provides a method for service registration and service discovery.

[0203] Microservice clusters can include Eureka microservice clusters and Nacos microservice clusters, and can be accessed through methods such as... Figure 3 The method shown demonstrates the integration and deployment of a global service registry cluster. Now, taking the addition of a new service to a Nacos microservice cluster as an example, we will briefly describe the service registration and service discovery process of this invention.

[0204] A new instance has been added to the Nacos microservice cluster. The instance information is (Order, Order2345, 192.168.54.65, 8080, Open). The Nacos microservice cluster will detect the new service registration and update its service list accordingly. Since the global registry client is registered as a pseudo-node in the Nacos microservice cluster, it can obtain the latest service list in real time. When the global registry client finds that the latest service list it obtains is inconsistent with the service list cached by the global registry server, it updates the service list on the global registry server. For example, information about adding an instance (Nacos425857, (Order, 192.168.54.65, 8080, Open)) under the relationship (Nacos425857, Nacos); in order to synchronize the latest service list to the global registry client of the Eureka microservice cluster, the global registry server will filter the entire service list of the Eureka registry cluster from the global service list, and broadcast the event of adding a new service instance in the Nacos microservice cluster one by one through the service list synchronization module to send it to the global registry client configured in each Eureka microservice cluster.

[0205] After the global registry client in the Eureka microservice cluster receives the latest service list of the Nacos microservice cluster through the service list update module interface, it finds that it differs from the locally cached global service list, thus determining that the service status of the Nacos microservice cluster has changed. At this time, the locally cached global service list can be updated; for example, adding information about a new instance (Nacos425857, (Order, 192.168.54.65, 8080, Open)) under the relationship (Nacos425857, Nacos); at this point, the event of adding a new Order instance to the Nacos registry cluster is synchronized to the Eureka registry cluster.

[0206] Thus, in this embodiment of the invention, service registration and service discovery for the two heterogeneous microservice clusters, Nacos and Eureka, can be achieved through the cooperation of the global registry center server and the global registry center client (the principle of service registration and service discovery for multiple heterogeneous microservice clusters is the same).

[0207] Example 2: This embodiment of the invention provides a service invocation method for a heterogeneous microservice cluster.

[0208] Based on service registration and service discovery, the information of the service list cached by the heterogeneous microservice cluster can be shown in Table 5 below (here, two heterogeneous microservice clusters are taken as an example, and the principle is similar for multiple microservice clusters):

[0209]

[0210] Table 5

[0211] The global registry client in the Eureka registry cluster can update the global service list of service instance clients in real time by obtaining or receiving data. When the Eureka microservice cluster needs to call the Order service in the Nacos microservice cluster, it can declare the identifier information of the registry cluster to be accessed, "Nacos425857," through the unified interface module. The service invocation module in the Eureka microservice cluster can filter the service list corresponding to the Nacos registry cluster based on the global service list cached in the service instance client. The service list corresponding to the Nacos registry cluster includes 4 Pay instances and 2 Order instances. The service invocation module in the Eureka microservice cluster returns the target service list based on the service name Order to be invoked. This target service list may include information about the two instances, Order9369 and Order9370. In the service invocation module of the Nacos microservice cluster, the load balancing module accesses the Order service based on the target service list of the two instances to be invoked. For example, a round-robin invocation method is used, such as accessing the Order9369 instance in the Nacos microservice cluster the first time and the Order9370 instance in the Nacos microservice cluster the second time. At the same time, the load balancing module completes network and data interaction based on the information of the target service list.

[0212] Thus, embodiments of the present invention can realize service calls in heterogeneous microservice clusters through service instance clients in a microservice cluster, such as globally registered clients and service calling modules in service instance clients.

[0213] It should be noted that the description of the service processing method in the heterogeneous microservice cluster below is similar to the description of the service processing system in the heterogeneous microservice cluster above. The beneficial effects of the same system will not be repeated. For technical details not disclosed in the embodiments of the service processing method in the heterogeneous microservice cluster of this invention, please refer to the description of the embodiments of the service processing system in the heterogeneous microservice cluster of this invention.

[0214] like Figure 8 As shown, this embodiment of the invention provides a service processing method in a heterogeneous service cluster, executed by a global registry center cluster, including the following steps:

[0215] Step S41: Obtain the first service list of at least one registry center cluster;

[0216] Step S42: Perform format conversion on at least one of the first service lists to obtain a first global service list;

[0217] Step S43: Send the first global service list to at least one microservice cluster that is connected to at least one of the registration center clusters respectively.

[0218] The service processing method in the heterogeneous service cluster provided in this embodiment of the invention can be executed by the global registration client in the global registration center cluster.

[0219] In the embodiments of this invention, the global registry cluster, the microservice cluster, and the registry cluster can be the global registry cluster, the microservice cluster, and the registry cluster described in the above embodiments, respectively. The service list, first service list, second service list, third service list, global service list, first global service list, second global service list, and third global service list mentioned in the embodiments of this invention and below can be the service list, first service list, second service list, third service list, global service list, first global service list, second global service list, and third global service list described in the above embodiments, respectively.

[0220] In some embodiments, the global registry cluster includes: at least one global registry server and at least one global registry client; the global registry client is configured in the service instance client of the microservice cluster;

[0221] The first global service list is cached in at least one of the global registry center servers;

[0222] And / or, the first global service list is used for at least one of the microservice clusters to cache in at least one of the service instance clients of the microservice cluster.

[0223] In some embodiments, the global registry cluster is a global registry server; the method includes:

[0224] Obtain at least one second service list from the registration center cluster, wherein the second service list is determined based on an update of the first service list;

[0225] At least one of the second service lists is compared with the first global service list to obtain a first comparison result;

[0226] The first global service list is updated based on the first comparison result to obtain the second global service list.

[0227] The first comparison result of the present invention embodiment can be the first comparison result of the above embodiment.

[0228] In some embodiments, the registry cluster includes at least: a first registry cluster corresponding to the first microservice cluster and a second registry cluster corresponding to the second microservice cluster; the global registry cluster is a global registry server; the method includes:

[0229] Obtain at least one list of third services from the first registry center cluster;

[0230] The format of the third service list is converted to obtain a third global service list;

[0231] The third global service list is sent to the second microservice cluster, wherein the third global service list is used by the second microservice cluster to update the first global service list.

[0232] like Figure 9 As shown, this embodiment of the invention provides a service processing method in a heterogeneous service cluster, executed by a service instance client in a microservice cluster, including the following steps:

[0233] Step S51: Receive a first global service list sent by the global registry cluster; wherein, the first global service list is obtained by the global registry cluster by transforming at least one first service list; the first service list is obtained by the global registry cluster from at least one registry cluster;

[0234] Step S52: Cache the first global service list.

[0235] In some embodiments, the registry center cluster includes at least one first registry center cluster and at least one second registry center cluster; the method includes:

[0236] Obtain the call request sent by the first registry center cluster; wherein, the call request includes identification information indicating the registry center cluster to be called and / or identification information indicating the service to be called;

[0237] If the registry cluster to be invoked is determined to be the first registry cluster based on the invocation request, then the client of the service embodiment in the first microservice cluster is determined to invoke the service to be invoked indicated by the invocation request.

[0238] Alternatively, if the registry cluster to be invoked is determined to be the second registry cluster based on the invocation request, the first global service list is filtered based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and the service to be invoked indicated by the first target service list in the second microserver cluster is invoked based on the load balancing method.

[0239] Here, calling the service to be called indicated by the first target service list in the second microserver cluster based on load balancing can also be: calling the service to be called indicated by the first target service list in the second microserver cluster based on round-robin or weight-based calling.

[0240] Here, invoking the service to be invoked indicated by the first target service list in the second microserver cluster based on load balancing includes: sending an invocation request of the first target service list to the second microserver cluster, wherein the invocation request is used for the service instance clients of the second microserver cluster to invoke the service to be invoked indicated by the first target list based on load balancing.

[0241] It should be noted that the description of the service processing device in the heterogeneous microservice cluster below is similar to the description of the service processing system and / or method in the heterogeneous microservice cluster above. The beneficial effects of the same system and / or method will not be repeated. For technical details not disclosed in the embodiments of the service processing device in the heterogeneous microservice cluster of this invention, please refer to the description of the embodiments of the service processing system and / or method in the heterogeneous microservice cluster of this invention.

[0242] like Figure 10 As shown, this embodiment of the invention provides a service processing device in a heterogeneous microservice cluster, applied to a global registry center cluster, comprising:

[0243] The first receiving module 61 is used to obtain the first service list of at least one registration center cluster;

[0244] The first processing module 62 is configured to perform format conversion on at least one of the first service lists to obtain a first global service list;

[0245] The first sending module 63 is used to send the first global service list to at least one microservice cluster that is connected to at least one of the registration center clusters respectively.

[0246] In some embodiments, the global registry cluster includes: at least one global registry server and at least one global registry client; the global registry client is configured in the service instance client of the microservice cluster;

[0247] The first global service list is cached in at least one of the global registry center servers;

[0248] And / or, the first global service list is used for at least one of the microservice clusters to cache in at least one of the service instance clients of the microservice cluster.

[0249] In some embodiments, the global registry cluster is a global registry server;

[0250] The first acquisition module 61 is used to acquire at least one second service list in the registration center cluster, wherein the second service list is determined based on the first service list after being updated;

[0251] The first processing module 62 is configured to compare at least one of the second service lists with the first global service list to obtain a first comparison result;

[0252] The first processing module 62 is used to update the first global service list based on the first comparison result to obtain a second global service list.

[0253] In some embodiments, the registry cluster includes at least: a first registry cluster corresponding to the first microservice cluster and a second registry cluster corresponding to the second microservice cluster; the global registry cluster is a global registry server.

[0254] The first receiving module 61 is used to obtain at least one list of third services in the first registration center cluster;

[0255] The first processing module 62 is used to perform format conversion on the third service list to obtain a third global service list;

[0256] The first sending module 63 is used to send the third global service list to the second microservice cluster, wherein the third global service list is used by the second microservice cluster to update the first global service list.

[0257] like Figure 11 As shown, this embodiment of the invention provides a service processing device in a heterogeneous microservice cluster, applied to a global registry center cluster, comprising:

[0258] The second receiving module 71 is used to receive a first global service list sent by the global registration center cluster; wherein the first global service list is obtained by the global registration center cluster by transforming at least one first service list; the first service list is obtained by the global registration center cluster from at least one registration center cluster.

[0259] The second processing module 72 is used to cache the first global service list.

[0260] In some embodiments, the registry center cluster includes at least one first registry center cluster and at least one second registry center cluster; the apparatus includes:

[0261] The second acquisition module is used to acquire the call request sent by the first registration center cluster; wherein, the call request includes identification information indicating the registration center cluster to be called and / or identification information indicating the service to be called;

[0262] The second processing module 72 is configured to, if the registration center cluster to be invoked is determined to be the first registration center cluster based on the invocation request, determine the service to be invoked indicated by the invocation request based on the service embodiment client in the first microservice cluster;

[0263] or,

[0264] The second processing module 72 is configured to, if it is determined from the call request that the registry cluster to be called is the second registry cluster, filter the first global service list based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and call the service to be called indicated by the first target service list in the second microserver cluster based on a load balancing method.

[0265] like Figure 12 As shown, this embodiment of the invention also provides a terminal, which includes a processor 81 and a memory 82 for storing computer programs that can run on the processor 81; wherein, when the processor 81 runs the computer program, it implements the service processing method in a heterogeneous microservice cluster of any embodiment of the invention.

[0266] In some embodiments of the present invention, the memory may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0267] The processor may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the processor's hardware or by software instructions. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0268] In some embodiments, the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the invention, or combinations thereof.

[0269] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or externally.

[0270] Another embodiment of the present invention provides a computer storage medium storing an executable program, which, when executed by a processor, can implement the steps of the service processing method in a heterogeneous microservice cluster according to any embodiment of the present invention.

[0271] In some embodiments, the computer storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0272] It should be noted that the technical solutions described in the embodiments of the present invention can be combined arbitrarily without conflict.

[0273] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A service processing system in a heterogeneous microservice cluster, characterized in that, include: A global registry cluster, at least two registry clusters, and at least two microservice clusters; among which, The microservice cluster is connected to the corresponding registry center cluster; The global registry cluster is connected to at least two registry clusters respectively, and is used to obtain a first service list of at least one registry cluster; and to perform format conversion on at least one first service list to obtain a first global service list in a unified format; wherein, the first service list has a data format corresponding to its respective registry cluster; The global registry cluster is connected to at least two of the microservice clusters respectively, and is used to send the first global service list to at least one of the microservice clusters; The global registry cluster includes at least one global registry server and at least one global registry client; the microservice cluster includes at least one service instance client; the global registry client is configured in the service instance client of the microservice cluster; the global registry cluster is the global registry server; the global registry server is used to cache the first global service list; the global registry client is used to obtain the first global service list provided by the global registry server and cache the first global service list; the microservice cluster performs service calls between microservice clusters based on the first global service list.

2. The system according to claim 1, characterized in that, The global registry center server is used to obtain at least one second service list in the registry center cluster, wherein the second service list is determined based on the first service list after being updated; The global registration center server is used to compare at least one of the second service lists with the first global service list to obtain a first comparison result; The global registration center server is used to update the first global service list based on the first comparison result to obtain the second global service list.

3. The system according to claim 1 or 2, characterized in that, The microservice cluster includes at least: at least one first microservice cluster and at least one second microservice cluster; the registry center cluster includes at least: a first registry center cluster connected to the first microservice cluster and a second registry center cluster connected to the second microservice cluster. The global registry center server is used to obtain at least one third service list from the first registry center cluster; and to perform format conversion on the third service list to obtain a third global service list. The global registry center server is used to update the third global service list to the service instance clients in the second microservice cluster.

4. The system according to claim 1 or 2, characterized in that, The microservice cluster includes at least one first microservice cluster and at least one second microservice cluster; the registry cluster includes at least one first registry cluster connected to the first microservice cluster and a second registry cluster connected to the second microservice cluster; the service instance client further includes a service invocation module; the service instance client in the first microservice cluster includes a first service invocation module, and the service instance client in the second microservice cluster includes a second service invocation module; The first service invocation module is used to obtain an invocation request; wherein, the invocation request includes identification information indicating the registration center cluster to be invoked and / or identification information indicating the service to be invoked; The first service invocation module is configured to, if the registry cluster to be invoked is determined to be the first registry cluster based on the invocation request, determine to invoke the service to be invoked indicated by the invocation request based on the service instance client in the first microservice cluster; Alternatively, the first service invocation module is configured to, if determined based on the invocation request that the registry cluster to be invoked is the second registry cluster, filter the first global service list based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and use the second invocation module to invoke the service to be invoked indicated by the first target service list in the second microservice cluster based on a load balancing method.

5. A service processing method in a heterogeneous microservice cluster, characterized in that, Executed by the global registry center cluster, including: Obtain a first service list of at least one registry center cluster; wherein the first service list has a data format corresponding to each of the respective registry center clusters; Perform a format conversion on at least one of the first service lists to obtain a first global service list in a uniform format; Send the first global service list to at least one microservice cluster that is connected to at least one of the registry center clusters respectively; The global registry cluster includes at least one global registry server and at least one global registry client; the microservice cluster includes at least one service instance client; the global registry client is set in the service instance client of the microservice cluster; the global registry cluster is a global registry server; the first global service list is cached in at least one of the global registry servers; the first global service list is cached in at least one of the at least one global registry client by at least one of the microservice clusters; the global service list in the global registry client is used for service calls between the microservice clusters.

6. The method according to claim 5, characterized in that, The method includes: Obtain at least one second service list from the registration center cluster, wherein the second service list is determined based on an update of the first service list; At least one of the second service lists is compared with the first global service list to obtain a first comparison result; The first global service list is updated based on the first comparison result to obtain the second global service list.

7. The method according to claim 5, characterized in that, The microservice cluster includes at least one first microservice cluster and at least one second microservice cluster; the registry center cluster includes at least one first registry center cluster corresponding to the first microservice cluster and a second registry center cluster corresponding to the second microservice cluster; the method includes: Obtain at least one list of third services from the first registry center cluster; The format of the third service list is converted to obtain a third global service list; The third global service list is sent to the second microservice cluster, wherein the third global service list is used by the second microservice cluster to update the first global service list.

8. A service processing method in a heterogeneous microservice cluster, characterized in that, Executed by the service instance client in the microservice cluster, including: The system receives a first global service list in a unified format sent by a global registry cluster. The first global service list in a unified format is obtained by the global registry cluster by converting at least one first service list. The first service list is obtained by the global registry cluster from at least one registry cluster. The first service list has a data format corresponding to its respective registry cluster. The global registry cluster includes at least one global registry server and at least one global registry client. The microservice cluster includes at least one service instance client. The global registry client is configured within the service instance client of the microservice cluster. The global registry cluster is a global registry server. The first global service list is cached in the at least one global registry center client; Service calls between the microservice clusters are made based on the first global service list.

9. The method according to claim 8, characterized in that, The microservice cluster includes at least one first microservice cluster and at least one second microservice cluster; the registry center cluster includes at least one first registry center cluster and at least one second registry center cluster; the method includes: Obtain the call request sent by the first registry center cluster; wherein, the call request includes identification information indicating the registry center cluster to be called and / or identification information indicating the service to be called; If the registry cluster to be invoked is determined to be the first registry cluster based on the invocation request, then the service instance client in the first microservice cluster is determined to invoke the service to be invoked as indicated by the invocation request. Alternatively, if the request determines that the registry cluster to be invoked is the second registry cluster, the first global service list is filtered based on the identification information of the second registry cluster to obtain the first target service list corresponding to the second registry cluster; and the service to be invoked indicated by the first target service list in the second microservice cluster is invoked based on the load balancing method.

10. A service processing device in a heterogeneous microservice cluster, characterized in that, Applied to global registry center clusters, including: A first receiving module is configured to obtain a first service list of at least one registry center cluster; wherein the first service list has a data format corresponding to each of the respective registry center clusters. The first processing module is used to perform format conversion on at least one of the first service lists to obtain a first global service list in a unified format. The first sending module is used to send the first global service list to at least one microservice cluster that is respectively connected to at least one of the registration center clusters; The global registry cluster includes at least one global registry server and at least one global registry client; the microservice cluster includes at least one service instance client; the global registry client is set in the service instance client of the microservice cluster; the global registry cluster is the global registry server; the first global service list is cached in at least one of the global registry servers; the first global service list is cached in at least one of the at least one global registry client by at least one of the microservice clusters; the global service list in the global registry client is used for service calls between the microservice clusters.

11. A service processing device in a heterogeneous microservice cluster, characterized in that, Applied to service instance clients in a microservice cluster, including: The second receiving module is used to receive a first global service list in a unified format sent by the global registry cluster; wherein the first global service list in a unified format is obtained by the global registry cluster by converting at least one first service list; the first service list is obtained by the global registry cluster from at least one registry cluster; the first service list has a data format corresponding to its respective registry cluster; the global registry cluster includes: at least one global registry server and at least one global registry client; the microservice cluster includes: at least one service instance client; the global registry client is set in the service instance client of the microservice cluster; the global registry cluster is the global registry server; The second processing module is used to cache the first global service list in the at least one global registry center client; The first invocation module is used to make service invocations between the microservice clusters based on the first global service list.

12. A terminal, characterized in that, The terminal includes a processor and a memory for storing computer programs that can run on the processor; wherein, when the processor runs the computer programs, it implements the service processing method in a heterogeneous microservice cluster as described in any one of claims 5 to 7 or 8 to 9.

13. A computer storage medium, characterized in that, The computer storage medium contains computer-executable instructions, characterized in that the computer-executable instructions are executed by a processor to implement the service processing method in the heterogeneous microservice cluster as described in any one of claims 5 to 7 or 8 to 9.

Images