Micro-service management method and system

Abstract

The invention provides a micro-service management method and system, and the method comprises the steps: analyzing a target deployment package, writing an operation program file obtained through analysis into a specified program operation directory of an operation system, and writing service assembly information indicated by the operation program file into a preset deployment configuration file, obtaining an updated preset deployment configuration file; creating a target service instance corresponding to the micro-service to be deployed; writing an environment variable corresponding to the to-be-deployed micro-service into an operation system and writing service instance information corresponding to a target service instance into the updated preset deployment configuration file to obtain a target deployment configuration file; and adding the deployed micro-service to the micro-service deployment list to complete the deployment process of the micro-service to be deployed. Through deployment generality analysis of different micro-services, a set of universal deployment templates is designed, the deployment requirements of various micro-services can be met, the deployment and unloading processes are greatly simplified, and the consistency and accuracy of deployment and unloading are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservice management, and particularly relates to a microservice management method and system. BACKGROUND

[0002] In the deployment scheme of microservices provided by the prior art, the deployment scheme based on a container orchestration tool is generally used, and specifically, Kubernetes is used as a representative. Kubernetes is an open source container orchestration engine that can automatically deploy, expand and manage containerized applications. When deploying microservices, developers package each microservice and its dependencies into a Docker container image, and then run one or more closely related containers through a Pod (the smallest deployment unit) resource object of Kubernetes. Kubernetes manages the Pod through labels and selectors, and a service resource provides a stable network endpoint for exposing a group of Pods to other services or external clients. For example, in a large e-commerce system, a commodity display microservice, an order processing microservice and a payment microservice are packaged into container images and deployed in a cluster through Kubernetes, so that efficient operation and flexible expansion of the services are achieved.

[0003] In the microservice deployment process provided by the prior art, although the container orchestration tools such as Kubernetes provide powerful functions, the deployment and configuration process is still complex, various dependent software required by Kubernetes needs to be installed and configured, lightweight deployment cannot be achieved, and the process is not friendly to non-professional operation and maintenance personnel. Therefore, the entire deployment process needs to be completed by professional personnel, which increases the operation and maintenance management cost of microservices. SUMMARY

[0004] Therefore, the purpose of the present application is to at least provide a microservice management method and system. Through deployment commonality analysis of different microservices, a general deployment template is designed, which can adapt to the deployment requirements of various microservices, greatly simplifies the deployment and uninstallation processes, and improves the consistency and accuracy of the deployment and uninstallation.

[0005] The present application mainly includes the following aspects: In a first aspect, embodiments of this application provide a microservice management method applied to management services. The method includes: importing a target deployment package corresponding to a microservice to be deployed into a corresponding runtime system. The target deployment package is an information data packet carrying the runtime program file corresponding to the microservice to be deployed, created based on a general deployment template. The general deployment template is created based on a general deployment configuration object abstracted from different microservices. The target deployment package is parsed, and the parsed runtime file is written to a specified program runtime directory of the runtime system, and the service component information indicated by the runtime file is written to a preset deployment configuration file to obtain an updated preset deployment configuration file. A target service instance corresponding to the microservice to be deployed is created. The environment variables corresponding to the microservice to be deployed are written to the runtime system, and the service instance information corresponding to the target service instance is written to the updated preset deployment configuration file to obtain a target deployment configuration file. The deployed microservice is added to the microservice deployment list to complete the deployment process of the microservice to be deployed.

[0006] In one possible implementation, the deployment package corresponding to the microservice to be deployed is created as follows: The microservice deployment interface is invoked, which provides a deployment package creation control; in response to a selection operation performed on the deployment package creation control, a deployment package configuration interface is displayed, which provides a general deployment template, which includes multiple general deployment configuration objects; according to the given deployment package format, multiple program files corresponding to the microservice to be deployed are respectively filled into the corresponding general deployment configuration objects to obtain the deployment package corresponding to the microservice to be deployed.

[0007] In one possible implementation, the method further includes: determining whether the target deployment package conforms to a given deployment package format before parsing the runtime files in the target deployment package; if the target deployment package conforms to the given deployment package format, parsing the runtime files in the target deployment package is performed, and the parsed service component information is written to the specified program directory in the preset deployment configuration file; if the target deployment package does not conform to the given deployment package format, the deployment process of the microservice to be deployed is exited and a deployment error message is generated.

[0008] In one possible implementation, the method further includes: obtaining service execution action parameters and passing them to the microservice launcher; parsing the service execution action parameters using the microservice launcher to obtain the service identifier and service execution action; if the service execution action is to start, reading service instance information from the target deployment configuration file corresponding to the target microservice indicated by the service identifier; checking whether the dependent service corresponding to the target microservice has been started based on the service dependency relationship described by the service instance information; if the dependent service has not been started, starting the dependent service, and after the dependent service is started, triggering the startup process for the target microservice to complete the startup of the target microservice; if the dependent service has been started, directly triggering the startup process for the target microservice to complete the startup of the target microservice.

[0009] In one possible implementation, service operation parameters for each microservice in the microservice deployment list are generated as follows: the corresponding service startup method is read from the target deployment configuration file corresponding to the microservice; if the service startup method is automatic startup, the corresponding service startup parameters are generated directly; if the service startup method is manual startup, the service startup parameters for the microservice are generated in response to the startup operation performed on the microservice in the microservice deployment list.

[0010] In one possible implementation, the startup of the target microservice is accomplished as follows: The service component corresponding to the target microservice is loaded using reflection, based on the component information described by the service instance information corresponding to the target microservice; the service component corresponding to the target microservice is initialized, and the initialization result is determined; if the initialization is successful, the target microservice is registered with the service registry and a service launch event is generated after registration; in response to the service launch event, the target microservice is updated to the service registration list; if the initialization fails, the startup process for the target microservice ends.

[0011] In one possible implementation, before initializing the service components corresponding to the target microservice, the method further includes: after triggering the startup process of the target microservice, starting the health check service corresponding to the target microservice; continuously sending health status query requests to the health check service corresponding to the target microservice within a preset waiting time; if a health feedback result is received within the preset waiting time, and the health feedback result indicates that the microservice has passed the health check, then initializing the service components corresponding to the target microservice; if a health feedback result is received within the preset waiting time, and the health feedback result indicates that the microservice has failed the health check, or if no health feedback result is received within the preset waiting time, then ending the startup process of the target microservice.

[0012] In one possible implementation, the method further includes: obtaining service operation parameters and passing them to the microservice launcher; parsing the service operation parameters using the microservice launcher to obtain the service identifier and service operation; if the service operation is to stop, controlling the target microservice indicated by the service identifier to enter a graceful shutdown mechanism, wherein the graceful shutdown mechanism includes: stopping the reception of new business processing requests and completing the processing of currently executing business processing requests, shutting down the running resources corresponding to the target microservice, and generating an offline trigger event; obtaining the offline trigger event fed back by the target microservice under the graceful shutdown mechanism; responding to the offline trigger event, determining whether the target microservice is still running within a preset timeout period; if the target microservice is still running within the preset timeout period, forcibly stopping the target microservice and generating a forced offline event for the target microservice; if the target microservice remains stopped within the preset timeout period, generating an offline notification event for the target microservice; responding to the forced offline event or offline notification event for the target microservice, removing the target microservice from the service registry and updating the service registry.

[0013] In one possible implementation, the method further includes: in response to an uninstallation request for a target microservice in the microservice deployment list, determining whether the target microservice is in a running state; if the target microservice is in a running state, ending the uninstallation of the target microservice and generating a service running prompt message; if the target microservice is not in a running state, uninstalling the service instance corresponding to the target microservice, deleting the environment variables of the target microservice in the running system, updating the deployment status in the deployment configuration file corresponding to the target microservice to a non-deployed state; deleting the service instance configuration information in the deployment configuration file corresponding to the target microservice and the running program file in the specified program running directory, thus completing the uninstallation of the target microservice.

[0014] Secondly, this application also provides a microservice management system, which includes multiple microservices and a management service. The management service is applied to any of the microservice management methods provided in the above embodiments. This application provides a microservice management method and system, comprising: importing a target deployment package corresponding to a microservice to be deployed into a corresponding runtime system; the target deployment package being an information data packet carrying the runtime program file corresponding to the microservice to be deployed, created based on a general deployment template; the general deployment template being created based on a general deployment configuration object abstracted from different microservices; parsing the target deployment package, writing the parsed runtime file into a specified program runtime directory of the runtime system, and writing the service component information indicated by the runtime file into a preset deployment configuration file to obtain an updated preset deployment configuration file; creating a target service instance corresponding to the microservice to be deployed; writing the environment variables corresponding to the microservice to be deployed into the runtime system and writing the service instance information corresponding to the target service instance into the updated preset deployment configuration file to obtain a target deployment configuration file; and adding the deployed microservice to the microservice deployment list to complete the deployment process of the microservice to be deployed. Through commonalities analysis of deployments of different microservices, a set of general deployment templates is designed, which can adapt to the deployment needs of various microservices, greatly simplifying the deployment and uninstallation process and improving the consistency and accuracy of deployment and uninstallation.

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart of a microservice management method provided in an embodiment of this application is shown; Figure 2 This document shows one of the flowcharts of a microservice startup method provided in an embodiment of this application; Figure 3 This document shows a second flowchart of a microservice startup method provided in an embodiment of this application. Figure 4 A flowchart of a microservice termination method provided in an embodiment of this application is shown; Figure 5 A flowchart of a microservice instance uninstallation method provided in an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0019] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In today's software development field, microservice architecture is widely used due to its advantages such as flexibility and scalability. As businesses continue to grow and systems expand, the effective management of microservice collections becomes crucial, especially in areas such as microservice deployment, startup, shutdown, service registration and discovery, and uninstallation.

[0021] In the process of managing the entire lifecycle of microservices, existing technical solutions mainly adopt the following technical means: 1) For microservice deployment, existing technologies generally adopt deployment schemes based on container orchestration tools: Kubernetes, for example, is an open-source container orchestration engine that automates the deployment, scaling, and management of containerized applications. When deploying microservices, developers package each microservice and its dependencies into Docker container images, and then run one or more closely related containers through Kubernetes Pod resource objects. Kubernetes manages Pods through labels and selectors, while service resources provide a stable network endpoint for exposing a group of Pods to other services or external clients. For example, in a large e-commerce system, product display microservices, order processing microservices, and payment microservices are packaged into container images and deployed in a cluster using Kubernetes, achieving efficient service operation and flexible scaling.

[0022] 2) For the microservice registration and invocation process, existing technologies generally provide management solutions based on service registration and discovery centers: service registration and discovery components such as Consul and Eureka are widely used. Taking Eureka as an example, when a microservice starts up, it registers its service instance information with the Eureka Server, including service name, IP address, port number, etc. When other microservices call the target service, they obtain a list of available service instances from the Eureka Server and select a service instance to invoke. At the same time, the Eureka Server periodically performs heartbeat checks with each service instance. If a service instance does not respond to the heartbeat within a certain period of time, the Eureka Server will remove it from the service registry.

[0023] 3) For managing the startup, shutdown, and uninstallation of microservices, existing technologies generally rely on traditional scripting methods. This involves developers writing shell scripts or batch scripts to start, stop, and uninstall microservices via command-line operations. For startup, the script executes a series of commands to start the microservice's runtime environment, such as starting the Java Virtual Machine (JVM) and loading the microservice's application code. It may also configure environment variables and database connections. Stopping typically involves finding the microservice's process ID (PID) and then terminating the process using operating system commands (such as the `kill` command). Uninstallation generally involves deleting microservice-related files and directories.

[0024] The existing technologies for managing microservices at each stage have at least the following shortcomings: A1. High deployment complexity: Although container orchestration tools such as Kubernetes provide powerful functions, the deployment and configuration process is still complex. It requires the installation and configuration of various dependent software required by Kubernetes, which cannot be lightweight, increases the complexity of microservice deployment, and is not friendly to non-professionals.

[0025] A2. The inflexibility and unreliability of microservice startup, shutdown, and uninstallation operations: Traditional script-based methods lack fine-grained management of the microservice lifecycle. During startup, it's difficult to start microservices in the order of dependencies, easily leading to startup failures due to incomplete dependency services. Stopping operations may result in forced process termination, causing data loss or transaction inconsistencies. Uninstallation operations may also leave behind some files or configurations, affecting system cleanliness and subsequent maintenance. Moreover, script-based methods are difficult to adapt to differences in different environments (such as development, testing, and production environments), requiring extensive manual adjustments (the entire lifecycle management process).

[0026] Based on this, embodiments of this application provide a microservice management method and system. Through analysis of the commonalities in the deployment of different microservices, a universal deployment template is designed, which can adapt to the deployment needs of various microservices, greatly simplifying the deployment and uninstallation process and improving the consistency and accuracy of deployment and uninstallation, as detailed below: Please see Figure 1 , Figure 1 A flowchart illustrating a microservice management method provided in an embodiment of this application is shown. Figure 1 As shown in the embodiments of this application, the method provided is applied to the management service in a microservice management system, and specifically includes the following steps: S100. Import the target deployment package corresponding to the microservice to be deployed into the corresponding running system.

[0027] The target deployment package is an information data package that carries the running program files corresponding to the microservice to be deployed, created based on a general deployment template. The general deployment template is created based on a general deployment configuration object abstracted from different microservices.

[0028] S101. Parse the target deployment package and write the parsed executable file to the specified program execution directory of the running system.

[0029] S102. Write the service component information indicated by the running program file into the preset deployment configuration file to obtain the updated preset deployment configuration file.

[0030] S103. Create the target service instance corresponding to the microservice to be deployed.

[0031] S104. Write the environment variables corresponding to the microservice to be deployed into the running system of the microservice to be deployed.

[0032] S105. Write the service instance information corresponding to the target service instance into the updated preset deployment configuration file to obtain the target deployment configuration file.

[0033] S106. Add the deployed microservices to the microservice deployment list to complete the deployment process for the microservices to be deployed.

[0034] In step S100, the management service of this application provides a deployment package template creation interface. The deployment package template creation interface includes a template creation identifier. In response to the selection operation performed on the template creation identifier, a deployment package template configuration interface is displayed. Multiple general deployment configuration objects are added to the deployment package template configuration interface. The multiple general configuration objects are abstracted by the developers for different microservices. Specifically, the multiple general deployment configuration objects include, but are not limited to, at least one of the following: network configuration objects (such as service IP, port) and environment variable configuration objects. Each general configuration object is associated with a corresponding deployment format (the deployment format can be a program file belonging to the general configuration object that is specified in advance). The deployment package template configuration interface also includes a template generation control. In response to the selection operation performed on the template generation control, a general deployment template is generated.

[0035] In a preferred embodiment, step S100 further includes: The microservice deployment interface is invoked. The microservice deployment interface provides a deployment package creation control. In response to the selection operation of the deployment package creation control, the deployment package configuration interface is displayed. The deployment package configuration interface displays a general deployment template. According to the given deployment package format, the multiple program files corresponding to the microservice to be deployed are respectively filled into the general deployment configuration object corresponding to the general deployment template to obtain the deployment package corresponding to the microservice to be deployed.

[0036] In practical implementation, the management service of this application also provides a microservice deployment interface. By performing relevant operations on the microservice deployment interface, a deployment package for the microservice to be deployed can be created. The given deployment package format includes the deployment format corresponding to each general deployment configuration object. During the process of filling the program files into the general deployment template, the type of the program files is filled into the corresponding general deployment configuration object. In a preferred embodiment, before performing step S101, the method provided in this application further includes: Determine whether the target deployment package conforms to the given deployment package format. If the target deployment package conforms to the given deployment package format, proceed to step S101. If the target deployment package does not conform to the given deployment package format, exit the deployment process of the microservice to be deployed and generate a deployment error message.

[0037] Specifically, before executing step S101, this application first verifies whether the filling of each program file is correct according to the deployment format corresponding to each general deployment configuration object. If any program file is filled incorrectly or there are missing / unfilled program files, it is determined that the target deployment package does not conform to the given deployment package format, and the deployment process of the microservice to be deployed is exited.

[0038] In a preferred embodiment, in steps S101 to S102, the management service of this application also provides a deployment configuration component creation interface. A preset deployment configuration file can be created and generated through the deployment configuration component creation interface. In this application, the service component information is obtained by parsing the running program file. The service component information includes, but is not limited to, at least one of the following: component name and program library path.

[0039] In step S103, the management service also provides a service instance creation interface. The service instance creation interface provides a service instance creation identifier. In response to the selection operation performed on the service instance creation identifier, a service instance configuration interface is generated. In response to the service instance information configuration operation performed on the service instance configuration interface for the microservice to be deployed, the service instance information corresponding to the target service instance is determined. The service instance configuration interface also includes an instance generation identifier. In response to the selection operation performed on the instance generation identifier, the target service instance is generated. Specifically, the service instance information includes, but is not limited to, at least one of the following: service instance name, IP address, and port number.

[0040] Step S103 further includes associating the target service instance with the library indicated by the service component information in the updated preset deployment configuration file.

[0041] In a preferred embodiment, in steps S104 to S105, while writing the service instance information into the deployment configuration file, the deployment status of the microservice to be deployed in the deployment configuration file is updated from not deployed to deployed, thus obtaining the target deployment configuration file.

[0042] In step S106, the microservice deployment interface also displays a microservice deployment list, and all deployed microservices will be added to the microservice deployment list.

[0043] In a preferred embodiment, please refer to Figure 2 , Figure 2 This document illustrates one of the flowcharts for a microservice startup method provided in an embodiment of this application. For example... Figure 2 As shown, for microservices in the microservice deployment list, the method provided in this application also includes: S200: Obtain service execution parameters and pass them to the microservice starter.

[0044] S201. Use the microservice starter to parse the service running action parameters to obtain the service identifier code and service running action.

[0045] S202. If the service operation action is "start", then read the service instance information from the target deployment configuration file corresponding to the target microservice indicated by the service identifier.

[0046] Preferably, the service instance information includes, but is not limited to, at least one of the following: microservice name, port, dependent services, and the component to which the service belongs.

[0047] S203. Based on the service dependency relationships of the target microservice described in the service instance information, check whether the dependent service of the target microservice has been started.

[0048] S204. If the dependent service is not started, start the dependent service.

[0049] S205. After the dependent service starts, the startup process for the target microservice is triggered, and the startup of the target microservice is completed.

[0050] S206. If the dependent service has already started, proceed directly to step S205.

[0051] In a preferred embodiment, steps S201 to S206 are encapsulated and run in a microservice launcher.

[0052] In steps S200 to S206 provided in this application, before starting the microservice, the microservice startup dependencies are analyzed, and the microservice is started according to the principle of "starting the dependent service first, and then starting the dependent service". This can improve the stability and reliability of the entire microservice startup. In steps S200 to S201, the service operation parameters describe the service identifier code (i.e., the identity identifier of the microservice) and the service execution action corresponding to the microservice to be started. The service identifier code is used to guide the microservice instance to be started. The service operation action includes starting and stopping. This application passes the obtained service operation parameters to the microservice starter and uses the microservice starter to control the microservice to start or stop as indicated by the service identifier code in the service operation parameters.

[0053] In a preferred embodiment, in step S200, the service execution action parameters corresponding to each microservice in the microservice deployment list are generated in the following manner: The corresponding service startup method is read from the target deployment configuration file of the microservice. If the service startup method is automatic startup, the corresponding service startup parameters are generated directly. If the service startup method is manual startup, the service startup parameters for the microservice are generated in response to the startup operation performed on the microservice in the microservice deployment list.

[0054] This application provides two startup methods for microservices: automatic startup and manual startup. Service startup parameters are stored in the deployment configuration file corresponding to the microservice during the microservice deployment phase. After deployment, the service startup parameters are directly read from the target configuration file. If the service startup parameter is automatic startup, the startup process for subsequent microservices is automatically initiated, and the service startup parameters are directly generated. If the service startup parameter is manual startup, it means that the startup trigger signal for the microservice issued by the user must be waited for before the startup process for subsequent microservices can begin. In this application, the startup trigger signal can be generated by performing a startup selection operation on the microservice to be started from the microservice list.

[0055] In a preferred embodiment, please refer to Figure 3 , Figure 3 A second flowchart of a microservice startup method provided in an embodiment of this application is shown. Figure 3 As shown, step S205 includes: S2050. Load the service component corresponding to the target microservice using reflection, based on the component information of the target microservice described by the service instance information corresponding to the target microservice.

[0056] S2051. Initialize the service components corresponding to the target microservice and determine the initialization result.

[0057] S2052. If initialization is successful, register the target microservice with the service registry and generate a service launch event after registration is completed.

[0058] S2053. In response to a service launch event, update the target microservice to the service registry list.

[0059] S2054. If initialization fails, the startup process for the target microservice will end.

[0060] In another preferred embodiment, before performing step S205, the method provided in this application further includes: After triggering the startup process for the target microservice, the health check service corresponding to the target microservice is started. Within a preset waiting time, health status query requests are continuously sent to the health check service corresponding to the target microservice. If a health feedback result is received within the preset waiting time, and the health feedback result indicates that the microservice has passed the health check, the service components corresponding to the target microservice are initialized. If a health feedback result is received within the preset waiting time, and the health feedback result indicates that the microservice has failed the health check, or if no health feedback result is received within the preset waiting time, the startup process for the target microservice ends.

[0061] In this application, the microservice has a built-in health check service. After the startup process of the target microservice is triggered, the health check service starts. After the health check service starts, it continuously sends health status query requests to the health check service within a preset waiting time (exemplarily 60 seconds). Based on the health status query requests, the health check service checks whether the target microservice is running normally and outputs health feedback results. If a health feedback result is obtained and the health feedback result indicates that the target microservice has passed the health check, the subsequent step S205 is executed. If no health feedback result is received after the preset waiting time or the health feedback result indicates that the health check has failed, an error message is recorded and the startup process of the target microservice is terminated.

[0062] In another preferred embodiment, please refer to Figure 4 , Figure 4 A flowchart illustrating a microservice termination method provided in an embodiment of this application is shown. Figure 4 As shown, after step S201, the method provided in this application further includes: S300. If the service operation action is to stop, the target microservice indicated by the control service identifier code will enter the graceful shutdown mechanism.

[0063] Preferably, the graceful shutdown mechanism includes: stopping the receipt of new business processing requests, completing the processing of currently executing business processing requests, shutting down the running resources corresponding to the target microservice, and generating an offline trigger event. The running resources include, but are not limited to, at least one of the following: database connection and network connection.

[0064] S301. Obtain the offline trigger event reported by the target microservice under the graceful shutdown mechanism.

[0065] S302. In response to the offline trigger event, determine whether the target microservice is still running within the preset timeout period.

[0066] S303. If the target microservice is still running within the preset timeout period, the target microservice will be forcibly stopped, and a forced shutdown event will be generated for the target microservice.

[0067] S304. If the target microservice remains in a stopped state for the preset timeout period, a shutdown notification event for the target microservice will be generated.

[0068] S305. In response to a forced offline event or offline notification event for the target microservice, remove the target microservice from the service registry and update the service registry.

[0069] In steps S302 to S304, this application pre-sets a timeout period for the graceful shutdown mechanism. If the target microservice fails to complete the graceful shutdown operation within the preset timeout period (i.e., after receiving the offline trigger event for the target microservice, the target microservice is still running within the preset timeout period and the shutdown fails), the target microservice is forcibly terminated, triggering a forced offline event. At the same time, the shutdown process information, including the shutdown time, is recorded. If the target microservice completes the graceful shutdown operation within the preset timeout period (i.e., after receiving the offline trigger event for the target microservice, the target microservice stops successfully within the preset timeout period), an offline notification event is generated.

[0070] In step S305, the target microservice is removed from the service registry to ensure that other services will not attempt to call the stopped target microservice.

[0071] In a preferred embodiment, please refer to Figure 5 , Figure 5 A flowchart illustrating a microservice instance uninstallation method provided in an embodiment of this application is shown. Figure 5 As shown, the method provided in this application also includes: S400: In response to an uninstallation request for a target microservice in the microservice deployment list, determine whether the target microservice is in a running state.

[0072] S401. If the target microservice is running, generate a service running prompt message and end the uninstallation of the target microservice.

[0073] S402. If the target microservice is not running, then uninstall the service instance corresponding to the target microservice.

[0074] S403. Delete the environment variables of the target microservice in the running system.

[0075] S404. Update the deployment status in the deployment configuration file corresponding to the target microservice to "not deployed".

[0076] S405. Delete the service instance configuration information in the deployment configuration file corresponding to the target microservice and the runtime files in the specified program running directory, and end the uninstallation of the target microservice.

[0077] The microservice management method provided in this application is simpler and easier to understand than Kubernetes in terms of microservice deployment and uninstallation. It does not require various additional dependent software, is more lightweight, and the process is more simplified. It can be implemented through a simple interface operation, reducing the professional requirements of operators. In terms of microservice startup and shutdown, it avoids the problem of not being able to finely control services caused by starting and stopping services through scripts. This application aims to improve the usability, stability, reliability and maintainability of microservice architecture through fine-grained management of key links such as microservice deployment, uninstallation, startup and shutdown.

[0078] The advantages of this application are: 1. Unified deployment template technology: By performing commonalities analysis on different microservices, a set of general deployment templates is provided, which can adapt to the deployment needs of various microservices, greatly simplifying the deployment and uninstallation process and improving the consistency and accuracy of deployment and uninstallation.

[0079] 2. Microservice startup dependency management and health check and waiting mechanism: Before starting a microservice, the dependencies between microservices are analyzed and started in the order of starting the dependent service first and then the dependent services. When each microservice starts, a built-in health check mechanism is used to determine whether the microservice is running normally by sending corresponding requests periodically. If it is running normally, it will start, ensuring startup stability and startup success rate.

[0080] 3. Graceful stopping and resource cleanup technology: During the microservice stopping and uninstallation process, a graceful stopping mechanism and comprehensive resource cleanup function are implemented to ensure data integrity and system environment cleanliness during microservice stopping and uninstallation, and reduce problems caused by improper service stopping and uninstallation.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0082] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0084] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0085] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A microservice management method, characterized in that, Applied to management services, the method includes: Import the target deployment package corresponding to the microservice to be deployed into the corresponding runtime system. The target deployment package is an information data package that carries the runtime program file corresponding to the microservice to be deployed, created based on a general deployment template. The general deployment template is created based on a general deployment configuration object abstracted from different microservices. The target deployment package is parsed, the parsed executable file is written to the specified program running directory of the running system, and the service component information indicated by the executable file is written to the preset deployment configuration file to obtain the updated preset deployment configuration file. Create the target service instance corresponding to the microservice to be deployed; The environment variables corresponding to the microservice to be deployed are written into the running system, and the service instance information corresponding to the target service instance is written into the updated preset deployment configuration file to obtain the target deployment configuration file. Add the already deployed microservices to the microservice deployment list to complete the deployment process for the microservices to be deployed.

2. The method according to claim 1, characterized in that, Create the deployment package corresponding to the microservice to be deployed using the following method: The microservice deployment interface is invoked, which provides controls for creating deployment packages. In response to a selection operation performed on the deployment package creation control, a deployment package configuration interface is displayed. The deployment package configuration interface provides a general deployment template, which includes multiple general deployment configuration objects. Based on the given deployment package format, the multiple program files corresponding to the microservice to be deployed are respectively populated into the corresponding general deployment configuration object to obtain the deployment package corresponding to the microservice to be deployed.

3. The method according to claim 1, characterized in that, The method further includes: Before parsing the executable files in the target deployment package, determine whether the target deployment package conforms to the given deployment package format; If the target deployment package conforms to the given deployment package format, then the runtime files in the target deployment package are parsed, and the parsed service component information is written to the specified program directory in the preset deployment configuration file; If the target deployment package does not conform to the given deployment package format, the deployment process for the microservice to be deployed will be exited and a deployment error message will be generated.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the service execution parameters and pass them to the microservice starter; The microservice starter is used to parse the service execution action parameters to obtain the service identifier code and service execution action; If the service operation action is to start, then read the service instance information from the target deployment configuration file corresponding to the target microservice indicated by the service identifier code; Based on the service dependency relationships of the target microservice described in the service instance information, check whether the dependent service of the target microservice has been started. If the dependent service is not started, the dependent service is started. After the dependent service is started, the startup process for the target microservice is triggered to complete the startup of the target microservice. If the dependent service has already started, the startup process for the target microservice will be triggered directly to complete the startup of the target microservice.

5. The method according to claim 4, characterized in that, Generate the service execution action parameters for each microservice in the microservice deployment list using the following method: Read the corresponding service startup method from the target deployment configuration file corresponding to the microservice; If the service startup method is automatic startup, then the corresponding service startup parameters will be generated directly; If the service startup method is manual startup, then in response to the startup operation performed on the microservice in the microservice deployment list, service startup parameters for the microservice are generated.

6. The method according to claim 4, characterized in that, Start the target microservice in the following ways: The service components corresponding to the target microservice are loaded using reflection, based on the component information of the target microservice as described by the service instance information corresponding to the target microservice. Initialize the service components corresponding to the target microservice and determine the initialization result; If initialization is successful, the target microservice is registered with the service registry and a service launch event is generated after registration is completed. In response to the service launch event, update the target microservice to the service registry list; If initialization fails, the startup process for the target microservice will end.

7. The method according to claim 6, characterized in that, Before initializing the service components corresponding to the target microservice, the method further includes: After triggering the startup process for the target microservice, start the health check service corresponding to the target microservice; Within a preset waiting time, continuously send health status query requests to the health check service corresponding to the target microservice; If a health feedback result is received within the preset waiting time, and the health feedback result indicates that the microservice has passed the health check, then the service component corresponding to the target microservice is initialized. If a health feedback result is received within the preset waiting time, and the health feedback result indicates that the microservice has failed the health check, or if no health feedback result is received within the preset waiting time, the startup process for the target microservice will end.

8. The method according to claim 1, characterized in that... The method further includes: Obtain the service execution parameters and pass them to the microservice starter; The microservice starter is used to parse the service execution action parameters to obtain the service identifier code and service execution action; If the service operation action is to stop, then the target microservice indicated by the service identifier code is controlled to enter the graceful shutdown mechanism, wherein the graceful shutdown mechanism includes: stopping the receipt of new business processing requests, completing the processing of the currently executing business processing requests, shutting down the running resources corresponding to the target microservice, and generating an offline trigger event; Obtain the shutdown trigger event reported by the target microservice under the graceful shutdown mechanism; In response to the offline trigger event, determine whether the target microservice is still running within a preset timeout period. If the target microservice is still running within the preset timeout period, forcibly stop the target microservice and generate a forced offline event for the target microservice. If the target microservice remains in a stopped state for a preset timeout period, an offline notification event for the target microservice will be generated. In response to a forced offline event or offline notification event for the target microservice, remove the target microservice from the service registry and update the service registry.

9. The method according to claim 1, characterized in that, The method further includes: In response to an uninstallation request for a target microservice in the microservice deployment list, determine whether the target microservice is in a running state; If the target microservice is running, the unloading of the target microservice will end, and a service running prompt message will be generated. If the target microservice is not running, uninstall the service instance corresponding to the target microservice, delete the environment variables of the target microservice in the running system, and update the deployment status in the deployment configuration file corresponding to the target microservice to the non-deployed status. Delete the service instance configuration information in the deployment configuration file corresponding to the target microservice and the runtime files in the specified program running directory to complete the uninstallation of the target microservice.

10. A microservice management system, characterized in that, The microservice management system includes multiple microservices and management services, and the management services are applied to the microservice management method according to any one of claims 1-9.

Images