Method, system and device for adapting service grid to traditional microservice registry

Abstract

The present invention relates to a method and system for realizing service grid adaptation to a traditional microservice registration center. The method comprises: in response to receiving a service registration request from a microservice application instance of a service grid sidecar, forwarding the service registration request to a corresponding registration center, and establishing and maintaining a correspondence between a traditional microservice model and a cloud-native microservice model. In response to receiving service discovery data from the registration center, converting the service discovery data of the traditional microservice model provided by the registration center into service discovery data of the cloud-native microservice model based on the correspondence between the traditional microservice model and the cloud-native microservice model, and sending the service discovery data of the cloud-native microservice model to the microservice application instance that initiated the service discovery request. Thus, without modifying the operating logic of the registration center, the microservice application instance under the traditional microservice architecture can perform service registration and service discovery in the cloud-native platform.

Description

Technical Field

[0001] The present invention relates to the field of cloud native technology, and in particular to a system, method, device, processor, and computer-readable storage medium thereof for implementing service grid adaptation to a traditional microservice registration center. Background Art

[0002] Microservice architecture refers to an architectural style that builds a business system by combining multiple microservice application instances. Microservice applications refer to the small services that make up the business system, that is, some collaborative, small and autonomous services. The functions of the services are specifically implemented by microservice application instances.

[0003] Cloud Native is an approach to building and running applications. Cloud means the application resides in the cloud, rather than in traditional data centers; native means the application is designed with the cloud in mind from the outset and is natively built in the cloud. Due to the advantages of cloud native in speed, security, self-healing, fault tolerance, fault isolation, visualization, and elastic scalability, more and more enterprises are transitioning their business systems from traditional microservices architectures to cloud-native microservices architectures.

[0004] Currently, most companies adopt the solution of deploying two registration centers simultaneously to adapt the registration center under the traditional microservice architecture to the cloud-native microservice architecture. In other words, they use the cloud-native registration center while retaining the registration center under the traditional microservice architecture, and use information synchronization mechanisms to keep the service registration information stored in the two registration centers synchronized. However, because the service registration information stored in the cloud-native registration center and the registration center under the traditional microservice architecture are different, the service registration information stored in the cloud-native registration center adds information on various cloud-native attributes, such as network type and service region information, while the registration center under the traditional microservice architecture does not define this cloud-native attribute information. Therefore, synchronizing the service registration information stored in the registration center under the traditional microservice architecture to the cloud-native registration center will damage some cloud-native capabilities.

[0005] Therefore, how to convert the business system of traditional microservice architecture into cloud-native microservice architecture in a low-cost and high-quality manner and realize cloud-native transformation of the business system is a technical problem that needs to be solved urgently. Summary of the Invention

[0006] Based on this, it is necessary to provide a method, system, device, processor and storage medium for implementing service grid adaptation to traditional microservice registration center in response to the above technical problems.

[0007] In a first aspect, a method for adapting a service grid to a traditional microservice registry is provided, the method comprising:

[0008] In response to receiving a service registration request for a microservice application instance from a service mesh sidecar, forwarding the service registration request to a corresponding registration center, collecting access information of the microservice application instance from the service mesh sidecar, and establishing and maintaining a correspondence between a traditional microservice model and a cloud-native microservice model based on the service registration information of the microservice application instance and the access information; wherein the service registration information is included in the service registration request;

[0009] In response to receiving a service discovery request from a service mesh sidecar, forwarding the service discovery request to a registry corresponding to a microservice application instance to be discovered; wherein the service discovery request includes identification information of the microservice application instance to be discovered;

[0010] In response to receiving the service discovery data from the registration center, the service discovery data of the traditional microservice model provided by the registration center is converted into service discovery data of the cloud-native microservice model based on the correspondence between the traditional microservice model and the cloud-native microservice model, and the service discovery data of the cloud-native microservice model is sent to the microservice application instance that initiated the service discovery request; wherein, the service discovery data of the cloud-native microservice model includes access information of the microservice application to be discovered.

[0011] After receiving the service registration request from the microservice application instance of the service mesh sidecar, the method further includes: decoding the service registration request using the corresponding access protocol according to the type of the registration center; parsing the decoded service registration request to obtain the service registration information of the microservice application instance; accordingly, sending the service discovery data of the cloud native microservice model to the microservice application instance that initiated the service discovery request, specifically: encoding the service discovery data of the cloud native microservice model according to the access protocol corresponding to the registration center, and sending the encoded service discovery data to the microservice application instance that initiated the service discovery request.

[0012] The establishing and maintaining the correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information and the access information is specifically: establishing and maintaining a service model mapping warehouse based on the service registration information of the microservice application instance and the access information of the microservice application instance; wherein the service model mapping warehouse records the correspondence between the traditional microservice model and the cloud-native microservice model in the form of a mapping table; accordingly, the converting the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model based on the correspondence between the traditional microservice model and the cloud-native microservice model is specifically: converting the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model based on the mapping table in the service model mapping warehouse.

[0013] The converting of the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model according to the mapping table in the service model mapping warehouse includes: repackaging the service discovery data of the traditional microservice model according to the mapping table in the service model mapping warehouse to convert it into the service discovery data of the cloud-native microservice model; wherein the repackaging content includes the service address, service area information and service network definition.

[0014] The method also includes: writing service registration information of the microservice application instance into a cloud native API-Server; obtaining service information of the microservice application instance from the cloud native API-Server; wherein the service information of the microservice application instance includes tag information of the microservice application instance.

[0015] In a second aspect, a system for adapting a service grid to a traditional microservice registry is provided, the system comprising:

[0016] The service mesh control center is used to manage the governance policy of the service mesh based on the actual needs of the service mesh;

[0017] The service mesh sidecar is used to intercept service registration requests or service discovery requests from microservice application instances, forward them to the registry adapter, and perform the governance of the service mesh.

[0018] The registration center adapter is used to receive and parse service registration requests or service discovery requests of microservice application instances;

[0019] When receiving the service registration request, the registration center adapter is further configured to collect access information of the microservice application instance from the service mesh sidecar, establish and maintain a correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information of the microservice application instance and the access information; and forward the service registration request to the corresponding registration center; wherein the service registration request includes the service registration information;

[0020] The registration center adapter is also used to forward the service discovery request to the corresponding registration center when receiving the service discovery request; and convert the service discovery data of the traditional microservice model provided by the registration center into service discovery data of the cloud native microservice model according to the correspondence between the various service models, and send the service discovery data of the cloud native microservice model to the microservice application that initiates the service discovery request.

[0021] Preferably, the registration center adapter includes:

[0022] a protocol decoding module, configured to decode the service registration request or the service discovery request using a corresponding access protocol according to the type of the registration center; and send the decoded service registration request to the service registration control module, and / or send the decoded service discovery request to the corresponding registration center;

[0023] A service registration control module, connected to the protocol decoding module, is configured to parse the decoded service registration request and forward the service registration request to the corresponding registration center; parse the service registration information from the service registration request; collect the access information from the service mesh sidecar, and establish and maintain a service model mapping repository based on the service registration information and the access information; wherein the service model mapping repository records the correspondence between the traditional microservice model and the cloud-native microservice model in the form of a mapping table;

[0024] A service model mapping warehouse is connected to the service registration control module, and is used to receive the service registration information and the access information sent by the service registration control module, and record the mutual correspondence between the traditional microservice model and the cloud native microservice model in the form of a mapping table for use by the service discovery adapter module;

[0025] a service discovery adapter module, connected to the service model mapping warehouse, for converting the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model according to the mapping table in the service model mapping warehouse, and sending the service discovery data of the cloud-native microservice model to the protocol encoding module for encoding processing; and

[0026] The protocol encoding module is connected to the service discovery adapter module and is used to encode the service discovery data of the cloud native microservice model according to the access protocol corresponding to the registration center, and send the encoded service discovery data to the microservice application instance that initiates the service discovery request.

[0027] Preferably, the system also supports hybrid deployment of cloud-native architecture and traditional architecture, specifically:

[0028] In the traditional architecture, a microservice application instance initiates a service registration request and accesses the registration center through the gateway. The registration center then registers the microservice application instance based on the service registration request.

[0029] The microservice application instance in the cloud-native architecture initiates a service registration request, which is adapted by the registration center adapter to establish a correspondence between the traditional microservice model and the cloud-native microservice model. The registration center then registers the microservice application instance based on the service registration request.

[0030] In a third aspect, a processor for implementing the processing of adapting a service grid to a traditional microservice registry center is provided. The processor is configured to execute computer-executable instructions. When the computer-executable instructions are executed by the processor, they are used to implement the various steps of the above-mentioned method for implementing the processing of adapting a service grid to a traditional microservice registry center.

[0031] In a fourth aspect, the computer-readable storage medium stores a computer program thereon, which can be executed by a processor to implement the various steps of the above-mentioned method for adapting a service grid to a traditional microservice registration center.

[0032] The above-mentioned system, method, device, processor and computer-readable storage medium for implementing the adaptation of the service grid to the traditional microservice registration center forwards the service registration request issued by the microservice application instance to be registered to the registration center under the traditional microservice architecture during service registration, and establishes and maintains the correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information of the microservice application instance obtained from the service registration request and the access information of the microservice application instance collected from the service grid sidecar. During service discovery, the service discovery request issued by the microservice application instance that initiates the service discovery request is forwarded to the registration center under the traditional microservice architecture, and based on the correspondence between the traditional microservice model and the cloud-native microservice model established during the service registration of the microservice application instance to be discovered, the service discovery data of the traditional microservice model provided by the registration center under the traditional microservice architecture is converted into service discovery data of the cloud-native microservice model, and the service discovery data of the cloud-native microservice model is sent to the microservice application instance that initiates the service discovery request. As a result, the business system under the traditional microservice architecture can be migrated to the cloud-native platform without modifying the operating logic of the registration center under the traditional microservice architecture, that is, without modifying the source code of the registration center, and traditional microservice application instances can perform service registration and service discovery on the cloud-native platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of using existing technologies to implement a registration center to migrate a business system with a traditional microservice architecture to the cloud.

[0034] Figure 2 This is a schematic diagram of using two registration centers to implement the cloud migration of a business system with a traditional microservice architecture using existing technologies.

[0035] Figure 3 A diagram comparing traditional microservice architecture and cloud-native microservice architecture.

[0036] Figure 4 This is a flowchart of a method for implementing service grid adaptation to a traditional microservice registry center, as proposed in an embodiment of the present invention.

[0037] Figure 5 This is a schematic diagram of the structure of a system for adapting a service grid to a traditional microservice registry center, as proposed in an embodiment of the present invention.

[0038] Figure 6 A logical diagram of the service mesh control center managing the service mesh sidecars.

[0039] Figure 7 A structural diagram of an example of a registration center adapter.

[0040] Figure 8 A diagram showing the structure of an example service mesh sidecar corresponding to a microservice application instance.

[0041] Figure 9 This is a logical diagram of how the cloud native API server and the registry adapter synchronize information.

[0042] Figure 10 This is a diagram of a multi-registry hybrid deployment architecture.

[0043] Figure 11 This diagram shows the effect of direct communication between traditional microservice application instances and cloud-native microservice application instances through cloud-native basic network facilities.

[0044] Figure 12 This is a diagram of the internal structure of the device that implements the service grid adaptation of the traditional microservice registration center in the present invention. DETAILED DESCRIPTION

[0045] In order to more clearly describe the technical content of the present invention, further description is given below in conjunction with specific embodiments.

[0046] Before describing in detail embodiments according to the present invention, it should be noted that, hereinafter, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, whereby a process, method, article, or apparatus comprising a list of elements includes not only those elements, but also other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0047] The registry is the core of the microservices architecture's business system, storing service registration information for microservice application instances. This service registration information includes the access addresses of microservice application instances. Microservice application instances can access the registry to obtain the access addresses of the microservice application instances they want to access within the business system and then use the obtained access addresses to access the desired microservice application instances. Therefore, the registry is a core component of the microservices architecture. When converting existing business systems based on traditional microservices architectures to a cloud-native microservices architecture, adapting the registry to the cloud-native architecture is a crucial step.

[0048] In other words, the service registration information recorded in the registry acts as a "phone book" for microservice application instances, recording the mapping between microservice application instances and access addresses. Upon startup, a microservice application instance sends its service registration information, including its access address, to the registry in the form of a service registration request. The registry stores this service registration information. A microservice application instance initiating a service discovery request can query the registry for the access address of the microservice reference instance it wishes to access and then use the retrieved access address to access the desired microservice application instance.

[0049] In existing technologies, when migrating from traditional microservices architecture to cloud-native microservices architecture, existing registry migration solutions are mainly divided into the following two categories:

[0050] The first option, such as Figure 1 As shown, a registration center is used: the registration center in the traditional microservice architecture is modified to adapt to the cloud-native microservice model, and the traditional microservice application instances are ported to the cloud-native platform without the traditional microservice application instances being aware of it. Specifically, by leveraging the sidecar's request interception capability, the workload and namespace information of the microservice application instance are added to the request header of the service registration request sent by the traditional microservice application instance. This is used to annotate the attributes of the microservice application instance in the cloud-native platform (such as a Kubernetes cluster. The Kubernetes system is open source container orchestration software used to manage container groups across multiple hosts in a cloud-native platform). Based on these attributes, other attribute information of the microservice application instance in the cloud-native platform is obtained. At the same time, the registration center in the traditional microservice architecture is modified to support both cloud-native microservice application instances and traditional microservice application instances.

[0051] Since the core of the cloud-native microservices architecture is to offload infrastructure to the cloud-native platform, and the registration and discovery of microservice application instances falls within that infrastructure, the aforementioned solution requires a comprehensive overhaul of the existing traditional microservices architecture and the migration of a significant amount of data. Otherwise, the traditional microservice application instances migrated to the cloud-native platform will not function properly. This solution is equivalent to tearing down existing infrastructure and building a new one. Therefore, it requires modifying the source code of the registry centers for different types of traditional microservices architectures and maintaining different versions of the registry centers, resulting in high operational pressure and costs.

[0052] The second option, such as Figure 2As shown, two registries are used: a cloud-native registry is used while the traditional microservices architecture registry is retained. Information synchronization is used to synchronize the service registration information stored in the two registries. Typical synchronization mechanisms include: exposing traditional microservices application instances to the cloud-native registry using external microservices application instances, with the cloud-native registry identifying the traditional microservices application instances; or managing traditional microservices application instances migrated to the cloud-native platform using internal microservices application instances, with the cloud-native registry synchronizing the service registration information of the traditional microservices application instances with the registry in the traditional microservices architecture migrated to the cloud-native platform. However, since the service registration information stored in the cloud-native registry and the registry in the traditional microservices architecture differ, the service registration information stored in the cloud-native registry includes various cloud-native attributes, such as network type and service region, which are not defined in the registry in the traditional microservices architecture. Therefore, synchronizing the service registration information stored in the registry in the traditional microservices architecture with the cloud-native registry will compromise some cloud-native capabilities, such as service runtime information, governance, and orchestration.

[0053] In addition, if Figure 3 As shown in the figure, in a traditional microservices architecture, communication between microservice application instances uses the actual IP address of the microservice application instance as the access address. However, communication between cloud-native microservice application instances uses the virtual IP address of the cloud-native microservice application as the access address for the multiple microservice application instances corresponding to the microservice application. This is because cloud-native microservice application instances automatically and rapidly change service deployments based on actual operating conditions, and their actual IP addresses frequently change, while the virtual IP addresses of cloud-native microservice applications remain unchanged. Therefore, cloud-native microservice application instances access each other through virtual IP addresses, preventing microservice application instances from losing connection due to changes in their actual IP addresses.

[0054] Accordingly, the registration center under the traditional microservice architecture only stores the actual IP address of the traditional microservice application instance, and after migrating the traditional microservice application instance to the cloud native platform, it still uses the actual IP address for direct communication. Once the deployment of the traditional microservice application changes, the service registration information will become invalid and the microservice application instance will lose connection.

[0055] Based on this, the technical solution of the present invention provides a method and system for non-invasively implementing service grid adaptation to traditional microservice registration centers. With the help of the service grid sidecar's interception function of requests, there is no need to change the microservice application instances and registration centers under the traditional microservice architecture. The microservice application instances and registration centers under the traditional architecture can be directly migrated to the cloud native platform for operation, and the traditional microservice application instances can perform service registration and service discovery in the cloud native platform.

[0056] An embodiment of the present invention provides a method for implementing service grid adaptation to a traditional microservice registration center. After migrating the microservice application instances and the registration center under the traditional microservice architecture to the cloud native platform, the microservice application instances only need to send service registration requests or service discovery requests to the registration center according to the operating logic under the traditional microservice architecture, and the registration center only needs to process the received service registration requests or service discovery requests according to the operating logic under the traditional microservice architecture, register the microservice application instance that issued the service registration request, and return the service discovery data of the traditional microservice model to the microservice application instance that issued the service discovery request. In other words, there is no need to modify the source code of the microservice application instances and the registration center under the traditional microservice architecture. After migrating the microservice application instances and the registration center to the cloud native platform, the microservice application instances and the registration center can operate normally according to the operating logic under the traditional microservice architecture.

[0057] When a microservice application instance initiates a service registration request, the service registration request is forwarded to the registry adapter via the service mesh sidecar. After receiving the service registration request, the registry adapter not only forwards the service registration request to the corresponding registry, but also collects the access information of the microservice application instance from the service mesh sidecar. Based on the service registration information and access information included in the service registration request, it establishes and maintains the correspondence between the traditional microservice model and the cloud-native microservice model. When a microservice application instance initiates a service discovery request, the service discovery request is forwarded to the registry adapter via the service mesh sidecar. The registry adapter forwards the service discovery request to the corresponding registry and, based on the correspondence between the traditional microservice model and the cloud-native microservice model, converts the service discovery data of the traditional microservice model provided by the registry into the service discovery data of the cloud-native microservice model. It then sends the service discovery data of the cloud-native microservice model to the microservice application instance that initiated the service discovery request.

[0058] In one embodiment, a method for implementing service grid adaptation to a traditional microservice registry is provided. The execution subject of the method is illustrated by taking a registry adapter as an example, that is, the method can be implemented by a program running on the registry adapter; wherein the registry adapter can be a component of an application system, and the component of the application system can also include: an application, which can run on the registry adapter.

[0059] Specifically, such as Figure 4 As shown, the method includes the following steps:

[0060] Step S100, in response to receiving a service registration request for a microservice application instance from a service mesh sidecar, forward the service registration request to the corresponding registration center, collect access information of the microservice application instance from the service mesh sidecar, and establish and maintain the correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information and access information of the microservice application instance.

[0061] The service registration request includes service registration information.

[0062] It's important to note that in cloud-native platforms, such as Kubernetes clusters, microservice application instances run in containers. Cloud-native platforms schedule and manage microservice application instances using pods as the smallest unit. Each pod contains one or more containers. Multiple containers within a pod share network and storage resources, including the same IP address.

[0063] A service mesh is a specialized infrastructure for service communication, enabling reliable request transmission across a complex topology of microservice application instances within a cloud-native platform. Simply put, the control plane component of a service mesh adds a service mesh sidecar (a container) to each container group containing a microservice application instance. The service mesh proxy component within the sidecar intercepts and processes requests entering and exiting the container group.

[0064] Specifically, after deployment, all microservice application instances in the cloud-native platform must register with the corresponding registry. This stores the service registration information for each microservice application instance. Other microservice application instances can then access the registration information by accessing the registry and using the access address in the service registration information to access the microservice application instance. Therefore, microservice application instances must send service registration information to the corresponding registry in the form of service registration requests.

[0065] It should be understood that when migrating a business system under a traditional microservice architecture to a cloud-native platform, multiple business systems under a traditional microservice architecture may be migrated to the same cloud-native platform. Accordingly, a cloud-native microservice registration center and multiple registration centers under a traditional microservice architecture will appear in the cloud-native platform. Moreover, the registration centers under multiple traditional microservice architectures may be of different types, so the microservice application instance needs to send a service registration request to the corresponding registration center.

[0066] Based on the preceding explanation, in a traditional microservices architecture, microservice application instances access each other via their actual IP addresses. Therefore, the access address in the service registration request sent by a traditional microservices application instance to the registry is the actual IP address of the microservice application instance. The access address of the microservice application instance in the service registration information stored in the registry under the traditional microservices architecture is also the actual IP address of the microservice application instance. After migrating traditional microservices application instances and the registry under the traditional microservices architecture to a cloud-native platform, there is no need to modify the source code of the traditional microservices application instances and the registry under the traditional microservices architecture. Therefore, the microservice application instance still encapsulates the actual IP address as the access address in the service registration request and sends it to the corresponding registry.

[0067] It should be noted that in the cloud native platform, microservice application instances are deployed in container groups. Therefore, the actual IP address of the microservice application instance is the IP address of the container group where the microservice application instance is located. Correspondingly, the access address of the microservice application instance included in the service registration request is the IP address of the container group where the microservice application instance is located.

[0068] A service mesh deployed on a cloud-native platform can add a service mesh sidecar to the container group containing a microservice application instance. Accordingly, the service mesh sidecar intercepts all requests from the microservice application instance. In other words, service registration requests from a microservice application instance to the registry must pass through the service mesh sidecar. A service registration request includes the service name of the microservice application instance, the IP address of the container group, and the microservice application instance's URL. For example, for inventory service: 192.168.169:9000 or points service: 192.168.183:9000. After intercepting all requests from the microservice application instance, the service mesh sidecar identifies the service registration request from the microservice application instance and sends it to the registry adapter. For example, it can identify the request based on the recipient. If the request is directed to the registry, it can be determined to be a service registration request.

[0069] After the registration center adapter receives the service registration request from the microservice application instance of the service mesh sidecar, on the one hand, since the source code of the registration center under the traditional microservice architecture has not been modified after being migrated to the cloud native platform, it can directly respond to the service registration request issued by the microservice application instance and store the service registration information of the microservice application instance. Therefore, the registration center adapter can directly forward the service registration request to the registration center without processing the service registration request, allowing the registration center to respond to the service registration request according to the operating logic under the traditional microservice architecture.

[0070] On the other hand, since microservice application instances encapsulate the IP address of their container group as the access address in service registration requests, the access address of the microservice application instance stored in the registration center is also the IP address of the container group. However, during the orchestration and scheduling process of the cloud-native platform, the container group is recreated and rescheduled. Accordingly, the IP address of the recreated or rescheduled container group will also change. Furthermore, the cloud-native platform can dynamically adjust the number of microservice application instances corresponding to each microservice application based on the load of the microservice application instance. Therefore, static recording of the IP addresses of microservice application instances is not appropriate. Instead, a dynamic service discovery mechanism should be adopted to enable mutual awareness between microservice application instances.

[0071] Based on this, in addition to ensuring that the registration center statically records the access address, the registration center adapter in the embodiment of the present invention also needs to introduce a dynamic service registration information update mechanism to adapt to the needs of the cloud native platform. Based on the above description, it can be seen that compared with the registration center under the traditional microservice architecture, the service registration information stored in the cloud native registration center adds a variety of cloud native attribute information, such as network type, service region information, etc., and the service grid, as a dedicated infrastructure for handling communications in the cloud native platform, can obtain access information for each microservice application instance in the cloud native platform, including the virtual IP address of the microservice application corresponding to the microservice application instance, as well as information on various other cloud native attributes. The service grid sends the network information related to each microservice application instance to the service grid sidecar of the container group to enable reliable request transmission between microservice application instances.

[0072] Therefore, after receiving the service registration request of the microservice application instance from the service mesh sidecar, the registration center adapter in the embodiment of the present invention can also collect the access information of the microservice application instance from the service mesh sidecar, thereby supplementing the access information with cloud-native attributes that is missing in the service registration information under the traditional microservice architecture.

[0073] Furthermore, the service registration information storage format of the registration center under the traditional microservice architecture is defined as the traditional microservice model, and the service registration information storage format of the cloud-native registration center is defined as the cloud-native microservice model. The information items corresponding to the two models include the IP address of the container group where the microservice application instance is located, but the information items corresponding to the cloud-native microservice model also include access information of cloud-native attributes. Therefore, the corresponding service registration information in the traditional microservice model and the access information with cloud-native attributes collected from the service mesh sidecar are aggregated to obtain the service registration information corresponding to the cloud-native microservice model.

[0074] Based on this, the registration center adapter can establish and maintain the correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information and access information included in the service registration request of the microservice application instance.

[0075] Furthermore, as can be seen from the preceding description, a microservice application instance encapsulates service registration information into a service registration request and sends it to the corresponding registry. Therefore, the registry adapter needs to parse the service registration request to obtain the service registration information from it. Furthermore, because different types of registries adapt to different access protocols, the microservice application instance must encode the service registration request using the encoding method corresponding to the registry. Accordingly, before parsing the service registration request, the registry adapter must first decode the service registration request using the decoding method corresponding to the registry.

[0076] That is, after the registration center adapter receives the service registration request of the microservice application instance from the service mesh sidecar, the method further includes: decoding the service registration request using the corresponding access protocol according to the type of the registration center, and parsing the decoded service registration request to obtain the service registration information of the microservice application instance.

[0077] Furthermore, in some embodiments of the invention, the correspondence between traditional microservice models and cloud-native microservice models is specifically established by a service model mapping repository in a registry center adapter. In other words, the aforementioned establishment and maintenance of the correspondence between traditional microservice models and cloud-native microservice models based on service registration requests and access information specifically involves establishing and maintaining a service model mapping repository based on the service registration information and access information of microservice application instances. The service model mapping repository records the correspondence between traditional microservice models and cloud-native microservice models in the form of a mapping table.

[0078] It can be understood that in order to establish and maintain the correspondence between the traditional microservice model and the cloud-native microservice model, the embodiment of the present invention separately sets up a service model mapping warehouse module in the registration center adapter. The service model mapping warehouse can establish independent mapping tables for different registration centers. Each mapping table is used to record the correspondence between the service registration information of the traditional microservice model corresponding to the registration center under a traditional microservice architecture and the service registration information of the cloud-native microservice model.

[0079] Step S200: In response to receiving a service discovery request from a service mesh sidecar, forward the service discovery request to a registration center corresponding to the microservice application instance to be discovered.

[0080] The service discovery request includes identification information of the microservice application instance to be discovered.

[0081] Based on the preceding description, it can be seen that when a microservice application instance wants to access another microservice application instance, it needs to access the registration center corresponding to the microservice application instance to obtain the access address of the microservice application instance to be accessed. It then uses the obtained access address to issue an access request to the microservice application instance to be accessed. This process is also called service discovery. Therefore, in embodiments of the present invention, the request sent by the microservice application instance to the registration center is called a service discovery request, and the microservice application instance to be accessed is called the microservice application instance to be discovered.

[0082] Similar to the aforementioned processing process of service registration requests, the microservice application instance initiates a service discovery request to the registration center corresponding to the microservice application instance to be discovered. The service discovery request passes through the service mesh sidecar. The service mesh sidecar recognizes that the request points to a certain registration center and determines that the request is a service discovery request. It sends the service discovery request to the registration center adapter.

[0083] It can be understood that in the scenario where the cloud native platform includes multiple registration centers under the microservice architecture, the service registration information of the microservice application instance to be discovered is stored in the corresponding registration center, so the service discovery request should point to the registration center corresponding to the microservice application instance to be discovered.

[0084] The registry adapter receives a service discovery request from a microservice application instance of the service mesh sidecar. It does not need to process the service discovery request and directly forwards it to the corresponding registry. The registry responds to the service discovery request according to the operating logic under the traditional microservice architecture and returns the service discovery data of the traditional microservice model to the registry adapter, that is, the service registration information of the microservice application instance to be discovered.

[0085] It can be understood that the service discovery request includes the identification information of the microservice application instance to be discovered, and the registration center can quickly locate the service registration information of the microservice application instance based on the identification information.

[0086] Step S300, in response to receiving the service discovery data from the registration center, convert the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model based on the correspondence between the traditional microservice model and the cloud-native microservice model, and send the service discovery data of the cloud-native microservice model to the microservice application instance that initiated the service discovery request.

[0087] Among them, the service discovery data of the cloud-native microservice model includes access information of the microservice application instance to be discovered.

[0088] Specifically, the registry responds to service discovery requests according to the operating logic of the traditional microservices architecture, returning the service discovery data of the traditional microservices model to the registry adapter. To enable the microservice application instance that initiated the service discovery request to obtain the service discovery data of the cloud-native microservices model, the registry adapter converts the service discovery data of the traditional microservices model provided by the registry into the service discovery data of the cloud-native microservices model based on the correspondence between the traditional microservices model and the cloud-native microservices model. The adapter then sends the converted service discovery data of the cloud-native microservices model to the microservice application instance that initiated the service discovery request.

[0089] The microservice application instance initiating the service discovery request can obtain the virtual IP address of the microservice application corresponding to the microservice application instance to be discovered, as well as various other cloud-native attribute information, from the service discovery data of the cloud-native microservice model. Therefore, the microservice application instance initiating the service discovery request can access the microservice application instance to be discovered by accessing the virtual IP address. Furthermore, using the obtained cloud-native attribute information, the microservice application instances can communicate with each other based on the cloud-native network infrastructure.

[0090] Specifically, similar to the aforementioned processing of service registration requests, the microservice application instance that initiates the service discovery request will also encode the service discovery request according to the access protocol corresponding to the registration center. Therefore, in order to send the service discovery data of the cloud-native microservice model to the microservice application instance that initiates the service discovery request, it is also necessary to encode the service discovery data of the cloud-native microservice model according to the access protocol corresponding to the registration center. In other words, the aforementioned sending of the service discovery data of the cloud-native microservice model to the microservice application instance that initiates the service discovery request specifically involves: encoding the service discovery data of the cloud-native microservice model according to the access protocol corresponding to the registration center, and sending the encoded service discovery data to the microservice application instance that initiates the service discovery request.

[0091] In addition, the embodiment of the present invention separately sets up a module called service model mapping warehouse in the registration center adapter. The service model mapping warehouse records the correspondence between the traditional microservice model and the cloud native microservice model in the form of a mapping table, which corresponds to the aforementioned processing process of the service registration request. After receiving the service discovery data from the registration center, the registration center adapter converts the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud native microservice model according to the mapping table in the service model mapping warehouse. That is to say, the aforementioned conversion of the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud native microservice model according to the correspondence between the traditional microservice model and the cloud native microservice model is specifically: the service discovery data of the traditional microservice model provided by the registration center is converted into the service discovery data of the cloud native microservice model according to the mapping table in the service model mapping warehouse.

[0092] Furthermore, when converting the service discovery data of the traditional microservice model into the service discovery data of the cloud-native microservice model, the registry adapter needs to repackage the service discovery data of the traditional microservice model, repackaging the virtual IP address of the microservice application recorded in the mapping table in the service model mapping repository, and other information on various cloud-native attributes together with the service discovery data of the traditional microservice model to obtain the service discovery data of the cloud-native microservice model. In other words, the aforementioned conversion of the service discovery data of the traditional microservice model provided by the registry center into the service discovery data of the cloud-native microservice model based on the mapping table in the service model mapping repository includes: repackaging the service discovery data of the traditional microservice model according to the mapping table in the service model mapping repository to convert it into the service discovery data of the cloud-native microservice model. The repackaged content includes the service address, service region information, and service network definition. The service address refers to the virtual IP address of the microservice application, the service region information refers to the region where the microservice application instance is located, and the service network definition refers to the configuration of the network used by microservice applications to communicate with each other.

[0093] As a preferred embodiment of the present invention, the method of implementing the service grid adaptation of the traditional microservice registration center of the present invention runs in a scenario where the cloud native architecture and the traditional architecture are hybrid deployed. The so-called hybrid deployment scenario refers to a business system under a traditional microservice architecture, in which the registration center and a part of the traditional microservice application instances are migrated to the cloud native platform, while the remaining traditional microservice application instances are not migrated. At this time, the traditional microservice application instances that have been migrated to the cloud native platform can use the aforementioned method to complete service registration and service discovery, while the traditional microservice application instances that have not been migrated need to complete service registration and service discovery by accessing the registration center under the traditional microservice architecture that has been migrated to the cloud native platform. Specifically, for traditional microservice application instances that have not been migrated to the cloud native platform, it is impossible to directly access the registration center under the traditional microservice architecture that has been migrated to the cloud native platform. It is necessary to first send a service registration request or a service discovery request to the gateway of the cloud native platform, and then the gateway of the cloud native platform forwards the request and routes the request to the registration center. For traditional microservice application instances that have been migrated to the cloud native platform, a service registration request or a service discovery request can be directly sent to the registration center under the traditional microservice architecture that has been migrated to the cloud native platform.

[0094] In other words, a microservice application instance in a traditional architecture initiates a service registration request, accesses the registry through a gateway, and the registry registers the microservice application instance based on the service registration request. A microservice application instance in a cloud-native architecture initiates a service registration request, which is then adapted by a registry adapter to establish a mapping between the traditional microservice model and the cloud-native microservice model. The registry then registers the microservice application instance based on the service registration request. Microservice application instances in a cloud-native architecture refer to traditional microservice application instances that have been migrated to the cloud-native platform.

[0095] As a preferred embodiment of the present invention, the method of the present invention for implementing service grid adaptation to a traditional microservice registration center also includes: writing the service registration information of the microservice application instance into a cloud native API-Server; obtaining the service information of the microservice application instance from the cloud native API-Server; wherein the service information of the microservice application instance includes the tag information of the microservice application instance.

[0096] As can be seen from the preceding description, compared to registries in traditional microservice architectures, cloud-native registries store not only service registration information but also various cloud-native attributes, including access information for microservice application instances. Furthermore, this cloud-native attribute information specifically includes service information for microservice application instances.

[0097] It should be noted that the cloud-native platform uses a service mechanism to manage microservice application instances. This mechanism aggregates multiple microservice application instances that provide the same service and provides a unified entry point. In other words, the service mechanism can centrally manage multiple microservice application instances that are aggregated into the same service.

[0098] Specifically, the service information in the cloud native platform corresponds to the service. By marking a certain service information for a microservice application instance, the microservice application instance can be associated with the service corresponding to the service information, thereby achieving the aggregation of all microservice application instances marked with the service information.

[0099] It should be understood that the service information in the cloud native platform can correspond to a single service or to multiple services. If the service information of the cloud native platform corresponds to a single service, then the identification information of the service (such as the name and number of the service, etc.) is directly used as the service information, that is, the identification information of the service is used to mark multiple microservice application instances, so that the aggregation of multiple microservice application instances corresponding to the same service can be achieved. If the service information of the cloud native platform corresponds to multiple services, independent label information is needed as the service information, that is, the label information is used to mark multiple microservice application instances, so that the aggregation of all microservice application instances corresponding to multiple services can be achieved. It can be understood that in the case where the service information corresponds to multiple services, all microservice application instances corresponding to multiple services can be uniformly managed with the help of unified service information.

[0100] In addition, in some special scenarios, in order to achieve flexible management of microservice application instances in the cloud native platform, the same label information can be marked for any multiple microservice application instances in the cloud native platform, so that all microservice application instances marked with the same label information can be managed uniformly.

[0101] In an embodiment of the present invention, in order to enable the registration center under the traditional microservice architecture migrated to the cloud-native platform to maintain information consistency with the cloud-native registration center, the registration center adapter continuously synchronizes newly written service registration information to the cloud-native API-Server, and continuously obtains corresponding service information through the cloud-native API-Server to improve the cloud-native microservice model stored in the service model mapping warehouse.

[0102] In order to implement the aforementioned method of adapting a service grid to a traditional microservice registry center, an embodiment of the present invention further proposes a system for adapting a service grid to a traditional microservice registry center.

[0103] like Figure 5 As shown, the system for implementing service grid adaptation to traditional microservice registration center includes:

[0104] The service mesh control center is used to manage the governance policy of the service mesh based on the actual needs of the service mesh;

[0105] The service mesh sidecar intercepts service registration requests or service discovery requests from microservice applications, forwards them to the registry adapter, and implements the governance capabilities of the service mesh.

[0106] A registry adapter is used to receive and parse service registration requests or service discovery requests from microservice applications. When receiving a service registration request, the registry adapter also collects access information about the microservice application from the service mesh sidecar, establishes and maintains the correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information and access information of the microservice application instance, and forwards the service registration request to the corresponding registry. The service registration request includes the service registration information.

[0107] When receiving a service discovery request, the registry adapter is also used to forward the service discovery request to the corresponding registry; and according to the correspondence between each service model, it converts the service discovery data of the traditional microservice model provided by the registry into the service discovery data of the cloud-native microservice model, and sends the service discovery data of the cloud-native microservice model to the microservice application that initiates the service discovery request.

[0108] Based on the description of the method for implementing service mesh adaptation to traditional microservice registry centers, it can be seen that in order for the registry center adapter to establish and maintain the correspondence between the traditional microservice model and the cloud-native microservice model, it is necessary to receive service registration requests from the service mesh sidecar and collect access information of microservice application instances from the service mesh sidecar.

[0109] like Figure 6 As shown in the figure, the service mesh sidecar, as a component of the service mesh, is managed by the service mesh control center. Therefore, the service mesh control center can issue corresponding configuration information to the service mesh sidecar to implement its governance. Specifically, the service mesh control center can issue interception and identification policies to the service mesh sidecar, identifying requests directed to the registry as service registration requests or service discovery requests, and forwarding the service registration requests or service discovery requests to the registry adapter.

[0110] After the service registration adapter receives the request forwarded by the service mesh sidecar, it further identifies the type of request. If it is identified as a service registration request, it needs to obtain the service registration information from the service registration request and collect access information from the service mesh sidecar, so as to establish and maintain the correspondence between the traditional microservice model and the cloud native microservice model, and forward the service registration request to the registration center. If it is identified as a service discovery request, it directly forwards the service discovery request to the registration center.

[0111] After receiving a service registration request, the registry responds to it according to the operating logic of the traditional microservices architecture, storing the service registration information according to the traditional microservices model. After receiving a service discovery request, the registry also responds to it according to the operating logic of the traditional microservices architecture, returning the service discovery data of the traditional microservices model to the registry adapter. The registry adapter then converts the service discovery data of the traditional microservices model provided by the registry into service discovery data of the cloud-native microservices model based on the mapping between the traditional microservices model and the cloud-native microservices model, and sends the service discovery data of the cloud-native microservices model to the microservice application instance that initiated the service discovery request.

[0112] It should be noted that the current operating modes of service mesh sidecars are mainly divided into three categories: running microservice application instances and service mesh sidecars in a program manner in the same virtual machine, running them in parallel as container groups in a cloud native platform, and running them in edge container mode in a cloud native platform. The service mesh sidecar and microservice application instances in the embodiments of the present invention are run in a parallel model. The parallel mode is a relatively mature mode under the service mesh architecture.

[0113] Furthermore, in order to reduce the difficulty of implementing the technical solution, the embodiment of the present invention can reuse the edge container mode and the plug-in mode to expand the capabilities of the service mesh sidecar, which can be used to expand the mutual access capabilities between microservice application instances, and the ability to send service registration requests and service discovery requests to the registration center.

[0114] like Figure 7 As shown, as a preferred embodiment of the present invention, the registration center adapter includes:

[0115] The protocol decoding module is used to decode the service registration request or service discovery request using the corresponding access protocol according to the type of the registration center; and send the decoded service registration request to the service registration control module, and / or send the decoded service discovery request to the corresponding registration center;

[0116] The service registration control module is connected to the protocol decoding module and is used to parse the decoded service registration request and forward it to the corresponding registration center. It also parses the service registration information from the service registration request, collects access information from the service mesh sidecar, and establishes and maintains the service model mapping warehouse based on the service registration information and access information. The service model mapping warehouse records the correspondence between the traditional microservice model and the cloud native microservice model in the form of a mapping table.

[0117] The service model mapping repository is connected to the service registration control module and is used to receive service registration information and access information from the service registration control module. It also records the correspondence between the traditional microservice model and the cloud-native microservice model in the form of a mapping table for use by the service discovery adapter module.

[0118] A service discovery adapter module, connected to the service model mapping repository, is used to convert the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model according to the mapping table in the service model mapping repository, and send the service discovery data of the cloud-native microservice model to the protocol encoding module for encoding processing; and

[0119] The protocol encoding module is connected to the service discovery adapter module. It is used to encode the service discovery data of the cloud native microservice model according to the access protocol corresponding to the registration center, and send the encoded service discovery data to the microservice application that initiates the service discovery request.

[0120] Based on the previous description of the system that implements service mesh adaptation to the traditional microservice registry, it can be seen that the registry adapter plays an important role in the functional implementation of the entire system.

[0121] It is necessary to receive service registration requests and service discovery requests from the service mesh sidecar, collect access information of microservice application instances from the service mesh sidecar, establish and maintain the correspondence between the traditional microservice model and the cloud-native microservice model, forward service registration requests and service discovery requests to the registration center, convert the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model, and send the service discovery data of the cloud-native microservice model to the microservice application instance that initiated the service discovery request.

[0122] In order to achieve the above functions, the registry adapter in the embodiment of the present invention can be composed of multiple modules, and the protocol decoding module and the protocol encoding module are used to communicate directly with the outside. It should be understood that in production practice, traditional microservice architectures can use different types of registry centers, and different types of registry centers use different access protocols. For example, the access protocol used by Nacos (an open source registry center dedicated to discovering, configuring and managing microservices) is HTTP (Hypertext Transfer Protocol); the access protocol used by Zookeeper (an open source distributed application coordination component that provides consistency services for distributed applications) is TCP (Transmission Control Protocol, a connection-oriented, reliable, byte-stream-based transport layer communication protocol); the access protocol used by Dubbo is Dubbo protocol (a microservice development framework that provides two key capabilities: RPC communication and microservice governance). Accordingly, the service registration request or service discovery request issued by the microservice application instance adapted to the registry will also use the corresponding access protocol. In order to enable the registry adapter in the embodiment of the present invention to adapt to various types of access protocols, the protocol decoding module and protocol encoding module in the registry adapter need to be able to use the corresponding access protocol for decoding and encoding according to the type of registry center. That is, when an external request is received, the corresponding access protocol is used to decode the request, and before sending the data to the outside, the corresponding access protocol is used to encode the data.

[0123] It should be noted that in addition to decoding the request, the protocol decoding module also needs to identify the type of the decoded request, send the decoded service registration request to the service registration control module, and send the decoded service discovery request to the registration center.

[0124] In addition, after receiving the service registration request, the service registration control module parses the service registration request to obtain the service registration information, and establishes and maintains the correspondence between the traditional microservice model and the cloud native microservice model based on the service registration information and the access information collected from the service mesh sidecar, and sends the service registration request to the registration center.

[0125] Preferably, the service model mapping repository can record the correspondence between traditional microservice models and cloud-native microservice models in the form of a mapping table. In other words, the service registration control module only needs to send service registration information and access information to the service model mapping repository, which will then record the correspondence between traditional microservice models and cloud-native microservice models according to pre-set settings.

[0126] After receiving the service discovery request, the registration center returns the service discovery data of the traditional microservice model to the registration center adapter. The service discovery adapter module is used to convert the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model according to the mapping table in the service model mapping warehouse, and send the service discovery data of the cloud-native microservice model to the protocol encoding module for encoding processing. The protocol encoding module then sends the encoded service discovery data to the microservice application that initiated the service discovery request.

[0127] Preferably, the service discovery adaptation module converts the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model. Specifically, the service discovery data of the microservice model is repackaged according to the mapping table in the service model mapping warehouse to convert it into the service discovery data of the cloud-native microservice model; wherein the service discovery data of the cloud-native microservice model includes access information of the microservice application to be discovered.

[0128] Preferably, given that different registries have different definitions of services, the service registration requests adapted by different registries are also different, specifically in terms of data structures and fields. Currently, service registration requests can be divided into API-level service registration requests and service-level service registration requests. When the service registration control module parses the service registration request, it needs to use different parsing methods to obtain service registration information based on the structure of the service registration request.

[0129] like Figure 8 The figure below is a schematic diagram of the structure of an example of a service mesh sidecar corresponding to a microservice application instance proposed in an embodiment of the present invention. In actual application, the service mesh sidecar includes:

[0130] The service registration module is used to forward the identified service registration request to the registration center adapter when the microservice application instance requests registration from the registration center;

[0131] The service discovery module is used to forward the identified service discovery request to the registry adapter when the microservice application instance requests service discovery data from the registry.

[0132] Preferably, the service mesh sidecar also has service mesh governance capabilities for service discovery, protocol parsing, enabling service governance policies, service observability, and service communication security.

[0133] like Figure 9As shown, the system also includes a cloud native API-Server, and the registration center adapter is used to write the service registration information of the microservice application instance to the cloud native API-Server, and obtain the service information of the microservice application instance from the cloud native API-Server; the cloud native API-Server is used to receive the service registration information of the microservice application instance written by the registration center adapter, and synchronize the service information of the microservice application instance to the registration center adapter; wherein, the service information of the microservice application instance includes the label information of the microservice application instance.

[0134] The tag information of a microservice application instance is used to characterize the business type of the microservice application instance, such as points service, inventory service, etc. The tag information of the same microservice application instance can be one, two, or more than two, such as quota, step, mutex, etc.

[0135] In practical applications, such as Figure 10 As shown, as a preferred embodiment of the present invention, the system also supports hybrid deployment of cloud native architecture and traditional architecture, specifically:

[0136] In the traditional architecture, a microservice application instance initiates a service registration request and accesses the registration center through the gateway. The registration center then registers the microservice application instance based on the service registration request.

[0137] The microservice application instance in the cloud-native architecture initiates a service registration request, which is adapted by the registration center adapter to establish a correspondence between the traditional microservice model and the cloud-native microservice model. The registration center then registers the microservice application instance based on the service registration request.

[0138] Among them, the microservice application instances in the traditional architecture have not been migrated to the cloud native platform, that is, they have not been put on the cloud. Therefore, they cannot directly access the registration center under the traditional microservice architecture that has been migrated to the cloud native platform. The service registration request must be sent to the corresponding registration center through the gateway of the cloud native platform. The corresponding registration center responds according to the operating logic in the traditional architecture and stores the service registration information of the microservice application instances in the traditional architecture in the registration center, without the need for a registration center adapter to process it.

[0139] The microservice application instance in the cloud-native architecture refers to the traditional microservice application instance that has been migrated to the cloud-native platform. The service registration can be completed directly using the method proposed in the embodiment of the present invention, which will not be repeated here.

[0140] like Figure 11As shown, after the traditional microservice application instance migrated to the cloud native platform uses the solution provided by the embodiment of the present invention, it can communicate directly through the cloud native basic network facilities like the cloud native microservice application instance, instead of using the IP address of the container group to access each other.

[0141] In one specific embodiment, when microservice application instance A needs to access microservice application instance B, it first obtains the address information of microservice application B through the cloud-native basic network infrastructure. Microservice application B then sends the request to the corresponding microservice application instance B. When cloud-native microservice application instance C needs to access microservice application instance B, the communication process can also be completed through the cloud-native basic network infrastructure.

[0142] In one embodiment, a device for implementing service grid adaptation to a traditional microservice registration center is provided. The device can be a server, and its internal structure diagram can be as follows: Figure 12 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data registered by the service. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a method for adapting a service grid to a traditional microservice registration center is implemented.

[0143] Those skilled in the art will understand that Figure 12 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention and does not constitute a limitation on the computer device to which the solution of the present invention is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0144] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0145] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0146] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention pertain.

[0147] It should be understood that each part of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution device.

[0148] Those skilled in the art will understand that all or part of the steps of the method for implementing the above-mentioned embodiment can be completed by instructing the relevant hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0149] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0150] Throughout this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "embodiment" indicate that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0151] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.

[0152] The system, method, device, processor and computer-readable storage medium thereof for implementing the service grid adaptation of the traditional microservice registration center of the present invention are adopted. During service registration, the service registration request issued by the microservice application instance to be registered is forwarded to the registration center under the traditional microservice architecture, and based on the service registration information of the microservice application instance obtained from the service registration request and the access information of the microservice application instance collected from the service grid sidecar, the corresponding relationship between the traditional microservice model and the cloud-native microservice model is established and maintained. During service discovery, the service discovery request issued by the microservice application instance that initiates the service discovery request is forwarded to the registration center under the traditional microservice architecture, and based on the corresponding relationship between the traditional microservice model and the cloud-native microservice model established during the service registration of the microservice application instance to be discovered, the service discovery data of the traditional microservice model provided by the registration center under the traditional microservice architecture is converted into the service discovery data of the cloud-native microservice model, and the service discovery data of the cloud-native microservice model is sent to the microservice application instance that initiates the service discovery request. As a result, the business system under the traditional microservice architecture can be migrated to the cloud-native platform without modifying the operating logic of the registration center under the traditional microservice architecture, that is, without modifying the source code of the registration center, and traditional microservice application instances can perform service registration and service discovery on the cloud-native platform.

[0153] In this specification, the present invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations may be made without departing from the spirit and scope of the present invention. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method for adapting a service grid to a traditional microservice registry, characterized in that: The method comprises the following steps: In response to receiving a service registration request for a microservice application instance from a service mesh sidecar, forwarding the service registration request to a corresponding registration center, collecting access information of the microservice application instance from the service mesh sidecar, and establishing and maintaining a correspondence between a traditional microservice model and a cloud-native microservice model based on the service registration information of the microservice application instance and the access information; wherein the service registration information is included in the service registration request; In response to receiving a service discovery request from a service mesh sidecar, forwarding the service discovery request to a registry corresponding to a microservice application instance to be discovered; wherein the service discovery request includes identification information of the microservice application instance to be discovered; In response to receiving the service discovery data from the registration center, the service discovery data of the traditional microservice model provided by the registration center is converted into service discovery data of the cloud-native microservice model based on the correspondence between the traditional microservice model and the cloud-native microservice model, and the service discovery data of the cloud-native microservice model is sent to the microservice application instance that initiated the service discovery request; wherein, the service discovery data of the cloud-native microservice model includes access information of the microservice application instance to be discovered.

2. The method for implementing service grid adaptation to traditional microservice registry according to claim 1, characterized in that: After receiving the service registration request from the microservice application instance of the service mesh sidecar, the method further includes: Decoding the service registration request using a corresponding access protocol according to the type of the registration center; Parsing the decoded service registration request to obtain service registration information of the microservice application instance; Accordingly, the service discovery data of the cloud native microservice model is sent to the microservice application instance that initiates the service discovery request, specifically: The service discovery data of the cloud native microservice model is encoded according to the access protocol corresponding to the registration center, and the encoded service discovery data is sent to the microservice application instance that initiates the service discovery request.

3. The method for implementing service grid adaptation to traditional microservice registry according to claim 1, characterized in that: The establishing and maintaining of the correspondence between the traditional microservice model and the cloud-native microservice model according to the service registration information and the access information is specifically as follows: Establish and maintain a service model mapping warehouse based on the service registration information of the microservice application instance and the access information of the microservice application instance; wherein the service model mapping warehouse records the correspondence between the traditional microservice model and the cloud native microservice model in the form of a mapping table; Accordingly, the service discovery data of the traditional microservice model provided by the registration center is converted into the service discovery data of the cloud-native microservice model based on the correspondence between the traditional microservice model and the cloud-native microservice model, specifically: The service discovery data of the traditional microservice model provided by the registration center is converted into the service discovery data of the cloud native microservice model according to the mapping table in the service model mapping warehouse.

4. The method for implementing service grid adaptation to traditional microservice registry according to claim 3, characterized in that: The converting the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model according to the mapping table in the service model mapping warehouse includes: The service discovery data of the traditional microservice model is repackaged according to the mapping table in the service model mapping warehouse to be converted into the service discovery data of the cloud-native microservice model; wherein the repackaged content includes the service address, service region information and service network definition.

5. The method for implementing service grid adaptation to traditional microservice registry according to claim 1, characterized in that: The method further comprises: Write the service registration information of the microservice application instance into the cloud native API server; Obtain service information of the microservice application instance from the cloud native API-Server; wherein the service information of the microservice application instance includes tag information of the microservice application instance.

6. A system for adapting a service grid to a traditional microservice registry, characterized in that: The system comprises: The service mesh control center is used to manage the governance policy of the service mesh based on the actual needs of the service mesh; The service mesh sidecar is used to intercept service registration requests or service discovery requests from microservice application instances, forward them to the registry adapter, and perform the governance of the service mesh. The registration center adapter is used to receive service registration requests or service discovery requests from microservice application instances; When receiving the service registration request, the registration center adapter is further configured to collect access information of the microservice application instance from the service mesh sidecar, establish and maintain a correspondence between the traditional microservice model and the cloud-native microservice model based on the service registration information of the microservice application instance and the access information; and forward the service registration request to the corresponding registration center; wherein the service registration request includes the service registration information; When receiving the service discovery request, the registration center adapter is also used to forward the service discovery request to the corresponding registration center; and convert the service discovery data of the traditional microservice model provided by the registration center into service discovery data of the cloud-native microservice model according to the correspondence between the various service models, and send the service discovery data of the cloud-native microservice model to the microservice application instance that initiates the service discovery request.

7. The system for implementing service grid adaptation to traditional microservice registry according to claim 6, characterized in that: The registration center adapter includes: a protocol decoding module, configured to decode the service registration request or the service discovery request using a corresponding access protocol according to the type of the registration center; and send the decoded service registration request to the service registration control module, and / or send the decoded service discovery request to the corresponding registration center; A service registration control module, connected to the protocol decoding module, is configured to parse the decoded service registration request and forward the service registration request to the corresponding registration center; parse the service registration information from the service registration request; collect the access information from the service mesh sidecar, and establish and maintain a service model mapping repository based on the service registration information and the access information; wherein the service model mapping repository records the correspondence between the traditional microservice model and the cloud-native microservice model in the form of a mapping table; A service model mapping warehouse is connected to the service registration control module, and is used to receive the service registration information and the access information sent by the service registration control module, and record the mutual correspondence between the traditional microservice model and the cloud native microservice model in the form of a mapping table for use by the service discovery adapter module; a service discovery adapter module, connected to the service model mapping warehouse, for converting the service discovery data of the traditional microservice model provided by the registration center into the service discovery data of the cloud-native microservice model according to the mapping table in the service model mapping warehouse, and sending the service discovery data of the cloud-native microservice model to the protocol encoding module for encoding processing; and The protocol encoding module is connected to the service discovery adapter module and is used to encode the service discovery data of the cloud native microservice model according to the access protocol corresponding to the registration center, and send the encoded service discovery data to the microservice application instance that initiates the service discovery request.

8. The system for implementing service grid adaptation to traditional microservice registry according to claim 6 or 7, characterized in that: The system also supports hybrid deployment of cloud-native and traditional architectures, specifically: In the traditional architecture, a microservice application instance initiates a service registration request and accesses the registration center through the gateway. The registration center then registers the microservice application instance based on the service registration request. The microservice application instance in the cloud-native architecture initiates a service registration request, which is adapted by the registration center adapter to establish a correspondence between the traditional microservice model and the cloud-native microservice model. The registration center then registers the microservice application instance based on the service registration request.

9. A processor for implementing service grid adaptation to traditional microservice registry, characterized in that: The processor is configured to execute computer-executable instructions. When the computer-executable instructions are executed by the processor, they are used to implement the steps of the method for implementing service grid adaptation to a traditional microservice registry center according to any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and the computer program can be executed by a processor to implement the various steps of the method for implementing service grid adaptation to a traditional microservice registration center as described in any one of claims 1 to 5.

Images