CN118714191A - A method for unified registration, discovery and invocation of multiple types of services - Google Patents

Abstract

The invention relates to the technical field of micro-service registration discovery and service call, in particular to a method for uniformly registering, discovering and calling multi-type services, which comprises the following steps: building a micro-service architecture, comprising a service registry, a registration center and a service gateway; the service registry is used for acquiring service instance information from different clusters and synchronizing the service instance information to the registry; the registration center is used for providing service information of service management, service registration, service discovery and service instance list, and the registration center adopts a service end registration mode to realize the decoupling of the registration center and the service; the service gateway is used for synchronously obtaining a service instance list from the registration center and selecting service instance call; the service registry configures an API of the cluster where the access is based on the cluster where the service deployment is located and correctly synchronizes the service instance information; the invention can realize unified service registration and discovery and service call without deployment and micro-service architecture transformation of different services of different systems.

Description

A method for unified registration, discovery and invocation of multiple types of services

Technical Field

The present invention relates to the technical field of microservice registration discovery and service invocation, and in particular to a method for unified registration, discovery and invocation of multiple types of services.

Background Art

In the internal IT systems of enterprises, there are often systems from various sources, such as purchased, self-developed, and open source. Different systems often use different technology stacks and microservice architectures, such as the common Springcloud, Dubbo, or monolithic service architecture; the deployment architectures of different systems are usually different, such as deployment based on fixed hosts, using distributed resource scheduling and management frameworks such as mesos and K8s; in this case, each project or system usually needs to maintain its own registration center and service load balancing, making it very difficult to build a unified cross-system service call, service and API management, service monitoring, link tracking, etc. for the company. Integrating or adapting the scattered heterogeneous system services requires huge costs and faces huge risks.

Therefore, without changing the deployment and service architecture of various heterogeneous systems, how to implement a unified service registration, discovery and call mechanism to reduce the management and operation costs of services is an urgent problem to be solved.

Summary of the invention

The purpose of the present invention is to overcome the defects of the prior art and provide a method for unified registration, discovery and invocation of multiple types of services.

The present invention provides a method for unified registration, discovery and invocation of multiple types of services, characterized in that it includes the following steps:

Step 1: Build a microservice architecture, including a service registrar, a registration center, and a service gateway;

The service registrar is used to obtain service instance information from different clusters and synchronize it to the registration center; the registration center is used to provide service information for service management, service registration, service discovery, and service instance list. The registration center adopts the server-side registration method to achieve the decoupling of the registration center and the service; the service gateway is used to synchronize the service instance list from the registration center and select the service instance to call;

Step 2: The service registrar configures the access cluster API and correctly synchronizes the service instance information according to the cluster where the service is deployed;

Step 3: When a service instance changes, the cluster service instance information is compared with the full service instance information obtained from the registration center, and the service instance information is updated according to the comparison result and synchronized to the service registrar;

Step 4: The service registrar obtains the updated service instance information and registers it with the registration center, so that the registration center obtains the latest service instance information;

Step 5: The service gateway obtains the latest service instance information from the registration center, matches the most appropriate service instance information according to the service request, initiates a service call, and forwards it to the service requester.

Further, in step 4, the mode in which the service registrar obtains service instance information includes:

1) Event monitoring mode: If the cluster supports service event monitoring, the service registrar will implement a listener and register it with the cluster to capture service status change events. When an event is captured, the registrar will obtain the latest status information of the relevant service instance;

2) Polling mode: If the cluster does not support event monitoring, the service registrar will use polling mode to periodically call the cluster API to obtain the list and status information of service instances.

Furthermore, in step 4, after registering the service instance information to the registration center, it also includes:

Step 4-1, synchronization of service registrar and registration center: the service registrar compares the obtained service instance information with the information in the registration center, identifies and processes service instances in different states. When a service instance exists in the cluster but not in the registration center, it is added to the registration center and identified as a newly added instance; when a service instance does not exist in the cluster but exists in the registration center, it is deleted from the registration center and identified as a stopped instance; when a service instance exists in both the cluster and the registration center, no processing is performed and it is identified as an existing instance;

Step 4-2, traverse and synchronize all service instances: The service registrar loops through all service instances and repeats step S4-1 until all service instances are processed.

Further, in step 5, the service gateway obtains the latest service instance information from the registration center, matches the most appropriate service instance information according to the service request, initiates a service call, and forwards it to the service requester, specifically including:

Step 5-1, the service gateway refreshes the service instance cache: the service gateway periodically polls the registration center to obtain the latest service instance information and refreshes the local cache;

Step 5-2, service call: Service request A initiates an access request to service instance B to the service gateway. After receiving the request, the service gateway queries the local service instance cache, matches the most suitable service instance B, initiates a service call, and forwards it to service request A.

Furthermore, the service call in step 5 specifically includes:

1) Query service instance: The service gateway queries the latest service instance information based on the service name and version number information in service request A;

2) Load balancing: Select the appropriate service instance B from the service instance list according to the load balancing policy corresponding to the service. If there is no available instance, it returns failure.

3) Signature verification: The service gateway verifies the signature of the request. The signature verification algorithm uses the request path combined with the timestamp and key MD5 signature authentication. If the verification fails, it returns failure.

4) Permission verification: Verify the API call permission. If the verification fails, it will return failure;

5) Logging: The service gateway records relevant information about the service call, including the call time, caller, callee, and request parameters;

6) Forward request: The service gateway forwards service request A to service instance B, waits for the return result, and returns the result information to service request A.

Furthermore, the load balancing strategies include random, round-robin and consistent hashing.

Furthermore, the registration center adopts a distributed master-slave architecture with a coordinator and multiple workers. The coordinator is used for service registration, discovery and service interface management. After accepting the service registration, the coordinator writes the service instance information into the service instance database. The service instance database is used to store all service instance information of the registration center and service instance information collection. The service instance database is a closure tree table structure, which is used to convert service instance retrieval into a dynamic binary tree search algorithm.

The worker node is used to communicate with the service gateway. The worker node obtains the full service instance information and refreshes the local cache of the registration center through regular communication with the coordinator node.

Compared with the prior art, the present invention has the following beneficial effects:

The present invention builds a microservice architecture, which includes a service registrar, a registration center, and a service gateway; the service registrar is used to obtain service instance information from different clusters and synchronize it to the registration center; the registration center is used to provide service information of service management, service registration, service discovery, and service instance list, and the registration center adopts a server-side registration method to achieve decoupling of the registration center and the service; the service gateway is used to synchronize the service instance list from the registration center and select the service instance to call; there is no mandatory requirement for the technology stack and deployment method used by the service itself, and the registration center adopts a server-side registration method, and the cluster where the service registrar is located obtains the updated service instance information through event monitoring or polling, and registers it to the registration center, and supports other types of clusters by extending the service registrar to achieve unified service registration and discovery under heterogeneous clusters, and incorporates various types and services of different deployment methods into a unified microservice communication and management system. In this way, the decoupling of the service and the registration center is achieved, and the service itself does not need to be modified, which greatly improves the operability and convenience of unified management of systems and services in a complex IT architecture environment of the enterprise, and reduces the access cost;

This application is applicable to the unified registration, discovery, and invocation of multiple types of services in heterogeneous cluster deployment scenarios, so that different services of different systems do not need to be deployed and transformed into microservice architecture, and unified service registration, discovery, and service invocation can be achieved.

BRIEF DESCRIPTION OF THE DRAWINGS

The following drawings are only used to illustrate and explain the present invention, and are not used to limit the scope of the present invention, wherein:

FIG1 is a schematic diagram of the structure of the service access registration center of different clusters of the present invention;

FIG2 is a schematic diagram of a multi-type service registration and discovery process of the present invention;

FIG3 is a schematic diagram of a multi-type service calling process of the present invention;

FIG4 is a schematic diagram of a unified registration, discovery and invocation structure of multiple types of services in a heterogeneous cluster deployment scenario of the present invention.

DETAILED DESCRIPTION

In order to make the purpose, technical solution, design method and advantages of the present invention clearer, the present invention is further described in detail by specific embodiments in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

As shown in FIG. 1 to FIG. 4 , the present invention provides a method for unified registration, discovery and invocation of multiple types of services, including the following steps:

Step 1: Build a microservice architecture, including a service registrar, a registration center, and a service gateway;

The service registrar is used to obtain service instance information from different clusters and synchronize it to the registration center; the registration center is used to provide service information for service management, service registration, service discovery and service instance list. The registration center adopts a server-side registration method, and the cluster where the service registrar is located obtains the updated service instance information through event monitoring or polling, and registers it to the registration center. By extending the service registrar to support other types of clusters, unified service registration and discovery under heterogeneous clusters are realized, and services of various types and different deployment methods are included in a unified microservice communication and management system. In this way, the decoupling of the registration center and the service is realized; the service gateway is used to synchronize the service instance list from the registration center and select the service instance to call;

The registration center adopts a distributed master-slave architecture with a coordinator and multiple workers. The coordinator is used for service registration, service discovery and service interface management. After accepting the service registration, the coordinator writes the service instance information into the service instance database. The service instance database is used to store all service instance information of the registration center and service instance information collection. The service instance database is a closure tree table structure, which is used to convert service instance retrieval into a dynamic binary tree search algorithm.

The worker node is used to communicate with the service gateway. It is used to obtain full service instance information and refresh the local cache of the registration center through regular communication between the worker node and the coordinator node.

The microservice architecture of this application is shown in Figure 1. The microservice architecture in Figure 1 includes the following:

1) Registration center: The registration center provides service management, service registration, and service discovery functions. This registration center is different from traditional registration centers such as eureka (service registration and discovery)/nacos (Dynamic Naming and Configuration Service, registration configuration center). Traditional registration centers mostly use client registration, that is, the service itself needs to establish a connection with the registration center and maintain a heartbeat to achieve service discovery and registration; the registration center of this application adopts a server-side registration method, that is, the registration center does not interact directly with the service, and the cluster where the service is located, including the host agent, K8s (Kubernetes, Google's open source container cluster management system), mesos (a framework for implementing this type of distributed computing), Alibaba Cloud ACR (Alibaba Cloud Container Registry, Alibaba Cloud Container Mirror Service), etc., obtains the latest status and address of the service instance through event monitoring or polling, and updates it to the registration center. In this way, the registration center and the service are decoupled, and any type of service can be connected to the registration center without feeling.

2) Service Registry: In order to support the service access registration center of various clusters in Figure 1, this application provides different service registries for different clusters. The service registrar is mainly responsible for monitoring or polling service changes from different clusters and synchronizing them to the registration center.

3) Service Gateway: Traditional microservice calls are usually client-side load balancing. The client itself stores a list of service instances, which is obtained by synchronization from the registration center, and the load balancing call is implemented through the client's built-in load balancing algorithm. This application adopts the server-side load balancing method. The service caller and the callee do not communicate directly. The service call and the callee are uniformly implemented through the service gateway routing. The service gateway and the registration center synchronize the service instance list regularly. In this way, on the one hand, the decoupling of the registration center and the service is achieved, and the service call only needs to interact with the service gateway; on the other hand, through the service gateway, it is easy to implement service management, service call record tracking, API (Application Programming Interface) management, and permission control functions;

It should be noted that this application builds a microservice architecture, which includes a registration center, a service registrar and a service gateway. The registration center adopts a server-side registration method, that is, the registration center does not interact directly with the service. The cluster where the service is located obtains the latest status and address of the service instance through event monitoring or polling, and updates it to the registration center. In this way, the decoupling of the registration center and the service is achieved, and any type of service can be connected to the registration center without feeling. The service registrar is mainly responsible for monitoring or polling service changes from different clusters and synchronizing them to the registration center. The server-side load balancing method is adopted, and the service caller and the callee do not communicate directly. The service call and the callee are uniformly implemented through the service gateway. The service gateway and the registration center periodically synchronize the service instance list, where the service instance list is used to record the service configuration. In this way, on the one hand, the decoupling of the registration center and the service is achieved, and the service call only needs to interact with the service gateway; on the other hand, through the service gateway, it is convenient to implement service management, service call record tracking, API management, and permission control functions; by extending the service registrar to support other types of clusters, unified registration, discovery, and calling of multiple types of services in heterogeneous clusters are achieved, and security and management functions such as signature verification, permission verification, and logging are provided.

Step 2: The service registrar configures the access cluster API and correctly synchronizes the service instance information according to the cluster where the service is deployed;

Step 3: When a service instance changes, the cluster service instance information is compared with the full service instance information obtained from the registration center, and the service instance information is updated according to the comparison result and synchronized to the service registrar;

Step 4: The service registrar obtains the updated service instance information and registers it with the registration center, so that the registration center obtains the latest service instance information;

Among them, the modes in which the service registrar obtains service instance information include:

1) Event monitoring mode: If the cluster supports service event monitoring, the service registrar will implement a listener and register it with the cluster to capture service status change events. When an event is captured, the registrar will obtain the latest status information of the relevant service instance;

2) Polling mode: If the cluster does not support event monitoring, the service registrar will use polling mode to periodically call the cluster API to obtain the list and status information of service instances;

In step 4, after registering the updated service instance information to the registration center, it also includes:

Step 4-1, synchronization of service registrar and registration center: the service registrar compares the obtained service instance information with the information in the registration center, identifies and processes service instances in different states. When a service instance exists in the cluster but not in the registration center, it is added to the registration center and identified as a newly added instance; when a service instance does not exist in the cluster but exists in the registration center, it is deleted from the registration center and identified as a stopped instance; when a service instance exists in both the cluster and the registration center, no processing is performed and it is identified as an existing instance;

Step 4-2, traverse and synchronize all service instances: The service registrar loops through all service instances and repeats step S4-1 until all service instances are processed;

As shown in Figure 2, a complete multi-type service registration and discovery process is as follows:

S1, based on the cluster where the service is deployed and started, when new services are released, existing services are restarted, services are scaled up or down, or services drift due to their own failures, the instance information on the deployment cluster where the service is located changes. Here, there are mature process solutions and APIs based on different cluster types such as mesos clusters;

S2: When all service instance information changes are completed, that is, the old instance is stopped and the new service is started, the service registrar obtains the updated service instance information and registers it to the registration center; specifically:

When a cluster such as a mesos cluster supports service event monitoring mode, the service registrar implements the listener and registers to monitor cluster service status change events;

When the cluster, such as Alibaba Cloud ack (Acknowledge character, indicating that the received character is error-free), does not support service event monitoring, the cluster API is called periodically in polling mode to obtain all instance information of the service.

S3, the service registrar synchronizes with the registration center, obtains the full amount of service instance information from the registration center, traverses the services, and compares them with the cluster service instances obtained in S2. When the service name, API version, IP, port and other information are consistent, they are considered to be the same instance. The following are identified: First, the instance exists in the cluster but not in the registration center. This is a new instance, so add this instance to the registration center; Second, the instance does not exist in the cluster but exists in the registration center. This instance has been stopped and is deleted from the registration center; Third, the instance exists in both the cluster and the registration center, so skip it directly;

S4, loop S3 until all services are traversed.

Step 5: The service gateway obtains the latest service instance information from the registration center, matches the most appropriate service instance information according to the service request, initiates a service call, and forwards it to the service requester.

Among them, the service caller initiates a service call through the service gateway, as shown in Figure 3. A complete multi-type service call process is as follows:

Step 5-1, the service gateway refreshes the service instance cache: the service gateway periodically polls the registration center to obtain the latest service instance information and refreshes the local cache;

Step 5-2, service call: Service request A initiates an access request to service instance B to the service gateway. After receiving the request, the service gateway queries the local service instance cache, matches the most suitable service instance B, initiates a service call, and forwards it to service request A;

In step 5-2, the service call specifically includes:

1) Query service instance: The service gateway queries the latest service instance information based on the service name and version number information in service request A;

2) Load balancing: Select the appropriate service instance B from the service instance list according to the load balancing policy corresponding to the service. If there is no available instance, it returns failure.

The load balancing strategies include random, round-robin, and consistent hashing;

3) Signature verification: The service gateway verifies the signature of the request. The signature verification algorithm uses the request path combined with the timestamp and the key MD5 (Message Digest Algorithm MD5, Message Digest Algorithm Version 5) signature authentication. If the verification fails, a failure is returned.

4) Permission verification: Verify the API call permission. If the verification fails, it returns failure;

5) Logging: The service gateway records relevant information about the service call, including the call time, caller, callee, and request parameters;

6) Forwarding request: The service gateway forwards service request A to service instance B, waits for the result to be returned, and returns the result information to service request A;

In the application, the registration center uniformly defines the service structure as follows:

kind: registration type, service type or other type;

specVersion: service specification version number;

name: service name;

apiVersion: API version;

group: service group information;

environment: environment, such as dev, test, prod, etc.

cluster: the cluster ID, such as marathon, mesos, etc.

sandBox: sandbox information;

containerType: container type, such as docker, node, etc.;

metadata: service metadata, such as memory, cpu, environment variables, mount points, etc.

loadbalance: load balancing strategy, such as random, weight-based, load-based, etc.

List<Instance>: instance list, including access protocol type such as Http, container IP, port, load weight and other information.

As shown in Figure 4, the implementation of the registration center needs to support high performance and high availability. The implementation structure adopts a distributed master-slave architecture with one admin (coordinator) and multiple workers.

Among them, the coordinator is used for service registration, service interface management, etc. The coordinator itself can also achieve high availability through load balancing. And because the coordinator node only communicates with the management page and the service registrar, the number of concurrency is not high, so there is no need for special performance optimization. After receiving the service registration, the coordinator writes the service instance information into the service instance database; among them, the service instance list is used to record the service configuration array; the service instance database is used to store the service instance information and the collection of the service instance list.

The service instance database is used to store all services and instance information of the registration center. In order to achieve high-performance reading and writing of service instances, the service instance database is implemented using a closure tree table structure. For each service instance, a key (path) is generated. The path key structure is: registration type/service specification version number/service name/API version/service group/environment identifier/cluster identifier/instance ID. The service instance list is designed with a tree table structure. Each level of directory in the path is an independent node, and the leaf node is the service instance. The service instance database uses a closure tree table structure to convert service instance retrieval into a dynamic binary tree search algorithm. In order to further improve the search efficiency, a Closure Table is constructed to store the node relationship and hierarchical information of the service instance tree nodes. This can reduce the service instance retrieval time complexity to the O(n) level.

A service instance tree and closure table data structure is as follows:

Node //Service instance node

{

String parentKey; //parent node path Key

String absoluteKey; //This node path key

...//Other information of the instance

List<Node>nodes; //Sub-node list

}

NodePath //Service instance tree closure table

{

String ancestor; //ancestor information

String descendant; //descendant information

Integer depth; //Tree depth level

};

The worker nodes of the registration center are mainly used for communication with the service gateway. The worker nodes obtain the full service instance information and refresh the local cache through regular communication with the coordinator node. The worker nodes use memory as a service instance cache to improve read and write efficiency. Multiple worker nodes achieve high availability through external load balancing such as nginx (lightweight/high-performance reverse proxy Web server) and SLB (Server Load Balance, network load balancing server).

Among them, heterogeneous cluster deployment scenarios include but are not limited to: containerized or non-containerized deployment based on fixed hosts, localized deployment based on K8s (Kubernetes, Google's open source container cluster management system) or k3s cluster (a lightweight version of K8s), localized deployment based on mesos+marathon (implementing service discovery and load balancing and other functions) clusters, deployment based on cloud native capabilities such as Alibaba Cloud ack/Taobao Jushita, etc.; multi-type services include but are not limited to JAVA microservices based on Springcloud (a full-family bucket technology stack), JAVA microservices based on Dubbo (a remote call distributed service framework), JAVA services using SSH (secure shell, secure shell protocol) or SSM (framework integration of Spring, SpringMVC, and Mybatis) frameworks, web (communication network) services built using Node.js (Javascript code running environment), web services built based on Python (a high-level programming language), etc.

It is worth noting that, compared with various existing open source and commercial registration centers and microservice framework solutions, the registration center and service gateway component introduced in the present invention has no mandatory requirements on the technology stack and deployment method used by the service itself, and adopts the server-side registration and service gateway load method to achieve the decoupling of the service and the microservice framework. The service itself does not perceive the microservice suite, which provides the service with extremely strong scalability and compatibility; the microservice suite itself can be horizontally expanded through high-performance components and high-availability design, and a high concurrent processing capability can be achieved in a simple way;

Through this solution, services of various types and deployment methods, such as JAVA services, Node (operating environment) services, etc., can be incorporated into a unified microservice communication and management system, and the services themselves do not need to be modified. This greatly improves the operability and convenience of unified management of systems and services in the complex IT architecture environment of the enterprise, and reduces access costs. This solution is highly innovative and practical in actual business system integration.

Embodiment 1: The registration center is implemented using JAVA (programming language) technology and Mysql (open source relational database management system) database structure, the service instance database is implemented using a closure tree table structure, and the implementation algorithm is a dynamic binary tree search algorithm.

Service registrar, this embodiment describes the technical method for implementing the K8s (Kubernetes, Google's open source container cluster management system) cluster, and the implementation methods of other clusters are similar. The K8s service registrar implements communication with the K8s cluster by introducing the client-javaSDK package. The introduction method is:

<dependency>

<groupId>io.kubernetes</groupId>

<artifactId>client-java</artifactId>

</dependency>;

The K8s cluster service uses the nodeport (port range) method to access the K8s cluster Service from outside the cluster without going through load balancing or Ingress (entrance). The registrar starts two scheduled tasks A and B. Scheduled task A regularly calls the registration center API to obtain a full list of service instances and caches them in local memory; scheduled task B calls the K8s cluster API to obtain all K8s cluster services. For each service, the service discovery list is obtained through the API, and the local memory cache is queried to obtain the service instance list, which is compared with step S3, and the stopped instances are removed from the registration center and new instances are added.

Service gateway, in this embodiment, OpenResty (network platform) script is used to implement a high-performance and highly available API gateway. Specifically, OpenResty is a high-performance Web platform based on Nginx (lightweight HTTP server) and Lua, which integrates a large number of sophisticated Lua (scripting language) libraries, third-party modules and most dependencies. It is used to easily build dynamic Web applications, Web services and dynamic gateways that can handle ultra-high concurrency and high scalability. In this embodiment, multiple Lua scripts can be written to realize the processing and forwarding of requests, such as request authentication, load balancing, etc. This method is all prior art.

In the specific implementation, the implementation of the method of unified registration, discovery and invocation of multiple types of services in the heterogeneous cluster deployment scenario is as follows from the steps of microservice architecture construction, service registration and discovery, and service invocation:

1) Select appropriate technical methods to implement microservice architecture: registration center, service registrar and service gateway;

Registration center: It is implemented using Java (programming language) technology and Mysql (open source relational database management system) database, and adopts a closed tree table structure to store service instance information. The registration center is used to provide service management, service registration, service discovery, and service instance list service information. The registration center adopts a server-side registration method to achieve decoupling of the registration center and the service;

Service Registry: For K8s cluster, use the client-java SDK (Software Development Kit) package to communicate with the K8s cluster. The service registrar needs to implement two scheduled tasks to obtain service instance status information from the K8s cluster at regular intervals and synchronize it to the registration center.

Service Gateway: Use OpenResty (network platform) script to implement high-performance API gateway, which is used to handle request authentication, load balancing and other functions, synchronize the service instance list from the registration center, and select the service instance to call;

2) Configure the access service registrar according to the cluster where the service is deployed.

Configure the K8s service registrar according to the K8s cluster where the service is deployed, and ensure that the service registrar can access the K8s cluster API and correctly synchronize service instance information;

3) Automatically or manually publish the service to the deployment cluster. When the service is started, the old instance is stopped and the new instance is started.

Automatically or manually publish the service to the K8s cluster. After the service is published, the old instance is stopped and the new instance is started;

4) The service registrar obtains the updated service instance information and registers it with the registration center, so that the registration center obtains the latest service instance information;

Specifically, scheduled task A of the K8s cluster service registrar obtains the full service instance list from the registration center and caches it in local memory.

Scheduled task B calls the K8s cluster API (Kubernetes Application Programming Interface) to obtain all Service and Endpoints information.

Scheduled task B compares the service instance information in the local cache and the K8s cluster, and updates the service instance list in the registration center based on the comparison results;

5) The service gateway obtains the latest service instance information from the registration center, matches the most appropriate service instance information according to the service request, initiates the service call, and forwards it to the service requester;

The service gateway refreshes the service instance cache: The service gateway periodically polls the registration center to obtain the latest service instance information and refreshes the local cache;

Service call: Service request A initiates an access request to service instance B to the service gateway. After receiving the request, the service gateway queries the local service instance cache, matches the most suitable service instance B, initiates a service call, and forwards it to service request A.

It should be noted that the service registrar synchronizes the service instance status information with the registration center, ensuring the accuracy of service discovery; the service gateway, as a unified entry point for services, implements routing and load balancing of service calls, improving the scalability and maintainability of the system; the registration center uses a closure tree table structure to store service instance information, supporting complex service management and query requirements. Service instance synchronization: The synchronization of service instances is achieved through the scheduled tasks of the service registrar, ensuring that the information in the registration center is consistent with the actual status of the service. Multi-cluster support: Although this embodiment is only described for K8s clusters, the service registrar can be extended to support other types of clusters to achieve unified service registration and discovery under heterogeneous clusters.

It is worth noting that this application is applicable to the unified registration, discovery and invocation of multiple types of services in heterogeneous cluster deployment scenarios, so that different services of different systems do not need to be deployed and transformed into microservice architecture, and unified service registration and discovery as well as service invocation can be achieved;

By building a microservice architecture, the microservice architecture includes a service registrar, a registration center, and a service gateway; the service registrar is used to obtain service instance information from different clusters and synchronize it to the registration center; the registration center is used to provide service information for service management, service registration, service discovery, and service instance list, and the registration center adopts a server-side registration method to achieve decoupling of the registration center and the service; the service gateway synchronizes the service instance list from the registration center and selects the service instance to call; there is no mandatory requirement for the technology stack and deployment method used by the service itself, and the registration center adopts a server-side registration method, and the cluster where the service is located obtains the updated service instance information through event monitoring or polling, and registers it to the registration center. In this way, the decoupling of the service and the registration center is achieved, and services of various types and different deployment methods, such as JAVA services, Node.js services, etc. can be included in a unified registration center, and the registration center is used to provide service information for service management, service registration, service discovery, and service instance list, and the registration center adopts a server-side registration method to achieve decoupling of the registration center and the service; and the service itself does not need to be modified, which greatly improves the operability and convenience of unified management of systems and services in the complex IT architecture environment of the enterprise, and reduces the access cost.

The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims (7)

1. A method for unified registration, discovery and invocation of multiple types of services, characterized in that it includes the following steps: Step 1: Build a microservice architecture, including a service registrar, a registration center, and a service gateway; The service registrar is used to obtain service instance information from different clusters and synchronize it to the registration center; the registration center is used to provide service information for service management, service registration, service discovery and service instance list. The registration center adopts the server-side registration method to achieve the decoupling of the registration center and the service; the service gateway is used to synchronize the service instance list from the registration center and select the service instance to call; Step 2: The service registrar configures the access cluster API and correctly synchronizes the service instance information according to the cluster where the service is deployed; Step 3: When a service instance changes, the cluster service instance information is compared with the full service instance information obtained from the registration center, and the service instance information is updated according to the comparison result and synchronized to the service registrar; Step 4: The service registrar obtains the updated service instance information and registers it with the registration center, so that the registration center obtains the latest service instance information; Step 5: The service gateway obtains the latest service instance information from the registration center, matches the most appropriate service instance information according to the service request, initiates a service call, and forwards it to the service requester. 2. The method for unified registration, discovery and invocation of multiple types of services according to claim 1, characterized in that: In step 4, the mode in which the service registrar obtains service instance information includes: 1) Event monitoring mode: If the cluster supports service event monitoring, the service registrar will implement a listener and register it with the cluster to capture service status change events. When an event is captured, the registrar will obtain the latest status information of the relevant service instance; 2) Polling mode: If the cluster does not support event monitoring, the service registrar will use polling mode to periodically call the cluster API to obtain the list and status information of service instances. 3. According to claim 2, a method for unified registration, discovery and invocation of multiple types of services is characterized in that in step 4, after registering the updated service instance information to the registration center, it also includes: Step 4-1, synchronization of service registrar and registration center: the service registrar compares the obtained service instance information with the information in the registration center, identifies and processes service instances in different states. When a service instance exists in the cluster but not in the registration center, it is added to the registration center and identified as a newly added instance; when a service instance does not exist in the cluster but exists in the registration center, it is deleted from the registration center and identified as a stopped instance; when a service instance exists in both the cluster and the registration center, no processing is performed and it is identified as an existing instance; Step 4-2, traverse and synchronize all service instances: The service registrar loops through all service instances and repeats step S4-1 until all service instances are processed. 4. The method for unified registration, discovery and invocation of multiple types of services according to claim 3, characterized in that: In step 5, the service gateway obtains the latest service instance information from the registration center, matches the most appropriate service instance information according to the service request, initiates a service call, and forwards it to the service requester, including: Step 5-1, the service gateway refreshes the service instance cache: the service gateway periodically polls the registration center to obtain the latest service instance information and refreshes the local cache; Step 5-2, service call: Service request A initiates an access request to service instance B to the service gateway. After receiving the request, the service gateway queries the local service instance cache, matches the most suitable service instance B, initiates a service call, and forwards it to service request A. 5. The method for unified registration, discovery and invocation of multiple types of services according to claim 4, characterized in that: The service call in step 5 specifically includes: 1) Query service instance: The service gateway queries the latest service instance information based on the service name and version number information in service request A; 2) Load balancing: Select the appropriate service instance B from the service instance list according to the load balancing policy corresponding to the service. If there is no available instance, it returns failure. 3) Signature verification: The service gateway verifies the signature of the request. The signature verification algorithm uses the request path combined with the timestamp and the MD5 signature authentication of the key. If the verification fails, a failure is returned. 4) Permission verification: Verify the API call permission. If the verification fails, it returns failure; 5) Logging: The service gateway records relevant information about the service call, including the call time, caller, callee, and request parameters; 6) Forward request: The service gateway forwards service request A to service instance B, waits for the return result, and returns the result information to service request A. 6. The method for unified registration, discovery and invocation of multiple types of services according to claim 5, characterized in that: The load balancing strategies include random, round-robin, and consistent hashing. 7. The method for unified registration, discovery and invocation of multiple types of services according to claim 1, characterized in that: The registration center adopts a distributed master-slave architecture with a coordinator and multiple workers. The coordinator is used for service registration, service discovery and service interface management. After accepting the service registration, the coordinator writes the service instance information into the service instance database. The service instance database is used to store all service instance information of the registration center and service instance information collection. The service instance database is a closure tree table structure, which is used to convert service instance retrieval into a dynamic binary tree search algorithm; The worker node is used to communicate with the service gateway. The worker node obtains the full service instance information and refreshes the local cache of the registration center by regularly communicating with the coordinator node.