Systems and methods for integrating microservice registry with service mesh

Abstract

Methods and systems are provided for integrating a cloud service engine framework with an open source service mesh (e.g., ISTIO) to bridge communication barriers between the two systems. The invention can enable users to adopt an iterative cloud modernization model by incorporating a hybrid microservices architecture. Adopting a multi-cloud architecture can also contribute to cost savings due to the lower resource footprint of proxy functionality.

Description

[0001] Cross-references to related applications

[0002] This is the first application filed for this invention. Technical Field

[0003] This invention relates to the field of cloud computing technology, and more particularly to methods and systems for integrating cloud service engine frameworks and open-source application service meshes to eliminate or reduce communication barriers between the two systems. Background Technology

[0004] In traditional cloud service engine (CSE) systems, services (microservices or microservice instances) are managed through a service registry (SR) stack. The term "microservice" refers to a software service that can be used to build distributed applications using containers. Microservices can have different types of connectivity: public IPv4, private IPv4, globally reachable IPv6, etc.

[0005] An alternative to SR is an application service mesh (SM), such as ISTIO. An SM is a dedicated infrastructure layer that can be added to applications running microservice instances in the cloud and can be used to control communication between microservices. SMs allow application developers to transparently add capabilities such as observability, traffic management, and security without integrating them into the application code.

[0006] A Service Mesh Control Plane (SM) is typically implemented as a scalable set of network proxies (a pattern sometimes called sidecars) deployed along with the application code. These proxies handle communication between microservices. The Service Mesh Control Plane can be deployed within the application platform (such as a Kubernetes platform). If the Service Mesh Control Plane is deployed within the application platform, the application platform's service registry and its discovery mechanism can be reused.

[0007] A service registry can include a database populated with information on how discovery requests are dispatched and how governance policies are distributed to microservice instances. The database can be used to register microservice applications and related data. Governance policies can rely on metadata registered in the SR (or SM) to control communication rules (e.g., message routing) and communication resilience (e.g., circuit breakers or rate limiting).

[0008] Service discovery is a mechanism for continuously tracking available instances of cloud applications and distributing requests across these instances. XDS is a general protocol for resource discovery between the control plane and the data plane. Controllers, at least partially implemented as XDS-based servers, can ensure that updates about new resources are dynamically delivered to users.

[0009] Conventional approaches can enable application service discovery running in the SM to discover services running in the SR stack. However, the reverse direction of service discovery is not available. Also, the conventional approaches cannot enable synchronization of service governance policies due to semantic gap between the synchronization protocol between the service mesh and the service registry. Further, the conventional approaches can only support deployment of services to one stack (i.e., SR or SM).

[0010] Therefore, there is a need for systems and methods that eliminate or reduce one or more limitations of the prior art.

[0011] Applicant believes that the background information provided herein is pertinent to the application. It is not necessarily admitted that any of the above information constitutes prior art for the present application, whether explicitly or implicitly recited. SUMMARY

[0012] Cloud computing customers, such as application modernization customers that are considering migrating their microservices from a traditional service registry to a service mesh, will need an approach that eliminates or reduces the communication barrier between these two heterogeneous technology stacks caused by different discovery and registration mechanisms. To facilitate modernization of microservices applications, embodiments of the present application provide integration of SR and SM in a way that microservices applications registered in SR can be discovered by SM and vice versa. Further, governance policies registered in SM can be synchronized to SR and vice versa.

[0013] Embodiments of the present application relate to methods, systems, and devices that enable bi-directional service discovery between SR of a cloud service engine (e.g., CSE) and an application SM (e.g., ISTIO). Bi-directional service discovery between SR and SM systems can avoid duplicate configuration of governance policies and enable application service functionality in a hybrid architecture. Then, SR and SM can operate in a coordinated manner simultaneously. Embodiments of the present application enable cloud computing customers to implement an iterative cloud modernization model to migrate to new applications in traditional industries such as banking, public sector, etc., and facilitate multi-cloud architecture (of cloud service engines) and compatibility with leading service mesh products (such as ISTIO), thereby enabling increased competitiveness.

[0014] It is an object of embodiments of the present application to provide systems and methods for integrating microservice registry and service mesh technologies, for example, to facilitate an iterative cloud modernization. In various aspects, a service mesh is provided with registry information about services registered to a service registry, and a service registry is provided with mesh information about services registered to a service mesh. The registration information is initially in a format that is not readable by the service mesh infrastructure, but is converted to a format that is readable by the service mesh infrastructure. The mesh information is initially in a format that is not readable by the service registry infrastructure, but is converted to a format that is readable by the service registry infrastructure.

[0015] According to embodiments of the present invention, a controller can receive a first discovery request from a service mesh, where the service mesh can be implemented using a scalable set of network proxies that are deployed with application code for providing microservice instances. The controller can be operatively coupled to a service registry. The controller obtains service registration information from the service registry, the service registration information indicating names and locations of services registered to the service registry. The service registry can include a database populated with information indicating how and where to dispatch service requests for implementation by other microservice instances.

[0016] In response to the first discovery request, the controller can provide translated data to the service mesh. The translated data can include the registry data in a format supported by the service mesh. The registry data can include all registration metadata held in the service registry for the services registered in the service registry.

[0017] The controller can also send a second discovery request to the service mesh and receive a response to the second discovery request from the service mesh. The response can indicate mesh data that also includes names and locations of services registered to the service mesh. Upon receiving the response, an update to the service registry can be initiated. The update can include providing second translated data to the service registry. The second translated data can include the mesh data in a format supported by the service registry. Additionally or alternatively, the service registry can be updated according to semantics of the mesh data. Further, the controller can translate the registry data to the translated data and / or translate the mesh data to the second translated data. Alternatively, the controller can direct or interoperate with other computing resources to perform such translations.

[0018] According to some embodiments, the controller can be used at least in part as an XDS-based server that receives the first discovery request and provides the translated data in response to the first discovery request. The translated data can include all registration metadata held in the service registry for the services registered to the service registry. The controller can additionally or alternatively be used at least in part as an XDS-based synchronization client that sends the second discovery request and receives the response to the second discovery request. The controller can repeatedly perform the operations of sending the second discovery request, receiving the response to the second discovery request, and initiating the update to the service registry.

[0019] Some embodiments of the invention relate to a controller that obtains a governance policy from a service registry and / or a service mesh, and provides a transformed version of the governance policy from the service registry to the service mesh and / or from the service mesh to the service registry. These embodiments can be combined with the above-described embodiments or provided separately. First, such a governance policy can indicate a microservice configuration stored by a service registry for governing operation of microservices. The service registry can include a database populated with information indicating how and where to dispatch service requests for fulfillment by microservice instances. The controller can provide a first transformed governance policy to a service mesh. The first transformed governance policy can include the first governance policy in a format supported by the service mesh, where the service mesh is implemented using a scalable set of network proxies deployed with application code for providing other microservice instances. The controller can also send a governance policy request to the service mesh and receive a response to the governance policy request from the service mesh. The governance policy request can be a request for a second governance policy stored by the service mesh for governing operation of the other microservice instances. The response can indicate the second governance policy.

[0020] After receiving the response, the controller can initiate an update to the service registry. The update can include providing a second transformed governance policy to the service registry. The second transformed governance policy can include the second governance policy in a format readable by the service registry.

[0021] In some embodiments of the invention, the format supported by the service mesh can be a service mesh governance data model.

[0022] In some embodiments of the invention, the controller can function at least in part as an XDS-based server that provides the first transformed governance policy to the service mesh. Additionally or alternatively, the controller can function at least in part as an XDS-based synchronization client that sends the governance policy request and receives the response to the governance policy request.

[0023] The controller can repeat the operations of sending the governance policy request, receiving the response to the governance policy request, and initiating the update to the service registry.

[0024] In some embodiments of the invention, the controller can convert the first governance policy from the service registry to the first converted governance policy readable by the service mesh, and / or convert the second governance policy from the service mesh to the second converted governance policy readable by the service registry.

[0025] The first converted governance policy can indicate routing data governing the microservice operations of the service registry. The second converted governance policy can indicate routing data governing the other microservice instances of the service mesh.

[0026] In various embodiments, the controller can be integrated with the service registry. In other embodiments, the controller can be integrated with the service mesh. In other embodiments, the controller can be separate from the service registry and the service mesh. In other embodiments, the controller can include a plurality of components, which can include components integrated with the service registry, components integrated with the service mesh, components separate from the service registry and the service mesh, or combinations thereof.

[0027] Embodiments of the invention relate to a method implemented by a controller as described above, a controller configured as described above, and a computer program product or computer readable medium comprising statements and instructions recorded thereon, which, when executed by a controller, cause the controller to implement the method as described above. The controller can comprise a processor executing program instructions stored in a memory and a network interface, or functionally equivalent electronic components.

[0028] Embodiments are described above in connection with various aspects of the invention, which can be implemented based on these aspects. It will be appreciated by those skilled in the art that embodiments can be implemented in connection with the aspects described in connection with these embodiments, but also in connection with other embodiments of the aspects. When embodiments are mutually exclusive or not compatible with each other, this will be apparent to those skilled in the art. Some embodiments can be described in connection with one aspect, but can also be applicable to other aspects, as will be apparent to those skilled in the art. BRIEF DESCRIPTION OF DRAWINGS

[0029] Further features and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, various embodiments of the invention:

[0030] Figure 1A is a general diagram showing a service registry (SR) with a plurality of associated services and a service mesh (SM) with a plurality of associated services.

[0031] Figure 1B is a block diagram illustrating an example of a communication barrier between a microservice using a service registry stack and a microservice using a service mesh stack.

[0032] Figure 2 a block diagram illustrating a system provided by embodiments of the present invention is shown.

[0033] Figure 3 is a block diagram illustrating a service mesh discovering a service registry service provided by embodiments of the present invention.

[0034] Figure 4 is a block diagram illustrating a service registry discovering a service mesh service provided by embodiments of the present invention.

[0035] Figure 5 is a block diagram illustrating a service registry synchronizing governance policies to a service mesh provided by embodiments of the present invention.

[0036] Figure 6 is a pseudo code example for converting a service registry routing data model to a service mesh data model.

[0037] Figure 7 is a block diagram illustrating a service mesh synchronizing governance policies to a service registry provided by embodiments of the present invention.

[0038] Figure 8 is a pseudo code example for converting a service mesh routing data model to a service registry data model.

[0039] Figure 9 is a block diagram of a controller provided by embodiments of the present invention.

[0040] It should be noted that like features are identified by like reference numbers throughout the drawings. DETAILED DESCRIPTION

[0041] Embodiments of the present invention relate to the integration of service registry and service mesh technologies. A controller, referred to herein as a synchronization controller, can facilitate this integration by facilitating bi-directional cross-technology service discovery, bi-directional cross-technology governance policy discovery, or a combination thereof. The controller can bi-directionally transform information between information readable by a service registry and information readable by a service mesh. The controller can be implemented as a computing device, a functional aspect of a computing device, or the like. In some embodiments, the computing device can be virtualized. For context, Figure 1AA service registry (SR) 29 is shown having multiple associated services, including service A, and a service mesh (SM) 26 is shown having multiple associated services, including service B. Operation of the SR 29 can be at least partially directed to facilitate access to and governance of services (microservices) such as service A, Al, and A2, as will be readily understood by those skilled in the art. Operation of the SM 26 can be at least partially directed to facilitate access to and governance of services such as service B, Bl, and B2, as will be readily understood by those skilled in the art.

[0042] For further context and motivation, Figure 1B A block diagram of a service registry stack 1 and a service mesh stack 2 is shown, with a communication barrier 3 between microservices handled by the respective stacks 1 and 2. As a result of the communication barrier 3, and in the absence of additional measures, microservices registered to the service registry (SR) 29 cannot be discovered by the service mesh (SM) 26, and microservices registered to the SM 26 cannot be discovered by the SR 29. In addition, governance policies registered to the SM 26 are not synchronized to the SR 29, and governance policies registered to the SR 29 are not synchronized to the SM 26. Modernization of microservices by embodiments of the present invention involves removing, overcoming, or reducing the communication barrier 3 between the SR 29 and the SM 26.

[0043] The synchronization controller of the present invention can function as a server in order to interact with at least one external entity (e.g., a service mesh). Additionally or alternatively, the synchronization controller can function as a client in order to interact with at least one external entity. A client (e.g., a synchronization controller client) can send requests to a server and wait for responses. A server (e.g., a synchronization controller server) will monitor for and respond to requests from associated clients.

[0044] Figure 2 is an overview diagram introducing the architecture and interconnections of the system provided by embodiments of the present invention. Figure 2A block diagram of a system implementing a synchronization controller 24 to handle connections with an SM 26 is shown. The illustrated synchronization controller 24 is associated with (e.g., embedded or integrated into) an SR 29. Alternatively, the synchronization controller 24 can also be a standalone device or function (adding observability and traffic management functionality transparently to the SR 29), or the synchronization controller 24 can be associated with the SM 26. Yet further, the synchronization controller 24 can include multiple components, one or more of which can be integrated with the SM 26 and / or the SR 29. In the presently illustrated embodiment, a server 28 of the synchronization controller 24 can synchronize with a client 27a at the SM 26. The server 28 can be at least partially an XDS-based server.

[0045] XDS is a mainstream service discovery protocol used for synchronization of control and data planes of a service mesh. The XDS protocol implemented for data synchronization between a service registry and a service mesh improves the efficiency and generality of application development, enabling data synchronization with other data planes that support the XDS protocol. Embodiments of the present invention can be readily implemented by leveraging the capabilities of XDS to perform a range of complex tasks. For example, by incorporating at least some elements of the XDS protocol into the synchronization controller 24 structure including the server 28 and client 27, design work for the synchronization controller 24 can be mitigated. XDS can be used to configure a service mesh’s sidecar.

[0046] The client 27 of the synchronization controller 24 can synchronize or communicatively couple with a server 28a of the SM 26. The client 27 can be at least partially an XDS-based client. Operations 21, 22, and 23 represent communications of registration, governance, and discovery indication information exchanged between the SR 29 and service A. Operations 21a, 22a, and 23a represent communications of registration, governance, and discovery indication information exchanged between the SM 26 and service B. Operations 21, 22, 23, 21a, 22a, and 23a arrows show the direction of information flow from or to services A and B so that these services can be discovered and used in an appropriate manner. If the synchronization controller 24 is not associated with the SR 29, the client 27 and server 28 components can be adjusted to interoperate with corresponding client and server components of the SR 29 and SM 26 in an appropriate manner, as would be readily understood by one skilled in the art.

[0047] Figure 3A block diagram of a synchronization controller 24 facilitating discovery of SR 29 services by SM 26 is shown. In response to receiving a discovery request 30 from the SM, the synchronization controller 24 can perform or initiate a data model conversion 30a to convert service names and service locations (e.g., microservices (MS) 30b and microservice instances 30b1 and 30b2) of the SR 39 to a service mesh data model (e.g., service entries (SE) 30c and workload entries / instances 30c1 and 30c2). The converted data includes data in a format supported by the SM 26. The converted data is pushed (31) by the synchronization controller 24 to the SM 26.

[0048] In more detail, the service mesh 26 is implemented using a scalable set of network proxies that are deployed with the application code used to provide microservice instances. The service mesh 26 can send a first discovery request 30 to the synchronization controller 24. The discovery request 30 can be sent from a client 27a of the service mesh 26 to a server 28 of the synchronization controller 24. Subsequent pushes 31 of converted data can be from the server 28 to the client 27a. In response to the first discovery request 30, the synchronization controller 24 can obtain registry data from the SR 29. The registry data indicates names and locations of services registered to the SR 29. The SR 29 includes a database populated with information indicating how and where to dispatch service requests for implementation by certain microservice instances. Further, the registry data can include all registration metadata held in the SR 29 for services registered to the SR 29. The synchronization controller 24 can also apply the data model conversion 30a to convert the registry data and thus provide the converted data to the SM 26 as shown by the “push 31” in Figure 3 In more detail, the service mesh 26 is implemented using a scalable set of network proxies that are deployed with the application code used to provide microservice instances. The service mesh 26 can send a first discovery request 30 to the synchronization controller 24. The discovery request 30 can be sent from a client 27a of the service mesh 26 to a server 28 of the synchronization controller 24. Subsequent pushes 31 of converted data can be from the server 28 to the client 27a. In response to the first discovery request 30, the synchronization controller 24 can obtain registry data from the SR 29. The registry data indicates names and locations of services registered to the SR 29. The SR 29 includes a database populated with information indicating how and where to dispatch service requests for implementation by certain microservice instances. Further, the registry data can include all registration metadata held in the SR 29 for services registered to the SR 29. The synchronization controller 24 can also apply the data model conversion 30a to convert the registry data and thus provide the converted data to the SM 26 as shown by the “push 31” in

[0049] The data model transformation 30a can involve one or more transformations 30aa of the data. The transformations 30aa can be used to transform the entire data structure (indicative of the data model) or the contents of the data structure. For example, the contents 30b indicative of a microservice can be transformed to contents 30c indicative of an equivalent service entry, the contents 30c being provided in a different format than the contents 30b. Similarly, the contents 30b1, 30b2 indicative of a microservice instance can be transformed to contents 30c1, 30c2 in a different format than the contents 30b1, 30b2. It is noted that the contents 30b, 30b1, 30b2 can initially be generated as a result of registering (21) the service with the SR 29. After or in response to receiving the information by the push 31, the discovery 23a can involve the SM 26 providing information to its services. Such information can include information from the service registry 29, transformed as appropriate by the synchronization controller 24.

[0050] Here and elsewhere, the transformation of information can be performed according to predetermined rules. The rules can specify how to transform information between formats, for example by finding a specified source data indicative of particular information, and using that information to populate destination data. The information itself can be transformed into a different format, moved to a different field of location, etc., or a combination of these operations.

[0051] Figure 4 A block diagram is shown of a synchronization controller 24 facilitating discovery of SM 26 services by the SR 29. The synchronization controller client 27, in communication coupling with the SM 26, can send a second discovery request 32 to the SM 26. In response to the second discovery request 32, the SM 26 can push (33) a response indicative of mesh data to the synchronization controller 24, the mesh data including other names and locations of services registered to the SM 26. The second discovery request 32 can be sent from the client 27 of the synchronization controller 24 to the server 28a of the service mesh 26. The subsequent push 33 (response indicative of mesh data) can be from the server 28a to the client 27. The synchronization controller 24 can apply data model transformations 33a to transform the received service name and location data (e.g., cluster discovery 33c and endpoint discovery 33c1 and 33c2) to an internal data model of the service registry (e.g., microservice (MS) 33b and microservice instances 33b1 and 33b2).

[0052] Upon receiving the response 33, the synchronization controller 24 can initiate an update to the SR 29 data store. The update can include second transformed data, where the second transformed data can include mesh data in a format supported by the SR 29. The synchronization controller 24 can act at least in part as an XDS-based synchronization client that sends a second discovery request and receives a response to the second discovery request. The synchronization controller 24 can repeat the above described operations of sending a second discovery request 32, receiving a response to the second discovery request 32 (push 33), and initiating an update to the SR 29. The repetition can occur periodically or in response to a trigger in order to maintain up-to-date information in the service registry. Similar repetition can occur in order to maintain up-to-date information in the service mesh, e.g., repeating the obtaining of data from the service registry, transforming the data, and pushing the transformed data to the service mesh. In addition, the synchronization controller 24 can continuously monitor for changes in the SM 26.

[0053] The data model transformation 33a can involve one or more transformations 33aa of the data. The transformations 33aa can be used to transform the entire data structure (indicative of the data model) or the contents of the data structure. For example, the contents 33c, 33cl, 33c2 indicative of a service entry in the service mesh data model can be transformed into contents 33b, 33bl, 33b2 indicative of an equivalent service entry in the service registry data model, the contents 33b, 33bl, 33b2 provided in a different format than the contents 33c, 33cl, 33c2. It is noted that the contents 33c, 30cl, 30c2 can have originally been generated as a result of registering (21a) a service with the SM 26, and can be related to cluster discovery and endpoint discovery operations. The discovery 23 can involve the SR 29 providing information to its services after or in response to receiving the information by the push 33. Thus, such information includes information from the service mesh 26, transformed appropriately by the synchronization controller 24.

[0054] Figure 3 And the operations of Figure 4 may be combined together to facilitate bidirectional service discovery. Figure 3 The operations of Figure 4 may be performed before, after, or concurrently with the operations of

[0055] Figure 5A block diagram of the synchronization controller 24 is shown that synchronizes governance policies from the SR 29 to the SM 26. After a governance request 36 from the SM 26 (or without such a request), the synchronization controller 24 can fetch a first governance policy from the SR 29. The SR 29 includes a database populated with information indicating how to dispatch service requests for implementation by microservice instances, such as governance configurations 36b1-36b6. The first governance policy indicates microservice configurations stored by the SR 29 for governing microservice operations. The synchronization controller 24 can use or implement a data model conversion 36a to convert the governance configurations 36b1-36b6 of the SR 29 to a service mesh governance data model, such as including virtual services 36c1 and destination rules 36c2. After the data model conversion 36a, the synchronization controller 24 can provide (push 37) a first converted governance policy to the SM 26. The first converted governance policy can include the first governance policy in a format readable or supported by the SM 26. For example, the format supported by the SM 26 can be a service mesh governance data model. The synchronization controller 24 can act at least in part as an XDS-based server that provides the first converted governance policy to the SM 26. Likewise, the first converted governance policy can indicate routing data for governing the microservice operations of the service registry.

[0056] The governance request 36 can be sent from a client 27a of the service mesh 26 to a server 28 (e.g., an XDS-based server) of the synchronization controller 24. Subsequent pushes 37 of converted governance policy data can be from the server 28 to the client 27a.

[0057] Data model conversion 36a can involve transforming 36aa, for example by sync controller 24 or another device, service registry data model governance information into service mesh data model governance information. Service registry data model governance information can include some or all of: information about load balancing 36bl; circuit breaking information 36b2; canary information 36b3, fault tolerance information 36b4, filter chain information 36b5, and rate limiting information 36b6. Service mesh data model governance information can include virtual service information 36cl and destination rules information 36c2. The 36bl through 36b6 data models can be considered specializations of 36cl and 36c2. The 36bl through 36b6 data models, each can have a subset of the fields of 36cl and 36c2. For example, during the transformation of 36bl into 36cl and 36c2, some of the 36c fields remain blank while others can be populated, for 36b2 the populated fields can be different than for 36bl, and so on. The fields on both sides can have different names, the equivalency is set based on the semantics of the fields, i.e. different name / format but same meaning. In all cases, each 36b data model will generate two structs, 36cl and 36c2, with different fields that are blank and populated. Data model conversion can generally involve converting the way the related information is presented, e.g. format, naming, etc. Some information can be discarded as part of the data model conversion if it is not relevant in the output data model. Other data model conversions as described herein can operate similarly.

[0058] Figure 6An example of pseudo code for converting a service registry routing data model to a service mesh data model in some embodiments of the present invention is shown. When the sync controller 24 receives a governance request 36 from the SM 26, converting the service registry routing data model to the service mesh data model can include the following steps. If a RouteRule exists in the SR 29 configuration store, the sync controller 24 can scope the RouteRule, decode the selected RouteRule, and get the service name from the selected RouteRule. If a microservice with the same service name exists in the SR 29, the sync controller 24 can create a DestinationRule with that service name. In addition, the sync controller 24 can extract the service address, port, and version from the microservice (and its instances) construct and insert the destinations into the DestinationRule. The sync controller 24 can create a virtual service for each destination of the DestinationRule and convert the weights in the DestinationRule to weights in the VirtualService. If the RouteRule specifies an http header match, the sync controller 24 converts the http header match portion to the match.header portion of the VirtualService. If the RouteRule specifies an instance version match, the sync controller 24 converts the version match portion to the subset portion of the VirtualService.

[0059] Figure 7A block diagram of the synchronization controller 24 that synchronizes governance policies from the SM 26 to the SR 29 is shown. The synchronization controller 24 can send a request 34 (with a governance policy) to the service mesh 26. The governance policy request 34 can be a request for a second governance policy that is maintained by the SM 26 for governing the operation of other microservice instances. The request 34 can be an XDS-based request. After the request 34, the synchronization controller 24 can receive (push 35) a response to the governance policy request 34 from the SM 26. The response indicates the second governance policy. After receiving the response 35, the synchronization controller 24 initiates an update to the SR 29. The update can include providing the second translated governance policy to the SR 29. The second translated governance policy can indicate routing data for governing other microservice instances of the SM 26. The second translated governance policy can include the second governance policy in a format supported by the SR 29. The synchronization controller 24 can analyze the response indicating the second governance policy (service governance policy data 35c) and generate a mapping. The synchronization controller 24 can also apply a data model translation 35a to translate the second governance policy 35c and the mapping to an internal representation 35b1-35b6 of the SR 29. Subsequently, the synchronization controller 24 can update the SR configuration store and continuously monitor for changes in the SM 26. The synchronization controller 24 can repeat sending a governance policy request, receiving a response to the governance policy request, and initiating an update to the SR 29. In addition, the synchronization controller 24 can at least partially function as an XDS-based synchronization client that sends a governance policy request and receives a response to the governance policy request.

[0060] The governance request 34 can be sent from a client 27 (e.g., an XDS-based client) of the synchronization controller 24 to a server 28a of the service mesh 26. Subsequent pushes 35 of translated governance policy data can be from the server 28a to the client 27.

[0061] Data model conversion 35a can involve transforming (35aa) service mesh data model governance information into service registry data model governance information, e.g., by synchronization controller 24 or another device. Service mesh data model governance information can include service governance policy data 35c. Service mesh data model governance information can additionally or alternatively include virtual service information, destination rule information, etc. Service registry data model governance information can include some or all of: information about load balancing 35bl; circuit breaking information 35b2; canary information 35b3, fault tolerance information 35b4, filter chain information 35b5, and rate limiting information 35b6. 35bl through 35b6 are specialized transformations of 35c. At a high level, transformation 35aa can delete the empty / unused fields of 35c, and use the remaining populated fields to create 35bl through 35b6. Field names can not match in the two structures, their equivalency is defined based on their semantics, i.e., name / structure is different but meaning is the same.

[0062] Figure 5 and Figure 7 Operations of one, some, or all of Figure 5 Operations of one, some, or all of Figure 7 may be performed before, after, or concurrently with operations of Figure 3 Operations of one, some, or all of Figure 5 may occur at the same time or at different times. Figure 4 Operations of one, some, or all of Figure 7 may occur at the same time or at different times. Figure 3 , Figure 4 , Figure 5 and Figure 7 Operations of one, some, or all of

[0063] Figure 8Pseudo code examples for converting a service mesh routing data model to a service registry data model in some embodiments of the application are shown. When the sync controller 24 sends a governance request 34, the conversion can include the following steps. If there is an RDS configuration in the response 35 from the SM 26, the sync controller 24 can filter out the system default configuration by name and namespace. The sync controller 24 can also scope the RDS configuration and decode the selected RDS configuration, thereby generating a virtual host. The sync controller 24 can also extract the virtual host service name and service namespace and create a service registry RouteRule with the service name. If there is a routes.match configuration in the virtual host, the sync controller 24 can set the match configuration to the service registry RouteRule. The sync controller can also extract the route configuration from the virtual host and scope the route configuration. In addition, the sync controller 24 can extract the service address, port, weight, and version from the selected route configuration and build the route configuration, setting the route configuration to the service registry RouteRule structure.

[0064] Figure 9 is a block diagram of an electronic device 24 represented as a controller in the present application. The controller can include a computer processor operably coupled to a computer memory. A computer equipped with network functionality can be configured as the controller. The controller can correspond to a portion of a computer server, for example in a data center, or a network node (e.g., gNB) that provides network access.

[0065] As shown in Figure 9 , the device 24 includes a processor 71, e.g., a central processing unit (CPU) or a specialized processor such as a graphics processing unit (GPU) or other such processor unit, a memory 74, a non-transitory mass storage device 72, an I / O interface 75, a network interface 73, and a transceiver 76, all of which are communicatively coupled via a bidirectional bus 77. According to certain embodiments, any or all of the described elements can be utilized, or merely a subset of the elements. Further, the device 24 can include multiple instances of certain elements, such as multiple processors, memories, or transceivers. Furthermore, elements of the hardware device can be directly coupled to other elements without the bidirectional bus. Other electronic elements, such as integrated circuits, can be used in place of, or to supplement, the processor and memory in performing the necessary logic operations.

[0066] The memory 74 can include any type of non-transitory memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof, etc. The mass storage 72 can include any type of non-transitory storage device or computer-readable medium, such as a solid-state drive, a hard disk drive, a magnetic disk drive, an optical disk drive, a USB drive, or any computer program product for storing data and machine-executable program code. According to certain embodiments, the memory 74 or the mass storage 72 can have recorded thereon statements and instructions executable by the processor 71 for performing any of the method operations described above.

[0067] Within the scope of the technology, a computer program product or program element, or a program storage device or a memory device such as a magnetic or optical record carrier, floppy disc, optical disc, ROM, etc. is provided for storing a machine readable signal which can be read by a computer to cause the computer to perform operations in accordance with the methods of the technology and / or to configure some or all of the components of the system in accordance with the technology. The actions associated with the methods described herein can be implemented as coded instructions in a single computer program product. In other words, the computer program product is a computer readable medium having software code recorded thereon for executing the method when the computer program product is loaded into the memory and executed on the microprocessor of the wireless communication device. Further, each operation of the method can be performed on any computing device, such as a personal computer, a server, a PDA, etc., and according to one or more program elements, modules or objects, or portions thereof, generated from any programming language such as C++, Java, etc. or a combination of one or more programming languages, or portions thereof. Further, each operation or the files or objects which implement each operation can be executed by special-purpose hardware or circuitry designed for that purpose or by a circuit module designed for that purpose.

[0068] Through the description of the above embodiments, the present application can be implemented only by hardware, or by software and necessary general hardware platform. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a plurality of instructions, which enable a computer device (personal computer, server, or network device) to perform the method provided in the embodiments of the present application. For example, such execution can correspond to the simulation of the logical operations described herein. According to the embodiments of the present application, the software product can additionally or alternatively include a plurality of instructions, which enable the computer device to perform the operation of configuring or programming a digital logic device.

[0069] Although the present application has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the present application. The specification and drawings are, therefore, to be regarded as illustrative only, and it is intended to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present application.

Claims

1. A method for integration of service registry and service mesh, characterized in that, The controller performs the following operations: receiving a first discovery request from the service mesh, the service mesh implementable using a scalable set of network proxies deployed with application code for providing microservice instances; obtaining registry data from the service registry, the registry data indicating names and locations of services registered to the service registry, the service registry comprising a database populated with information indicating how and where to dispatch service requests for implementation by other microservice instances; providing, in response to the first discovery request, transformed data to the service mesh, the transformed data comprising the registry data in a format readable by the service mesh; sending a second discovery request to the service mesh; receiving a response to the second discovery request from the service mesh, the response indicating mesh data further comprising names and locations of services registered to the service mesh; after receiving the response, initiating an update to the service registry, the update comprising providing second transformed data to the service registry, the second transformed data comprising the mesh data in a format readable by the service registry.

2. The method of claim 1, wherein, The controller is at least partially used as an XDS-based server that receives the first discovery request and provides the transformed data in response to the first discovery request.

3. The method according to claim 1 or 2, characterized in that, The controller is at least partially used as an XDS-based synchronization client that sends the second discovery request and receives the response to the second discovery request.

4. The method according to any one of claims 1 to 3, characterized in that, Further comprising repeatedly performing the operations of sending the second discovery request, receiving the response to the second discovery request, and initiating the update to the service registry.

5. The method according to any one of claims 1 to 4, characterized in that, Further comprising transforming the registry data into the transformed data and / or transforming the mesh data into the second transformed data.

6. The method according to any one of claims 1 to 5, characterized in that, The registry data comprises all registration metadata held in the service registry for the services registered in the service registry.

7. A method for integrating a service registry with a service mesh, the method comprising: The controller performs the following operations: obtaining a first governance policy from the service registry, the first governance policy indicating microservice configurations stored by the service registry for governing microservice operations, the service registry comprising a database populated with information indicating how to dispatch service requests for implementation by microservice instances; providing a first transformed governance policy to the service mesh, the first transformed governance policy comprising the first governance policy in a format readable by the service mesh, the service mesh implemented using a scalable set of network proxies deployed with application code for providing other microservice instances; sending a governance policy request to the service mesh, the governance policy request being a request for a second governance policy held by the service mesh for governing operations of the other microservice instances; receiving, from the service mesh, a response to the governance policy request, the response indicating the second governance policy; after receiving the response, initiating an update to the service registry, the update including providing a second converted governance policy to the service mesh to the service registry, the second converted governance policy including the second governance policy in a format readable by the service registry.

8. The method of claim 7, wherein, the format readable by the service mesh is a service mesh governance data model.

9. The method according to claim 7 or 8, characterized in that, the controller is used at least in part as an XDS-based server that provides the first converted governance policy to the service mesh.

10. The method according to any one of claims 7 to 9, characterized in that, the controller is used at least in part as an XDS-based synchronization client that sends the governance policy request and receives the response to the governance policy request.

11. The method according to any one of claims 7 to 10, characterized in that, Further comprising repeatedly performing the operations of sending the governance policy request, receiving the response to the governance policy request, and initiating the update to the service registry.

12. The method according to any one of claims 7 to 11, characterized in that, Further comprising: converting the first governance policy from the service registry to the first converted governance policy readable by the service mesh, and / or converting the second governance policy from the service mesh to the second converted governance policy readable by the service registry.

13. The method according to any one of claims 7 to 12, characterized in that, the first converted governance policy indicates routing data governing the microservice operations of the service registry.

14. The method according to any one of claims 7 to 13, characterized in that, the second converted governance policy indicates routing data governing the other microservice instances of the service mesh.

15. A controller characterized by comprising: including a computer processor operably coupled to a computer memory and configured to perform the method of any of claims 1-14.

16. A computer program product, characterised in that, including a computer-readable medium having stored thereon statements and instructions that, when executed by a computer, cause the computer to function as a controller that performs the method of any of claims 1-14.

Images