Automatic operation and maintenance method and device for micro-service architecture, and nonvolatile storage medium

Abstract

The application discloses an automatic operation and maintenance method and device of a micro-service architecture, and a nonvolatile storage medium. The method comprises the following steps: obtaining related files of the micro-service architecture, wherein the micro-service architecture is used for providing a plurality of micro-services; generating a knowledge graph according to the related files, wherein the knowledge graph is used for recording at least a micro-service interface of a micro-service in the micro-service architecture, a configuration parameter of the micro-service interface, and a calling relationship between the micro-services; in the case that a change instruction is received, determining a change risk level according to the knowledge graph and a specified change object carried by the change instruction, and determining whether to execute a change operation indicated by the change instruction according to the change risk level; in the case that no change instruction is received within a preset statistical period, identifying static configuration nodes and dynamic configuration nodes in the knowledge graph, and performing multi-dimensional detection on the static configuration nodes and the dynamic configuration nodes to obtain a detection result; and outputting prompt information corresponding to the detection result.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to an automated operation and maintenance method and apparatus for a microservice architecture, and a non-volatile storage medium. Background Technology

[0002] In related technologies, the configuration files of microservice architectures are manually maintained. However, whenever the system architecture is adjusted, environment parameters are changed, or code logic is modified, the configuration files of each environment need to be updated synchronously, and the completeness, format, and matching of configuration items with the code need to be manually verified. Therefore, the manual maintenance of configuration files for microservice architectures suffers from low maintenance efficiency and low stability of microservice architectures.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides an automated operation and maintenance method and apparatus for microservice architecture, as well as a non-volatile storage medium, to at least solve the technical problems of low operation and maintenance efficiency and unstable operation of microservice architecture due to manual operation and maintenance.

[0005] According to one aspect of the embodiments of this application, an automated operation and maintenance method for a microservice architecture is provided, comprising: obtaining relevant files of the microservice architecture, wherein the microservice architecture is used to provide multiple microservices, and the relevant files of the microservice architecture include: a microservice delivery unit for each microservice; generating a knowledge graph based on the relevant files, wherein the knowledge graph is used to record at least the microservice interfaces of the microservices in the microservice architecture, the configuration parameters of the microservice interfaces, and the calling relationships between microservices; upon receiving a change instruction, determining the change risk level based on the knowledge graph and the specified change object carried by the change instruction, and determining whether to execute the change operation indicated by the change instruction based on the change risk level; if no change instruction is received within a preset statistical period, identifying static configuration nodes and dynamic configuration nodes in the knowledge graph, and performing multi-dimensional detection on the static configuration nodes and dynamic configuration nodes to obtain detection results, wherein static configuration nodes represent configuration parameters with fixed parameter values, and dynamic configuration nodes represent configuration parameters with parameter values ​​that change dynamically with the operating environment of the microservice architecture; and outputting prompt information corresponding to the detection results, wherein the prompt information is used to prompt the handling of the issues indicated by the detection results.

[0006] Optionally, a knowledge graph is generated based on relevant documents, including: parsing the source code and configuration files in the microservice delivery unit to obtain parsing results, wherein the configuration files are used to record configuration parameters that support the implementation of microservices through microservice interfaces; generating multiple mapping tables based on the parsing results, wherein the multiple mapping tables include: a first type of mapping table used to record the association between each microservice interface and configuration parameters, and a second type of mapping table used to record the call relationships between different microservices; and generating a knowledge graph based on the first type of mapping table, the second type of mapping table, and the configuration files.

[0007] Optionally, a knowledge graph is generated based on the first type of mapping table, the second type of mapping table, and the configuration file, including: generating a first type of node to represent a microservice interface based on the attribute information of each microservice interface recorded in the first type of mapping table, wherein each first type of node represents a microservice interface; generating a second type of node to represent a microservice based on the attribute information of each microservice recorded in the second type of mapping table, wherein each second type of node represents a microservice, and the attribute information of the microservice includes: configuration parameters associated with the microservice; and generating a third type of node to represent a configuration parameter based on each configuration parameter recorded in the configuration file, wherein each third type of node represents a microservice interface. A class node represents a type of microservice. During the generation of a third class node, different configuration parameters are distinguished by separators recorded in the configuration file. The first connection relationship between the first class node and the third class node is determined based on the association relationship recorded in the first class mapping table. The second connection relationship between multiple second class nodes is determined based on the call relationship recorded in the second class mapping table. The third connection relationship between the second class node and the third class node is determined based on the configuration parameters associated with the microservices recorded in the second class mapping table. A knowledge graph is generated based on multiple first class nodes, multiple second class nodes, multiple third class nodes, and the first, second, and third connection relationships.

[0008] Optionally, the change risk level is determined based on the knowledge graph and the specified change object carried by the change instruction, including: querying the target link to which the specified change object belongs in the knowledge graph, wherein the type of the specified change object includes: microservice, microservice interface; determining a first number of microservices and a second number of core microservice interfaces contained in the target link, wherein a core microservice interface is a microservice interface whose core score is greater than a preset score value, the core score is used to quantitatively evaluate the importance of the microservice interface to the microservice in the microservice architecture, and the core score is determined based on the number of links associated with the microservice interface in the knowledge graph; and determining the change risk level based on the first number and the second number.

[0009] Optionally, determining whether to execute the change operation indicated by the change instruction based on the change risk level includes: if the change risk level is the highest (Level 1), generating an approval work order based on the information recorded in the change instruction and the information recorded in the target link, sending the approval work order to multiple user terminals, receiving the response information of the approval work order, and determining whether to execute the change operation based on the response information; if the change risk level is the medium (Level 2), sending an approval work order to any user terminal, receiving the response information of the approval work order, and determining whether to execute the change operation based on the response information; if the change risk level is the lowest (Level 3), updating the configuration parameters of the specified change object to the new configuration parameters recorded in the change instruction, and then pushing the new configuration parameters of the specified change object to the configuration file management center to complete the change operation.

[0010] Optionally, after performing the change operation, the method further includes: obtaining the execution result of the change operation; if the execution result indicates that the update operation in the change operation failed, performing a rollback operation on the configuration parameters of the specified change object, wherein the update operation is used to indicate the operation of updating the configuration parameters of the specified change object to the new configuration parameters recorded in the change instruction, and the rollback operation is used to change the configuration parameters of the specified change object back to the original parameters; if the execution result indicates that the push operation in the change operation failed, performing a rollback operation on the configuration parameters of the specified change object and deleting the new configuration parameters pushed to the configuration file management center, wherein the push operation is used to push the new configuration parameters to the configuration file management center.

[0011] Optionally, multi-dimensional detection is performed on static and dynamic configuration nodes, including: consistency detection, where consistency detection indicates whether the parameter values ​​of static configuration nodes are consistent in different operating environments, and whether the parameter values ​​of dynamic configuration nodes meet the configuration requirements of the corresponding operating environments; redundancy detection, where redundancy detection indicates detecting redundant static and dynamic configuration nodes that do not belong to any link in the knowledge graph; and invalid relationship detection, where invalid relationship detection indicates whether the attribute information of static configuration nodes records information of a first type of target node, and whether the attribute information of dynamic configuration nodes records information of a second type of target node, where the first type of target node is a node located on the same link as the static configuration node, and the second type of target node is a node located on the same link as the dynamic configuration node.

[0012] Optionally, the output of prompt information corresponding to the detection results includes: if the detection result indicates that the consistency detection has failed, generating and outputting a first type of prompt information based on the first type of problematic nodes that failed the consistency detection, wherein the first type of prompt information is used to instruct the repair of the first type of problematic nodes; if the detection result indicates that the redundancy detection has failed, generating and outputting a second type of prompt information based on the redundant static configuration nodes and redundant dynamic configuration nodes in the detection result, wherein the second type of prompt information is used to instruct the deletion of the redundant static configuration nodes and redundant dynamic configuration nodes; if the detection result indicates that the invalid relationship detection has failed, generating a third type of prompt information based on the first type of invalid connection relationship and the second type of invalid connection relationship, wherein the third type of prompt information is used to instruct the deletion of the first type of invalid connection relationship and the second type of invalid connection relationship, wherein the first type of invalid connection relationship is the connection relationship between the first type of target node and the static configuration node, and the second type of invalid connection relationship is the connection relationship between the second type of target node and the dynamic configuration node.

[0013] According to another aspect of the embodiments of this application, an automated operation and maintenance device for a microservice architecture is also provided, comprising: an acquisition module, configured to acquire relevant files of the microservice architecture, wherein the microservice architecture provides multiple microservices, and the relevant files of the microservice architecture include: a microservice delivery unit for each microservice; a knowledge graph generation module, configured to generate a knowledge graph based on the relevant files, wherein the knowledge graph at least records the microservice interfaces of the microservices in the microservice architecture, the configuration parameters of the microservice interfaces, and the calling relationships between the microservices; and a risk level determination module, configured to, upon receiving a change instruction, determine the risk level based on the knowledge graph and the information carried by the change instruction. The system defines the change object and determines the change risk level, and decides whether to execute the change operation indicated by the change instruction based on the change risk level; the detection module is used to identify static and dynamic configuration nodes in the knowledge graph when no change instruction is received within a preset statistical period, and to perform multi-dimensional detection on static and dynamic configuration nodes to obtain detection results. Static configuration nodes represent configuration parameters with fixed parameter values, while dynamic configuration nodes represent configuration parameters whose parameter values ​​change dynamically with the microservice architecture's operating environment; the alarm module is used to output prompts corresponding to the detection results, where the prompts are used to prompt the handling of issues indicated by the detection results.

[0014] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, in which a computer program is stored, wherein the above-described automatic operation and maintenance method of the microservice architecture is executed by running the computer program on the device where the non-volatile storage medium is located.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described automatic operation and maintenance method of the microservice architecture through the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the steps of the above-described automatic operation and maintenance method for a microservice architecture.

[0017] In this embodiment, the following methods are employed: Obtaining relevant documents of the microservice architecture, which provides various microservices, and including microservice delivery units for each microservice; generating a knowledge graph based on these documents, wherein the knowledge graph at least records the microservice interfaces, configuration parameters of the microservice interfaces, and call relationships between microservices; upon receiving a change instruction, determining the change risk level based on the knowledge graph and the specified change object carried by the change instruction, and determining whether to execute the change operation indicated by the change instruction based on the change risk level; if no change instruction is received within a preset statistical period, identifying static and dynamic configuration nodes in the knowledge graph, and performing multi-dimensional detection on the static and dynamic configuration nodes to obtain detection results, wherein static configuration nodes represent configuration parameters with fixed values, and dynamic configuration nodes represent configuration parameters whose values ​​change with the microservice architecture. The system dynamically adjusts configuration parameters based on the operating environment of the microservice architecture; outputs prompts corresponding to the detection results, indicating how to handle issues indicated by the detection results. By constructing a knowledge graph, it achieves intelligent association between microservice interfaces and configuration parameters, as well as automatic identification of cross-service call relationships, shortening the operation and maintenance time of the microservice architecture. By establishing verification rules for configuration files, it automatically detects the completeness and format correctness of configuration items under different environments, avoiding system failures caused by configuration errors and improving the stability of the microservice architecture. The preset quantitative assessment and hierarchical approval mechanism for risk levels effectively prevents online failures caused by high-risk operations, improving system stability and security, and achieving the goal of automated operation and maintenance of the microservice architecture. This achieves the technical effect of improving the operation and maintenance efficiency and operational stability of the microservice architecture, thereby solving the technical problems of low operation and maintenance efficiency and unstable operation of the microservice architecture caused by manual operation and maintenance. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1This is a hardware structure block diagram of a computer terminal for implementing an automated operation and maintenance method for a microservice architecture, according to an embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating the steps of an automated operation and maintenance method for a microservice architecture according to an embodiment of this application.

[0021] Figure 3 This is a schematic diagram illustrating the generation of configuration nodes in an e-commerce service scenario according to an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of a configuration node table according to an embodiment of this application;

[0023] Figure 5 This is a list of functions for a configuration management interface according to an embodiment of this application;

[0024] Figure 6 This is a structural diagram of an automated operation and maintenance device for a microservice architecture according to an embodiment of this application;

[0025] Figure 7 This is a distributed storage result of a knowledge graph according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0029] Microservice architecture: Microservice architecture decomposes a software application into a set of microservices that can be deployed and scaled independently, each microservice being built around a specific business function.

[0030] Microservice interface: In a microservice architecture, the microservice interface is the port through which microservice components communicate and exchange data.

[0031] Non-leaf nodes: In the scenario described in this embodiment, non-leaf nodes act as bridges in the tree structure, responsible for linking different configuration levels or categories. They are used to accommodate more child configuration nodes, rather than directly storing configuration information.

[0032] Leaf node: In the scenario described in this embodiment, a leaf node refers to a node at the bottom level of the configuration hierarchy that directly stores the specific values ​​and metadata of the configuration.

[0033] In related technologies, microservice architectures are manually maintained, which leads to problems such as low operational efficiency and poor operational effectiveness. To address this issue, this application provides a relevant solution, which is described in detail below.

[0034] According to an embodiment of this application, an embodiment of an automated operation and maintenance method for a microservice architecture is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing an automated operation and maintenance method for a microservice architecture is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0036] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the automatic operation and maintenance method of the microservice architecture in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned automatic operation and maintenance method of the microservice architecture. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0038] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0039] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0040] This application provides an automated operation and maintenance method for a microservice architecture that can run in the above-described operating environment. Figure 2 This is a flowchart illustrating the steps of an automated operation and maintenance method for a microservice architecture provided in an embodiment of this application, as follows: Figure 2 As shown, the method includes the following steps:

[0041] Step S202: Obtain the relevant documents for the microservice architecture. The microservice architecture is used to provide multiple microservices. The relevant documents for the microservice architecture include: the microservice delivery unit for each microservice.

[0042] This application provides a configuration management technology for a microservice architecture. Through static analysis, knowledge graphs, and a dynamically synchronized intelligent microservice configuration management system, it addresses issues such as "fuzzy relationships, high change risks, asynchronous dynamic configurations, and difficulty in tracing cross-service dependencies" in related technologies for operating and maintaining microservice architectures. In step S202, static analysis is performed on the configuration files of the microservice architecture. Specifically, a configuration information collection process is initiated to collect relevant files of the microservice architecture. Specifically, the microservice delivery units that integrate various microservices within the microservice architecture can be collected. Each microservice delivery unit records all necessary components, configurations, and prepared deployable entities for a microservice, containing all resources and information required for microservice operation. That is, a microservice delivery unit may contain Docker images, deployment scripts, configuration files, and other information.

[0043] Step S204: Generate a knowledge graph based on relevant documents. The knowledge graph is used to record at least the microservice interfaces of the microservices in the microservice architecture, the configuration parameters of the microservice interfaces, and the calling relationships between the microservices.

[0044] In step S204, the data obtained in step S202 is integrated to construct a full-link knowledge graph of "microservice-interface-configuration-cross-service call". That is, each link in the knowledge graph records the microservice interface used to implement a microservice, the configuration parameters that the microservice interface depends on, and the cross-service call relationship of the microservice corresponding to this link. For example, if microservice A can only be implemented by calling microservice B and microservice C, then microservice B and microservice C have a call relationship with microservice A (i.e., a cross-service call relationship).

[0045] According to some optional embodiments of this application, generating a knowledge graph based on relevant documents includes: parsing the source code and configuration files in the microservice delivery unit to obtain parsing results, wherein the configuration files are used to record configuration parameters that support the implementation of microservices through microservice interfaces; generating multiple mapping tables based on the parsing results, wherein the multiple mapping tables include: a first type of mapping table used to record the association between each microservice interface and configuration parameters, and a second type of mapping table used to record the calling relationships between different microservices; and generating a knowledge graph based on the first type of mapping table, the second type of mapping table, and the configuration files.

[0046] The microservice architecture files obtained in step S202 contain microservice delivery units for each microservice. Each microservice delivery unit includes the source code of each microservice (including control class parameter annotations (@RestController), cross-service call annotations (@FeignClient), and parameter value annotations (@Valu), etc.) and microservice configuration files (such as application service configuration files (application.yaml)). When constructing the knowledge graph, the source code and configuration files in the microservice delivery units are deeply analyzed to extract the associations between all microservice interfaces and configuration parameters, as well as the call relationships between different microservices. For example, when scanning the source code, the `@RestController` annotation is parsed to obtain the interface URL, such as the resource name (`order`) and creation action (`create`) in the URL. The interface call chain is traced (interface → utility class → configuration usage method). The mapping relationship between `@Value` and microservices and parameters (`@ConfigurationProperties`) can be parsed to extract configuration keys (such as `order.max-amount`). Each configuration key records the association relationship between microservice interfaces and configuration parameters. When encountering cross-service (Feign) calls, the `@FeignClient` annotation is parsed to extract the mapping relationship of "caller service - target service (i.e., the called microservice) - target interface (the call interface between two services)". Only the identifier (ID) of the caller service, the ID of the target service, the ID of the target interface, and the fully qualified class name of the Feign interface are recorded, without going into the downstream parsing. In this embodiment, the information obtained from the above parsing serves as a data source for constructing a knowledge graph. The interface-configuration association (i.e., the association between microservice interfaces and configuration parameters) is stored in the URL configuration mapping table (url_config_mapping table) (i.e., the first type of mapping table), and the Feign call relationship is stored in the cross-service call configuration mapping table (feign_config_mapping table) (i.e., the second type of mapping table).

[0047] The method provided in this embodiment uses an Abstract Syntax Tree (AST) to parse the source code to extract the interface URL and configuration key, parses the @FeignClient annotation to obtain the cross-service call mapping, and constructs a knowledge graph based on the parsed information to present the full-link dependency relationship between microservices in a visual way, thereby improving the speed of problem location and decision-making efficiency during operation and maintenance.

[0048] Next, taking the order service and payment service of an e-commerce system as specific application scenarios, we will illustrate the process of parsing the microservice delivery unit. For the order service and payment service, the source code obtained includes: the source code of the order service (order-service source code) contains the control class parameters of the order service (OrderController) and the payment call (PayFeignClient) interface; the source code of the payment service (pay-service source code) contains the control class parameters of the payment service (PayController class) and the cross-service call configuration file of the two services (application-dev.yaml configuration file). The process of parsing the above information is as follows: Source code scanning: Parse the `@RestController` annotation of `order-service` to extract the microservice interface associated with the path " / order / create (create order microservice)"; trace the call chain: " / order / create → OrderService → PayFeignClient → configuration usage method", and extract the configuration key `order.max-amount` (maximum order amount) by parsing `@Value("${order.max-amount}")`; parse the `@RestController` annotation of the payment service (`pay-service`) to extract the microservice interface with the path " / pay / create (create payment microservice)"; and extract the configuration key `pay.timeout` (payment service timeout) by `@Value("${pay.timeout}")`. Cross-service call scanning: Parse the `@FeignClient(value = "pay-service")` annotation of `order-service` to extract the caller service ID (`service_id=1` of `order-service`), the payment service ID (`service_id=2` of `pay-service`), and the payment creation service interface ID (`interface_id=3` of ` / pay / create`). After performing the above parsing operations, the parsed information is stored in the following way: the "interface-configuration association" is stored in the url_config_mapping table. In the url_config_mapping table, mapping_id=1, order service identifier (service_id)=1, interface identifier (interface_id)=1 (ID of the microservice interface with path / order / create), configuration node identifier (config_node_id)=1, and the node ID of the configuration key order.max-amount.The Feign call relationships are stored in the feign_config_mapping table. In the order.max-amount table, the cross-service call identifier (feign_id) = 1, the caller service identifier (caller_service_id) = 1, the caller service identifier (target_service_id) = 2, and the caller interface identifier (target_interface_id) = 3.

[0049] Optionally, a knowledge graph is generated based on the first type of mapping table, the second type of mapping table, and the configuration file, including: generating a first type of node to represent a microservice interface based on the attribute information of each microservice interface recorded in the first type of mapping table, wherein each first type of node represents a microservice interface; generating a second type of node to represent a microservice based on the attribute information of each microservice recorded in the second type of mapping table, wherein each second type of node represents a microservice, and the attribute information of the microservice includes: configuration parameters associated with the microservice; and generating a third type of node to represent a configuration parameter based on each configuration parameter recorded in the configuration file, wherein each third type of node represents a microservice interface. A class node represents a type of microservice. During the generation of a third class node, different configuration parameters are distinguished by separators recorded in the configuration file. The first connection relationship between the first class node and the third class node is determined based on the association relationship recorded in the first class mapping table. The second connection relationship between multiple second class nodes is determined based on the call relationship recorded in the second class mapping table. The third connection relationship between the second class node and the third class node is determined based on the configuration parameters associated with the microservices recorded in the second class mapping table. A knowledge graph is generated based on multiple first class nodes, multiple second class nodes, multiple third class nodes, and the first, second, and third connection relationships.

[0050] The results of parsing the files obtained in step S202 will be used as data for constructing a knowledge graph, thereby building a full-link knowledge graph of "microservice-interface-configuration-cross-service call" to achieve visualization and traceability of relationships. Since the first type of mapping table (url_config_mapping) stores the association between microservice interfaces and configuration parameters, traversing the first type of mapping table (url_config_mapping) can extract the attribute information of each microservice interface, such as interface_id (microservice interface ID), microservice interface URL, and the ID of the service to which each microservice interface belongs. Each node representing a microservice interface in the knowledge graph (i.e., the first type of node) carries the above attribute information. Each first type of node represents a microservice interface, such as the order interface and create interface in the order service scenario and the payment service scenario. The second type of mapping table (feign_config_mapping) stores the call relationships between microservices. Therefore, the caller service identifier (caller_service_id) and the calling interface identifier (target_service_id) of each microservice can be obtained from the feign_config_mapping table. Combined with the microservice's attribute information (such as microservice name and status), nodes representing microservices (i.e., second-type nodes) are generated, such as the order-service and pay-service nodes in the order service scenario and the payment service scenario. Each node representing a microservice also carries the attribute information of the microservice it represents, such as the configuration parameters used to execute the microservice. The caller_service_id can be understood as the identifier of the microservice represented by the node, and the target_service_id can be understood as which interface other microservices use to call the microservice represented by the node.Furthermore, the knowledge graph constructed according to the scheme provided in this application also includes nodes representing configuration parameters (i.e., third-type nodes). These third-type nodes are generated by scanning configuration files and dividing them according to delimiters in the configuration files. For example, the levels are split by the delimiter (“.”). Taking order.max-amount mentioned in the above embodiment as an example, order.max-amount will be split into two levels: order and order.max-amount. Each level generates an independent (third-type) node. Among the two configuration nodes (i.e., third-type nodes) obtained from splitting order.max-amount, since there are more granular configuration items (order.max-amount) under Order, therefore, in the knowledge... In the configuration hierarchy, the configuration node representing "order" is a non-leaf node. For non-leaf nodes, their node identifier (node_id) and root node identifier (parent_id) are 0, and their multi-environment metadata (content) is empty (it only serves as a container to hold more child configuration nodes, rather than directly storing configuration information). "order.max-amount" is the lowest level of this configuration hierarchy, and the node connected above it is "order," which is a leaf node of "Order." For leaf nodes, "node_id" is auto-incremented, and "parent_id" points to the parent node (such as the "node_id" of "order"). The multi-environment metadata stored in "content" contains the specific value of this configuration item ("order.max-amount") and other relevant information in each environment.

[0051] The above describes how nodes in a knowledge graph are generated. Next, we describe a method for determining the connection relationships between different nodes. In this embodiment, for third-type nodes that have hierarchical information, a "parent configuration node → child configuration node" contain association is constructed based on the hierarchical relationship to connect third-type nodes with contain associations. A "contain" association indicates that a configuration node (parent node) acts as a container, containing one or more more specific configuration nodes (child nodes). For example, the configuration node order contains the configuration node order.max-amount, with the configuration node order as the parent node and order.max-amount as the child node connected to the configuration node order. The association between a microservice interface and its configuration parameters (i.e., the first connection relationship) and the association between a microservice and its configuration parameters (i.e., the third connection relationship) are called single-service associations. Single-service associations can be constructed based on the `url_config_mapping` table (i.e., the first type of mapping table). Specifically, the association between a microservice interface and its configuration parameters (i.e., the first connection relationship) can be constructed based on the `url_config_mapping` table. The first connection relationship includes a direct association of "interface → leaf configuration node" and an indirect association of "preceding interface → leaf configuration node" can be derived through the interface call chain. Furthermore, based on the association between the interface and its configuration parameters in the `url_config_mapping` table and the microservice call relationship (i.e., the cross-service call relationship) in the `feign_config_mapping` table (i.e., the second mapping table), the dependency relationship between the calling microservice and the target microservice configuration parameters (i.e., the third connection relationship) can be jointly determined. The third connection relationship includes the dependency relationship of "calling interface → target service leaf configuration node". The cross-service call relationship (i.e., the second connection relationship) between different microservices can be extracted from the feign_config_mapping table. The second connection relationship includes the call relationship of "calling microservice → target microservice (the called microservice)". In the solution provided in this embodiment, all associations (including entity type, relationship type, association ID, and additional information) in the knowledge graph can be stored in a table that records information in the form of "node_service_relation" to enable the visualization of the knowledge graph (such as service dependency topology graph and configuration influence chain graph).

[0052] The method adopted in this embodiment generates a knowledge graph based on the parsing results of the microservice delivery unit, providing powerful visualization support for the operation and maintenance of the microservice architecture, significantly improving the query speed when querying various relationships in the microservice architecture, and improving the efficiency of system maintenance.

[0053] Next, using the order-service and pay-service of an e-commerce system as specific application scenarios, we will detail the implementation process of building the knowledge graph. First, nodes are generated based on the parsing results of the microservice delivery units of order-service and pay-service. Microservice nodes (i.e., the second type of node) are generated using the following methods: The following attribute information for order-service is read from the service information table (service_info): service_id=1, status=1 (current status is active), generating a node representing order-service. Similarly, the following attribute information for pay-service is read: service_id=2, status=1, generating a node representing pay-service. Interface nodes are generated using the following methods: The interface information table (interface_info) is read from the microservice interface called by the order service at path " / order / create (order service - create)" with interface_id=1, service_id=1. The microservice interface called by the microservice at path " / pay / create (payment service - create)" with interface_id=3, service_id=2. Configuration nodes are generated based on... Figure 3 The method shown generates it. Figure 3 This is a diagram illustrating the generation of configuration nodes in an e-commerce service scenario, such as... Figure 3As shown, in the e-commerce service scenario, the configuration nodes include: order, order.max-amount, payment configuration (pay), and pay.timeout. Among them, order.max-amount and pay.timeout are leaf nodes that store multi-environment metadata (content). Both the order.max-amount node and the pay.timeout node store configuration parameters such as runtime environment, value, and type. The relationships between the nodes are constructed using the following methods: Parent-child relationships are configured (relationships between nodes are configured): node_id=1→node_id=10 (order contains order.max-amount), node_id=2→node_id=20 (pay contains pay.timeout); In single-service relationships, the relationships between interfaces and configuration parameters include: interface_id=1→node_id=1 ( / order / create depends on order.max-amount), interface_id=3→node_id=2 ( / pay / create depends on pay.timeout); Cross-service relationships include: service_id=1→service_id=2 (order-service calls pay-service), interface_id=1→node_id=2 ( / order / create depends on pay.timeout via Feign); After generating the knowledge graph of e-commerce services based on the above nodes and relationships, the relationships stored in the knowledge graph can be stored in the node_service_relation table to support visualization operations of the knowledge graph.

[0054] Step S206: Upon receiving a change instruction, determine the change risk level based on the knowledge graph and the specified change object carried by the change instruction, and determine whether to execute the change operation indicated by the change instruction based on the change risk level.

[0055] After successfully constructing the full-link knowledge graph of the microservice architecture in step S204, the constructed instruction graph can be used to manage the configuration information of the microservice architecture, and through the management of the configuration information of the microservice architecture, automatic operation and maintenance of the microservice architecture can be achieved. For example, in step S206, changes to the microservice architecture can be implemented based on the knowledge graph. Specifically, when the system executing the method provided in this application embodiment receives a change instruction, it can determine the scope of impact of the change operation when performing a change operation on the specified change object carried in the change instruction based on the link recorded in the knowledge graph. Further, the change risk level is determined according to the scope of impact and a preset risk level quantification method. Finally, it is determined whether to execute the change operation indicated by the change instruction based on the change risk level to ensure the security of the change operation. The change operation can be a change to the configuration parameters of the microservice, a change to the microservice itself, etc.

[0056] According to some optional embodiments of this application, determining the change risk level based on the knowledge graph and the specified change object carried by the change instruction includes: querying the target link to which the specified change object belongs in the knowledge graph, wherein the type of the specified change object includes: microservice, microservice interface; determining a first number of microservices and a second number of core microservice interfaces contained in the target link, wherein a core microservice interface is a microservice interface whose core score is greater than a preset score value, the core score is used to quantitatively evaluate the importance of the microservice interface to the microservice in the microservice architecture, and the core score is determined based on the number of links associated with the microservice interface in the knowledge graph; and determining the change risk level based on the first number and the second number.

[0057] In a microservice architecture, changes to configuration files can affect multiple microservices and interfaces. Without effective risk assessment and management mechanisms, this can lead to a decrease in the overall stability and reliability of the system. This embodiment aims to determine the potential risk level of configuration changes through the analysis of knowledge graphs and change instructions, thereby assisting in decision-making and change implementation. With the knowledge graph constructed, if a configuration change instruction (i.e., a change command) is received, the impact of the change operation corresponding to the change instruction on the microservice architecture is determined based on the information carried in the change command and the knowledge graph. Specifically, the change operation includes modifying configuration files (e.g., adding, modifying, or deleting configurations). The information carried in the change command includes: the microservice or microservice interface whose configuration parameters are to be modified (i.e., the specified change object). Based on the constructed knowledge graph, all links associated with the specified change object (i.e., the target links) can be determined, and all nodes contained in the target links are included in the scope of the change operation. For example, taking `order.max-amount` as an example, the target link may include `order-service`, the interface with the path " / order / create", `pay-service`, etc. After identifying all links associated with the specified change object (i.e., target links), the change risk level of the change operation indicated by the change instruction is determined jointly based on the number of microservices involved in the target link (i.e., the first number) and the number of core microservice interfaces (i.e., the second number). In this embodiment, the number of microservices involved in the target link can be determined by the microservice nodes (i.e., the second type of nodes) contained on the target link. However, not all microservice interfaces contained on the target link are core microservice interfaces. In this embodiment, the coreness of the microservice interface represented by the interface node (i.e., the first type of node) is determined based on the number of links associated with the interface node. The more links an interface node is associated with, the higher its coreness. For example, if an interface node is associated with 5 links, then its coreness can be determined as 5. The coreness score can be equal to the coreness or determined based on the weight of the coreness and the microservice interface. The weight of the microservice interface is preset based on the importance of the microservices associated with the microservice interface. Interfaces represented by interface nodes with a coreness score greater than the preset score (e.g., 5 points) are determined as core microservice interfaces.

[0058] The method provided in this embodiment determines the change risk level of change instructions based on preset risk level quantification rules and knowledge graphs, avoiding the execution of various operations on the microservice architecture without clearly understanding the impact of the operation on the microservice architecture, thereby reducing the system failure rate.

[0059] Optionally, determining whether to execute the change operation indicated by the change instruction based on the change risk level includes: if the change risk level is the highest (Level 1), generating an approval work order based on the information recorded in the change instruction and the information recorded in the target link, sending the approval work order to multiple user terminals, receiving the response information of the approval work order, and determining whether to execute the change operation based on the response information; if the change risk level is the medium (Level 2), sending an approval work order to any user terminal, receiving the response information of the approval work order, and determining whether to execute the change operation based on the response information; if the change risk level is the lowest (Level 3), updating the configuration parameters of the specified change object to the new configuration parameters recorded in the change instruction, and then pushing the new configuration parameters of the specified change object to the configuration file management center to complete the change operation.

[0060] This application provides an approval and execution mechanism based on change risk levels. Through automated processes and a multi-level approval system, it improves the security and operational efficiency of configuration changes. Specifically, for high-risk change operations, a dual approval mechanism is implemented. This means that for high-risk change operations, approval work orders are sent to multiple user terminals. The decision to execute the high-risk change operation is jointly determined based on the multiple response messages returned by these user terminals. For example, approval work orders are sent to user terminals with different risk levels. These different risk levels represent different operational permissions for the microservice architecture; for instance, the risk level of an operations engineer's terminal differs from that of an operations supervisor. The aforementioned approval work order is determined based on the related links (i.e., target links) in the knowledge graph between the change instruction and the change request. The approval work order specifically records the change details of the change instruction, such as the specified change object, the configuration parameters of the specified change object before the change, and the configuration parameters of the specified change object after the change (i.e., the new configuration parameters). For medium-risk change operations, a single approval mechanism is implemented. This means that for a medium-risk change operation, only one approval work order needs to be sent to a single user terminal. The decision to execute the medium-risk change operation is determined based on the response information returned by that single user terminal. For example, the approval work order can be sent to the user terminal of an operations engineer or a development engineer. For low-risk change operations, there is no need to generate and send an approval work order. After receiving the change instruction, the operation can be executed according to the instructions. For example, if the change instruction indicates modifying the configuration parameters of the object to be changed (order.max-amount) to the new configuration parameters, and the operation is determined to be low-risk, the system implementing the solution provided in this embodiment will modify the configuration parameters of order.max-amount to the new configuration parameters recorded in the change execution and synchronize the new configuration parameters to the configuration file management center and the code repository. In this embodiment, the code repository allows developers to create and use it on their local computers and synchronize it with other repositories. The configuration file management center is a configuration management and service management platform that provides dynamic domain name resolution services, service metadata management, namespace access control, and real-time configuration monitoring.

[0061] In this embodiment, whether the change operation indicated by the change instruction is a high-risk, medium-risk, or low-risk change operation is determined jointly based on the number of microservices (i.e., the first number) and the number of core microservice interfaces (i.e., the second number) involved in the link (i.e., the target data link) associated with the change instruction in the knowledge graph. For example, a microservice number threshold of 2 and a core microservice interface threshold of 3 can be preset. When the number of microservices involved in the target link (i.e., the first number) is ≥2 and the number of core microservice interfaces involved in the target link (i.e., the second number) is ≥3, the change risk level is determined to be the highest, the first risk level. The risk level is determined as follows: if the number of microservices involved in the target link (i.e., the first number) is ≥2, or the number of core microservice interfaces involved in the target link (i.e., the second number) is ≥3, then the risk level is determined to be medium (second level), and the change instruction indicates a medium-risk change operation; if the number of microservices involved in the target link (i.e., the first number) is <2, and the number of core microservice interfaces involved in the target link (i.e., the second number) is <3, then the risk level is determined to be low (third level), and the change instruction indicates a low-risk change operation.

[0062] Optionally, after performing the change operation, the method further includes: obtaining the execution result of the change operation; if the execution result indicates that the update operation in the change operation failed, performing a rollback operation on the configuration parameters of the specified change object, wherein the update operation is used to indicate the operation of updating the configuration parameters of the specified change object to the new configuration parameters recorded in the change instruction, and the rollback operation is used to change the configuration parameters of the specified change object back to the original parameters; if the execution result indicates that the push operation in the change operation failed, performing a rollback operation on the configuration parameters of the specified change object and deleting the new configuration parameters pushed to the configuration file management center, wherein the push operation is used to push the new configuration parameters to the configuration file management center.

[0063] This embodiment of the application sets up a dual rollback mechanism to address the failure of change operations. This mechanism enables automated rollback and recovery of change operations, ensuring that the system can quickly return to a safe state even in the event of a failed change. The execution of a change operation consists of two phases: the first phase updates the new configuration parameters to the code repository (i.e., an update operation), and the second phase synchronizes the new configuration parameters to the file management center (i.e., a push operation). The second phase occurs only if the first phase succeeds. This embodiment sets up different rollback mechanisms based on the different stages of failure. If problems are encountered during the process of updating the new configuration parameters to the code repository, such as network issues or limitations of the code repository itself preventing successful update submission, the system will perform a partial rollback operation. This means only the modifications made in the configuration node (config_node) table are rolled back, and only the configuration parameters of the specified changed object after the change operation are restored to their state before the change operation (i.e., the original parameters). If the process of pushing new configuration parameters to the file management center fails—for example, due to the file management center's server being unreachable or the configuration format not conforming to the file management center's acceptance standards—the system will perform a full rollback. This means not only restoring the configuration parameters of the specified changed object to their state before the change operation (i.e., the original parameters), but also deleting the newly pushed configuration parameters from the file management center and deleting any incomplete push processes. Furthermore, in the method provided in this embodiment, regardless of at which stage a failure occurs, after the corresponding rollback mechanism is executed, the system will also record a failure log and provide a retry entry point for subsequent troubleshooting and re-attempting configuration synchronization.

[0064] The method provided in this embodiment designs corresponding automated rollback and recovery mechanisms for different failure scenarios, ensuring that even if the change fails, the system can quickly recover to a safe state, avoiding system shutdown due to automated operation and maintenance failures, and ensuring the stability of system operation.

[0065] The steps described in S206 above, including determining the risk level of the change instruction, applying the risk level, using multiple approval mechanisms based on the risk level, and implementing a double rollback mechanism for change failures, can be summarized as follows: For example, user operation: The user selects the microservice to be changed (specifying the change object), configuration node, operating environment (multiple selections are possible), and operation type (add, modify, or delete) on the interactive interface; by calling the knowledge graph interface (getConfigRelations), the interface and microservice associated with the user-specified configuration change operation are queried, and a pop-up window displays the impact chain (i.e., the target chain). For example, the current configuration change impact... The system affects 2 microservices and 3 core microservice interfaces. Based on the information in the impact chain, the user-specified change operation is determined to be a high-risk operation (such as deleting configuration nodes that core interfaces depend on). Therefore, a work order approval process is triggered, recording the operator, scope of impact, and reason for the change in the approval work order. If the received response indicates that the user terminal has approved the change, the configuration operation is further executed (adding or modifying the contents of the `config_node` table, or deleting microservices marked as offline (`status=0`). If the above operation to update configuration parameters fails, a partial rollback operation is performed: the changed configuration parameters are restored to their original values. If the above operation to update configuration parameters is successfully executed, the updated values ​​of the configuration parameters are further synchronized to the configuration file management center. If synchronization fails, the `config_node` table is automatically rolled back to its state before the operation, and the configuration parameters pushed to the configuration file management center are deleted, with a failure log recorded. If synchronization is successful, a success log is recorded. In this embodiment, all operation logs generated by the above change operation can be stored in the configuration operation log (`config_operate_log`) for traceability. Additionally, for microservices, microservice interfaces, and other configuration parameters unaffected by the changes, the `node_service_relation` table can be scanned periodically (e.g., every 30 minutes) to check the validity of relationships such as "configuration → interface" and "configuration → dynamic configuration" (e.g., whether the interface has been deleted or the dynamic configuration has become invalid). Cleanup prompts should be pushed out to prevent invalid relationships from impacting risk assessments. In the example above, risk levels are predicted through change level analysis, erroneous operations are blocked through an approval mechanism, and the "difficult to recover from bad changes" problem is solved through a rollback mechanism, reducing the failure rate of configuration changes and improving system stability.

[0066] Step S208: If no change instruction is received within the preset statistical period, identify static configuration nodes and dynamic configuration nodes in the knowledge graph, and perform multi-dimensional detection on static configuration nodes and dynamic configuration nodes to obtain detection results. Static configuration nodes represent configuration parameters with fixed parameter values, while dynamic configuration nodes represent configuration parameters with dynamically changing parameter values ​​depending on the microservice architecture's operating environment.

[0067] As described in the above embodiments, the management of configuration information of the microservice architecture can realize the automatic operation and maintenance of the microservice architecture. The automatic operation and maintenance also includes multi-dimensional detection of the microservice architecture. For example, in step S208, a knowledge graph can be used to realize multi-dimensional detection of the microservice architecture. Specifically, if it is within a preset statistical period (e.g., every 1 hour) and no other operation and maintenance operations need to be performed (e.g., no change instruction is received, indicating that no change operation needs to be performed), then static configuration nodes and dynamic configuration nodes are identified in the knowledge graph and multi-dimensional detection is performed on them. The multi-dimensional detection includes: detecting whether there are configuration parameters, whether the format of the configuration parameters is correct, and other aspects. The static and dynamic configuration nodes mentioned above are nodes representing configuration parameters in the knowledge graph. Static configuration nodes represent configuration parameters with fixed values. For example, for the order service, the predefined maximum amount and payment timeout duration are configuration parameters with fixed values. Dynamic configuration nodes represent configuration parameters whose values ​​change dynamically with the operating environment of the microservice architecture. For example, for the order service, the key required to call the interface (Application Programming Interface, API) of external services and the address for interaction between the microservice and the message middleware are configuration parameters whose values ​​change dynamically with the operating environment of the microservice architecture.

[0068] According to some optional embodiments of this application, multi-dimensional detection is performed on static configuration nodes and dynamic configuration nodes, including: consistency detection of static configuration nodes and dynamic configuration nodes, wherein consistency detection indicates whether the parameter values ​​of static configuration nodes are consistent in different operating environments, and whether the parameter values ​​of dynamic configuration nodes in different operating environments meet the configuration requirements corresponding to the operating environment; redundancy detection of static configuration nodes and dynamic configuration nodes, wherein redundancy detection indicates detecting redundant static configuration nodes and redundant dynamic configuration nodes that do not belong to any link in the knowledge graph; invalid relationship detection of static configuration nodes and dynamic configuration nodes, wherein invalid relationship detection indicates whether the attribute information of static configuration nodes records information of a first type of target node, and whether the attribute information of dynamic configuration nodes records information of a second type of target node, wherein the first type of target node is a node located on the same link as the static configuration node, and the second type of target node is a node located on the same link as the dynamic configuration node.

[0069] The method provided in this application divides the nodes in the knowledge graph into two categories: static configuration nodes and dynamic configuration nodes. Static configuration nodes are generated based on static configuration parameters, while dynamic configuration nodes are generated based on dynamic configuration parameters. In this embodiment, static configuration parameters refer to configuration items that are determined during microservice deployment and do not change much or at all during service operation. Static configuration parameters are typically related to business logic, such as data timeout time and business parameter thresholds, and their values ​​are preset to fixed values. Dynamic configuration parameters refer to configuration parameters that may change during service operation based on external systems (such as the runtime environment) or requirements. Dynamic configuration items include database connection information and middleware addresses, and their specific parameter values ​​usually depend on the external system. For example, the configuration parameter value of the same dynamic configuration item in different environments such as development (dev), testing (test), pre-release (pre), and production (release) is determined by the specific runtime environment. In the method provided in this embodiment, when the knowledge graph is stored in a data table, the configuration nodes in the knowledge graph will be stored in a configuration node table (config_node table). Figure 4 This is a diagram illustrating the configuration of the node table, such as... Figure 4 As shown, to clearly distinguish between static and dynamic configuration parameters, the config_node table uses a source type field to identify the parameter type and adopts a differentiated lightweight data exchange format (JSON structure) for the content field; therefore, dynamic and static configuration nodes in the knowledge graph can be distinguished based on the source field.

[0070] After distinguishing between static and dynamic configuration nodes in the knowledge graph, an automated detection mechanism is used to perform multi-dimensional checks on both to ensure the health of configuration data and the stable operation of the system. These multi-dimensional checks include consistency checks, redundancy checks, and invalid relation checks. For static configuration nodes, the consistency check specifically involves verifying whether the value field of the same static configuration node is consistent across different runtime environments. For dynamic configuration nodes, the consistency check specifically involves confirming whether the value of the dynamic configuration node meets the configuration requirements of the corresponding runtime environment based on the config_type and value associated with each runtime environment recorded in the dynamic configuration node table (dynamic_config table). For example, does mysql-username point to the correct database account in both the dev and release environments? When performing redundancy detection based on a visualized knowledge graph, nodes in the knowledge graph that are not directly or indirectly associated with any link, whether static or dynamic, are marked as redundant nodes (redundant static or dynamic configuration nodes). The specific operation for performing redundancy detection based on static and dynamic configuration nodes stored in tabular form is as follows: Nodes in the `config_node` table that have "no interface association (no `url_config_mapping` record) and no dynamic configuration association (no `relate_dc` type relationship in the `node_service_relation` table) are marked as redundant nodes (redundant static or dynamic configuration nodes). When performing invalid relationship detection on each static configuration node based on the visualized knowledge graph, the information (such as ID) of nodes located on the same link as the static configuration node to be detected (i.e., the first type of target node) is queried from the attribute information carried by the static configuration node to be detected. Similarly, when performing invalid relationship detection on each dynamic configuration node based on the visualized knowledge graph, the information (such as ID) of nodes located on the same link as the dynamic configuration node to be detected (i.e., the second type of target node) is queried from the attribute information carried by the dynamic configuration node to be detected. When performing invalidation detection based on static configuration nodes stored in the `config_node` table, the `node_service_relation` table identifies the node associated with the static configuration node (the first type of target node). If the first type of target node represents a microservice interface, the `interface_info` table checks if the interface represented by the first type of target node exists. If it does not exist, the first type of target node is marked as a redundant static configuration node. If the first type of target node represents a microservice, the `status` field of the microservice represented by the first type of target node is checked in the `service_info` table. If `status=0`, the first type of target node is marked as a redundant static configuration node.If the first type of target node represents a configuration item (configuration parameter), the parameter value of the configuration item represented by the first type of target node is queried in the `config_node` table. If it differs from the parameter value recorded in the `config_node` table, the first type of target node is marked as a redundant static configuration node. When performing invalidation detection based on the dynamic configuration nodes stored in the `config_node` table, the node associated with the dynamic configuration node (i.e., the second type of target node) is determined in the `node_service_relation` table. If the second type of target node represents a microservice interface, the existence of the interface represented by the second type of target node is checked in the `interface_info` table. If it does not exist, the second type of target node is marked as a redundant dynamic configuration node. If the second type of target node represents a microservice, the `status` field of the microservice represented by the second type of target node is checked in the `service_info` table. If `status=0`, the second type of target node is marked as a redundant dynamic configuration node. If the second type of target node represents a configuration item (configuration parameter), then the parameter value of the configuration item represented by the second type of target node is queried in the config_node table. If it is different from the parameter value recorded in the config_node table, then the second type of target node is marked as a redundant static configuration node (or a redundant dynamic configuration node). The above multi-dimensional detection can be performed periodically according to a preset period (e.g., 30 minutes).

[0071] The method provided in this embodiment performs multi-dimensional checks on static and dynamic configuration nodes, including consistency checks, redundancy checks, and invalid relationship checks, by periodically and automatically executing a detection mechanism. This ensures the health of configuration data and the stable operation of the system, avoiding the limitations of manual detection.

[0072] Step S210: Output the prompt information corresponding to the detection result, wherein the prompt information is used to prompt the processing of the detection result indication problem.

[0073] For the multi-dimensional detection operations included in automated operation and maintenance, after obtaining the detection results of the multi-dimensional detection, in step S210, the prompt information corresponding to the detection results is output. The prompt information records the problems detected during the multi-dimensional detection. Therefore, the output prompt information is also different when the detection results are different. Pushing the prompt information to the user terminal or configuration management interface of the operation and maintenance personnel helps to quickly locate and handle the problems existing in the microservice architecture.

[0074] Optionally, the output of prompt information corresponding to the detection results includes: if the detection result indicates that the consistency detection has failed, generating and outputting a first type of prompt information based on the first type of problematic nodes that failed the consistency detection, wherein the first type of prompt information is used to instruct the repair of the first type of problematic nodes; if the detection result indicates that the redundancy detection has failed, generating and outputting a second type of prompt information based on the redundant static configuration nodes and redundant dynamic configuration nodes in the detection result, wherein the second type of prompt information is used to instruct the deletion of the redundant static configuration nodes and redundant dynamic configuration nodes; if the detection result indicates that the invalid relationship detection has failed, generating a third type of prompt information based on the first type of invalid connection relationship and the second type of invalid connection relationship, wherein the third type of prompt information is used to instruct the deletion of the first type of invalid connection relationship and the second type of invalid connection relationship, wherein the first type of invalid connection relationship is the connection relationship between the first type of target node and the static configuration node, and the second type of invalid connection relationship is the connection relationship between the second type of target node and the dynamic configuration node.

[0075] In this embodiment, corresponding prompts are output based on the detection results from the multi-dimensional detection performed in step S208, so that operations and maintenance personnel can promptly address the detected issues and complete the operation and maintenance of the microservice architecture. Specifically, in this embodiment, if the consistency detection fails, a configuration inconsistency repair prompt (i.e., the first type of prompt) will be output. This prompt records the inconsistencies marked during the consistency detection process (such as microservices and / or microservice interfaces whose associated configuration parameter values ​​differ in different operating environments). For example, if the value of `order.max-amount` is detected as 1000 in the `dev` environment and 1500 in the `release` environment, which does not meet the consistency standard, the first type of prompt is: "The value of `order.max-amount` is inconsistent in the `dev` and `release` environments; `dev=1000`, `release=1500`. Please fix this problem through the knowledge graph interface or by directly editing the configuration file."

[0076] If the redundancy detection fails, a redundancy configuration deletion prompt (i.e., the second type of prompt) will be output. The redundancy configuration deletion prompt lists the redundant static configuration nodes and redundant dynamic configuration nodes that need to be deleted. For example, if a periodic scan of the config_node table identifies that the database timeout configuration key is not referenced in any link and is considered a redundant static configuration node, the second type of prompt will be output as: "The configuration key database.timeout is not referenced in any service link. Confirm whether it needs to be deleted."

[0077] If the invalid relationship detection fails, an invalid relationship cleanup prompt (i.e., the third type of prompt) will be output. This prompt lists the relationships that need to be deleted. These relationships can be either statically configured nodes and their associated other nodes (i.e., first-type target nodes) (i.e., first-type invalid connections), or dynamically configured nodes and their associated other nodes (i.e., second-type target nodes) (i.e., second-type invalid connections). For example, if an invalid association is detected between the `order.max-amount` configuration key of `order-service` and `pay-service`, but `pay-service` does not depend on this configuration key in the knowledge graph, the third type of prompt will be: "An invalid connection relationship has been detected between `order.max-amount` and `pay-service`. Please check the relevant service dependencies and delete unnecessary associations."

[0078] The method provided in this embodiment outputs prompt information corresponding to the detection results, so that maintenance personnel can quickly locate the problem, shorten the maintenance time, and improve maintenance efficiency.

[0079] The method provided in this embodiment can be implemented in the configuration management interface mentioned in step S210. In this embodiment, the configuration management interface is an interactive interface that provides visual interactive capabilities such as "multi-environment selection - configuration merging display - dynamic association - right-click editing - icon splitting." Therefore, the configuration management interface supports merging and displaying runtime environments with the same configuration parameters, solving the problems of scattered environment configurations, unintuitive association status, and cumbersome batch operations. In this embodiment, the configuration management interface adopts a four-layer architecture of "service selection - configuration tree display - editing interaction - status feedback." Figure 5 This is the function list of the configuration management interface. As can be seen from the content recorded in the function list of the configuration management interface, the "Service Selection" function supports the selection of microservices and operating environments (supporting multiple selections); the configuration tree display function supports merging and displaying nodes that have passed consistency checks (consistency checks of static configuration nodes and consistency checks of dynamic configuration nodes); the editing interaction function supports modifying a single running environment, and also supports modifying multiple running environments at the same time; the status feedback function supports real-time display of configuration modification results and icon split status.

[0080] Next, we will give an example to illustrate how users can implement... Figure 5The interactive operations performed on the configuration management interface of the functions described herein, if the user selects order-service in the configuration management interface and checks the "dev" and "release" environments; the front end will call the getMergedConfigTree interface, and the back end will return hierarchical configuration nodes: the parent node order (node_id=10) is expandable, the child node order.max-amount (node_id=1) displays a merge icon (green on the left, red on the right, without "..."). The interface tree view displays the hierarchy "order → order.max-amount", with a hover tooltip indicating "Contains: dev, release, static configuration". If the user expands the order node, right-clicks the order.max-amount merge icon (showing the dev + release merge status), and selects "Edit Environment Configuration": changes the dev environment value to 1500, and keeps the release environment value at 1000; clicks "Save", the frontend calls the update static configuration (updateStaticConfig) interface, passing node_id=1 (unique node ID) and environment configuration values ​​(env_values={"dev":1500,"release":1000}. The backend will then perform the following processing: maintain node uniqueness (node_id=1 remains unchanged), only update the content field to distinguish environment configurations, and execute the following code:

[0081] {

[0082] "dev":{ / / Runtime environment: development;

[0083] "value": 1500, / / The parameter value is 1500;

[0084] "source": "staticConfig", / / Type: Static configuration node;

[0085] "updateTime":"2023-AB 15:00:00" / / Records the latest modification time of the dev environment;

[0086] },;

[0087] "release": { / / Runtime environment: production;

[0088] "value": 1000, / / The parameter value is 1000;

[0089] "source": "staticConfig", / / Type: Static configuration node;

[0090] "updateTime": "2023-AB 10:30:00" / / Retains historical modification times for the release environment;

[0091] };

[0092] }

[0093] The front-end interface feedback (“icon splitting” is only a visual representation) is as follows: the original merged icons (green on the left and red on the right) are split into two independent visual units, but still belong to the same node: the left side displays the dev environment: a pure green icon with a value of “1500”, and a mouse hover tooltip “Environment: dev, last updated: 15:00”; the right side displays the release environment: a pure red icon with a value of “1000”, and a mouse hover tooltip “Environment: release, last updated: 10:30”; clicking on either environment icon automatically positions the editing interface to the corresponding environment's input box, and after modification, it still updates to the content field of the same node.

[0094] If the user operation involves selecting the `pay.timeout` node within the `pay-service` directory, right-clicking and selecting "Associate Dependency Configuration"; then selecting "mysql-username" from the list, the frontend will call the `bindDynamicToConfig` interface to bind dynamic configuration to the configuration node table. The backend will then update the `content` of `node_id=2` to reflect the dynamic configuration structure. The backend execution code is as follows:

[0095] {

[0096] "dev":{"configType":"mysql-username","source":"dynamicConfig","bindTime": "2023-C-D16:00:00"}, / / In the development environment, the associated dynamic configuration type is the database username, the type is dynamic configuration, and the timestamp of the configuration node bound to the dynamic configuration type is 2023-C-D16:00:00;

[0097] "release":{"configType": "mysql-username","source":"dynamicConfig", "bindTime": "2023-C-D16:00:00"} / / In the production environment, the associated dynamic configuration type is the database username, the type is dynamic configuration, and the timestamp of the configuration node bound to the dynamic configuration type is 2023-C-D16:00:00;

[0098] }

[0099] The front-end interface feedback is as follows: The pay.timeout icon has been added with a correlation marker, and the value is displayed as "mysql-username→ root_dev (main account in development environment)" (dev) and "mysql-username→ root_prod (main account in production environment)" (release); hovering prompts "Correlation: mysql-username".

[0100] After performing the above operations, the operations personnel updated the release environment value of dc_id=5 in the dynamic_config table to "root_new". 30 minutes later, the scheduled task detected the change, updated the release configuration file of pay-service in the codebase, and pushed it to the configuration file management center. The front-end interface showed the following: a WebSocket push event was displayed, the pay.timeout(release) value was updated to "root_new", and the "↑ Updated" label was displayed. After completing the above operations, if the user clicks the order node and selects "View All Sub-Configurations", the front-end interface displays all child nodes under order (order.max-amount(dev), order.max-amount(release)); right-clicking order.max-amount(dev) and selecting "View Influence Chain" displays the following in the knowledge graph interface: order.max-amount(dev) ←depend_on ← / order / create ←call ← / pay / create, clearly showing the dependency relationships.

[0101] Through the above steps, a multi-environment verification, code linkage, and automatic synchronization mechanism for configuration files can be built based on configuration file metadata and code scanning technology. This enables full lifecycle management of configuration files, thereby achieving automated operation and maintenance of microservice architectures and improving the technical effects of improving the operational efficiency and enhancing system stability of microservice architectures.

[0102] Figure 6 This is a structural diagram of an automated operation and maintenance device for a microservice architecture provided in the embodiments of this application, as shown below. Figure 6As shown, the automated operation and maintenance device for a microservice architecture includes: an acquisition module 60, used to acquire relevant files of the microservice architecture, wherein the microservice architecture provides multiple microservices, and the relevant files of the microservice architecture include: a microservice delivery unit for each microservice; a knowledge graph generation module 62, used to generate a knowledge graph based on the relevant files, wherein the knowledge graph records at least the microservice interfaces of the microservices in the microservice architecture, the configuration parameters of the microservice interfaces, and the calling relationships between microservices; and a risk level determination module 64, used to determine the risk level based on the knowledge graph and the specified change object carried by the change instruction when a change instruction is received. The system further classifies risk levels and determines whether to execute the change operation indicated by the change instruction based on the risk level. A detection module 66 identifies static and dynamic configuration nodes in the knowledge graph when no change instruction is received within a preset statistical period. It performs multi-dimensional detection on both static and dynamic configuration nodes to obtain detection results. Static configuration nodes represent configuration parameters with fixed values, while dynamic configuration nodes represent configuration parameters whose values ​​change dynamically with the microservice architecture's operating environment. An alarm module 68 outputs prompts corresponding to the detection results, indicating the issues to be addressed.

[0103] When the automated operation and maintenance device of the microservice architecture described above executes the method provided in this application embodiment, the acquisition module 60 is responsible for acquiring the relevant files of the microservice architecture to be operated and maintained. These files include: microservice delivery units for each microservice provided by the microservice architecture. Each microservice unit includes source code and a configuration file. The microservice delivery unit provides a data foundation for subsequent analysis and automated operation and maintenance. For example, the microservice delivery unit includes: microservice source code (including @RestController / @FeignClient / @Value annotations) and a configuration file (such as application.yaml). Next, the knowledge graph generation module 62 constructs a full-link knowledge graph based on the files acquired by the acquisition module 60. The acquisition module 60 can use an Abstract Syntax Tree (AST) to parse the microservice source code to extract the interface URL and configuration key, parse the @FeignClient annotation to obtain cross-service call mappings, and finally store the interface-configuration association in the url_config_mapping table (i.e., the first type of mapping table) and the Feign call relationship in the feign_config_mapping table (i.e., the second type of mapping table). The knowledge graph is constructed based on the information obtained from the above parsing. Figure 7This is the distributed storage result of the knowledge graph. In the solution provided in this embodiment, the information used to construct the knowledge graph can be stored as seven tables. These seven tables are linked by foreign keys (PK) to form a data link centered on microservices, supporting data reading, writing, and related queries for all modules. Figure 7 As shown, the knowledge graph can be stored as seven tables that can be linked via foreign keys (PK): service_info, interface_info, configuration_node, dynamic_config, url_config_mapping, feign_config_mapping, and node_service_relation. After constructing the knowledge graph, if a configuration change instruction is received, the risk level determination module 64 analyzes the impact of the change instruction on the entire chain based on the knowledge graph and the received change instruction, determines the change risk level (low, medium, high), and decides whether to execute the change instruction based on the determined change risk level. In the method provided in this embodiment, change operations of different risk levels are subject to corresponding approval mechanisms. For example, high-risk change operations are executed with double approval, medium-risk change operations are executed with single approval, and low-risk change operations are executed automatically, ensuring the security and controllability of configuration changes. If no change instruction is received within a preset statistical period (e.g., hourly), the detection module 66 performs periodic multi-dimensional detection. The detection module 66 automatically scans static and dynamic configuration nodes in the knowledge graph, performing multi-dimensional detection including consistency checks, redundancy checks, and invalid relationship checks to identify potential configuration problems. The alarm module 68 outputs prompts corresponding to the detection results output by the detection module 66. These prompts remind users to address the issues indicated in the detection results. In this embodiment, the prompts include: a first type of prompt reminding users to repair nodes that failed the consistency check; a second type of prompt reminding users to delete redundant configuration nodes; and a third type of prompt suggesting the deletion of invalid connections. These prompts can be sent to maintenance personnel via an interactive interface or email to ensure timely resolution of issues.

[0104] It should be noted that, Figure 6 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2 The relevant descriptions of the embodiments shown will not be repeated here.

[0105] This application also provides a non-volatile storage medium storing a computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned automatic operation and maintenance method of microservice architecture by running the computer program.

[0106] The aforementioned non-volatile storage medium is used to store programs that perform the following functions: acquiring relevant files of the microservice architecture, wherein the microservice architecture provides various microservices, and the relevant files include: a microservice delivery unit for each microservice; generating a knowledge graph based on the relevant files, wherein the knowledge graph records at least the microservice interfaces, configuration parameters of the microservice interfaces, and call relationships between microservices in the microservice architecture; upon receiving a change instruction, determining the change risk level based on the knowledge graph and the specified change object carried by the change instruction, and determining whether to execute the change operation indicated by the change instruction based on the change risk level; if no change instruction is received within a preset statistical period, identifying static and dynamic configuration nodes in the knowledge graph, and performing multi-dimensional detection on the static and dynamic configuration nodes to obtain detection results, wherein static configuration nodes represent configuration parameters with fixed parameter values, and dynamic configuration nodes represent configuration parameters whose parameter values ​​change dynamically with the operating environment of the microservice architecture; and outputting prompt information corresponding to the detection results, wherein the prompt information is used to prompt the handling of the issues indicated by the detection results.

[0107] This application also provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to execute the above-described microservice architecture automatic operation and maintenance method through the computer program.

[0108] The processor in the aforementioned electronic device is used to run a program that performs the following functions: acquiring relevant files of the microservice architecture, wherein the microservice architecture provides various microservices, and the relevant files include: a microservice delivery unit for each microservice; generating a knowledge graph based on the relevant files, wherein the knowledge graph records at least the microservice interfaces, configuration parameters of the microservice interfaces, and call relationships between microservices in the microservice architecture; upon receiving a change instruction, determining the change risk level based on the knowledge graph and the specified change object carried by the change instruction, and determining whether to execute the change operation indicated by the change instruction based on the change risk level; if no change instruction is received within a preset statistical period, identifying static configuration nodes and dynamic configuration nodes in the knowledge graph, and performing multi-dimensional detection on the static and dynamic configuration nodes to obtain detection results, wherein static configuration nodes represent configuration parameters with fixed parameter values, and dynamic configuration nodes represent configuration parameters whose parameter values ​​change dynamically with the operating environment of the microservice architecture; and outputting prompt information corresponding to the detection results, wherein the prompt information is used to prompt the handling of the issues indicated by the detection results.

[0109] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the steps of the above-described automatic operation and maintenance method for a microservice architecture.

[0110] It should be noted that the modules in the operation and maintenance device of the microservice architecture described above can be program modules (such as a set of program instructions that implement a certain function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0111] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0112] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0114] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0115] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0116] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or 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, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0117] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An automated operation and maintenance method for a microservice architecture, characterized in that, include: Obtain the relevant documents for the microservice architecture, wherein the microservice architecture is used to provide multiple microservices, and the relevant documents for the microservice architecture include: a microservice delivery unit for each of the microservices; A knowledge graph is generated based on the relevant documents, wherein the knowledge graph is used to record at least the microservice interfaces of the microservices in the microservice architecture, the configuration parameters of the microservice interfaces, and the calling relationships between the microservices; Upon receiving a change instruction, the change risk level is determined based on the knowledge graph and the specified change object carried by the change instruction, and the change operation indicated by the change instruction is executed based on the change risk level. If no change instruction is received within the preset statistical period, static configuration nodes and dynamic configuration nodes are identified in the knowledge graph, and multi-dimensional detection is performed on the static configuration nodes and dynamic configuration nodes to obtain detection results. The static configuration nodes represent configuration parameters with fixed parameter values, and the dynamic configuration nodes represent configuration parameters with dynamically changing parameter values ​​according to the operating environment of the microservice architecture. Output a prompt message corresponding to the detection result, wherein the prompt message is used to prompt the user to handle the problem indicated by the detection result.

2. The method according to claim 1, characterized in that, Generate a knowledge graph based on the relevant documents, including: The source code and configuration files in the microservice delivery unit are parsed to obtain the parsing results. The configuration files are used to record the configuration parameters that support the implementation of the microservice interface. Multiple mapping tables are generated based on the parsing results, wherein the multiple mapping tables include: a first type of mapping table for recording the association between each microservice interface and the configuration parameters, and a second type of mapping table for recording the call relationship between different microservices; The knowledge graph is generated based on the first type of mapping table, the second type of mapping table, and the configuration file.

3. The method according to claim 2, characterized in that, The knowledge graph is generated based on the first type of mapping table, the second type of mapping table, and the configuration file, including: A first type of node is generated to represent each microservice interface according to the attribute information of each microservice interface recorded in the first type of mapping table, wherein each first type of node represents one microservice interface; and a second type of node is generated to represent each microservice according to the attribute information of each microservice recorded in the second type of mapping table, wherein each second type of node represents one type of microservice, and the attribute information of the microservice includes configuration parameters associated with the microservice; and a third type of node is generated to represent each configuration parameter recorded in the configuration file, wherein each third type of node represents one type of microservice, and different configuration parameters are distinguished by a separator recorded in the configuration file during the generation of the third type of node. A first connection relationship between the first type of node and the third type of node is determined according to the association relationship recorded in the first type of mapping table; and a second connection relationship between multiple second type of nodes is determined according to the call relationship recorded in the second type of mapping table; and a third connection relationship between the second type of node and the third type of node is determined according to the microservice association configuration parameters recorded in the second type of mapping table. The knowledge graph is generated based on multiple first-type nodes, multiple second-type nodes, multiple third-type nodes, the first connection relationship, the second connection relationship, and the third connection relationship.

4. The method according to claim 1, characterized in that, The change risk level is determined based on the knowledge graph and the specified change object carried by the change instruction, including: The target link to which the specified change object belongs is queried in the knowledge graph, wherein the type of the specified change object includes: the microservice and the microservice interface; Determine a first number of microservices and a second number of core microservice interfaces contained in the target link, wherein the core microservice interfaces are microservice interfaces whose core score is greater than a preset score value. The core score is used to quantitatively evaluate the importance of the microservice interface to the microservice in the microservice architecture. The core score is determined based on the number of links associated with the microservice interface in the knowledge graph. The change risk level is determined based on the first quantity and the second quantity.

5. The method according to claim 4, characterized in that, Determining whether to execute the change operation indicated by the change instruction based on the change risk level includes: When the change risk level is the highest level, an approval work order is generated based on the information recorded in the change instruction and the information recorded in the target link. The approval work order is sent to multiple user terminals, and the response information of the approval work order is received. The change operation is then determined based on the response information. If the change risk level is Level 2, indicating moderate change risk, the approval work order is sent to any of the user terminals, and the response information of the approval work order is received. Based on the response information, it is determined whether to execute the change operation. When the change risk level is the third level, which indicates the lowest change risk, after updating the configuration parameters of the specified change object to the new configuration parameters recorded in the change instruction, the new configuration parameters of the specified change object are pushed to the configuration file management center to complete the change operation.

6. The method according to claim 1, characterized in that, After performing the change operation, the method further includes: Obtain the execution result of the change operation. If the execution result indicates that the update operation in the change operation failed, perform a rollback operation on the configuration parameters of the specified change object. The update operation is used to indicate the operation of updating the configuration parameters of the specified change object to the new configuration parameters recorded in the change instruction. The rollback operation is used to change the configuration parameters of the specified change object back to the original parameters. If the execution result indicates that the push operation in the change operation failed, the configuration parameters of the specified change object are rolled back, and the new configuration parameters pushed to the configuration file management center are deleted, wherein the push operation is used to push the new configuration parameters to the configuration file management center.

7. The method according to claim 1, characterized in that, Multi-dimensional detection is performed on the static and dynamic configuration nodes, including: A consistency check is performed on the static configuration node and the dynamic configuration node, wherein the consistency check indicates whether the parameter values ​​of the static configuration node are consistent in different operating environments, and whether the parameter values ​​of the dynamic configuration node in different operating environments meet the configuration requirements corresponding to the operating environment. Redundancy detection is performed on the static configuration nodes and the dynamic configuration nodes, wherein the redundancy detection indicates the detection of redundant static configuration nodes and redundant dynamic configuration nodes that do not belong to any link in the knowledge graph; Invalid relationship detection is performed on the static configuration node and the dynamic configuration node. The invalid relationship detection indicates whether the attribute information of the static configuration node contains information of a first type of target node, and whether the attribute information of the dynamic configuration node contains information of a second type of target node. The first type of target node is a node located on the same link as the static configuration node, and the second type of target node is a node located on the same link as the dynamic configuration node.

8. The method according to claim 7, characterized in that, Output the prompt information corresponding to the detection result, including: If the detection result indicates that the consistency test has failed, a first type of prompt information is generated based on the first type of problem node that failed the consistency test, and the first type of prompt information is output, wherein the first type of prompt information is used to indicate the repair of the first type of problem node; If the detection result indicates that the redundancy detection has failed, a second type of prompt information is generated based on the redundant static configuration node and the redundant dynamic configuration node in the detection result, and the second type of prompt information is output, wherein the second type of prompt information is used to indicate the deletion of the redundant static configuration node and the redundant dynamic configuration node; If the detection result indicates that the invalid relationship detection has failed, a third type of prompt information is generated based on the first type of invalid connection relationship and the second type of invalid connection relationship. The third type of prompt information is used to indicate the deletion of the first type of invalid connection relationship and the second type of invalid connection relationship. The first type of invalid connection relationship is the connection relationship between the first type of target node and the static configuration node, and the second type of invalid connection relationship is the connection relationship between the second type of target node and the dynamic configuration node.

9. An automated operation and maintenance device for a microservice architecture, characterized in that, include: The acquisition module is used to acquire relevant files of the microservice architecture, wherein the microservice architecture is used to provide multiple microservices, and the relevant files of the microservice architecture include: a microservice delivery unit for each microservice; A knowledge graph generation module is used to generate a knowledge graph based on the relevant files, wherein the knowledge graph is used to record at least the microservice interfaces of the microservices in the microservice architecture, the configuration parameters of the microservice interfaces, and the calling relationships between the microservices; The risk level determination module is used to determine the change risk level based on the knowledge graph and the specified change object carried by the change instruction when a change instruction is received, and to determine whether to execute the change operation indicated by the change instruction based on the change risk level. The detection module is used to identify static configuration nodes and dynamic configuration nodes in the knowledge graph when no change instruction is received within a preset statistical period, and to perform multi-dimensional detection on the static configuration nodes and dynamic configuration nodes to obtain detection results. The static configuration nodes represent configuration parameters with fixed parameter values, and the dynamic configuration nodes represent configuration parameters with parameter values ​​that change dynamically with the operating environment of the microservice architecture. An alarm module is used to output prompt information corresponding to the detection result, wherein the prompt information is used to prompt the handling of the problem indicated by the detection result.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, wherein the device where the non-volatile storage medium is located executes the automatic operation and maintenance method of the microservice architecture according to any one of claims 1 to 8 by running the computer program.

11. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the automated operation and maintenance method of the microservice architecture according to any one of claims 1 to 8 through the computer program.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the automated operation and maintenance method for the microservice architecture as described in any one of claims 1 to 8.

Images