Micro-service deployment method and system supporting non-stop release and continuous delivery platform

Abstract

The invention provides a micro-service deployment method and system supporting non-stop release and a continuous delivery platform, and the method comprises the steps: receiving a version identification file corresponding to to-be-updated version data of a micro-service, selecting a part of service nodes in a first namespace currently running in a micro-service system to stop based on an elegant stop rule, and sending the selected part of service nodes to the micro-service system; switching and deploying the shutdown node to the second namespace; gateway dynamic routing switching is carried out to route the traffic to each service node of the second namespace; if the stable operation of the second namespace is confirmed, switching and deploying the remaining service nodes in the first namespace to the second namespace in sequence; according to the application, the problems of poor user experience, data loss and service unavailability caused by shutdown when the new version of the micro-service is released and the problems of complicated micro-service system development, compatibility need to be considered and tedious multi-version management caused by a non-shutdown mode can be solved at the same time, so that smooth upgrading and high availability of the micro-service system can be realized.

Description

Technical Field

[0001] The present application relates to the field of information processing technology, and in particular to a microservice deployment method, system, and continuous delivery platform that supports non-stop release. Background Art

[0002] With the widespread application of microservice architecture, the rapid iteration and stability assurance of microservice systems have become the focus of enterprise attention. However, traditional microservice system release methods usually include two types: downtime and non-downtime. Downtime release will cause the service to be unavailable for a short period of time, causing inconvenience to users and having a significant impact on business continuity. In a multi-node microservice system, downtime release is also prone to cause data loss, service anomalies and other problems, and cannot meet the enterprise's requirements for high availability and high reliability. The existing non-stop release method requires version number matching, and then routing and dependency matching based on the request version, which will lead to complex microservice system development, the need to consider compatibility, and cumbersome multi-version management.

[0003] Therefore, there is an urgent need to design a microservice deployment method that can simultaneously solve the problems of poor user experience, data loss, and service unavailability caused by downtime when a new version of a microservice is released, as well as the complex development of microservice systems caused by non-downtime, the need to consider compatibility, and the cumbersome management of multiple versions. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a microservice deployment method, system and continuous delivery platform that support non-stop release to eliminate or improve one or more defects existing in the prior art.

[0005] One aspect of the present application provides a microservice deployment method that supports non-stop release, including:

[0006] Receive a version identification file corresponding to the to-be-updated version data of the microservice, select a portion of service nodes from among the service nodes currently running in the first namespace of the microservice system for shutdown based on a preset graceful shutdown rule, and switch and deploy the service nodes currently in a shutdown state to a second namespace in the microservice system;

[0007] Performing dynamic gateway routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace;

[0008] If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirements, the remaining service nodes in the first namespace are switched and deployed to the second namespace in sequence.

[0009] In some embodiments of the present application, based on a preset graceful shutdown rule, a portion of service nodes are selected from each service node currently running in a first namespace in a microservice system for shutdown, and each of the service nodes currently in a shutdown state is switched and deployed to a second namespace in the microservice system, including:

[0010] A portion of the service nodes currently running in the first namespace of the microservice system are used as current target service nodes, and the shutdown scripts corresponding to the target service nodes are modified to preset safety shutdown signals, so that the applications corresponding to the target service nodes receive the safety shutdown signals and enter the shutdown preparation state and stop receiving new requests;

[0011] Based on the preset application program listener, each of the target service nodes that has entered the shutdown preparation state is monitored to execute a corresponding server shutdown event;

[0012] Invoke the closing method data of the custom thread pool in the application listener, so that each of the target service nodes completes its corresponding currently executing task;

[0013] Shut down the server instances corresponding to the target service nodes and rewrite the shutdown method data of the message queue and the scheduled task to complete the graceful shutdown of the target service nodes;

[0014] The startup scripts corresponding to the target service nodes are modified to switch and deploy the target service nodes to the second namespace in the microservice system.

[0015] In some embodiments of the present application, the performing dynamic gateway routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace so that each of the service nodes in the second namespace runs in the second namespace includes:

[0016] configuring a dynamic routing rule in the gateway based on the request header identifier in the version identifier file to route the current traffic to each of the service nodes in the second namespace through the request header identifier, so that each of the service nodes in the second namespace runs in the second namespace;

[0017] And, sending a default routing rule modification instruction based on the request header identifier in the version identification file to the gateway, so that the gateway modifies the default routing rule according to the request header identifier to route subsequent traffic to each of the service nodes in the second namespace based on the default routing rule.

[0018] In some embodiments of the present application, if it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirement, then switching each of the remaining service nodes in the first namespace to the second namespace in sequence includes:

[0019] If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirements, then based on the preset graceful shutdown rules, each of the remaining service nodes in the first namespace is shut down in turn, and the remaining service nodes in the first namespace that are currently in a shut down state are switched and deployed to the second namespace in the microservice system.

[0020] In some embodiments of the present application, the microservice deployment method supporting non-stop release also includes:

[0021] If abnormal state data is detected during the process of switching the service node to be deployed in the second namespace in the microservice system, a preset rollback operation is performed to switch the current traffic from each of the service nodes in the second namespace back to each of the service nodes in the first namespace.

[0022] In some embodiments of the present application, the microservice deployment method supporting non-stop release also includes:

[0023] Based on the preset running status verification rules, the running status of each of the service nodes in the second namespace is verified and the corresponding verification result data is output.

[0024] In some embodiments of the present application, before receiving the version identification file corresponding to the to-be-updated version data of the microservice, the method further includes:

[0025] Create a first namespace and a second namespace in the microservice system;

[0026] All service nodes in the initial state are deployed in the first namespace.

[0027] Another aspect of the present application provides a microservice deployment system that supports non-stop release, including:

[0028] A shutdown and switch deployment module is used to receive a version identification file corresponding to the to-be-updated version data of the microservice, select a portion of service nodes from among the service nodes currently running in the first namespace of the microservice system for shutdown based on a preset graceful shutdown rule, and switch and deploy each of the service nodes currently in a shutdown state to a second namespace in the microservice system;

[0029] A gateway dynamic routing switching module, configured to perform gateway dynamic routing switching based on the version identification file, so as to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace;

[0030] The full switching module is used to switch and deploy the remaining service nodes in the first namespace to the second namespace in sequence if it is confirmed that the service nodes in the second namespace currently meet the preset stable operation requirements.

[0031] A third aspect of the present application provides a continuous delivery platform, wherein the continuous delivery platform includes a microservice deployment system that supports non-stop release;

[0032] The microservice deployment system supporting non-stop release is used to execute the microservice deployment method supporting non-stop release based on a preset automation script.

[0033] A fourth aspect of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the microservice deployment method supporting non-stop release when executing the computer program.

[0034] A fifth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the microservice deployment method supporting non-stop release.

[0035] A sixth aspect of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the microservice deployment method that supports non-stop release.

[0036] The microservice deployment method that supports non-stop release provided in the present application receives a version identification file corresponding to the to-be-updated version data of the microservice, and based on a preset graceful shutdown rule, selects a portion of service nodes from each service node currently running in a first namespace in the microservice system for shutdown, and switches and deploys each of the service nodes that are currently in a shutdown state to a second namespace in the microservice system; performs dynamic gateway routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace; if it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirements, then the first namespace is switched to a second namespace. The remaining service nodes in the first namespace are switched to be deployed to the second namespace in turn, which can simultaneously solve the problems of poor user experience, data loss and service unavailability caused by downtime when a new version of the microservice is released, as well as the complex development of the microservice system, the need to consider compatibility and cumbersome multi-version management caused by the non-downtime method. It can enable new and old services to run in parallel, and can ensure that the normal operation of the existing microservice system is not affected when a new version of the microservice is released; it can also reduce manual intervention in the microservice deployment process, and can improve the stability and release efficiency of the microservice system; and it can give priority to completing the current task before the service is shut down, avoiding data loss or task interruption, and ensuring that the service node can be safely offline, thereby achieving smooth upgrades and high availability of the microservice system.

[0037] Additional advantages, purposes, and features of the present application will be partially described in the following description, and will become partially apparent to those skilled in the art after studying the following, or may be learned from the practice of the present application. The purposes and other advantages of the present application can be achieved and obtained by the structures specifically pointed out in the specification and the drawings.

[0038] Those skilled in the art will understand that the purposes and advantages that can be achieved by the present application are not limited to the above specific description, and the above and other purposes that can be achieved by the present application will be more clearly understood based on the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application, constitute a part of the present application, and do not constitute a limitation of the present application. The components in the drawings are not drawn to scale, but are only for the purpose of illustrating the principles of the present application. In order to facilitate the illustration and description of some parts of the present application, the corresponding parts in the drawings may be enlarged, that is, they may become larger relative to other components in the exemplary device actually manufactured according to the present application. In the drawings:

[0040] Figure 1This is a first flow chart of a microservice deployment method that supports non-stop release in one embodiment of the present application.

[0041] Figure 2 This is a second flow chart of a microservice deployment method that supports non-stop release in one embodiment of the present application.

[0042] Figure 3 This is a second flow chart of a microservice deployment method that supports non-stop release in one embodiment of the present application.

[0043] Figure 4 This is a structural diagram of a microservice deployment system that supports non-stop release in one embodiment of the present application.

[0044] Figure 5 Schematic diagram of the architecture of a continuous payment platform in one embodiment of the present application.

[0045] Figure 6 This is a schematic diagram of the execution logic of dual namespace isolation and gateway dynamic routing in an application example of this application. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the implementation modes and the accompanying drawings. Here, the illustrative implementation modes and descriptions of the present application are used to explain the present application, but are not intended to limit the present application.

[0047] It should also be noted here that in order to avoid obscuring the present application due to unnecessary details, only the structures and / or processing steps closely related to the scheme according to the present application are shown in the accompanying drawings, while other details that are not very relevant to the present application are omitted.

[0048] It should be emphasized that the term “include / comprises” when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0049] It should also be noted that, unless otherwise specified, the term “connection” herein may refer not only to a direct connection but also to an indirect connection involving an intermediate.

[0050] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. In the accompanying drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0051] In order to solve the problems of poor user experience, data loss and service unavailability caused by downtime when a new version of a microservice is released, as well as complex microservice system development, the need to consider compatibility and cumbersome multi-version management caused by a non-stop approach, the embodiments of the present application respectively provide a microservice deployment method that supports non-stop release, a microservice deployment system that supports non-stop release for executing the microservice deployment method that supports non-stop release, a continuous delivery platform, an electronic device, a computer-readable storage medium and a computer program product, which can achieve smooth upgrade and high availability of the microservice system.

[0052] The details are described in detail through the following examples.

[0053] Based on this, the embodiment of the present application provides a microservice deployment method that supports non-stop release, which can be implemented by a microservice deployment system that supports non-stop release. Figure 1 The microservice deployment method that supports non-stop release specifically includes the following contents:

[0054] Step 100: Receive a version identification file corresponding to the to-be-updated version data of the microservice, select a portion of service nodes from among the service nodes currently running in the first namespace of the microservice system for shutdown based on a preset graceful shutdown rule, and switch and deploy the service nodes currently in a shutdown state to a second namespace in the microservice system.

[0055] In one or more embodiments of the present application, graceful shutdown refers to notifying the application process to release the occupied resources to ensure that the application is shut down. Graceful shutdown rules can be manually set according to actual application needs, and then sent to the microservice deployment system that supports non-stop release for storage, so as to give priority to completing the current task before the service is shut down, avoid data loss or task interruption, and ensure that the service node can be safely offline; or, the graceful shutdown rules can also be implemented by introducing graceful shutdown components into the microservice system, giving priority to completing the current task before the service is shut down, avoiding data loss or task interruption, and ensuring that the service node can be safely offline. Among them, the version identification file is used to store the request header identification.

[0056] It can be understood that the first namespace and the second namespace are both set in the microservice system, the first namespace can be written as namespace-A; the second namespace can be written as namespace-B; the first namespace and the second namespace in the microservice system realize dual namespace isolation.

[0057] Step 200: Perform dynamic gateway routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace.

[0058] Step 300: If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirement, the remaining service nodes in the first namespace are switched and deployed to the second namespace in sequence.

[0059] In step 300, the stable operation requirements (i.e., data used to record the stable operation requirements) can be manually set according to actual application needs, and then sent to a microservice deployment system that supports non-stop release for storage, for example, to determine whether the amount of data corresponding to the execution of the service by each of the service nodes in the second namespace meets the preset data amount requirements within a preset time period.

[0060] From the above description, it can be seen that the microservice deployment method that supports non-stop release provided by the embodiment of the present application can simultaneously solve the problems of poor user experience, data loss and service unavailability caused by downtime when a new version of the microservice is released, as well as the complex development of the microservice system caused by the non-stop method, the need to consider compatibility and the cumbersome multi-version management. It can enable new and old services to run in parallel, and can ensure that the normal operation of the existing microservice system is not affected when a new version of the microservice is released; it can also reduce manual intervention in the microservice deployment process, and can improve the stability and release efficiency of the microservice system; and it can give priority to completing the current task before the service is shut down, avoid data loss or task interruption, and ensure that the service node can be safely offline, thereby achieving smooth upgrades and high availability of the microservice system.

[0061] In order to further improve the effectiveness and reliability of dual namespace isolation and graceful shutdown, in a microservice deployment method that supports non-stop release provided in an embodiment of the present application, see Figure 2 Step 100 of the microservice deployment method supporting non-stop release specifically includes the following contents:

[0062] Step 110: Take a portion of the service nodes currently running in the first namespace of the microservice system as the current target service nodes, and modify the shutdown script corresponding to each of the target service nodes to a preset safety shutdown signal, so that the application corresponding to each of the target service nodes receives the safety shutdown signal and enters the shutdown preparation state and stops receiving new requests.

[0063] Step 120: Based on a preset application monitor, each of the target service nodes that has entered the shutdown preparation state executes a corresponding server shutdown event.

[0064] Step 130: calling the closing method data of the custom thread pool in the application listener, so that each of the target service nodes completes its corresponding currently executing task.

[0065] Step 140: shut down the server instances corresponding to the target service nodes and rewrite the shutdown method data of the message queue and the scheduled task to complete the graceful shutdown of the target service nodes.

[0066] Step 150: modify the startup scripts corresponding to the target service nodes to switch and deploy the target service nodes to the second namespace in the microservice system.

[0067] In one example, the safety shutdown signal may refer to the KILL-15 shutdown signal, the server shutdown event may refer to the tomcat shutdown event, and the application listener may refer to the Tomcat Servlet listener. Specifically, the elegant shutdown is achieved by capturing the KILL-15 signal (terminating a program in the normal way), combining Tomcat personalized configuration and custom thread pool shutdown mechanism to achieve a smooth offline. Tomcat is an open source web server, mainly used for deploying Java web applications. It is characterized by high ease of use, good stability, wide compatibility, etc. It is suitable for Java web application deployment scenarios. The specific steps are as follows:

[0068] (1) Receiving KILL-15 shutdown signal:

[0069] Modify the shutdown script to KILL-15. After receiving the KILL-15 signal, the application enters the shutdown preparation state and stops receiving new requests.

[0070] (2)Tomcat Servlet Listener:

[0071] Add a personalized Servlet listener to monitor the tomcat shutdown event and perform cleanup work before shutdown.

[0072] (3) Close the custom thread pool:

[0073] Call the shutdown method of the custom thread pool in the listener to ensure that all executing tasks can be completed successfully.

[0074] (4)Tomcat server shutdown:

[0075] Gracefully shut down the Tomcat instance, ensuring that resources are released correctly.

[0076] (5) Rewrite the message queue and scheduled task closing method:

[0077] Rewrite the closing methods of message queues and scheduled tasks to ensure that unfinished tasks are handled correctly during shutdown.

[0078] In order to further improve the effectiveness and reliability of gateway dynamic routing switching, in a microservice deployment method that supports non-stop publishing provided in an embodiment of the present application, see Figure 2 , step 200 in the microservice deployment method supporting non-stop release specifically includes the following contents:

[0079] Step 210: Configure dynamic routing rules in the gateway based on the request header identifier in the version identification file to route the current traffic to each of the service nodes in the second namespace through the request header identifier, so that each of the service nodes in the second namespace runs in the second namespace.

[0080] Step 220: Send a default routing rule modification instruction based on the request header identifier in the version identification file to the gateway, so that the gateway modifies the default routing rule according to the request header identifier to route subsequent traffic to each of the service nodes in the second namespace based on the default routing rule.

[0081] Specifically, dynamic routing rules are configured in the gateway to direct traffic to the new version service node of namespace-B through the request header identifier. At the same time, the gateway is notified to modify the default routing rules so that subsequent traffic is routed to namespace-B.

[0082] In order to further improve the effectiveness and reliability of full switching, in a microservice deployment method that supports non-stop release provided in an embodiment of the present application, see Figure 2 Step 300 of the microservice deployment method supporting non-stop release specifically includes the following contents:

[0083] Step 310: If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirements, then based on the preset graceful shutdown rules, each of the remaining service nodes in the first namespace is shut down in turn, and the remaining service nodes in the first namespace that are currently in a shutdown state are switched and deployed to the second namespace in the microservice system.

[0084] In step 310, each of the remaining service nodes in the first namespace is shut down in turn, and each of the remaining service nodes in the first namespace that is currently in a shut down state is switched to be deployed in the second namespace in the microservice system, which can be done in the same way as shutting down the target service node, i.e. switching to the second namespace.

[0085] That is to say, once the new version of namespace-B is confirmed to be running stably, the microservice deployment system that supports non-stop release will gradually switch the remaining nodes from namespace-A to namespace-B to achieve a seamless transition.

[0086] In order to further improve the effectiveness and reliability of microservice deployment that supports non-stop release, in a microservice deployment method that supports non-stop release provided in an embodiment of the present application, see Figure 3 The microservice deployment method supporting non-stop release further specifically includes the following contents after step 300:

[0087] Step 400: If abnormal state data is detected during the process of switching the service node to be deployed in the second namespace in the microservice system, a preset rollback operation is performed to switch the current traffic from each of the service nodes in the second namespace back to each of the service nodes in the first namespace.

[0088] That is to say, if a problem is found during the switching process, the traffic can be quickly switched back to the old version of namespace-A to ensure the stability of the system. The rollback method can adopt the reverse process of the aforementioned control target service node shutdown and deployment switching.

[0089] In order to further improve the effectiveness and reliability of microservice deployment that supports non-stop release, in a microservice deployment method that supports non-stop release provided in an embodiment of the present application, see Figure 3 The microservice deployment method supporting non-stop release further specifically includes the following contents after step 300:

[0090] Step 500: Based on preset running status verification rules, the running status of each of the service nodes in the second namespace is verified and corresponding verification result data is output.

[0091] That is to say, after all service nodes are upgraded, the continuous delivery platform will verify the operating status of all services to ensure the smooth operation of the system.

[0092] In order to further improve the effectiveness and reliability of dual namespace isolation, in a microservice deployment method that supports non-stop release provided in an embodiment of the present application, see Figure 3The microservice deployment method supporting non-stop release also specifically includes the following contents before step 100:

[0093] Step 010: Create a first namespace and a second namespace in the microservice system.

[0094] Step 020: deploy all service nodes in the initial state in the first namespace.

[0095] From the software level, the present application also provides a microservice deployment system that supports non-stop release for executing all or part of the microservice deployment method that supports non-stop release, see Figure 4 The microservice deployment system that supports non-stop release specifically includes the following contents:

[0096] The shutdown and switch deployment module 10 is used to receive the version identification file corresponding to the to-be-updated version data of the microservice, select a part of the service nodes from among the service nodes currently running in the first namespace of the microservice system for shutdown based on the preset graceful shutdown rule, and switch and deploy the service nodes currently in the shutdown state to the second namespace of the microservice system;

[0097] A gateway dynamic routing switching module 20, configured to perform gateway dynamic routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace;

[0098] The full switching module 30 is used to switch and deploy the remaining service nodes in the first namespace to the second namespace in sequence if it is confirmed that the service nodes in the second namespace currently meet the preset stable operation requirements.

[0099] The embodiment of the microservice deployment system supporting non-stop release provided in the present application can be specifically used to execute the processing flow of the embodiment of the microservice deployment method supporting non-stop release in the above-mentioned embodiment. Its functions are not described in detail here, and reference can be made to the detailed description of the embodiment of the microservice deployment method supporting non-stop release.

[0100] The part of the microservice deployment system supporting non-stop release that supports non-stop release can be completed in the server or the client device. The specific selection can be based on the processing capability of the client device and the limitations of the user's usage scenario. This application is not limited to this. If all operations are completed in the client device, the client device may also include a processor for supporting the specific processing of the microservice deployment of non-stop release.

[0101] The client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side, and other implementation scenarios may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, or a server cluster consisting of multiple servers, or a server structure of a distributed device.

[0102] The server and the client device may communicate with each other using any suitable network protocol, including network protocols that have not yet been developed on the date of filing this application. The network protocols may include, for example, TCP / IP, UDP / IP, HTTP, HTTPS, etc. Of course, the network protocols may also include, for example, RPC (Remote Procedure Call Protocol) and REST (Representational State Transfer) protocols used on top of the above protocols.

[0103] From the above description, it can be seen that the microservice deployment system that supports non-stop release provided by the embodiment of the present application can simultaneously solve the problems of poor user experience, data loss and service unavailability caused by downtime when a new version of the microservice is released, as well as the complex development of the microservice system caused by the non-stop method, the need to consider compatibility and the cumbersome multi-version management. It can enable new and old services to run in parallel, and can ensure that the normal operation of the existing microservice system is not affected when a new version of the microservice is released; it can also reduce manual intervention in the microservice deployment process, and can improve the stability and release efficiency of the microservice system; and it can give priority to completing the current task before the service is shut down, avoid data loss or task interruption, and ensure that the service node can be safely offline, thereby achieving smooth upgrades and high availability of the microservice system.

[0104] Based on the above-mentioned embodiment of the microservice deployment system that supports non-stop release, the present application also provides an embodiment of a continuous delivery platform, see Figure 5 , the continuous delivery platform includes a microservice deployment system that supports non-stop releases;

[0105] The microservice deployment system supporting non-stop release is used to execute the aforementioned microservice deployment method supporting non-stop release based on a preset automation script.

[0106] The microservice deployment method supporting non-stop release adopted in the embodiment of the continuous delivery platform provided in the present application can be specifically used to execute the processing flow of the embodiment of the microservice deployment method supporting non-stop release in the above-mentioned embodiment. Its functions will not be repeated here, and reference can be made to the detailed description of the above-mentioned embodiment of the microservice deployment method supporting non-stop release.

[0107] That is to say, the embodiment of the present application can configure automated deployment scripts in the continuous delivery platform, including shutdown of services, rolling release, service status monitoring and other operations. And during the deployment process, the continuous delivery platform will first gracefully shut down the nodes one by one, that is, first process the current task, and then offline the node after completion, to avoid task interruption and data loss. And after all nodes (i.e., the abbreviation of service nodes) are upgraded, the continuous delivery platform will verify the operating status of all services to ensure the smooth operation of the system.

[0108] In order to further illustrate the above-mentioned microservice deployment method supporting non-stop release and the embodiment of the continuous delivery platform, the present application also provides a specific application example, which relates to the field of information technology, and in particular to a microservice deployment system and method supporting non-stop release, which is used to achieve smooth upgrade and high availability of the microservice system without affecting the normal operation of the system, making the development process simpler. The application example of this application achieves the above purpose through the following core technologies:

[0109] 1. Dual namespace isolation solution: The microservice nodes are divided into two namespaces, namespace-A and namespace-B. Through dynamic routing switching by the gateway, the new and old services can run in parallel, ensuring that the normal operation of the existing system is not affected when the new version is released.

[0110] 2. Automated deployment and continuous delivery: Use the continuous delivery platform to perform batch shutdown and rolling release of each microservice, execute the deployment process through automated scripts, reduce manual intervention, and improve system stability and release efficiency.

[0111] 3. Graceful shutdown mechanism: By introducing graceful shutdown components, current tasks are prioritized before the service is shut down to avoid data loss or task interruption, ensuring that the service node can be safely offline.

[0112] Based on this, see Figure 6 The microservice deployment method that supports non-stop release in this application instance specifically includes the following steps:

[0113] S1. Prepare dual namespace.

[0114] S2. The front-end request corresponding to the front-end version file carries version information, and updates the middleware and configuration files at the gateway, including the gateway request header routing rules and / or default routing rules.

[0115] S3. Use the automated deployment platform to shut down some nodes in namespace-A gracefully, modify the startup script to migrate services, and deploy these nodes to the new namespace namespace-B.

[0116] S4. Modify the front-end version file, notify the gateway to adjust the default routing strategy, and switch traffic.

[0117] S5. Process and deploy the remaining nodes, and the release is complete.

[0118] Among them, the application example of this application can ensure the smooth upgrade of microservices without downtime through the design of a dual namespace isolation solution; through the introduction of an elegant shutdown mechanism, the problems of task interruption and data loss during traditional shutdown processes are solved; through the combination of automated deployment and continuous delivery platforms, the release efficiency and security of the system are improved; through namespace switching, the requirements in the development process are reduced. The following describes the four parts of dual namespace isolation and gateway dynamic routing, automated deployment, version identification of the front-end and mobile terminals, and elegant shutdown respectively:

[0119] 1: Dual namespace isolation and gateway dynamic routing

[0120] The dual namespace isolation strategy is used to implement version switching of microservices without downtime. Through the AB switching mode, the production environment is configured with two namespaces (such as namespace-A and namespace-B), and the namespaces are rotated every time a new version is launched. The following are the detailed steps:

[0121] (1) Initial state configuration: Configure two namespaces in the production environment, named namespace-A and namespace-B. In the initial state, all service nodes are deployed in namespace-A.

[0122] (2) Update preparation: When a new version is released, some nodes are shut down and taken offline through graceful shutdown and automated deployment in step 2. The shut-down nodes are deployed to namespace-B by modifying the startup script and their working status is monitored.

[0123] (3) Dynamic routing switching of the gateway: Configure dynamic routing rules in the gateway to direct traffic to the new version service node of namespace-B through the request header identifier. At the same time, notify the gateway to modify the default routing rules so that subsequent traffic is routed to namespace-B.

[0124] (4) Full switch: Once the new version of namespace-B is confirmed to be running stably, the remaining nodes are gradually switched from namespace-A to namespace-B to achieve a seamless transition.

[0125] (5) Rollback mechanism: If a problem is found during the switching process, the traffic can be quickly switched back to the old version of namespace-A to ensure system stability.

[0126] 2: Automated deployment

[0127] (1) Configure automated deployment scripts in the continuous delivery platform, including service shutdown, rolling release, service status monitoring, and other operations.

[0128] (2) During the deployment process, the continuous delivery platform will gracefully shut down the nodes one by one, that is, it will process the current task first and then shut down the node after completion, to avoid task interruption and data loss.

[0129] (3) After all nodes are upgraded, the continuous delivery platform will verify the operating status of all services to ensure smooth operation of the system.

[0130] 3: Version identification of front-end and mobile terminal

[0131] (1) When packaging, the front-end adds a version identification file. The continuous delivery platform automatically modifies the file when publishing, so that the front-end request header carries identification information, and the gateway routes according to the identification.

[0132] (2) The mobile terminal cannot be updated in real time, so the default routing strategy is adopted, and the request is dynamically forwarded by promptly notifying the gateway to modify the default routing strategy.

[0133] 4: Graceful shutdown

[0134] Graceful shutdown is achieved by capturing the KILL-15 signal (terminating a program in a normal way), combining Tomcat's personalized configuration and custom thread pool shutdown mechanism to achieve a smooth offline. Tomcat is an open source web server, mainly used to deploy Java web applications. It is characterized by high ease of use, good stability, and wide compatibility. It is suitable for Java web application deployment scenarios. The specific steps are as follows:

[0135] (1) Receiving KILL-15 shutdown signal:

[0136] Modify the shutdown script to KILL-15. After the application receives the KILL-15 signal, it enters the shutdown preparation state and stops receiving new requests. The KILL-15 shutdown signal or command is used in the Linux system to send a SIGTERM signal to the target process to terminate it gracefully.

[0137] (2)Tomcat Servlet Listener:

[0138] Add a personalized Servlet listener to monitor the tomcat shutdown event and perform cleanup work before shutdown.

[0139] (3) Close the custom thread pool:

[0140] Call the shutdown method of the custom thread pool in the listener to ensure that all executing tasks can be completed successfully.

[0141] (4)Tomcat server shutdown:

[0142] Gracefully shut down the Tomcat instance to ensure that resources are released correctly. Tomcat is a web application server. Tomcat server is a free and open source web application server. It is a lightweight application server and is widely used in small and medium-sized systems and occasions with not many concurrent access users. It is the first choice for developing and debugging JSP programs.

[0143] (5) Rewrite the message queue and scheduled task closing method:

[0144] Rewrite the closing methods of message queues and scheduled tasks to ensure that unfinished tasks are handled correctly during shutdown.

[0145] In summary, the purpose of the application example of this application is to provide a microservice deployment system and method that supports non-stop release, so as to solve the problems of poor user experience, data loss, service unavailability, etc. caused by downtime in the prior art, and realize smooth upgrade and high availability of the microservice system. The application example of this application has the following beneficial effects:

[0146] 1. Achieve non-stop release: Through dual namespace isolation and gateway dynamic routing switching, the old and new versions of the service can run in parallel, achieving smooth system upgrades, reducing downtime, and improving system availability.

[0147] 2. Automated deployment: Use continuous delivery platforms and automated deployment tools to reduce the risk of errors caused by manual operations and improve the efficiency and reliability of system releases.

[0148] 3. Graceful shutdown: Prioritize the completion of current tasks before the service is shut down, avoiding task interruption and data loss, and ensuring high availability of the service.

[0149] The embodiment of the present application also provides an electronic device, which may include a processor, a memory, a receiver and a transmitter, wherein the processor is used to execute the microservice deployment method supporting non-stop release mentioned in the above embodiment, wherein the processor and the memory may be connected via a bus or other means, such as by bus connection. The receiver may be connected to the processor and the memory via wired or wireless means.

[0150] The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0151] As a non-transient computer-readable storage medium, the memory can be used to store non-transient software programs, non-transient computer executable programs and modules, such as the program instructions / modules corresponding to the microservice deployment method supporting non-stop release in the embodiment of the present application. The processor executes various functional applications and data processing of the processor by running the non-transient software programs, instructions and modules stored in the memory, that is, the microservice deployment method supporting non-stop release in the above method embodiment is implemented.

[0152] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0153] The one or more modules are stored in the memory, and when executed by the processor, the microservice deployment method supporting non-stop release in the embodiment is executed.

[0154] In some embodiments of the present application, the user equipment may include a processor, a memory, and a transceiver unit, which may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected through a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0155] As an implementation method, the functions of the receiver and the transmitter in the present application can be considered to be implemented through a transceiver circuit or a dedicated chip for transceiver, and the processor can be considered to be implemented through a dedicated processing chip, a processing circuit or a general chip.

[0156] As another implementation method, it is possible to use a general-purpose computer to implement the server provided in the embodiment of the present application, that is, to store the program code for implementing the functions of the processor, receiver, and transmitter in a memory, and the general-purpose processor implements the functions of the processor, receiver, and transmitter by executing the code in the memory.

[0157] The embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the steps of the aforementioned microservice deployment method supporting non-stop release are implemented. The computer-readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0158] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the aforementioned microservice deployment method that supports non-stop release.

[0159] It should be understood by those skilled in the art that the exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is specifically performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0160] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0161] In the present application, features described and / or illustrated for one embodiment may be used in the same manner or in a similar manner in one or more other embodiments, and / or combined with features of other embodiments or replace features of other embodiments.

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

Claims

1. A microservice deployment method that supports non-stop release, characterized in that: include: Receive a version identification file corresponding to the to-be-updated version data of the microservice, select a portion of service nodes from among the service nodes currently running in the first namespace of the microservice system for shutdown based on a preset graceful shutdown rule, and switch and deploy the service nodes currently in a shutdown state to a second namespace in the microservice system; Performing dynamic gateway routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace; If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirements, the remaining service nodes in the first namespace are switched and deployed to the second namespace in sequence.

2. The microservice deployment method supporting non-stop release according to claim 1, characterized in that: The method of selecting a portion of service nodes from among the service nodes currently running in the first namespace in the microservice system for shutdown based on the preset graceful shutdown rule, and switching and deploying the service nodes currently in the shutdown state to the second namespace in the microservice system, includes: A portion of the service nodes currently running in the first namespace of the microservice system are used as current target service nodes, and the shutdown scripts corresponding to the target service nodes are modified to preset safety shutdown signals, so that the applications corresponding to the target service nodes receive the safety shutdown signals and enter the shutdown preparation state and stop receiving new requests; Based on the preset application program listener, each of the target service nodes that has entered the shutdown preparation state is monitored to execute a corresponding server shutdown event; Invoke the closing method data of the custom thread pool in the application listener, so that each of the target service nodes completes its corresponding currently executing task; Shut down the server instances corresponding to the target service nodes and rewrite the shutdown method data of the message queue and the scheduled task to complete the graceful shutdown of the target service nodes; The startup scripts corresponding to the target service nodes are modified to switch and deploy the target service nodes to the second namespace in the microservice system.

3. The microservice deployment method supporting non-stop release according to claim 1 is characterized in that: The performing dynamic gateway routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace so that each of the service nodes in the second namespace runs in the second namespace includes: configuring a dynamic routing rule in the gateway based on the request header identifier in the version identifier file to route the current traffic to each of the service nodes in the second namespace through the request header identifier, so that each of the service nodes in the second namespace runs in the second namespace; And, sending a default routing rule modification instruction based on the request header identifier in the version identification file to the gateway, so that the gateway modifies the default routing rule according to the request header identifier to route subsequent traffic to each of the service nodes in the second namespace based on the default routing rule.

4. The microservice deployment method supporting non-stop release according to claim 1, characterized in that: If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirement, then switching each of the remaining service nodes in the first namespace to the second namespace in sequence includes: If it is confirmed that each of the service nodes in the second namespace currently meets the preset stable operation requirements, then based on the preset graceful shutdown rules, each of the remaining service nodes in the first namespace is shut down in turn, and the remaining service nodes in the first namespace that are currently in a shut down state are switched and deployed to the second namespace in the microservice system.

5. The microservice deployment method supporting non-stop release according to claim 1, characterized in that: Also includes: If abnormal state data is detected during the process of switching the service node to be deployed in the second namespace in the microservice system, a preset rollback operation is performed to switch the current traffic from each of the service nodes in the second namespace back to each of the service nodes in the first namespace.

6. The microservice deployment method supporting non-stop release according to claim 1, characterized in that: Also includes: Based on the preset running status verification rules, the running status of each of the service nodes in the second namespace is verified and the corresponding verification result data is output.

7. The microservice deployment method supporting non-stop release according to claim 1, characterized in that: Before receiving the version identification file corresponding to the to-be-updated version data of the microservice, the method further includes: Create a first namespace and a second namespace in the microservice system; All service nodes in the initial state are deployed in the first namespace.

8. A microservice deployment system that supports non-stop release, characterized in that: include: A shutdown and switch deployment module is used to receive a version identification file corresponding to the to-be-updated version data of the microservice, select a portion of service nodes from among the service nodes currently running in the first namespace of the microservice system for shutdown based on a preset graceful shutdown rule, and switch and deploy each of the service nodes currently in a shutdown state to a second namespace in the microservice system; A gateway dynamic routing switching module, used for performing gateway dynamic routing switching based on the version identification file to route traffic to each of the service nodes in the second namespace, so that each of the service nodes in the second namespace runs in the second namespace; The full switching module is used to switch and deploy the remaining service nodes in the first namespace to the second namespace in sequence if it is confirmed that the service nodes in the second namespace currently meet the preset stable operation requirements.

9. A continuous delivery platform, characterized in that: The continuous delivery platform includes a microservice deployment system that supports non-stop releases; The microservice deployment system supporting non-stop release is used to execute the microservice deployment method supporting non-stop release as described in any one of claims 1 to 7 based on a preset automation script.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the microservice deployment method supporting non-stop release as described in any one of claims 1 to 7 is implemented.

Images