A unified governance method and system for multiple types of registration centers on a cloud native platform

Abstract

The present application provides a method and system for unified governance of multiple types of registry centers on a cloud native platform. When a first query request directed to a target microservice is received, the native interface provided by the target registry center where the target microservice is located is called to obtain the service registration information of the target microservice; the service registration information of the target microservice is converted into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first type of service attributes are service attributes commonly supported by all types of registry centers, and the second type of service attributes are service attributes individually supported by the target registry center; the target service registration information is returned as a response to the first query request. Thus, the service registration information stored in multiple registry centers is converted into target service registration information, and the query request is responded to using unified target service registration information, so as to achieve unified governance of multiple types of registry centers.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a method, system, computer-readable storage medium, and electronic device for unified governance of multiple types of registration centers on a cloud native platform. Background Art

[0002] In the microservice system, there are three roles according to different functions: microservice provider (RPC Server), microservice consumer (RPC Client), and registration center (Register). Among them, when the microservice provider starts, it registers and stores its own service registration information in the registration center, and sends a heartbeat mechanism to the registration center regularly to ensure its survival status; the microservice consumer obtains the service registration information of the microservice provider from the registration center, and implements service calls based on the service registration information.

[0003] Microservice technology is the technology for realizing the above-mentioned microservice system. In the process of microservice technology development, a variety of different microservice frameworks (such as Spring Cloud, Dubbo, etc.) have emerged. Different microservice frameworks are equipped with different registration centers (such as Eureka, Nacos, Zookeeper, Mesh, etc.). The registration center is used to realize the registration and discovery of various microservices under the microservice framework. With the continuous development and complexity of business, enterprises usually have applications based on different microservice frameworks, which also requires access to multiple types of registration centers. At this time, due to the different underlying architectures of various microservice frameworks, different registration centers use different data structures, access protocols, data consistency implementation methods, and interface types. As a result, different registration centers can only provide their own governance methods. When administrators manage different registration centers, there is no unified governance method and they can only access the corresponding registration center platform one by one for operation, which is very inconvenient.

[0004] The premise of achieving unified governance is to unify the service registration information in different registration centers and then provide a unified calling method to the outside world. To this end, the relevant technologies usually solve this problem through the following ways: First, modify the source code of each registration center so that the service registration information stored in it is arranged according to a unified data structure, so that the service registration information can be used in a unified calling method; second, do not modify the source code of the registration center, but rewrite the service registration information generated by the registration center, that is, intercept the service registration information of different data structures generated by different registration centers during the service registration process, rewrite it into service registration information with a preset coding structure, and then store it back in the registration center, so that service consumers can call the rewritten service in a unified way according to the coding.

[0005] However, on the one hand, both of the above methods require modifying the service registration / calling process of the original registration center, which invades the original microservice system, has high transformation costs, and is difficult to implement in production practice; on the other hand, both of the above methods improve the microservice registration process from the perspective of computer program identification and management, and do not take into account the administrator's governance needs for various types of registration centers. In other words, for administrators, there is still no way to govern microservices managed by various types of registration centers through a unified governance interface.

[0006] Therefore, it is necessary to provide an improved technical solution to address the above-mentioned deficiencies in the prior art. Summary of the invention

[0007] The purpose of this application is to provide a method, system, computer-readable storage medium and electronic device for unified governance of various types of registration centers on a cloud native platform to solve or alleviate the problems existing in the above-mentioned prior art.

[0008] In order to achieve the above objectives, this application provides the following technical solutions:

[0009] This application provides a unified governance method for multiple types of registry centers on a cloud native platform, including:

[0010] In response to receiving a first query request directed to a target microservice, calling a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice; the target registration center is any one of multiple types of registration centers;

[0011] Convert the service registration information of the target microservice into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by aggregating first-class service attributes and second-class service attributes; the first-class service attributes are service attributes commonly supported by all types of the registration centers, and the second-class service attributes are service attributes individually supported by the target registration center;

[0012] The target service registration information is returned as a response to the first query request.

[0013] Preferably, the first type of service attribute is determined by the following steps:

[0014] Collect all service attributes contained in the service registration information stored in all types of registries;

[0015] Comparing the service attributes contained in the service registration information stored in different types of registration centers;

[0016] In response to the service registration information stored in all types of the registration centers containing the same service attributes, the fields of the same service attributes are unified, and the values ​​of the same service attributes are converted according to a preset mapping relationship to serve as the first type of service attributes.

[0017] Preferably, while determining the first type of service attributes, the second type of service attributes are determined by the following steps:

[0018] In response to the service registration information stored in the registration center containing service attributes other than the first category of service attributes, the fields and values ​​of the service attributes other than the first category of service attributes are written into a predefined encapsulation field, and the fields and values ​​of the service attributes other than the first category of service attributes are kept unchanged as the second category of service attributes.

[0019] Preferably, after returning the target service registration information as a response to the first governance request, the method further includes:

[0020] Cache the target service registration information;

[0021] In response to receiving a second query request directed to the target microservice, calling a native interface provided by the target registration center to obtain the last update time of the target microservice;

[0022] In response to the last update time of the target microservice matching the update time recorded in the cached target service registration information, the cached target service registration information is returned as a response to the second query request.

[0023] Preferably, the above-mentioned unified governance method for multiple types of registration centers on the cloud native platform also includes:

[0024] In response to a change in the running state of the target microservice, the target microservice sends a service registration information update request to the target registration center;

[0025] In response to an update of the service registration information of the target microservice stored in the target registration center, the cached target service registration information is updated based on the updated service registration information.

[0026] Preferably, the updating of the cached target service registration information based on the updated service registration information is specifically as follows:

[0027] Determining, according to the changed service attribute field in the service registration information, the corresponding service attribute field in the target service registration information;

[0028] The values ​​of the changed service attributes in the service registration information are converted and used as the values ​​of the corresponding service attributes in the target service registration information.

[0029] Preferably, before in response to receiving the first query request directed to the target microservice, calling a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice, the method further includes:

[0030] In response to receiving an instruction to manage all the registration centers;

[0031] Acquire native interface information provided by each registration center based on the access address and type of each registration center;

[0032] The registration center is managed based on the native interface information of the registration center.

[0033] The present application embodiment provides a unified governance system for multiple types of registration centers on a cloud native platform, including:

[0034] A calling unit is configured to, in response to receiving a first query request directed to a target microservice, call a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice; the target registration center is any one of multiple types of registration centers;

[0035] A conversion unit, configured to convert the service registration information of the target microservice into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by aggregating first-class service attributes and second-class service attributes; the first-class service attributes are service attributes commonly supported by all types of the registration centers, and the second-class service attributes are service attributes individually supported by the target registration center;

[0036] The returning unit is configured to return the target service registration information as a response to the first query request.

[0037] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored, wherein the computer program is a method for unified governance of multiple types of registration centers of a cloud native platform as described above.

[0038] An embodiment of the present application also provides an electronic device, including: a memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the unified governance method for multiple types of registration centers of a cloud native platform as described above is implemented.

[0039] Beneficial effects:

[0040] In the technical solution provided by the present application, when receiving the first query request pointing to the target microservice, the native interface provided by the target registration center where the target microservice is located is called to obtain the service registration information of the target microservice; the service registration information of the target microservice is converted into the target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by collecting the first type of service attributes and the second type of service attributes; the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes supported by the target registration center alone; the target service registration information is returned as a response to the first query request. In this way, the service registration information of the target microservice is obtained by calling the native interface provided by the target registration center, and it is converted into the target service registration information with a unified format. There is no need to modify the service registration information stored in the target registration center, and unified governance of multiple types of registration centers can be achieved. Accordingly, the administrator only needs to access the centralized microservice governance center provided by the present application to uniformly govern microservices under different microservice frameworks, thereby reducing the workload of the administrator and improving the efficiency of microservice governance. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The drawings constituting part of the present application are used to provide a further understanding of the present application. The exemplary embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. Among them:

[0042] Figure 1 A schematic diagram of the relationship between the roles in the microservice system in related technologies;

[0043] Figure 2 A logical diagram of the corresponding relationship between the microservice framework and the supporting registration center in the relevant technology;

[0044] Figure 3 A logical diagram of a unified governance method for multiple types of registry centers on a cloud native platform provided according to some embodiments of the present application;

[0045] Figure 4 A flowchart of a unified governance method for multiple types of registry centers on a cloud native platform provided according to some embodiments of the present application;

[0046] Figure 5 A schematic diagram of the structure of a unified governance system for multiple types of registration centers on a cloud native platform provided according to some embodiments of the present application;

[0047] Figure 6A schematic diagram of the structure of an electronic device provided according to some embodiments of the present application;

[0048] Figure 7 A hardware structure diagram of an electronic device provided according to some embodiments of the present application. DETAILED DESCRIPTION

[0049] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. Each example is provided by way of explanation of the present application and does not limit the present application. In fact, it will be clear to those skilled in the art that modifications and variations may be made in the present application without departing from the scope or spirit of the present application. For example, a feature shown or described as a part of an embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desired that the present application includes such modifications and variations within the scope of the appended claims and their equivalents.

[0050] In the following description, the terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first / second / third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0051] In order to facilitate understanding of the technical solution of the present application, the relevant technology is explained below.

[0052] In a microservice system, there are usually three roles: microservice provider, microservice consumer, and registration center. Among them, the registration center is the core component, which is used to store the service registration information of microservices, such as location data, metadata, heartbeat data, etc. In addition, the registration center also records the mapping relationship between microservices and access addresses. When the service consumer needs to call other microservices, it first obtains the service registration information of the microservice to be called from the registration center, and initiates a call request to the service according to the access address contained in the service registration information. It can be understood that a microservice can call other microservices, and can also be called by other microservices. In other words, for the same microservice, it can be a microservice provider or a microservice consumer, or obtain both the roles of microservice provider and microservice consumer at the same time.

[0053] Specifically, the relationship between the roles in the microservice system is as follows: Figure 1As shown in the figure, when the microservice provider starts the service, it registers its own information with the registration center, and sends heartbeat feedback information to the registration center at a certain time interval to provide its survival status. The registration center is used to save the service registration information of the microservice provider, and when the service instance information of the microservice provider changes, it can be synchronized and updated in time to avoid call failures between microservices. When the microservice consumer starts, it subscribes to the microservice to be called through the registration center to obtain the service registration information of the microservice from the registration center, and initiates a call request to the microservice based on the service registration information, that is, establishes a connection with the microservice provider, and caches the obtained service registration information locally to update the local routing table originally cached.

[0054] Due to the different underlying architectures of various microservice frameworks, different registration centers use different data structures, access protocols, data consistency implementation methods, and interface types. Taking the data structure as an example, although the service registration information managed by each registration center contains the service status attribute, the fields and field values ​​used by each registration center to store the service status attribute are different. For example, in Eureka, the status field is used to record the service status. When the status value is "UP", it means that the service is running normally. In Mesh, the instanceStatus field is used to record the service status. When the instanceStatus value is "STATUS_UP", it means that the service is running normally. Due to the different data structures, access protocols, data consistency implementation methods, and interface types used by different registration centers, the management interfaces are different. When the administrator manages different registration centers, there is no unified entrance and can only access the corresponding registration center platform one by one to operate, which is very inconvenient and inefficient.

[0055] Most of the solutions provided by related technologies improve the microservice registration process from the perspective of facilitating computer program identification and management. The goal is to break the barriers to service calls between different registration centers so that microservices managed by different registration centers can call each other in a unified manner. The unified governance requirements of administrators for multiple types of registration centers are not taken into account. For example, when rewriting service registration information, some technologies first intercept the service registration process, then select several service attributes from the service registration information, such as access IP address, port, etc., and then convert them into a unified service code according to certain encoding rules, and store the unified service code in the service registration table, while storing the mapping relationship between the service identifier and the unified service code. In this way, when a service consumer calls the service or an administrator needs to govern the service, it is necessary to find the corresponding unified service code from the mapping relationship according to the service identifier carried in the service request, and decode it to obtain the original service registration information, and finally provide the original service registration information to the service consumer or the administrator. It can be seen that the above process is oriented to the unification of program interfaces, that is, the computer program can determine the service registration information pointed to by the service identifier through the unified service coding. This not only interferes with the original communication protocol between each microservice and the registration center, but also for the administrator, what they are faced with is still the original service registration information with different data structures after decoding. There is still no unified governance interface to facilitate the administrator to manage microservices managed by various types of registration centers.

[0056] To this end, the present application provides a method, system, computer-readable storage medium and electronic device for unified management of multiple types of registration centers on a cloud native platform. By converting the service registration information of the target microservice into target service registration information containing a first service attribute set and a second service attribute set, extracting and aggregating the service attributes commonly supported by all types of registration centers through the first service attribute set, encapsulating the service attributes individually supported by each registration center, and finally converting the service registration information with different data structures into target service registration information with consistent data structures, it is greatly convenient for administrators to uniformly manage multiple types of registration centers. In addition, by calling the native API interface provided by the target registration center where the target microservice is located to obtain the service registration information of the target microservice, the target microservice and its consumers of the target microservice are completely unaware of the process, and will not interfere with the original communication protocols of the parties, thereby achieving non-intrusive unified management.

[0057] Exemplary Methods

[0058] This application embodiment provides a unified management method for multiple types of registration centers on a cloud native platform, such as Figure 3 , Figure 4 As shown, the method includes:

[0059] Step S101: In response to receiving a first query request directed to a target microservice, a native interface provided by a target registration center where the target microservice is located is called to obtain service registration information of the target microservice.

[0060] The target registration center is any one of multiple types of registration centers.

[0061] Microservices are originally independent systems split into multiple micro-services, which are all running in their own independent processes, and the microservices mainly collaborate through the Hypertext Transfer Protocol (HTTP). In order to achieve zero service interruption, microservices are usually deployed with multiple service instances, also called service nodes. Each service instance in the multiple service instances can be regarded as a copy of the microservice, and each service instance provides the same function and provides services to the outside world together. In the embodiment of the present application, the target microservice can be any microservice managed by the target registration center. The service registration information of the target microservice can include the information of the target microservice itself, such as the name of the microservice, the virtual IP address of the microservice, etc., and can also include the information of multiple service instances corresponding to the target microservice, such as the access address and port of each service instance.

[0062] In the unified governance method for multiple types of registry centers on a cloud native platform provided in an embodiment of the present application, the multiple types of registry centers include but are not limited to: Eureka, Consul, Zookeeper, Nacos, etc. These registry centers are usually important components of a microservice framework and jointly implement the governance of microservices.

[0063] For ease of understanding, the microservice framework and various types of registration centers are described in detail below.

[0064] A microservice framework is a runtime environment required for deploying microservices. Therefore, in order to deploy microservices, it is usually necessary to first deploy the corresponding microservice framework in the cloud native platform so that the microservices can run normally. Common microservice frameworks include Spring Cloud and Dubbo. Generally speaking, different microservice frameworks have different corresponding registration center types.

[0065] Specifically, see Figure 2, microservice frameworks include Spring Cloud, Dubbo, etc. It should be understood that microservice frameworks also include different versions. For example, Dubbo commonly uses 2.x or 3.x versions, referred to as Dubbo2 / 3. For microservices under the Spring Cloud framework, Eureka is usually used as its registration center. Microservices under the Dobbo framework are often used in conjunction with Zookeeper, and the Nacos registration center can be connected to microservices under the Spring Cloud framework as well as microservices under the Dubbo framework.

[0066] Different registration centers have different characteristics. The following introduces each type of registration center separately.

[0067] Eureka is a registry developed by Netflix, which is mainly applicable to distributed systems implemented in Java language or systems built with programming languages ​​compatible with Java Virtual Machine (JVM). In addition to Java systems, the service governance mechanism of Eureka server also provides a complete RESTful application programming interface (Application Program Interface, API) to incorporate microservices built in programming languages ​​other than Java into Eureka's service governance system.

[0068] Eureka consists of two components: Eureka Server and Eureka Client. Eureka Server provides microservice registration services. After each service instance (also called service node) corresponding to the microservice is started, it will be registered in Eureka Server. In this way, the service registry in Eureka Server will store information about all available service nodes of the microservice.

[0069] Eureka Client is a client developed in Java language, which is used to interact with Eureka Server. For microservices implemented in Java language, Eureka Client can easily manage them. However, for microservices built in other programming languages, after being incorporated into Eureka through RESTful API, the corresponding Eureka Client is implemented for the microservice when it is used, so that the microservice can interact normally with Eureka Server.

[0070] It should be noted that in order to ensure the high availability of the registration center, Eureka is usually deployed in a cluster. Eureka clusters usually adopt a non-master-slave architecture (non-Master / Slave architecture), so the roles of each node in the cluster are consistent, and there is no distinction between master nodes and slave nodes. After the data generated by the microservice registration, renewal, consumption, and offline processes are written to any node in the cluster, the node will replicate it to other nodes in the cluster to achieve weak consistency synchronization.

[0071] Nacos is another type of registry that is dedicated to discovering, configuring, and managing microservices, and can quickly and easily build cloud-native applications and microservice platforms. Specifically, Nacos enables the rapid construction of cloud-native applications and microservice platforms by providing a set of simple and easy-to-use feature sets, including: service discovery and service health monitoring, dynamic configuration services, dynamic DNS services, services and their metadata management, etc. Nacos supports the docking of microservices of almost all microservice frameworks, such as microservices managed by Dubbo / gRPC, RESTful API microservices of Spring Cloud, or microservices managed by Kubernetes. In other words, Nacos has a wide range of support capabilities for microservice frameworks. It can dock with various types of microservice frameworks and serve as a registry for microservice frameworks, providing them with service registration, service discovery, and other functions.

[0072] ZooKeeper is a distributed, open source distributed application coordination service. It is an open source implementation of Google's Chubby and an important component of Hadoop and Hbase. It can provide consistency services for distributed applications. The functions provided by ZooKeeper include: configuration maintenance, domain name service, distributed synchronization, group service, etc. In the development of microservice projects, ZooKeeper is often used in conjunction with the microservice framework Dubbo. As the registration center of Dubbo, it provides microservice registration, discovery and other capabilities.

[0073] It can be seen that the various registries introduced above are developed by different companies, and there are many differences between them, such as differences in interface types and access protocols. Specifically, the access protocol is a communication protocol formed between the registry and each microservice to achieve microservice governance. In the early distributed system architecture, the DNS protocol is usually used as the communication protocol for microservice registration and discovery. However, the microservice registration and discovery mechanism based on the DNS protocol has problems such as poor flexibility, inability to customize, ports and language frameworks. To solve the above problems, large companies began to lead the development of new registries, resulting in the emergence of more and more registries based on "private" protocols. Since each registry is developed by different companies, its working methods and basic concept models are different, and the development and configuration requirements for microservices are also different. For example, some registries need to integrate specific software development kits (SDK), and some registries need to complete specified configuration content when deployed. These differences have virtually raised the technical threshold for the development of microservices and put forward higher technical requirements for developers, which in turn has brought many challenges to enterprises using microservices to implement their business systems.

[0074] For example, the differences among Eureka, Zookeeper, and Nacos in terms of interface type, data consistency, and access protocol are shown in Table 1. Table 1 is as follows:

[0075] Table 1 Comparison of differences between Eureka, Zookeeper, and Nacos

[0076]

[0077] As can be seen from Table 1, Eureka, Zookeeper, and Nacos all provide interfaces to the outside world through SDK. In terms of data consistency, the three registry centers are all implemented based on the distributed theory CAP. Among them, the CAP theory specifically explains that in a distributed system, Consistency, Availability, and PartitionTolerance cannot be established at the same time, that is, among the three main aspects of consistency C, availability A, and partition tolerance P of a distributed system, only two of them can be selected to be implemented at the same time. Usually, partition tolerance is necessary, so common distributed systems can be CP systems or AP systems. In Table 1, Zookeeper is a CP system, Nacos can be an AP system or a CP system, and Eureka is an AP system. In terms of access protocol, Zookeeper and Eureka both use the TCP protocol for communication, while Nacos uses the HTTP protocol.

[0078] It is precisely because of the above differences between different types of registration centers that various types of registration centers cannot communicate and merge with each other directly. In the related art, unified management is achieved by modifying the registration center itself to implement logic or intercepting the communication of the registration center and rewriting the service registration information. However, the above methods all invade the original microservice system. In the embodiment of the present application, in order to achieve unified governance without intrusion on the original microservice system, the service registration information is obtained by calling the native interface (API interface) provided by the registration center.

[0079] Specifically, see Figure 3 The cloud native platform is deployed with a centralized microservice governance center. The centralized microservice governance center is a component deployed for administrators to uniformly govern multiple registration centers. It is used to call the native API interface provided by each registration center through the access endpoint (Endpoint) of the unified microservice registration center integration platform to obtain the service registration information of multiple types of registration centers. In other words, the embodiment of the present application performs unified abstract encapsulation of different types of registration centers, and implements a unified interface definition on the periphery of various types of registration centers according to the characteristics of each registration center, such as interface type, data consistency, access protocol, etc., to form an access endpoint of the unified microservice registration center integration platform. The centralized microservice governance center obtains the service registration information in different types of registration centers through the access endpoint, thereby realizing the unified management of different types of microservice centers.

[0080] When the centralized microservice governance center receives the administrator's first query request to the target microservice, it calls the native interface provided by the target registration center where the target microservice is located through the access endpoint to obtain the service registration information of the target microservice. Here, the target registration center can be any of a variety of types of registration centers, and the target microservice can be any microservice in the target registration center. In other words, the administrator can uniformly govern any microservice in different microservice centers through the centralized microservice governance center without switching, and will not interfere with the original communication of the registration center, so that each registration center is unaware of this.

[0081] In the embodiment of the present application, the service registration related to the target registration center is still completed by the microservice provider and the target registration center in cooperation. Only when the first query request pointing to the target microservice is received, the centralized microservice governance center will call the native interface provided by the target registration center to obtain the service registration information of the target microservice, so that the obtained service registration information of the target microservice can always be consistent with the service registration information stored in the target registration center, realizing the automatic registration of microservices and maintenance of service lists, while being able to perform quasi-real-time data query and data synchronization.

[0082] It should be understood that before sending the first query request directed to the target microservice, the administrator needs to obtain the correspondence between the target registration center and the target microservice, that is, all registration centers must be uniformly managed first. To this end, in some embodiments, in response to receiving the first query request directed to the target microservice, calling the native interface provided by the target registration center where the target microservice is located to obtain the service registration information of the target microservice, it also includes: responding to receiving an instruction to manage all registration centers; obtaining the native interface information provided by each registration center based on the access address and type of each registration center; and managing the registration center based on the native interface information of the registration center.

[0083] Specifically, when the business system is deployed, the administrator can obtain information such as the type, quantity, deployment method, specific distribution location, access address, etc. of all the registration centers. After the centralized microservice governance center is initialized, the administrator sends an instruction to the centralized microservice governance center to manage all the registration centers. The centralized microservice governance center receives the instruction and determines the native interface information of each registration center according to the access address and type of each registration center, that is, determines the native API interface and call parameters that the access endpoint needs to call, etc. Then, based on the native interface information of each registration center, a query instruction is issued to each registration center through the access endpoint to obtain a list of some or all microservices managed by each registration center, and thus obtains the corresponding relationship between each registration center and the microservices it manages, so as to achieve unified access and management of the registration center.

[0084] Among them, the query instruction can be an instruction to obtain the service list of the registration center or an instruction to obtain the operating status of the registration center, or an instruction to obtain the namespace of the registration center. The above instructions can be issued to each registration center at the same time through the access endpoint, or they can be issued separately. This application does not limit this. In addition, each registration center can be deployed in a cluster manner. Therefore, the access address of the registration center can be the access address of a single node in the cluster, or it can be a collection of access addresses of multiple nodes in the cluster. In other words, the access endpoint of this application can query information to multiple nodes of the registration center at the same time based on the access addresses of multiple nodes in a unified manner.

[0085] As a unified interface outside various types of registration centers, the access endpoint implements the abstract encapsulation of different types of registration centers. That is, for different types of registration centers, the access endpoint performs access processing separately. Taking Eureka, Zookeeper, and Nacos as examples, the access processing process is as follows:

[0086] For Nacos-type registry centers, the access endpoint uses the access address of the Nacos-type registry center as a parameter, and uses the native development API provided by Nacos to send query instructions to the registry center, so as to unify the microservices under some or all namespaces in the Nacos registry center into the centralized microservice governance center.

[0087] For Eureka-type registries, the access endpoint uses the access address of the Eureka-type registries as a parameter. Through the native API interface provided by Eureka, the microservices in the Eureka registries are managed as a whole in the centralized microservice governance center at one time.

[0088] When accessing a Zookeeper-type registration center, the access endpoint uses the access address exposed by the Zookeeper registration center as a parameter, and uses the Zookeeper client SDK to manage Zookeeper as a registration center in the centralized microservice governance center.

[0089] From the above process, it can be seen that when the centralized microservice governance center manages various types of registration centers, the access endpoint accesses different types of registration centers through the native interfaces provided by various types of registration centers. It will not interfere with the original communication protocol between the microservices and each registration center, nor will it change the original service registration and service discovery process. No adjustments are required for either the server or the client of the registration center, thus achieving unaware and non-invasive unified access and governance of microservices.

[0090] Step S102: Convert the service registration information of the target microservice into target service registration information.

[0091] Among them, the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by collecting the first type of service attributes and the second type of service attributes; the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes individually supported by the target registration center.

[0092] It should be noted that the service registration information of the target microservice includes multiple service attributes, each of which is usually represented by a key-value pair (key / value), where the keyword key represents the name of the service attribute, and the value value is used to represent the specific value of the service attribute.

[0093] As mentioned above, different registration centers use different data structures. For example, the same service attributes are stored using different key-value pairs, or the service attributes with the same content have different value expressions. The service registration information of the target microservice obtained through the native interface provided by the target registration center still retains the original data structure of the target registration center, which is not conducive to the administrator's unified management. Therefore, in an embodiment of the present application, the service registration information of the target microservice is converted into the target service registration information so that it has a unified data structure so that the administrator can perform unified management. Specifically, the target service registration information includes two types of service attributes, namely, the first type of service attributes and the second type of service attributes, wherein the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes supported solely by the target registration center. The first type of service attributes and the second type of service attributes in the service registration information of the target microservice are respectively collected to obtain the first service attribute set and the second service attribute set.

[0094] Furthermore, the first category of service attributes is determined through the following steps: collecting all service attributes contained in the service registration information stored in all types of registration centers; comparing the service attributes contained in the service registration information stored in different types of registration centers; in response to the fact that the service registration information stored in all types of registration centers contains the same service attributes, unifying the fields of the same service attributes, and converting the values ​​of the same service attributes according to a preset mapping relationship as the first category of service attributes.

[0095] In order to determine the service attributes commonly supported by all types of registration centers, in an embodiment of the present application, the service registration information stored in all types of registration centers is first collected, all the service attributes contained therein are collected, and then the collected service attributes are compared to extract the same content. When it is determined that the service registration information stored in all types of registration centers contains a certain identical service attribute, the fields of the identical service attribute are unified, and the values ​​of the identical service attribute are converted according to the preset mapping relationship as the first type of service attribute, so that the service attributes commonly supported by all registration centers can be returned in a unified data structure. In this way, the administrator only needs to be familiar with a set of specific data structures of service attributes to understand the meaning of their expression at a glance, and then manage them, reducing the workload of the administrator and improving management efficiency.

[0096] Taking the status field and instanceStatus field in the aforementioned Eureka and Mesh as an example, given that the status field and instanceStatus field in Eureka and Mesh are both used to record the service status, the embodiment of the present application regards the status field and instanceStatus field as the same service attribute, uses a unified status field to record the service status, and uniformly converts the values ​​​​"UP" and "STATUS_UP" to "working" to indicate that the service is running normally.

[0097] Various types of registration centers also include unique service attributes, which are service attributes that are separately supported by various registration centers. In order to preserve the integrity of the data, the embodiments of the present application encapsulate them as second-class service attributes. Specifically, while determining the first-class service attributes, the second-class service attributes are determined through the following steps: In response to the service registration information stored in the registration center containing service attributes other than the first-class service attributes, the fields and values ​​of the service attributes other than the first-class service attributes are written into pre-defined encapsulation fields, and the fields and values ​​of the service attributes other than the first-class service attributes are kept unchanged as the second-class service attributes.

[0098] It should be understood that after collecting all service attributes contained in the service registration information stored by all types of registration centers, the process of determining whether a certain service attribute should be classified as a first-category service attribute or a second-category service attribute is carried out simultaneously, that is, the service attributes contained in the service registration information stored by different types of registration centers are compared. When it is determined that a certain service attribute is a service attribute common to all types of registration centers, it is confirmed that the service attribute can be used as a first-category service attribute, and the possibility that it is a second-category service attribute is excluded, and vice versa. When a certain service attribute is a service attribute other than a first-category service attribute contained in the service registration information stored by the registration center, it should be written into the pre-defined encapsulation field as a second-category service attribute, and the field and value of the service attribute should be kept unchanged.

[0099] It should be noted that all service attributes contained in the service registration information stored in all types of registration centers are still collected through the native interfaces provided by each type of registration center. The specific method of obtaining service registration information through the native interface of the registration center is shown in the above steps, which will not be repeated here.

[0100] For example, the service registration information of a microservice stored in a Nacos-type registry includes name, namespace, and service attributes such as dom, cacheMillis, useSpecifiedUrl, checksum, env, and clusters. The name and namespace of Service are the same service attributes in all types of registries, as the first type of service attributes, while dom, cacheMillis, useSpecifiedUrl, checksum, env, and clusters are unique to Nacos-type registries, as the second type of service attributes. After converting the service registration information stored in a Nacos-type registry into the target service registration information, the data structure is as follows:

[0101]

[0102] In the embodiment of the present application, the service registration information of the target microservice is converted into the target service registration information by collecting, comparing, unifying and encapsulating the service attributes contained in the service registration information, thereby forming a unified data structure, which is not only conducive to the rapid identification of service attributes, but also more convenient for administrators to uniformly manage the service registration information. At the same time, since the process only involves extraction, comparison and encapsulation operations, the consumption of computing resources is low, which improves the computing efficiency compared to operations such as encoding / decoding that require a large amount of computing resources.

[0103] Step S103: Return the target service registration information as a response to the first query request.

[0104] In the embodiment of the present application, after obtaining the target service registration information with a unified data structure, it is returned as a response to the first query request. In this way, for different types of registration centers, the centralized microservice governance center can obtain service registration information with a unified data structure, and realize the panoramic observability of the microservices managed by each registration center. When a new type of registration center needs to be accessed, due to the unified data structure, the administrator does not need to understand the data structure of the service registration information of the new type of registration center to uniformly manage it. It is not only very convenient to access and manage different types of registration centers, improve the compatibility of different types of registration centers, but also enable administrators to focus more on business management and improve management efficiency. In addition, the present application uses a centralized microservice governance center as a unified entrance to uniformly manage different types of registration centers. When the administrator manages the microservices managed by different types of registration centers, there is no need to access the corresponding registration center platform one by one to operate, which improves the operation and maintenance efficiency and reduces the workload of the administrator.

[0105] It should be understood that the response to the first query request can be returned in a variety of forms, such as being written to a file, being returned immediately in a unified message mode, or being returned in XML, JSON, etc., which is not limited in this application. After obtaining the response to the first query request, a friendly and unified graphical interface can also be used for display, so that the administrator can more clearly understand the various service attribute information of the target microservice and the operating status of each service node.

[0106] In actual applications, when querying the target microservice for the first time, in order to ensure that the service registration information of the target microservice is synchronized with the service registration information stored in the target registration center, it is necessary to obtain the service registration information stored in the target registration center through the native interface provided by the target registration center. If the administrator queries the target microservice again later, he can choose one of the following two methods to handle it: the first method is to use the same method as the first query, that is, to call the native interface provided by the target registration center to obtain the service registration information stored in the target registration center; the second method is to introduce a cache mechanism to improve query efficiency.

[0107] To this end, in an embodiment of the present application, after returning the target service registration information as a response to the first governance request, it also includes: caching the target service registration information; in response to receiving a second query request directed to the target microservice, calling the native interface provided by the target registration center to obtain the last update time of the target microservice; in response to the last update time of the target microservice matching the update time recorded in the cached target service registration information, returning the cached target service registration information as a response to the second query request.

[0108] Specifically, after obtaining the target service registration information, the target service registration information is cached locally in the centralized microservice governance center. When a query request (second query request) pointing to the target microservice is received again, the centralized microservice center first calls the native interface provided by the target registration center to obtain the last update time of the target microservice, and compares the obtained last update time of the target microservice with the update time recorded in the cached target service registration information. Only when the last update time of the target microservice is the same as the update time recorded in the cached target service registration information, that is, the service registration information of the target microservice has not changed after caching, the cached target service registration information is returned as a response to the second query request. In this way, the step of converting the service registration information of the target microservice into the target service registration information can be skipped through caching, thereby further improving the query efficiency.

[0109] It should be understood that when the last update time of the target microservice is different from the update time recorded in the cached target service registration information, it means that the locally cached target service registration information may be different from the service registration information stored in the registration center. At this time, the centralized microservice governance center will obtain the latest service registration information of the target microservice through the native interface provided by the target registration center to convert it into the target service registration information, and return the conversion result as a response to the second query request to ensure data synchronization between the centralized microservice governance center and the various types of registration centers it governs.

[0110] It should be understood that the above implementation method of improving query efficiency through caching is to obtain the latest service registration information of the target microservice through the native interface provided by the target registration center when a query request directed to the target microservice is received and the last update time of the target microservice is different from the update time recorded in the cached target service registration information, so as to update the cached target service registration information. If no query request directed to the target microservice is received for a long time, the cached target service registration information will not be updated for a long time.

[0111] In addition, the embodiments of the present application also support synchronous updating of cached target service registration information when the running state of the target microservice changes. Simply put, in production practice, the running state of the target microservice may change, such as the state change caused by the microservice going online or offline, etc. In order to ensure that the service registration information of the target microservice after the running state changes is consistent with the target service registration information cached locally in the centralized microservice governance center, in some embodiments, it also includes: in response to the change in the running state of the target microservice, the target microservice sends a service registration information update request to the target registration center; in response to the service registration information of the target microservice stored in the target registration center being updated, the cached target service registration information is updated based on the updated service registration information.

[0112] Specifically, when the running state of the target microservice changes, the target microservice will send a service registration information update request to the target registration center. The target registration center will update the service registration information of the target microservice according to the service registration information update request to keep the running state of the target microservice stored in the target registration center consistent with the changed running state. The centralized microservice governance center monitors the changes in the service registration information of the target microservice. When it detects that the service registration information of the target microservice stored in the target registration center has been updated, the target service registration information cached locally in the centralized microservice governance center is updated based on the updated service registration information.

[0113] It should be noted that since monitoring changes in the service registration information of all microservices will consume a lot of computing resources, this application sets an automatic update attribute for the microservice to indicate whether to monitor changes in the service registration information of the microservice. In other words, the administrator can set some microservices that need to be accessed frequently as microservices that need to be automatically updated. In this way, the centralized microservice center only monitors changes in the service registration information of these microservices stored in the registration center, and updates the cached target service registration information based on the updated service registration information.

[0114] Furthermore, the cached target service registration information is updated based on the updated service registration information, specifically: according to the fields of the service attributes that have changed in the service registration information, the fields of the corresponding service attributes in the target service registration information are determined; the values ​​of the service attributes that have changed in the service registration information are converted and used as the values ​​of the corresponding service attributes in the target service registration information.

[0115] Based on the above description, it can be known that the target service registration information in the embodiment of the present application includes a first service attribute set and a second service attribute set. The first type of service attributes are generated by unifying the fields of the same service attributes and converting the values ​​of the same service attributes according to a preset mapping relationship. The second type of service attributes are generated by writing the fields and values ​​of service attributes other than the first type of service attributes into a predefined encapsulation field and keeping the fields and values ​​of service attributes other than the first type of service attributes unchanged. Therefore, different types of service attributes need to be updated in different ways.

[0116] For the first type of service attributes, the field of the service attribute corresponding to the field of the changed service attribute is first determined, and then the value of the changed service attribute is converted according to the preset mapping relationship as the value of the corresponding service attribute.

[0117] For the second type of service attributes, it is only necessary to directly determine the field of the service attribute corresponding to the field of the changed service attribute, and directly use the value of the changed service attribute as the value of the corresponding service attribute.

[0118] In an embodiment of the present application, based on the fields of the service attributes that have changed in the service registration information, the fields of the corresponding service attributes in the target service registration information are determined to convert the values ​​of the changed service attributes, thereby eliminating the need to comprehensively update the cached target service registration information. Instead, it is only necessary to quickly locate the fields of the corresponding service attributes in the cached target service registration information based on the fields of the service attributes that have changed, and update the values ​​of the corresponding service attributes, thereby greatly reducing the amount of data that needs to be updated and improving the efficiency of updating the cached target service registration information.

[0119] In summary, in this application, when a first query request pointing to a target microservice is received, the native interface provided by the target registration center where the target microservice is located is called to obtain the service registration information of the target microservice; the target registration center is any one of multiple types of registration centers; the service registration information of the target microservice is converted into the target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by collecting the first type of service attributes and the second type of service attributes; the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes supported by the target registration center alone; the target service registration information is returned as a response to the first query request. In this way, the service registration information of the target microservice is obtained by calling the native interface provided by the target registration center, and it is converted into the target service registration information with a unified format. Without modifying the service registration information stored in the target registration center, unified governance of multiple types of registration centers can be achieved. Accordingly, the administrator only needs to access the centralized microservice governance center provided by this application to uniformly govern microservices under different microservice frameworks, thereby reducing the workload of the administrator and improving the efficiency of microservice governance.

[0120] In an embodiment of the present application, by encapsulating different types of interfaces of different types of registration centers in the cloud native platform and providing a complete set of access methods that are compatible with multiple types of registration centers, administrators can easily manage multiple types of registration centers and manage microservices of different types of registration centers.

[0121] In an embodiment of the present application, service registration information of microservices is obtained by using native interfaces provided by multiple types of registration centers, and service attributes commonly supported by all types of registration centers are aggregated into a first service attribute set, and service attributes individually supported by each type of registration center are encapsulated into a second service attribute set, thereby achieving unified microservice discovery and unified display of microservices in different types of registration centers.

[0122] Exemplary Systems

[0123] The present application also provides a unified management system for various types of registration centers on a cloud native platform, such as Figure 5 As shown, the system includes multiple gateway instances, and the multiple gateway instances are located in different namespaces. The system includes: a calling unit 501, a conversion unit 502, and a return unit 503. Among them:

[0124] The calling unit 501 is configured to, in response to receiving a first query request directed to a target microservice, call a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice.

[0125] The target registration center is any one of multiple types of registration centers.

[0126] The conversion unit 502 is configured to convert the service registration information of the target microservice into the target service registration information.

[0127] Among them, the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by collecting the first type of service attributes and the second type of service attributes; the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes individually supported by the target registration center.

[0128] The returning unit 503 is configured to return the target service registration information as a response to the first query request.

[0129] The unified governance system for multiple types of registration centers on a cloud native platform provided in the embodiment of the present application can implement the processes and steps of the unified governance method for multiple types of registration centers on a cloud native platform provided in any of the above embodiments, and achieve the same technical effects, which will not be repeated here one by one.

[0130] Exemplary Devices

[0131] Figure 6 Schematic diagram of the structure of an electronic device provided according to some embodiments of the present application; Figure 6 As shown, the electronic device includes:

[0132] One or more processors 601;

[0133] The computer-readable medium can be configured to store one or more programs 602. When one or more processors 601 execute one or more programs 602, the following steps are implemented: in response to receiving a first query request directed to a target microservice, calling a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice; the target registration center is any one of a plurality of types of registration centers; converting the service registration information of the target microservice into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by aggregating the first type of service attributes and the second type of service attributes; the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes individually supported by the target registration center; returning the target service registration information as a response to the first query request.

[0134] Figure 7 The hardware structure of the electronic device provided according to some embodiments of the present application; Figure 7 As shown, the hardware structure of the electronic device may include: a processor 701 , a communication interface 702 , a computer-readable medium 703 and a communication bus 704 .

[0135] The processor 701 , the communication interface 702 , and the computer-readable storage medium 703 communicate with each other via a communication bus 704 .

[0136] Optionally, the communication interface 702 may be an interface of a communication module, such as an interface of a GSM module.

[0137] Among them, the processor 701 can be specifically configured as: in response to receiving a first query request directed to a target microservice, calling a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice; the target registration center is any one of a plurality of types of registration centers; converting the service registration information of the target microservice into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by aggregating the first type of service attributes and the second type of service attributes; the first type of service attributes are service attributes commonly supported by all types of registration centers, and the second type of service attributes are service attributes individually supported by the target registration center; returning the target service registration information as a response to the first query request.

[0138] The processor 701 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0139] The electronic device of the embodiment of the present application exists in various forms, including but not limited to:

[0140] (1) Mobile communication devices: These devices are characterized by their mobile communication functions and their main purpose is to provide voice and data communications. These terminals include: smart phones (e.g., iPhone), multimedia phones, functional phones, and low-end phones.

[0141] (2) Ultra-mobile personal computer devices: These devices fall into the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access features. These terminals include: PDA, MID and UMPC devices, such as iPad.

[0142] (3) Portable entertainment devices: These devices can display and play multimedia content. They include audio and video players (such as iPods), handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0143] (4) Server: A device that provides computing services. The server consists of a processor, hard disk, memory, system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0144] (5) Other electronic devices with data interaction functions.

[0145] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0146] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as a computer code originally stored in a remote recording medium or a non-temporary machine storage medium downloaded through a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the unified governance method for various types of registry centers of a cloud native platform described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown herein.

[0147] Those of ordinary skill in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and constraints involved in the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present application.

[0148] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0149] The device and system embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components described as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative work.

[0150] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A unified governance method for multiple types of registration centers on a cloud native platform, characterized in that: include: In response to receiving a first query request directed to a target microservice, calling a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice; The target registration center is any one of multiple types of registration centers; The target microservice is any microservice in the target registration center; the first query request is a request sent by an administrator to the target microservice by the centralized microservice governance center; the centralized microservice governance center obtains service registration information in different types of registration centers through access endpoints; the access endpoint implements a unified interface definition on the periphery of various types of registration centers according to the characteristics of each registration center; Convert the service registration information of the target microservice into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by aggregating first-class service attributes and second-class service attributes; the first-class service attributes are service attributes commonly supported by all types of the registration centers, and the second-class service attributes are service attributes individually supported by the target registration center; The target service registration information is returned as a response to the first query request.

2. The unified management method for multiple types of registration centers on a cloud native platform according to claim 1 is characterized in that: The first type of service attributes are determined by the following steps: Collect all service attributes contained in the service registration information stored in all types of registries; Comparing the service attributes contained in the service registration information stored in different types of registration centers; In response to the service registration information stored in all types of the registration centers containing the same service attributes, the fields of the same service attributes are unified, and the values ​​of the same service attributes are converted according to a preset mapping relationship to serve as the first type of service attributes.

3. The unified management method for multiple types of registration centers on a cloud native platform according to claim 2 is characterized in that: While determining the first type of service attributes, the second type of service attributes are determined by the following steps: In response to the service registration information stored in the registration center containing service attributes other than the first category of service attributes, the fields and values ​​of the service attributes other than the first category of service attributes are written into a predefined encapsulation field, and the fields and values ​​of the service attributes other than the first category of service attributes are kept unchanged as the second category of service attributes.

4. The unified management method for multiple types of registration centers on a cloud native platform according to claim 1 is characterized in that: After returning the target service registration information as a response to the first query request, the method further includes: Cache the target service registration information; In response to receiving a second query request directed to the target microservice, calling a native interface provided by the target registration center to obtain the last update time of the target microservice; In response to the last update time of the target microservice matching the update time recorded in the cached target service registration information, the cached target service registration information is returned as a response to the second query request.

5. The unified management method for multiple types of registration centers of cloud native platform according to claim 4 is characterized in that: Also includes: In response to a change in the running state of the target microservice, the target microservice sends a service registration information update request to the target registration center; In response to an update of the service registration information of the target microservice stored in the target registration center, the cached target service registration information is updated based on the updated service registration information.

6. The unified management method for multiple types of registration centers on a cloud native platform according to claim 5 is characterized in that: The updating of the cached target service registration information based on the updated service registration information is specifically as follows: Determining, according to the changed service attribute field in the service registration information, the corresponding service attribute field in the target service registration information; The values ​​of the changed service attributes in the service registration information are converted and used as the values ​​of the corresponding service attributes in the target service registration information.

7. The unified management method for multiple types of registration centers of a cloud native platform according to any one of claims 1 to 6, characterized in that: Before, in response to receiving a first query request directed to a target microservice, calling a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice, the method further includes: In response to receiving an instruction to manage all the registration centers; Acquire native interface information provided by each registration center based on the access address and type of each registration center; The registration center is managed based on the native interface information of the registration center.

8. A unified governance system for multiple types of registration centers on a cloud native platform, characterized in that: include: A calling unit is configured to, in response to receiving a first query request directed to a target microservice, call a native interface provided by a target registration center where the target microservice is located to obtain service registration information of the target microservice; The target registration center is any one of multiple types of registration centers; The target microservice is any microservice in the target registration center; the first query request is a request sent by an administrator to the target microservice by the centralized microservice governance center; the centralized microservice governance center obtains service registration information in different types of registration centers through access endpoints; the access endpoint implements a unified interface definition on the periphery of various types of registration centers according to the characteristics of each registration center; A conversion unit, configured to convert the service registration information of the target microservice into target service registration information; wherein the target service registration information includes a first service attribute set and a second service attribute set; the first service attribute set and the second service attribute set are respectively obtained by aggregating first-class service attributes and second-class service attributes; the first-class service attributes are service attributes commonly supported by all types of the registration centers, and the second-class service attributes are service attributes individually supported by the target registration center; The returning unit is configured to return the target service registration information as a response to the first query request.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for unified governance of multiple types of registration centers of a cloud native platform as described in any one of claims 1-7 is implemented.

10. An electronic device, characterized in that: include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for unified governance of multiple types of registration centers on a cloud native platform as described in any one of claims 1-7 is implemented.

Images