A web-based microservice process management method

Abstract

This invention provides a web-based microservice process management method, comprising the following steps: receiving a process management operation instruction containing a target microservice service identifier; retrieving the microservice configuration database based on the service identifier to obtain the target microservice configuration information; responding to the instruction and automatically executing the corresponding process operation based on the configuration information; updating the microservice status database information according to the execution result and presenting the target microservice status. This method eliminates the need for operations personnel to memorize complex command lines and configuration details, reducing their professional skill requirements and management costs, and minimizing the risk of manual errors; it integrates instruction triggering, background execution, and status updates into an automated closed loop, eliminating process breakpoints and providing "instruction issued - result known" feedback, improving management efficiency and stability; and it abandons traditional command-line text output, providing an easy-to-understand status view, improving operational intuitiveness and human-computer interaction efficiency.

Description

Technical Field

[0001] This disclosure generally relates to the field of microservice process management technology, and specifically to a web-based microservice process management method. Background Technology

[0002] With the rapid development of cloud computing and containerization technologies, microservice architecture has become the mainstream architectural pattern for modern software systems. Microservices break down large monolithic applications into multiple independent small services, each focusing on a specific business function and interacting through lightweight communication mechanisms. This architectural pattern brings better scalability, maintainability, and technical diversity, but it also introduces new challenges:

[0003] The number of services is surging: a large system may contain hundreds of microservice instances;

[0004] Increased deployment complexity: It requires managing the starting, stopping, and restarting of numerous services;

[0005] Increased monitoring difficulty: It requires real-time understanding of the operational status of each service;

[0006] Rising maintenance costs: Traditional manual maintenance methods can no longer meet the needs.

[0007] Current technical solutions, such as the Kubernetes container orchestration platform, define services through YAML configuration files and manage them using the kubectl command-line tool. The core operational mode of this approach is that operations personnel send commands based on predefined configuration files (e.g., YAML files) to the cluster via command-line tools (e.g., kubectl) to perform process management operations. Specifically, a complete management cycle consists of two separate steps: first, operations personnel trigger an operation on the target microservice using a first command; then, to confirm the operation result, they must actively and independently execute another separate query command to obtain the service's status information. This technical solution has the following drawbacks: complex operation and high technical threshold; disjointed management process and non-real-time feedback. Summary of the Invention

[0008] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a web-based microservice process management method, including the following steps:

[0009] Receive user process management operation instructions for a target microservice, wherein the operation instructions include at least the service identifier of the target microservice;

[0010] Based on the service identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database. The microservice configuration database stores at least the service identifier, service name, service path, startup command, environment identifier, and dependency information.

[0011] In response to the operation command, the process operation corresponding to the operation command is automatically executed based on the configuration information;

[0012] Based on the execution result of the process operation, the status information in the microservice status database is updated and the status of the target microservice is presented. The microservice status database stores at least the status identifier, the service identifier, the process identifier, the current status, and the last check timestamp.

[0013] According to the technical solution provided in the embodiments of this application, the operation instruction includes a start instruction, and the automatic execution of the process operation corresponding to the operation instruction based on the configuration information includes the following steps:

[0014] Obtain the service path and startup command of the target microservice from the configuration information;

[0015] Based on the service path and the startup command, create and run the system process corresponding to the target microservice, and obtain the process identifier;

[0016] The service identifier and its corresponding process identifier are associated and stored in the microservice state database;

[0017] Based on the process identifier, verify whether the target microservice has started successfully.

[0018] According to the technical solution provided in the embodiments of this application, verifying whether the target microservice has started successfully includes the following steps:

[0019] Check if the process corresponding to the process identifier exists;

[0020] If it exists, obtain the running attribute information of the process, which includes the complete command line used when starting the process;

[0021] Match the complete command line string with the service name;

[0022] If the service name is included in the string of the complete command line, the target microservice is considered to have started successfully.

[0023] According to the technical solution provided in the embodiments of this application, the operation instruction includes a shutdown instruction; the step of updating the status information in the microservice status database and presenting the status of the target microservice based on the execution result of the process operation includes the following steps:

[0024] Based on the service identifier, the process identifier corresponding to the target microservice is obtained from the microservice state database;

[0025] An asynchronous task is started, which sends a termination signal to the process corresponding to the process identifier to execute a shutdown instruction.

[0026] According to the technical solution provided in the embodiments of this application, the step of starting an asynchronous task, in which the asynchronous task sends a termination signal to the process corresponding to the process identifier to execute a shutdown instruction, includes the following steps:

[0027] Send a first shutdown signal to the process corresponding to the process identifier, the first shutdown signal being used to request the process to exit normally;

[0028] After waiting for a preset time, check whether the process corresponding to the process identifier is still running;

[0029] If so, a second shutdown signal is sent to the process corresponding to the process identifier, the second shutdown signal being used to forcibly terminate the process.

[0030] The technical solution provided in the embodiments of this application further includes the following steps:

[0031] Perform status checks on the microservices in the system according to a set periodicity;

[0032] Based on the results of the status check, the current status and the last check timestamp of each microservice in the microservice status database are updated, and the updated status is presented.

[0033] According to the technical solution provided in the embodiments of this application, the step of performing status checks on microservices in the system according to a set period includes the following steps:

[0034] Retrieve the service identifier and the corresponding process identifier of each microservice from the microservice state database;

[0035] Check if the process corresponding to each process identifier exists;

[0036] For existing processes, their runtime attribute information is matched with the service name obtained based on the service identifier;

[0037] Update the current state in the microservice state database based on process existence and matching results.

[0038] According to the technical solution provided in the embodiments of this application, the operation instruction includes starting multiple microservices. After responding to the operation instruction and before automatically executing the process operation corresponding to the operation instruction based on the queried configuration information, the following steps are further included:

[0039] Based on the service identifiers of the multiple target microservices, the dependency information between the multiple target microservices is obtained by retrieving the microservice configuration database.

[0040] Based on the dependency information, the startup order of multiple target microservices is determined to ensure that the target microservices that are depended upon start before the target microservices that depend on them.

[0041] According to the technical solution provided in the embodiments of this application, the following steps are included before receiving the user's process management operation instructions for the target microservice:

[0042] The system receives an environment switching instruction from a user. The environment switching instruction is used to select a target environment from multiple preset environments. The preset environments include at least a development environment and a test environment. The environment switching instruction contains an environment identifier of the target environment.

[0043] Based on the service identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database, and then updated to: based on the service identifier and the environment identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database.

[0044] Compared with existing technologies, the beneficial effects of this application are as follows: This invention abstracts microservice process management into simple operation command input. Operation and maintenance personnel no longer need to memorize complex command-line instructions and configuration file details, greatly reducing the professional skill requirements for operation and maintenance personnel and simplifying operation steps. This reduces the operational risks caused by manual input errors, thereby lowering the management cost and technical threshold of microservice operation and maintenance. Furthermore, this invention creatively integrates command triggering, background execution, and status updates into an automated and coherent technical closed loop. After receiving the operation command, the system automatically executes all necessary subsequent process operations and automatically updates and presents the final execution result to the user. This eliminates the process breakpoints in operation and query quality inspection found in existing technologies, providing users with an instant and coherent feedback experience of "command issued - result known," greatly improving management efficiency and operational stability. This invention presents the execution result, changing the traditional mode that relies on command-line text output, providing users with an easily understandable view of status information, improving the intuitiveness of operation and maintenance management and the efficiency of human-computer interaction. Attached Figure Description

[0045] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0046] Figure 1 A flowchart illustrating a Web-based microservice process management method provided in an embodiment of this application. Detailed Implementation

[0047] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0048] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0049] As mentioned in the background section, this application proposes a Web-based microservice process management method. This method is implemented on a Web microservice process management system, which adopts a four-layer architecture, from top to bottom as follows:

[0050] User Interface Layer: A web graphical interface implemented based on modern front-end frameworks such as React. It is responsible for receiving user commands, presenting microservice status and configuration information, and serves as the direct portal for user interaction.

[0051] Backend service layer: This is a RESTful API service built on a framework such as Django (or Spring Boot), and it is the core of the business logic. It handles requests from the frontend, schedules and coordinates the data storage layer and the process management layer, and is the "command center" of the system.

[0052] Data storage layer: Employing relational databases such as MySQL and PostgreSQL, this layer is responsible for persistently storing microservice configuration information, real-time status, historical operation records, and other data, providing the system with state persistence and data query capabilities. It includes two databases: a microservice configuration database and a microservice status database. The microservice configuration database stores static, predefined information for microservices, determined during service registration or deployment, primarily including service_id (service identifier), service_name (service name), environment (environment identifier), and service_path (service path). The microservice status database stores dynamic information during service runtime, including process_id (process identifier), status_id (storage status identifier), and status (current status).

[0053] Process Management Layer: This is a process control module built using Python libraries such as subprocess and psutil. It interacts directly with the server operating system and is responsible for performing low-level operations such as starting, stopping, and checking the status of processes. It is the system's "execution terminal".

[0054] Each layer interacts with the others through standard, well-defined interfaces (such as HTTP API, database connections, and function calls), with clear responsibilities, and together they achieve modularity, scalability, high cohesion, and low coupling in microservice management.

[0055] like Figure 1 As shown, the management method includes the following steps:

[0056] S001. Receive a process management operation instruction from a user for a target microservice, wherein the operation instruction includes at least the service identifier of the target microservice;

[0057] Specifically, a target microservice refers to one or more microservice instances managed by the user. Microservices are a software architectural style that breaks down an application into multiple small, independent services, each running in an independent process and interacting through lightweight communication mechanisms. Users select the target microservice and trigger operation commands through the web management interface via the user interface layer. These commands include a service identifier uniquely identifying the target microservice and parameters specifying the operation type. The user interface layer encapsulates these two key pieces of information into digitized data and transmits it to the backend service layer via the HTTP protocol. For example, when a user needs to start an order service, they click the start button on the interface. The system automatically retrieves "order-service-001" as the service identifier and "start" as the operation type, constructs complete request data, and sends it to the backend interface.

[0058] S002. Based on the service identifier, retrieve the configuration information of the target microservice from the microservice configuration database. The microservice configuration database stores at least the service identifier, service name, service path, startup command, environment identifier, and dependency information.

[0059] Specifically, upon receiving a request containing a service identifier, the backend service layer initiates a configuration query to the data storage layer. The data storage layer retrieves the corresponding configuration record from the microservice configuration repository based on the service identifier, returning complete configuration information including the service path and startup command. After receiving the configuration information, the backend service layer verifies its completeness and validity to ensure that subsequent process operations can be executed based on the correct parameters. For example, when the system queries the service identifier "user-service-001", the data storage layer returns the executable file path of the service as " / opt / services / user-service.jar", and the startup parameters as "--port8080--cluster", among other configuration details.

[0060] S003. In response to the operation command, automatically execute the process operation corresponding to the operation command based on the configuration information.

[0061] Specifically, the backend service layer selects the appropriate processing strategy based on the operation type and converts the configuration information into parameters required for process operation. After receiving these parameters, the process management layer interacts with the operating system through system calls to execute specific process management operations. For example, for a startup operation, the system locates the executable file based on the service path and creates a new process using the startup command parameters; for a stop operation, it sends a termination signal to the specified process. The entire process is fully automated and requires no manual intervention.

[0062] S004. Based on the execution result of the process operation, update the status information in the microservice status database and present the status of the target microservice, wherein the microservice status database stores at least the status identifier, the service identifier, the process identifier, the current status, and the last check timestamp.

[0063] Specifically, after the process management layer completes its operation, it returns the execution result to the backend service layer. The backend service layer updates the microservice status record in the data storage layer based on the result, including key information such as running status, process ID, and last update time. The user interface layer obtains status updates through a real-time communication mechanism, dynamically adjusts the interface display, and provides timely feedback to the user. For example, when a service starts successfully, the system updates the status to "Running," records the process ID with the actual assigned value, and displays it as a green status indicator in the user interface.

[0064] This invention constructs a "means-driven, automated, and state-closed-loop" management and control model through the collaboration of four layers: the user interface layer, the backend service layer, the data storage layer, and the process management layer. Specifically, the user interface layer encapsulates the user's advanced management intentions (such as click operations) into structured operation instructions. Upon receiving the instructions, the backend service layer retrieves pre-configured settings from the data storage layer and schedules the process management layer to execute the corresponding operating system-level process operations. Finally, the operation results are stored in the data storage layer and synchronously fed back to the user interface layer for presentation via the backend service layer. This principle fundamentally solves the problems of high operational complexity and lack of a unified management interface caused by reliance on command lines and configuration files in existing technologies. Ultimately, it achieves significant technical effects such as simplified operation (replacing complex commands with graphical clicks), unified management (completing all operational activities in a single portal), and automated processes (integrating fragmented multi-step manual operations into a seamless closed loop).

[0065] In a preferred embodiment, the operation instruction includes a start instruction, and the automatic execution of the process operation corresponding to the operation instruction based on the configuration information includes the following steps:

[0066] S100. Obtain the service path and startup command of the target microservice from the configuration information;

[0067] Specifically, the backend service layer extracts key operational parameters from the configuration information, including the service path and startup command. The service path specifies the exact location of the executable file on the server, while the startup command contains all the parameters and options required for service operation. The system verifies that the service path exists and is executable, and also confirms the completeness and correctness of the startup command. For example, if the configuration information parses a service path of " / usr / bin / node" and a startup command of "app.js --cluster --port=3000", the system will confirm that the Node.js executable file is located in the specified path and has execution permissions, and also verify that the parameter format in the startup command is correct.

[0068] S110. Based on the service path and the startup command, create and run the system process corresponding to the target microservice, and obtain the process identifier;

[0069] Specifically, the process management layer locates the executable file based on the service path and creates a new process instance according to the parameters configured in the startup command. The system sets the correct working directory, environment variables, and runtime parameters to ensure that the process starts and runs in the expected environment. After successful process creation, the operating system returns a unique process identifier. For example, after executing the startup command " / usr / bin / nodeapp.js --cluster --port=3000", the system obtains process A and immediately verifies whether the process has been successfully created and is running normally.

[0070] S120. Associate and store the service identifier and its corresponding process identifier in the microservice state database;

[0071] Specifically, the backend service layer persistently stores the mapping between service identifiers and process identifiers in the data storage layer. Establishing this association provides a foundation for subsequent status monitoring, process management, and service operation and maintenance. For example, a record is inserted into the microservice status database to establish an association between "auth-service-002" and process A, while also recording the service's startup time and initial state.

[0072] S130. Based on the process identifier, verify whether the target microservice has started successfully. This includes the following steps:

[0073] S131. Check if the process corresponding to the process identifier exists;

[0074] Specifically, the process management layer verifies the existence of a process corresponding to a given process identifier by querying the operating system's process table. The system not only checks the existence of the process but also confirms that the process is in a normal running state, rather than a zombie process or one about to terminate. For example, when the system checks process B, it confirms that the process exists in the system process table and its status is "running".

[0075] S132. If it exists, obtain the running attribute information of the process, the running attribute information including the complete command line used when starting the process;

[0076] Specifically, for a confirmed process, the process management layer will further obtain its detailed runtime attributes, especially the complete command-line information used when the process started. This attribute information serves as an important basis for service authentication. For example, the complete command-line information for process B is obtained as: " / usr / bin / java-jarpayment-service.jar--port8443".

[0077] S133. Match the complete command line string with the service name;

[0078] Specifically, the backend service layer compares and verifies the command-line information obtained from the process with the service name obtained from the configuration database. The system uses a string matching algorithm to confirm whether the command line contains the expected service identifier characteristics. For example, it compares "payment-service" in the command line with the configured service name to verify their consistency.

[0079] S134. If the service name is included in the string of the complete command line, the target microservice is determined to have started successfully.

[0080] Specifically, the system makes a comprehensive judgment based on the existence of the process and the command line matching result. Only when both conditions are met is the service considered to have started successfully. For example, if the process exists and the command line contains the service name "payment-service", the system marks the service status as successfully started. If the system determines that the process corresponding to the process identifier does not exist, it judges the startup as failed or terminated, and marks the current status as "stopped" in the microservice status database; if the system determines that the process corresponding to the process identifier exists, but the command line does not contain the service name, it marks the current status as "error" in the microservice status database.

[0081] This application, based on the operating system's process creation and dual-verification mechanism, calls to create a new process and establish a mapping relationship between service names and process identifiers. Combining process existence checks and application-level feature matching, it verifies the process status by querying the operating system's process table and verifies the process identity through a string matching algorithm, constructing a complete verification system from process creation to status confirmation. This dual-verification mechanism effectively prevents misjudgments caused by identifier reuse, reduces the false status determination rate, and improves the reliability of the monitoring system.

[0082] In a preferred embodiment, the operation instruction includes a shutdown instruction; updating the status information in the microservice status database and presenting the status of the target microservice based on the execution result of the process operation includes the following steps:

[0083] S200. Obtain the process identifier corresponding to the target microservice from the microservice state database based on the service identifier;

[0084] Specifically, when a user initiates a shutdown command, the backend service layer first queries the microservice state database for the process identifier corresponding to the target microservice. The system ensures that it obtains the latest and valid process identifier, providing an accurate target for subsequent shutdown operations. For example, the process corresponding to the service "message-queue-001" is 'C'.

[0085] S210. Start an asynchronous task, which sends a termination signal to the process corresponding to the process identifier to execute a shutdown instruction. This includes the following steps:

[0086] S211. Send a first shutdown signal to the process corresponding to the process identifier, the first shutdown signal being used to request the process to exit normally;

[0087] Specifically, the asynchronous task first sends a friendly termination signal to the target process, allowing the process to perform necessary cleanup operations. This signal can be caught by the process and used for cleanup tasks such as saving data and closing connections. For example, sending a SIGTERM signal to process D requests its normal exit.

[0088] S212. After waiting for a preset time, check whether the process corresponding to the process identifier is still running;

[0089] Specifically, after sending a friendly termination signal, the system waits for a preset time interval to allow the process sufficient time to clean up. After the wait is complete, the system checks the process status again to confirm whether it has exited. For example, it checks whether process D still exists after waiting 5 seconds.

[0090] S213. If so, a second shutdown signal is sent to the process corresponding to the process identifier, the second shutdown signal being used to forcibly terminate the process.

[0091] Specifically, if a process fails to exit after the waiting period, the system sends a forced termination signal. This signal is handled directly by the operating system kernel to ensure the process is terminated immediately. For example, sending a SIGKILL signal to process D forcibly terminates that process.

[0092] This application achieves controllable process termination and safe release of resources by handling time-consuming operations asynchronously and using a phased termination strategy. It combines a first shutdown signal to allow the process to exit normally and a second shutdown signal to ensure the finality of termination.

[0093] In a preferred embodiment, the microservice process management method further includes the following steps:

[0094] S300. Perform status checks on the microservices in the system according to the set period;

[0095] Specifically, the system establishes a periodic health check mechanism to monitor the status of all microservices at preset time intervals. The monitoring frequency can be customized according to the importance and characteristics of the services. For example, the system performs a full service health check every 30 seconds, covering all registered microservice instances.

[0096] Includes the following steps:

[0097] S301. Obtain the service identifier and the corresponding process identifier of each microservice from the microservice state database;

[0098] Specifically, each time the system checks the status, it first retrieves a list of all microservices that need to be monitored and their corresponding process identifiers from the data storage layer. This process ensures that monitoring covers all active service instances. For example, the system queries and retrieves a list of service identifiers and process identifiers for 20 microservices.

[0099] S302. Check if the process corresponding to each process identifier exists;

[0100] Specifically, the system uses concurrency techniques to check the status of multiple processes simultaneously, improving monitoring efficiency. Each process identifier is verified to ensure that its corresponding process exists and is running normally in the operating system. For example, a thread pool is used to check the existence and status of 20 processes in parallel.

[0101] S303. For existing processes, match their runtime attribute information with the service name obtained based on the service identifier;

[0102] Specifically, for processes that are confirmed to exist, the system further verifies whether the process is indeed a genuine instance of the corresponding microservice, and not another process or an unrelated process reusing a process identifier. The verification method compares the process's command-line information with the characteristics that the service should possess, obtained from the configuration database. For example, it verifies whether the process's command-line information contains the configured service name characteristic, ensuring the authenticity of the process's identity.

[0103] S304. Update the current state in the microservice state database based on the process existence and matching results.

[0104] Specifically, the system updates service status in batches based on the verification results. Only services with existing processes and successful authentication are marked as running normally. For example, services with existing processes but mismatched command lines are marked as abnormal and trigger the corresponding alarm mechanism.

[0105] S310. Based on the results of the status check, update the current status and the last check timestamp of each microservice in the microservice status database, and present the updated status.

[0106] Specifically, the system updates the status information of microservices in batches based on the inspection results, including running status, resource usage, etc., and records the last inspection time. The user interface reflects these status changes in real time. For example, if the log service is found to be unresponsive, its status is updated to "abnormal" and an alarm notification is sent.

[0107] This application establishes a systematic proactive monitoring mechanism that can promptly detect anomalies and issue early warnings. While ensuring monitoring accuracy, it significantly improves processing efficiency, supports monitoring needs at the scale of thousands of services, effectively prevents false alarms and missed alarms, and realizes a complete monitoring closed loop from status checks to identity verification.

[0108] In a preferred embodiment, the operation instruction includes starting multiple microservices. After responding to the operation instruction and before automatically executing the process operation corresponding to the operation instruction based on the queried configuration information, the method further includes the following steps:

[0109] S400. Based on the service identifiers of the multiple target microservices, retrieve the microservice configuration database to obtain the dependency information between the multiple target microservices;

[0110] Specifically, when multiple interdependent microservices need to be started, the system first resolves the dependencies between these services from the configuration database. Dependency information is stored and represented in the form of a graph structure. For example, a system query reveals that the order service depends on the user service, which in turn depends on the API gateway service.

[0111] S410. Based on the dependency information, determine the startup order of the multiple target microservices to ensure that the target microservices that are depended upon start before the target microservices that depend on them.

[0112] Specifically, the system calculates a reasonable startup order based on the dependency graph and uses a topology sorting algorithm to ensure that dependent services start first. The system also detects and handles anomalies such as circular dependencies. For example, the startup order is determined to be: API Gateway - User Service - Order Service.

[0113] In a preferred embodiment, the following steps are further included before receiving the user's process management operation instruction for the target service:

[0114] The system receives an environment switching instruction from a user. The environment switching instruction is used to select a target environment from multiple preset environments. The preset environments include at least a development environment and a test environment. The environment switching instruction contains an environment identifier of the target environment.

[0115] Specifically, users can switch between different deployment environments through the interface, and the system records the selected target environment identifier. Environment switching provides users with service management views under different environments. For example, when a user switches from a development environment to a test environment, the system records the environment identifier "test".

[0116] Based on the service identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database, and then updated to: based on the service identifier and the environment identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database.

[0117] Specifically, all operations are automatically associated with the current environment identifier. When querying configuration information, the system automatically adds environment filtering conditions to ensure that the operation is performed on the service configuration in the correct environment. For example, "ANDenvironment='test'" is automatically added to the query conditions. This achieves secure isolation management of multiple environments, effectively preventing configuration confusion and misoperation between different environments, supporting parallel development and testing processes, providing a unified management platform for team collaboration, and improving development and operation efficiency.

[0118] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A Web-based microservice process management method, characterized in that, Includes the following steps: Receive user process management operation instructions for a target microservice, wherein the operation instructions include at least the service identifier of the target microservice; Based on the service identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database. The microservice configuration database stores at least the service identifier, service name, service path, startup command, environment identifier, and dependency information. In response to the operation command, the process operation corresponding to the operation command is automatically executed based on the configuration information; Based on the execution result of the process operation, the status information in the microservice status database is updated and the status of the target microservice is presented. The microservice status database stores at least the status identifier, the service identifier, the process identifier, the current status, and the last check timestamp. The operation instructions include a start instruction, and the automatic execution of the process operation corresponding to the operation instruction based on the configuration information includes the following steps: Obtain the service path and startup command of the target microservice from the configuration information; Based on the service path and the startup command, create and run the system process corresponding to the target microservice, and obtain the process identifier; The service identifier and its corresponding process identifier are associated and stored in the microservice state database; Based on the process identifier, verify whether the target microservice has started successfully; Verifying whether the target microservice has started successfully includes the following steps: Check if the process corresponding to the process identifier exists; If it exists, obtain the running attribute information of the process, which includes the complete command line used when starting the process; Match the complete command line string with the service name; If the service name is included in the string of the complete command line, the target microservice is considered to have started successfully.

2. The Web-based microservice process management method according to claim 1, characterized in that, The operation instructions include a shutdown instruction; updating the status information in the microservice status database and presenting the status of the target microservice based on the execution result of the process operation includes the following steps: Based on the service identifier, the process identifier corresponding to the target microservice is obtained from the microservice state database; An asynchronous task is started, which sends a termination signal to the process corresponding to the process identifier to execute a shutdown instruction.

3. The Web-based microservice process management method according to claim 2, characterized in that, The process of starting an asynchronous task, in which the asynchronous task sends a termination signal to the process corresponding to the process identifier to execute a shutdown instruction, includes the following steps: Send a first shutdown signal to the process corresponding to the process identifier, the first shutdown signal being used to request the process to exit normally; After waiting for a preset time, check whether the process corresponding to the process identifier is still running; If so, a second shutdown signal is sent to the process corresponding to the process identifier, the second shutdown signal being used to forcibly terminate the process.

4. The Web-based microservice process management method according to claim 1, characterized in that, It also includes the following steps: Perform status checks on the microservices in the system according to a set periodicity; Based on the results of the status check, the current status and the last check timestamp of each microservice in the microservice status database are updated, and the updated status is presented.

5. The Web-based microservice process management method according to claim 4, characterized in that, The process of performing status checks on microservices in the system according to a set period includes the following steps: Retrieve the service identifier and the corresponding process identifier of each microservice from the microservice state database; Check if the process corresponding to each process identifier exists; For existing processes, their runtime attribute information is matched with the service name obtained based on the service identifier; Update the current state in the microservice state database based on process existence and matching results.

6. The Web-based microservice process management method according to claim 1, characterized in that, The operation instruction includes starting multiple microservices. After responding to the operation instruction and before automatically executing the process operation corresponding to the operation instruction based on the configuration information, the following steps are also included: Based on the service identifiers of the multiple target microservices, the dependency information between the multiple target microservices is obtained by retrieving the microservice configuration database. Based on the dependency information, the startup order of multiple target microservices is determined to ensure that the target microservices that are depended upon start before the target microservices that depend on them.

7. The Web-based microservice process management method according to claim 1, characterized in that, Before receiving user instructions for process management operations on the target microservice, the following steps are also included: The system receives an environment switching instruction from a user. The environment switching instruction is used to select a target environment from multiple preset environments. The preset environments include at least a development environment and a test environment. The environment switching instruction contains an environment identifier of the target environment. Based on the service identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database, and then updated to: based on the service identifier and the environment identifier, the configuration information of the target microservice is obtained by retrieving the microservice configuration database.

Images