A method and device for migrating microservice applications

Abstract

An embodiment of the present application provides a method and device for migrating a microservice application, which is applied in the field of cloud technology, including: starting a first microservice application through a startup script, wherein the startup script includes a proxy package; when running the proxy package, reading the original configuration file of the first microservice application; sending the original configuration file to the service grid control plane through the sidecar corresponding to the first microservice application, so that the service grid control plane modifies the original configuration file into a target configuration file, and the target configuration file is used to configure the sidecar as a service proxy for the first microservice application; receiving the target configuration file sent by the service grid control plane through the sidecar, and replacing the original configuration file in the first microservice application with the target configuration file. The present application completes the migration of the microservice application to the non-transparent proxy service grid by adding a proxy package to the startup script of the microservice application, thereby reducing the cost of migrating the microservice application and improving the efficiency of the migration.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of cloud technology, and in particular to a method and device for migrating microservice applications. Background Art

[0002] With the development of Internet technology, cloud computing has been continuously applied. The business and service population of major Internet companies are constantly growing, and the services are also growing. Microservice architecture technology is also gradually being used, promoted and popularized in Internet companies. Building a service grid has gradually become the mainstream solution for enterprises to promote service governance.

[0003] When building a service mesh, a transparent proxy service mesh is often used due to management difficulties, security, and communication performance considerations. To promote the large-scale use of service meshes, it is necessary to address the issue of migrating microservice applications from transparent proxy service meshes to non-transparent proxy service meshes.

[0004] In related technologies, Java microservice applications are migrated to a non-transparent proxy service grid by rewriting their code. However, migrating microservice applications through code rewriting often incurs high rewriting costs and is inefficient. Summary of the Invention

[0005] Embodiments of the present application provide a method and apparatus for migrating a microservice application to a non-transparent proxy service grid.

[0006] In a first aspect, an embodiment of the present application provides a method for migrating a microservice application, which is applied to a first node and includes:

[0007] Start the first microservice application through a startup script, where the startup script includes an agent package;

[0008] When running the agent package, reading the original configuration file of the first microservice application;

[0009] Sending the original configuration file to the service mesh control plane through the sidecar corresponding to the first microservice application, so that the service mesh control plane modifies the original configuration file into a target configuration file, where the target configuration file is used to configure the sidecar as a service proxy for the first microservice application;

[0010] The target configuration file sent by the service mesh control plane is received by the sidecar, and the original configuration file in the first microservice application is replaced with the target configuration file.

[0011] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0012] Optionally, the sidecar is further configured to record the target configuration file.

[0013] Optionally, after replacing the original configuration file in the first microservice application with the target configuration file, the method further includes:

[0014] Receiving, through the sidecar, a service call request for the first microservice application sent by a second node, where the service call request is triggered by a second microservice application in the second node;

[0015] Obtaining service information of the target service requested to be called from the service call request through the sidecar, and determining the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service and the service port of the first microservice application;

[0016] Forwarding the service call request to the target service port through the sidecar;

[0017] The call result output by the target service port is sent to the second node through the sidecar.

[0018] Optionally, forwarding the service call request to the target service port through the sidecar includes:

[0019] If the second microservice application supports a different communication protocol than the first microservice application, the service call request is forwarded to the target service port by the sidecar using the communication protocol supported by the first microservice application.

[0020] Optionally, if the second microservice application is a native microservice application, the node information of the first node included in the service call request is obtained by the second node from a microservice registration center;

[0021] If the second microservice application is a migrated microservice application, the service call request includes node information of the first node, which is obtained by the second node from the service grid registration center.

[0022] Optionally, the heartbeat status of the first microservice application is monitored by the sidecar, and when the heartbeat status of the first microservice application is abnormal, an abnormal message is reported to the service grid control plane, so that the service grid control plane modifies the service status of the first microservice application in the microservice registration center.

[0023] In a second aspect, an embodiment of the present application provides a method for migrating a microservice application, a service mesh control plane, including:

[0024] The receiving node sends an original configuration file through a sidecar corresponding to a first microservice application, where the first microservice application is started by the node through a startup script, and the original configuration file is read by the node when running an agent package included in the startup script;

[0025] Modify the original configuration file into a target configuration file, where the target configuration file is used to configure the sidecar as a service proxy for the first microservice application;

[0026] The target configuration file is sent to the sidecar, so that the node replaces the original configuration file in the first microservice application with the target configuration file.

[0027] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0028] Optionally, modifying the original configuration file to a target configuration file includes:

[0029] The communication mode recorded in the original configuration file is modified to directly connect to the peer end, the address of the sidecar is set to the peer end address, and the listening mode of the service port of the first microservice application recorded is modified to sidecar listening to obtain the target configuration file.

[0030] Optionally, obtaining service information of at least one service provided by the first microservice application from the target configuration file;

[0031] Register the service information of each provided service and the port of the sidecar to the microservice registry and the service mesh registry.

[0032] Optionally, obtaining service information of at least one service subscribed to by the first microservice application from the target configuration file;

[0033] For each subscribed service, based on the service information of the subscribed service, obtain a list of nodes that provide the subscribed service from the first microservice registry and the service grid registry respectively;

[0034] A routing table is obtained based on service information of at least one subscribed service and a corresponding node list.

[0035] Optionally, after obtaining the routing table based on the service information of at least one subscribed service and the corresponding node list, the method further includes:

[0036] Send the routing table to the sidecar.

[0037] In a third aspect, an embodiment of the present application provides a microservice application migration device, which is applied to a first node and includes:

[0038] A startup module, configured to start the first microservice application through a startup script, wherein the startup script includes an agent package;

[0039] A reading module, configured to read an original configuration file of the first microservice application when running the proxy package;

[0040] a processing module, configured to send the original configuration file to the service mesh control plane through a sidecar corresponding to the first microservice application, so that the service mesh control plane modifies the original configuration file into a target configuration file, where the target configuration file is used to configure the sidecar as a service proxy for the first microservice application;

[0041] A replacement module is configured to receive the target configuration file sent by the service mesh control plane through the sidecar, and replace the original configuration file in the first microservice application with the target configuration file.

[0042] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0043] Optionally, the processing module is specifically configured to:

[0044] The sidecar is also used to record the target configuration file.

[0045] Optionally, the processing module is specifically configured to:

[0046] Receiving, through the sidecar, a service call request for the first microservice application sent by a second node, where the service call request is triggered by a second microservice application in the second node;

[0047] Obtaining service information of the target service requested to be called from the service call request through the sidecar, and determining the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service and the service port of the first microservice application;

[0048] Forwarding the service call request to the target service port through the sidecar;

[0049] The call result output by the target service port is sent to the second node through the sidecar.

[0050] Optionally, the processing module is specifically configured to:

[0051] If the second microservice application supports a different communication protocol than the first microservice application, the service call request is forwarded to the target service port by the sidecar using the communication protocol supported by the first microservice application.

[0052] Optionally, the processing module is specifically configured to:

[0053] If the second microservice application is a native microservice application, the node information of the first node included in the service call request is obtained by the second node from the microservice registration center;

[0054] If the second microservice application is a migrated microservice application, the service call request includes node information of the first node, which is obtained by the second node from the service grid registration center.

[0055] Optionally, the processing module is specifically configured to:

[0056] The heartbeat status of the first microservice application is monitored by the sidecar, and when the heartbeat status of the first microservice application is abnormal, an abnormal message is reported to the service grid control plane, so that the service grid control plane modifies the service status of the first microservice application in the microservice registration center.

[0057] In a fourth aspect, an embodiment of the present application provides a microservice application migration device, which is applied to a service grid control plane, including:

[0058] an acquisition module, configured to receive an original configuration file sent by a node through a sidecar corresponding to a first microservice application, where the first microservice application is started by the node through a startup script, and the original configuration file is read by the node when running an agent package included in the startup script;

[0059] a processing module, configured to modify the original configuration file into a target configuration file, wherein the target configuration file is used to configure the sidecar as a service proxy for the first microservice application;

[0060] The processing module is further configured to send the target configuration file to the sidecar, so that the node replaces the original configuration file in the first microservice application with the target configuration file.

[0061] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0062] Optionally, the processing module is specifically configured to:

[0063] The communication mode recorded in the original configuration file is modified to directly connect to the peer end, the address of the sidecar is set to the peer end address, and the listening mode of the service port of the first microservice application recorded is modified to sidecar listening to obtain the target configuration file.

[0064] Optionally, the processing module is specifically configured to:

[0065] Obtaining service information of at least one service provided by the first microservice application from the target configuration file;

[0066] Register the service information of each provided service and the port of the sidecar to the microservice registry and the service mesh registry.

[0067] Optionally, the processing module is specifically configured to:

[0068] Obtaining service information of at least one service subscribed to by the first microservice application from the target configuration file;

[0069] For each subscribed service, based on the service information of the subscribed service, obtain a list of nodes that provide the subscribed service from the microservice registry and the service grid registry respectively;

[0070] A routing table is obtained based on service information of at least one subscribed service and a corresponding node list.

[0071] Optionally, the processing module is specifically configured to:

[0072] Send the routing table to the sidecar.

[0073] In a fifth aspect, an embodiment of the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the migration method of the microservice application described in any of the above-mentioned first aspects.

[0074] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program executable by a computer device. When the program runs on the computer device, the computer device executes any of the microservice application migration methods described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0076] Figure 1 This is a schematic diagram of the architecture of a microservice grid system applicable to embodiments of the present application;

[0077] Figure 2 A flowchart of a method for migrating a microservice application provided in an embodiment of the present application;

[0078] Figure 3 A process sequence diagram of the migration of a microservice application provided in an embodiment of the present application;

[0079] Figure 4 A schematic diagram of a process for a second microservice application to call a first microservice application service provided in an embodiment of the present application;

[0080] Figure 5 A schematic diagram of a process for a native microservice to call a first microservice application service provided in an embodiment of the present application;

[0081] Figure 6 A schematic diagram of a process for a migrated microservice to call a first microservice application service provided in an embodiment of the present application;

[0082] Figure 7 A schematic diagram of the structure of a migration device for a microservice application provided in an embodiment of the present application;

[0083] Figure 8A schematic diagram of the structure of a migration device for a microservice application provided in an embodiment of the present application;

[0084] Figure 9 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0085] In order to make the purpose, technical solutions and beneficial effects of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0086] For ease of understanding, the terms involved in the embodiments of the present invention are explained below.

[0087] Service Mesh: A service mesh is a dedicated infrastructure layer that facilitates service-to-service communication between services or microservices using proxies. A service mesh consists of a network proxy paired with each service in an application and a set of task management processes.

[0088] Transparent proxy service: The client and the server are unaware of the existence of the proxy. The client does not need to modify the destination address, nor does it need to use the proxy protocol to connect to the proxy server. All destination address conversions are completed in the transparent proxy.

[0089] Non-transparent proxy service: The client needs to modify the destination address to the address of the proxy server and use the proxy protocol to connect to the proxy server.

[0090] Service mesh control plane: Provides policies and configurations for all running data planes in the mesh without touching any packets / requests in the system. The control plane turns all data planes into a distributed system.

[0091] Figure 1 This is a schematic diagram of the architecture of a microservices mesh system provided by an embodiment of the present invention. The system architecture includes a first node 100, a service mesh control plane 102, a microservices registry 103, and a service mesh registry 104. First node 100 communicates with service mesh control plane 102, and service mesh control plane 102 can communicate with microservices registry 103 and service mesh registry 104, respectively.

[0092] based on Figure 1 The microservice grid system architecture diagram shown in FIG, the embodiment of the present application provides a process of migrating a microservice application, such as Figure 2 As shown, the process of this method can be Figure 1 The first node shown is executed, including the following steps:

[0093] Step S201: Start the first microservice application through a startup script, where the startup script includes an agent package;

[0094] Specifically, the first node includes a first microservice application and a sidecar corresponding to the first microservice application. Before starting the first microservice application, an agent package (Java Agent JAR) is added to the startup script of the first microservice application. The agent package can start the first microservice application according to the original process by referencing the code "-javaagent:${JAR package name}.jar".

[0095] Step S202: when running the proxy package, read the original configuration file of the first microservice application;

[0096] Specifically, when the first microservice application starts, the proxy package is run and the original configuration file is read according to the original logic of the first microservice application; wherein the original configuration file includes the services subscribed by the first microservice application, the services that can be provided, and the mapping relationship between each service and the corresponding port.

[0097] Step S203: Send the original configuration file to the service mesh control plane through the side car corresponding to the first microservice application, so that the service mesh control plane modifies the original configuration file into a target configuration file. The target configuration file is used to configure the side car as a service proxy for the first microservice application.

[0098] Specifically, the sidecar corresponding to the first microservice application receives the original configuration file sent by the first microservice application, parses the original configuration file, and records the mapping relationship between each service and port in the first microservice application. The sidecar sends the original configuration file to the service mesh control plane, which has a receiving interface for receiving the original configuration file. The service mesh control plane modifies the original configuration file to obtain a target configuration file. The target configuration file is used to communicate with the sidecar as a service proxy for the first microservice application. The service mesh control plane then returns the target configuration file to the sidecar.

[0099] In some embodiments, the service mesh control plane modifies the original configuration file into a target configuration file, including: modifying the communication mode recorded in the original configuration file to directly connect to the peer end, setting the address of the sidecar to the peer end address, and modifying the listening mode of the service port of the recorded first microservice application to sidecar listening to obtain the target configuration file.

[0100] Specifically, the original communication mode of the original configuration file is registration discovery, that is, the first microservice application before migration needs to communicate through the microservice application center. The service mesh control plane changes the communication mode to direct connection to the other end, that is, the first microservice application can communicate directly through the sidecar; the other end address in the original configuration file is set to the address of the sidecar; the port corresponding to each service in the original configuration file is changed to sidecar listening, that is, the port of each service is taken over by the sidecar; finally, the service mesh control plane obtains the target configuration file.

[0101] In some embodiments, the service mesh control plane obtains service information of at least one service provided by the first microservice application from the target configuration file; and registers the service information of each provided service and the port of the sidecar with the microservice registration center and the service mesh registration center.

[0102] Specifically, the target configuration file includes at least one service provided by the first microservice application. Each service contains corresponding service information, including the service ID, service timeout, and service invocation policy. Each service provided by the first microservice application has a corresponding port, which is monitored by the sidecar. The service mesh control plane registers the service information of each service provided by the first microservice application, as well as the mapping between the service and the sidecar port, with the microservice registry and the service mesh registry.

[0103] In some embodiments, the service mesh control plane obtains service information of at least one service subscribed to by the first microservice application from the target configuration file; for each subscribed service, based on the service information of the subscribed service, obtains a list of nodes providing the subscribed service from the microservice registry and the service mesh registry respectively; and obtains a routing table based on the service information of the at least one subscribed service and the corresponding node list.

[0104] Specifically, the target configuration file includes at least one service subscribed to by the first microservice application. Each service contains corresponding service information, including the service ID, service timeout, and service invocation policy. For each subscribed service, based on the service information of the subscribed service, a list of nodes that can provide the subscribed service of the first microservice application is retrieved from the microservice registry and the service mesh registry. Based on the mapping between the subscribed service ID and other service information, such as the node list, service invocation policy, and service timeout, a routing table is generated.

[0105] In some embodiments, the service mesh control plane sends the routing table to the sidecar.

[0106] Step S204: Receive the target configuration file sent by the service mesh control plane through the sidecar, and replace the original configuration file in the first microservice application with the target configuration file.

[0107] Specifically, the sidecar receives the target configuration file sent by the service mesh control plane, and sends the target configuration file to the first microservice application. The first microservice application performs a deserialization operation based on the target configuration file and overwrites the original configuration file.

[0108] In some embodiments, the sidecar is also used to record target configuration files.

[0109] Specifically, in the target configuration file, the peer address is the address of the sidecar and each service of the first microservice application is monitored by the sidecar. The sidecar needs to record the correspondence between the service and the port.

[0110] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0111] like Figure 3 The figure shows a process sequence diagram of migrating a microservice application to a non-transparent proxy service grid according to an embodiment of the present application. The microservice application is a first microservice application, and specifically includes the following steps:

[0112] Step S301: The first microservice application is started through a startup script;

[0113] Specifically, the first microservice application is started according to the original logic by adding a proxy package to the startup script;

[0114] Step S302: The first microservice application sends the original configuration file to the sidecar;

[0115] Step S303: The sidecar sends the original configuration file to the service mesh control plane.

[0116] Step S304: The service grid control plane modifies the original configuration file to obtain a target configuration file;

[0117] Specifically, the service mesh control plane modifies the communication mode recorded in the original configuration file to a direct connection to the peer end, sets the sidecar address to the peer end address, and modifies the listening mode of the service port of the recorded microservice application to sidecar listening, and obtains the target configuration file for configuring the sidecar as a service agent for the first microservice application.

[0118] Step S305: The service mesh control plane sends the target configuration file to the microservice registry for registration discovery.

[0119] Specifically, the target configuration file includes at least one service provided by the first microservice application. Each service contains corresponding service information, including the service ID, service timeout, and service invocation policy. Each service provided by the first microservice application has a corresponding port, which is monitored by the sidecar. The service mesh control plane registers the service information of each service provided by the first microservice application, as well as the mapping between the service and the sidecar port, with the microservice registry and the service mesh registry.

[0120] Step S306: The microservice registration center returns the node list to the service mesh control plane;

[0121] Specifically, the node list is each service subscribed by the first microservice application to the microservice registration center. Based on the service information of the subscribed service, a node list that can provide the subscribed service of the first microservice application is obtained from the microservice registration center.

[0122] Step S307: The service mesh control plane obtains a routing table based on the node list.

[0123] Specifically, the service mesh control plane can obtain a routing table based on the mapping relationship between the subscribed service ID and other service information such as the node list, service call policy, and service timeout period.

[0124] Step S308: The service mesh control plane sends the target configuration file and routing table to the sidecar.

[0125] Specifically, the sidecar is also used to record the target configuration file and take over the traffic of the first microservice application according to the routing table.

[0126] Step S309: The sidecar sends the target configuration file to the first microservice application;

[0127] In step S310, the first microservice application performs deserialization according to the target configuration file, overwriting the original configuration file.

[0128] In some embodiments, after replacing the original configuration file in the first microservice application with the target configuration file, the following steps are also included: Figure 4 The process shown in FIG2 shows a second microservice application calling a first microservice application service, specifically including the following steps:

[0129] Step S401: receiving a service call request for a first microservice application sent by a second node through a sidecar, where the service call request is triggered by a second microservice application in the second node.

[0130] Specifically, the second node needs to call the service of the first microservice application. The second node initiates a service call request to the sidecar on the first node. The service call request is triggered by the second microservice application in the second node.

[0131] Step S402: Obtain service information of the target service requested from the service call request through the sidecar, and determine the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service ports of the first microservice application;

[0132] Specifically, the service that the second microservice should request to call is the target service. The sidecar is used to parse the service call request triggered by the second microservice application, and obtain the service information of the target service from the request header of the service call request. Based on the service information, the sidecar searches for the target service and the port corresponding to the target service saved in the routing table, and determines that the port is the target service port.

[0133] Step S403: forward the service call request to the target service port through the sidecar;

[0134] Specifically, the sidecar sends the service call request triggered by the second microservice application to the target service port.

[0135] Step S404: Send the call result output by the target service port to the second node through the sidecar.

[0136] Specifically, the sidecar processes the service call request triggered by the target service port to the second microservice application, and sends the call result to the second node.

[0137] In some embodiments, if the second microservice application supports a different communication protocol than the first microservice application, the service call request is forwarded to the target service port by the sidecar using the communication protocol supported by the first microservice application.

[0138] Specifically, the communication protocol supported by the second microservice application is different from the communication protocol supported by the first microservice application. The sidecar needs to convert the protocol into the communication protocol supported by the first microservice application, and then forward the service call request to the target service port.

[0139] In some embodiments, if the second microservice application is a native microservice application, the node information of the first node included in the service call request is obtained by the second node from the microservice registration center;

[0140] Specifically, native microservice applications are microservice applications that have not been migrated to a non-transparent proxy service grid. Native microservice applications communicate directly with the microservice registry. The first node is determined by the second node based on the service information of the target service being called after obtaining a node list from the microservice registry. The service information can be the target service's invocation policy.

[0141] For example, the communication process of a native microservice application initiating a target service call request is as follows: Figure 5 The steps shown are as follows. The native microservice application is on the second node, the first microservice application is on the first node, and the first node includes a sidecar corresponding to the first microservice application. The steps of this process are as follows:

[0142] Step S501: The native microservice application obtains a service node list from the microservice registration center;

[0143] Specifically, the native microservice application obtains the node list of the target service from the microservice registration center.

[0144] Step S502: The native microservice application triggers a service call request and sends the service call request to the sidecar corresponding to the first microservice application;

[0145] Specifically, the first microservice is determined by the native microservice application from a node list based on service information of the target service, where the service information may be a service call policy. The native microservice application may obtain the node list periodically, and there is no fixed time sequence associated with triggering the service call request.

[0146] Step S503: The sidecar obtains the service information of the target service from the service call request.

[0147] Specifically, the sidecar determines the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service ports of the first microservice application.

[0148] Step S504: The sidecar forwards the service call request to the target service port of the first microservice application;

[0149] Step S505: The first microservice application sends the service call result to the sidecar through the target service port;

[0150] In step S506, the sidecar sends the service call result to the native microservice application.

[0151] In some embodiments, if the second microservice application is a migrated microservice application, the service call request includes node information of the first node, which is obtained by the second node from the service grid registration center.

[0152] Specifically, the second microservice application is a migrated microservice application, and the second node has a sidecar corresponding to the second microservice application. The first node is determined by the second node based on the service information of the target service after obtaining a node list from the service grid registry. The service information may be the invocation policy of the target service.

[0153] For example, the communication process of the second microservice application initiating a target service call request is as follows: Figure 6 The steps shown are as follows. The first microservice application is on the first node, which includes a first sidecar corresponding to the first microservice application. The second microservice application and the corresponding second sidecar are on the second node. The steps of this process are as follows:

[0154] Step S601: The second microservice application obtains a node list of the target service from the service grid registration center through the second sidecar;

[0155] Specifically, the second microservice application obtains the node list of the target service from the service grid registration center through the second sidecar.

[0156] Step S602: The second microservice application triggers a service call request and sends the service call request to the first sidecar corresponding to the first microservice application through the second sidecar.

[0157] Specifically, the first microservice is determined by the second microservice application from a node list based on service information of the target service, where the service information may be a service call policy. The second microservice application may obtain the node list periodically, and there is no fixed time sequence associated with triggering the service call request.

[0158] Step S603: The first sidecar obtains service information of the target service requested from the service call request.

[0159] Specifically, the first sidecar determines the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service ports of the first microservice application.

[0160] Step S604: The first sidecar forwards the service call request to the target service port of the first microservice application;

[0161] Step S605: The first microservice application sends the call result to the first sidecar through the target service port;

[0162] Step S606: The first sidecar sends the call result to the second sidecar;

[0163] In step S607, the second sidecar sends the call result to the second microservice application.

[0164] In some embodiments, the heartbeat status of the first microservice application is monitored by a sidecar, and when the heartbeat status of the first microservice application is abnormal, an abnormal message is reported to the service mesh control plane, so that the service mesh control plane modifies the service status of the first microservice application in the microservice registration center.

[0165] Specifically, when the first microservice application is running, the sidecar sends a heartbeat to the service port of the first microservice application. If the heartbeat status of the first microservice application is abnormal, the sidecar reports the abnormality to the service mesh control plane. The service mesh control plane then modifies the service status of the first microservice application in the microservice registry, preventing the second microservice application from calling the first microservice application. Furthermore, the service mesh control plane monitors the microservice registry and the service status information subscribed to by the first microservice application in the service mesh registry. If the service status information subscribed to by the first microservice application changes, the service mesh control plane notifies the sidecar of the first microservice application to prevent the first microservice application from calling the first microservice application.

[0166] By detecting heartbeats through the sidecar, the security and accuracy of service calls are improved.

[0167] Based on the same technical concept, the embodiment of the present application provides a structural diagram of a migration device for a microservice application, which is applied to a first node, such as Figure 7 As shown, the apparatus 700 includes:

[0168] A startup module 701 is configured to start a first microservice application through a startup script, wherein the startup script includes an agent package;

[0169] A reading module 702 is configured to read the original configuration file of the first microservice application when running the proxy package;

[0170] A processing module 703 is configured to send the original configuration file to the service mesh control plane through the sidecar corresponding to the first microservice application, so that the service mesh control plane modifies the original configuration file into a target configuration file, where the target configuration file is used to configure the sidecar as a service proxy for the first microservice application.

[0171] The replacement module 704 is configured to receive the target configuration file sent by the service mesh control plane through the sidecar, and replace the original configuration file in the first microservice application with the target configuration file.

[0172] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0173] Optionally, the processing module 703 is specifically configured to:

[0174] The sidecar is also used to record the target configuration file.

[0175] Optionally, the processing module 703 is specifically configured to:

[0176] Receiving, through the sidecar, a service call request for the first microservice application sent by a second node, where the service call request is triggered by a second microservice application in the second node;

[0177] Obtaining service information of the target service requested to be called from the service call request through the sidecar, and determining the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service and the service port of the first microservice application;

[0178] Forwarding the service call request to the target service port through the sidecar;

[0179] The call result output by the target service port is sent to the second node through the sidecar.

[0180] Optionally, the processing module 703 is specifically configured to:

[0181] If the second microservice application supports a different communication protocol than the first microservice application, the service call request is forwarded to the target service port by the sidecar using the communication protocol supported by the first microservice application.

[0182] Optionally, the processing module 703 is specifically configured to:

[0183] If the second microservice application is a native microservice application, the node information of the first node included in the service call request is obtained by the second node from the microservice registration center;

[0184] If the second microservice application is a migrated microservice application, the service call request includes node information of the first node, which is obtained by the second node from the service grid registration center.

[0185] Optionally, the processing module 703 is specifically configured to:

[0186] The heartbeat status of the first microservice application is monitored by the sidecar, and when the heartbeat status of the first microservice application is abnormal, an abnormal message is reported to the service grid control plane, so that the service grid control plane modifies the service status of the first microservice application in the microservice registration center.

[0187] Based on the same technical concept, the embodiment of the present application provides a structural diagram of a migration device for a microservice application, which is applied to the control plane of the service grid, such as Figure 8 As shown, the apparatus 800 includes:

[0188] An acquisition module 801 is configured to receive an original configuration file sent by a node through a sidecar corresponding to a first microservice application, where the first microservice application is started by the node through a startup script, and the original configuration file is read by the node when running an agent package included in the startup script;

[0189] A processing module 802 is configured to modify the original configuration file into a target configuration file, where the target configuration file is used to configure the sidecar as a service proxy for the first microservice application;

[0190] The processing module 802 is further configured to send the target configuration file to the sidecar, so that the node replaces the original configuration file in the first microservice application with the target configuration file.

[0191] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0192] Optionally, the processing module 802 is specifically configured to:

[0193] The communication mode recorded in the original configuration file is modified to directly connect to the peer end, the address of the sidecar is set to the peer end address, and the listening mode of the service port of the first microservice application recorded is modified to sidecar listening to obtain the target configuration file.

[0194] Optionally, the processing module 802 is specifically configured to:

[0195] Obtaining service information of at least one service provided by the first microservice application from the target configuration file;

[0196] Register the service information of each provided service and the port of the sidecar to the microservice registry and the service mesh registry.

[0197] Optionally, the processing module 802 is specifically configured to:

[0198] Obtaining service information of at least one service subscribed to by the first microservice application from the target configuration file;

[0199] For each subscribed service, based on the service information of the subscribed service, obtain a list of nodes that provide the subscribed service from the microservice registry and the service grid registry respectively;

[0200] A routing table is obtained based on service information of at least one subscribed service and a corresponding node list.

[0201] Optionally, the processing module 802 is specifically configured to:

[0202] Send the routing table to the sidecar.

[0203] By adding a proxy package to the startup script of the microservice application, the microservice application is migrated to a non-transparent proxy service grid to enable sidecar monitoring of the traffic of the microservice application. There is no need to modify the service call code of the microservice application or the logic of calling the peer service node, which reduces the cost of microservice application migration and improves the efficiency of migration.

[0204] Based on the same technical concept, the embodiment of the present application provides a computer device, such as Figure 9 As shown, it includes at least one processor 901 and a memory 902 connected to the at least one processor. The specific connection medium between the processor 901 and the memory 902 is not limited in the embodiment of the present application. Figure 9 For example, the processor 901 and the memory 902 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, and the like.

[0205] In an embodiment of the present application, the memory 902 stores instructions that can be executed by at least one processor 901. The at least one processor 901 can execute the steps of the above-mentioned microservice application migration method by executing the instructions stored in the memory 902.

[0206] Among them, the processor 901 is the control center of the computer device, which can use various interfaces and lines to connect various parts of the computer device, and realize the migration of microservice applications by running or executing instructions stored in the memory 902 and calling data stored in the memory 902. Optionally, the processor 901 may include one or more processing units. The processor 901 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, etc., and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 901. In some embodiments, the processor 901 and the memory 902 may be implemented on the same chip. In some embodiments, they may also be implemented separately on independent chips.

[0207] The processor 901 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0208] The memory 902 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 902 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 902 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 902 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0209] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program that can be executed by a computer device. When the program runs on the computer device, the computer device executes the steps of the above-mentioned microservice application migration method.

[0210] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0211] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0212] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0213] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0214] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A method for migrating a microservice application, applied to a first node, characterized in that: include: Start the first microservice application through a startup script, where the startup script includes an agent package; When running the agent package, reading the original configuration file of the first microservice application; The original configuration file is sent to the service mesh control plane through the sidecar corresponding to the first microservice application, so that the service mesh control plane modifies the communication mode recorded in the original configuration file to a direct connection to the peer end, sets the address of the sidecar to the peer end address, and modifies the listening mode of the service port of the first microservice application recorded in the original configuration file to sidecar listening, thereby obtaining a target configuration file. The target configuration file is used to configure the sidecar as a service proxy for the first microservice application. The target configuration file sent by the service mesh control plane is received by the sidecar, and the original configuration file in the first microservice application is replaced with the target configuration file.

2. The method according to claim 1, wherein The sidecar is also used to record the target configuration file.

3. The method according to claim 1, wherein After replacing the original configuration file in the first microservice application with the target configuration file, the method further includes: Receiving, through the sidecar, a service call request for the first microservice application sent by a second node, where the service call request is triggered by a second microservice application in the second node; Obtaining service information of the target service requested to be called from the service call request through the sidecar, and determining the target service port corresponding to the target service based on the service information of the target service and the mapping relationship between the service and the service port of the first microservice application; Forwarding the service call request to the target service port through the sidecar; The call result output by the target service port is sent to the second node through the sidecar.

4. The method according to claim 3, wherein Forwarding the service call request to the target service port through the sidecar includes: If the second microservice application supports a different communication protocol than the first microservice application, the service call request is forwarded to the target service port by the sidecar using the communication protocol supported by the first microservice application.

5. The method according to claim 3, wherein Also includes: If the second microservice application is a native microservice application, the node information of the first node included in the service call request is obtained by the second node from the microservice registration center; If the second microservice application is a migrated microservice application, the service call request includes node information of the first node, which is obtained by the second node from the service grid registration center.

6. The method according to claim 1, wherein Also includes: The heartbeat status of the first microservice application is monitored by the sidecar, and when the heartbeat status of the first microservice application is abnormal, an abnormal message is reported to the service grid control plane, so that the service grid control plane modifies the service status of the first microservice application in the microservice registration center.

7. A method for migrating microservice applications, applied to a service grid control plane, characterized in that: include: The receiving node sends an original configuration file through a sidecar corresponding to a first microservice application, where the first microservice application is started by the node through a startup script, and the original configuration file is read by the node when running an agent package included in the startup script; Modify the communication mode recorded in the original configuration file to directly connect to the peer end, set the address of the sidecar to the peer end address, and modify the listening mode of the service port of the first microservice application recorded to sidecar listening, and obtain a target configuration file. The target configuration file is used to configure the sidecar as a service proxy for the first microservice application; The target configuration file is sent to the sidecar, so that the node replaces the original configuration file in the first microservice application with the target configuration file.

8. The method according to claim 7, wherein Also includes: Obtaining service information of at least one service provided by the first microservice application from the target configuration file; Register the service information of each provided service and the port of the sidecar to the microservice registry and the service mesh registry.

9. The method according to claim 7, wherein Also includes: Obtaining service information of at least one service subscribed to by the first microservice application from the target configuration file; For each subscribed service, based on the service information of the subscribed service, obtain a list of nodes that provide the subscribed service from the first microservice registry and the service grid registry respectively; A routing table is obtained based on service information of at least one subscribed service and a corresponding node list.

10. The method according to claim 9, wherein After obtaining the routing table based on the service information of at least one subscribed service and the corresponding node list, the method further includes: Send the routing table to the sidecar.

11. A migration device for a microservice application, applied to a first node, characterized in that: include: A startup module, configured to start the first microservice application through a startup script, wherein the startup script includes an agent package; A reading module, configured to read an original configuration file of the first microservice application when running the proxy package; A processing module is configured to send the original configuration file to the service mesh control plane through the sidecar corresponding to the first microservice application, so that the service mesh control plane modifies the communication mode recorded in the original configuration file to a direct connection to the peer, sets the address of the sidecar to the peer address, and modifies the listening mode of the service port of the first microservice application recorded in the original configuration file to sidecar listening, thereby obtaining a target configuration file, wherein the target configuration file is used to configure the sidecar as a service proxy for the first microservice application; A replacement module is configured to receive the target configuration file sent by the service mesh control plane through the sidecar, and replace the original configuration file in the first microservice application with the target configuration file.

12. A migration device for microservice applications, applied to a service grid control plane, characterized in that: include: an acquisition module, configured to receive an original configuration file sent by a node through a sidecar corresponding to a first microservice application, where the first microservice application is started by the node through a startup script, and the original configuration file is read by the node when running an agent package included in the startup script; A processing module is configured to modify the communication mode recorded in the original configuration file to a direct connection to the peer end, set the address of the sidecar to the peer end address, and modify the listening mode of the service port of the first microservice application recorded to sidecar listening, thereby obtaining a target configuration file, wherein the target configuration file is used to configure the sidecar as a service proxy for the first microservice application; The processing module is further configured to send the target configuration file to the sidecar, so that the node replaces the original configuration file in the first microservice application with the target configuration file.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 1 to 10 are implemented.

14. A computer-readable storage medium, characterized in that It stores a computer program that can be executed by a computer device. When the program is run on the computer device, the computer device executes the steps of any one of the methods according to claims 1 to 10.

Images