A method and apparatus for managing configuration parameters

Abstract

The application discloses a kind of management method and device of configuration parameter, comprising: first application node obtains upload instruction;In response to upload instruction, download instruction is sent to second application node;Download instruction is used to indicate that second application node switches to download state;First application node switches to upload state;After determining that the configuration parameter of first application node is updated, updated configuration parameter is sent to second application node, to indicate that second application node loads updated configuration parameter.Wherein, first application node is any application node in microservice architecture;Second application node is any application node except first application node in microservice architecture;Download state indicates that second application node allows to load configuration parameter;Upload state indicates that the configuration parameter of first application node is allowed to update.Easy to this microservice architecture, reduce the operation and maintenance workload and complexity of each application node in microservice architecture, improve the efficiency of configuration parameter management.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and apparatus for managing configuration parameters. Background Technology

[0002] As the internet matures, data volumes are increasing dramatically, making maintenance extremely difficult. Therefore, existing technologies utilize microservice architecture to improve data processing efficiency. A microservice architecture comprises multiple application nodes; these nodes connect different networks and provide specific application services based on their configured parameters. This enables intelligent data management, offering management advantages for data technology and information management systems.

[0003] Currently, there are generally two methods for managing the configuration parameters loaded in application nodes.

[0004] In a microservice architecture, each application node connects directly to the database, which manages the configuration parameters of each application node. The microservice gateway cluster represents a collection of application gateways that implement microservices.

[0005] Second, the configuration parameters of each application node in the microservice architecture are managed through a configuration center. The configuration center connects to both the database and each application node, and uses ZooKeeper (a reliable coordination system for distributed systems) to publish and subscribe to configuration parameters.

[0006] However, in the above approach, each application node needs to connect directly to the database or configuration center, making the maintenance workload of the database or configuration center for each application node cumbersome, increasing the burden of maintenance work, and affecting the efficiency of configuration parameter management. In addition, as the number of application nodes increases, it can easily lead to unstable database or configuration center connections, resulting in service interruptions. Summary of the Invention

[0007] This invention provides a method and apparatus for managing configuration parameters, which is used to lightweight microservice architecture, reduce the workload and complexity of operation and maintenance of each application node in the microservice architecture, and improve the efficiency of configuration parameter management.

[0008] In a first aspect, embodiments of the present invention provide a method for managing configuration parameters, comprising:

[0009] The first application node obtains the upload command; the first application node can be any application node in the microservice architecture;

[0010] In response to the upload command, the first application node sends a download command to the second application node; the download command is used to instruct the second application node to switch to download mode; the download mode indicates that the second application node is allowed to load configuration parameters; the second application node is any application node in the microservice architecture other than the first application node;

[0011] The first application node switches to upload mode; the upload mode indicates that the configuration parameters of the first application node are allowed to be updated.

[0012] After the first application node determines that its configuration parameters have been updated, it sends the updated configuration parameters to the second application node to instruct the second application node to load the updated configuration parameters.

[0013] In the above technical solution, the application nodes in the microservice architecture no longer connect directly to the database or configuration center. Instead, the management of configuration parameters (such as modification, addition, and deletion of parameters) is achieved through communication between the application nodes within the microservice architecture. This reduces the microservice architecture's dependence on external component systems (such as databases and configuration centers), thereby making the microservice architecture lightweight, reducing the complexity and workload of operation and maintenance, and improving the efficiency of configuration parameter management in the microservice architecture.

[0014] Furthermore, microservice architectures are not limited by resources or the number of application nodes during development, reducing development workload and thus improving development efficiency. Moreover, when managing configuration parameters for each application node in a microservice architecture, the configuration parameters are first updated on any application node (the first application node), and then that application node distributes the updated configuration parameters to other application nodes (the second application nodes). This eliminates concerns about configuration parameter updates failing due to application node failures, enhancing the security of configuration parameter management.

[0015] Optionally, after the first application node receives the upload instruction, it also includes:

[0016] The first application node determines whether it is in an idle state; if so, it responds to the upload command; the idle state indicates that the application node is allowed to respond to the command.

[0017] Otherwise, the upload command will not be responded to.

[0018] In the above technical solution, after the first application node receives the upload command, it first determines whether it is in an idle state. If so, it means that the first application node is not currently running other processes, i.e., it is not responding to other upload commands, and therefore can respond to this upload command. Otherwise, it means that the first application node is currently responding to other upload commands, and therefore is not allowed to respond to this upload command. This ensures the accuracy and security of configuration parameter management.

[0019] Optionally, the download instruction is further used to instruct the second application node to add a read-write lock to the configuration parameters of the second application node after switching to the download state; the read-write lock is used to prohibit write operations on the configuration parameters of the second application node.

[0020] In the above technical solution, by instructing the second application node to add a read-write lock to its own configuration parameters, other application nodes are prevented from updating the configuration parameters at the same time, thereby ensuring the accuracy and security of configuration parameter management.

[0021] Optionally, before the first application node switches to the upload state, it further includes:

[0022] The first application node receives the response result fed back by the second application node based on the download instruction;

[0023] The first application node determines whether to switch to upload mode based on the response result.

[0024] Optionally, the first application node determines whether to switch to the upload state based on the response result, including:

[0025] If the response result is "successful switch", then the first application node switches to the upload state; the successful switch indicates that the second application node switches to the download state.

[0026] If the response result is a switching failure, the first application node will not switch to the upload state; the switching failure indicates that the second application node has not switched to the download state.

[0027] In the above technical solution, the first application node will only switch to the upload state when the second application node switches to the download state, thereby preventing the second application node from being unable to update configuration parameters and ensuring the accuracy and security of configuration parameter management.

[0028] Optionally, after the first application node switches to upload mode, it further includes:

[0029] The first application node receives the configuration file;

[0030] The first application node reads the parameters from the configuration file;

[0031] The first application node loads the parameters from the configuration file into the configuration parameters of the first application node.

[0032] Optionally, after the first application node determines that its configuration parameters have been updated and sends the updated configuration parameters to the second application node, the method further includes:

[0033] The first application node receives the loading result fed back by the second application node based on the updated configuration parameters;

[0034] When the first application node determines that the loading result is successful, it sends a reset command to the second application node to instruct the second application node to switch to an idle state.

[0035] Secondly, embodiments of the present invention provide a configuration parameter management device, comprising:

[0036] The acquisition module is used to obtain upload instructions;

[0037] The processing module is configured to respond to the upload instruction by sending a download instruction to the second application node; the download instruction is configured to instruct the second application node to switch to download mode; the download mode indicates that the second application node is allowed to load configuration parameters; the second application node is any application node in the microservice architecture other than the first application node; the first application node is any application node in the microservice architecture;

[0038] Switch the first application node to upload mode; the upload mode indicates that the configuration parameters of the first application node are allowed to be updated.

[0039] After determining that the configuration parameters of the first application node have been updated, the updated configuration parameters are sent to the second application node to instruct the second application node to load the updated configuration parameters.

[0040] Optionally, the processing module is further configured to:

[0041] After receiving the upload command, it is determined whether the first application node is in an idle state; if so, it responds to the upload command; the idle state indicates that the application node is allowed to respond to the command.

[0042] Otherwise, the upload command will not be responded to.

[0043] Optionally, the download instruction is further used to instruct the second application node to add a read-write lock to the configuration parameters of the second application node after switching to the download state; the read-write lock is used to prohibit write operations on the configuration parameters of the second application node.

[0044] Optionally, the processing module is further configured to:

[0045] Before switching the first application node to the upload state, receive the response result from the second application node based on the download instruction;

[0046] Based on the response result, determine whether to switch the first application node to upload mode.

[0047] Optionally, the processing module is specifically used for:

[0048] If the response result is "successful switch", then the first application node is switched to the upload state; "successful switch" means that the second application node is switched to the download state.

[0049] If the response result is a switching failure, the first application node will not be switched to the upload state; the switching failure indicates that the second application node has not been switched to the download state.

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

[0051] After switching the first application node to upload mode, it receives the configuration file;

[0052] Read the parameters from the configuration file;

[0053] The parameters in the configuration file are loaded into the configuration parameters of the first application node.

[0054] Optionally, the processing module is further configured to:

[0055] After determining that the configuration parameters of the first application node have been updated, the updated configuration parameters are sent to the second application node, and the loading result fed back by the second application node based on the updated configuration parameters is received.

[0056] When the loading result is determined to be successful, a reset command is sent to the second application node to instruct the second application node to switch to an idle state.

[0057] Thirdly, embodiments of the present invention also provide a computer device, comprising:

[0058] Memory, used to store program instructions;

[0059] The processor is used to call the program instructions stored in the memory and execute the management method of the above configuration parameters according to the obtained program.

[0060] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described management method for configuration parameters. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 A schematic diagram illustrating configuration parameter management as provided in an embodiment of the present invention;

[0063] Figure 2 A schematic diagram illustrating configuration parameter management as provided in an embodiment of the present invention;

[0064] Figure 3 A schematic diagram of a microservice architecture provided in an embodiment of the present invention;

[0065] Figure 4 A flowchart illustrating a method for managing configuration parameters provided in an embodiment of the present invention;

[0066] Figure 5 A schematic diagram illustrating the management of configuration parameters provided in an embodiment of the present invention;

[0067] Figure 6 A schematic diagram illustrating the management of configuration parameters provided in an embodiment of the present invention;

[0068] Figure 7 A schematic diagram illustrating the management of configuration parameters provided in an embodiment of the present invention;

[0069] Figure 8 This is a schematic diagram of a configuration parameter management device provided in an embodiment of the present invention. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0071] In a microservice architecture, application nodes support core front-end functionalities such as access control, traffic splitting, rate limiting, and central switching. The configuration parameters of existing application nodes are typically obtained through a database or a centralized configuration center. It's important to note that the application service functions corresponding to each application node within the same microservice architecture are identical.

[0072] Figure 1 This is a schematic diagram illustrating a configuration parameter management method as exemplified in an embodiment of the present invention, such as... Figure 1 As shown, each application node in the microservice architecture is directly connected to the database. During configuration parameter maintenance, operations personnel directly modify the data in the database and then notify each application node to read the modified data by calling the parameter interface provided by each application node, thereby updating the configuration parameters in each application node.

[0073] The number of application nodes is n, and there is no limit to the number of application nodes.

[0074] Figure 2 This is a schematic diagram illustrating a configuration parameter management method as exemplified in an embodiment of the present invention, such as... Figure 2 As shown, the configuration center reads and writes to the database (or cache server). The configuration center registers its instance information with ZooKeeper and subscribes to the instance information of each application node. Each application node registers its own instance information with ZooKeeper and subscribes to the configuration center's instance information. Each application node can proactively download configuration parameters from the configuration center. The configuration center can proactively push updated configuration parameters to each application node.

[0075] In other words, operations and maintenance personnel will update the configuration parameters in the database, and then the configuration center will read the updated configuration parameters from the database and push the updated configuration parameters to each application node through ZooKeeper's publish and subscribe service.

[0076] Based on the above description Figure 1 In the current technical solution, each application node directly connects to the database to obtain configuration parameters. After updating the configuration parameters in the database, operations personnel need to send update commands to each application node sequentially to ensure the new parameters take effect in real time, so that each application node loads the new parameters from the database. However, as the number of application nodes in the microservice architecture increases, the operation and maintenance work of operating each application node individually becomes more cumbersome, increasing the burden on operations and maintenance; moreover, loading errors are prone to occur during operations and maintenance, affecting the accuracy of configuration parameter management.

[0077] Furthermore, as the carrier of persistent configuration and the data source, the database needs to establish connections with each application node in the microservice architecture. As the number of application nodes increases, the connection between the database and the application nodes can become unstable. When the database fails, the security of application nodes reading configuration parameters from the database cannot be guaranteed, affecting the security of configuration parameter management.

[0078] Figure 2 In technical solutions, configuration centers typically integrate supporting components such as ZooKeeper, databases, and caches, further complicating the microservice architecture. The stable acquisition of configuration parameters by each application node also depends on the high availability of these components. If any component of the configuration center fails, the entire configuration center cannot function properly, affecting the security of configuration parameter management.

[0079] Therefore, there is an urgent need for a configuration parameter management method to achieve lightweight microservice architecture, reduce the workload and complexity of operation and maintenance of each application node in the microservice architecture, and improve the efficiency of configuration parameter management.

[0080] Figure 3 An exemplary microservice architecture applicable to an embodiment of the present invention is illustrated, comprising application node A, application node B, and application node C. It should be noted that this embodiment uses three application nodes as an example, but the number of application nodes is not limited.

[0081] Application node A, as the first application node, includes a management module A1, a loading module A2, and a communication module A3. Application nodes B and C, as the second application nodes, include a management module B1, a loading module B2, and a communication module B3; and application node C includes a management module C1, a loading module C2, and a communication module C3.

[0082] In this embodiment of the invention, the application node management module includes three states during operation: "idle state," "download state," and "upload state." Only the first application node switches to the upload state, and only the second application node switches to the download state. The upload state indicates that the configuration parameters of the first application node are being updated; the download state indicates that the second application node is allowed to load the configuration parameters; and the idle state indicates that the application node is allowed to respond to commands.

[0083] based on Figure 3 The management module A1 receives upload commands and then checks its own status to see if it is idle. If so, it sends download commands to application nodes B and C via communication module A3.

[0084] Application node B and application node C receive download instructions through their own communication modules B3 and C3, respectively. In response to the download instructions, they switch their own state to download state and send the switching result back to application node A.

[0085] After receiving the switchover result, if application node A confirms that the switchover was successful, it will switch its status to upload. At this time, operations and maintenance personnel are allowed to update the configuration parameters in application node A through management module A1. For example, operations and maintenance personnel can load a configuration file in management module A1.

[0086] Application node A's loading module A2 reads the parameters from the configuration file and then loads the parameters from the configuration file into the configuration parameters of the first application node, thereby updating the configuration parameters.

[0087] After application node A updates its configuration parameters, it sends the updated configuration parameters to application nodes B and C via communication module A3. This allows application nodes B and C to receive the updated configuration parameters and then call their respective loading modules B2 and C2 to load the updated parameters into their own configuration parameters, thus achieving configuration parameter updates for each application node in the microservice architecture.

[0088] It should be noted that the above Figure 3 The structure shown is merely an example, and the embodiments of the present invention are not limited thereto.

[0089] Based on the above description Figure 4 An exemplary flowchart of a configuration parameter management method provided by an embodiment of the present invention is shown, which can be executed by a configuration parameter management device.

[0090] like Figure 4 As shown, the process specifically includes:

[0091] Step 410: The first application node obtains the upload instruction.

[0092] In this embodiment of the invention, the first application node is any application node in the microservice architecture; the upload command is triggered by the operations and maintenance personnel on the first application node, indicating that the configuration parameters of each application node in the microservice architecture need to be managed. For example, it indicates that the configuration parameters of each application node in the microservice architecture need to be updated.

[0093] Step 420: In response to the upload command, the first application node sends a download command to the second application node.

[0094] In this embodiment of the invention, the download instruction is used to instruct the second application node to switch to the download state; the download state indicates that the second application node is allowed to load configuration parameters; the second application node is any application node in the microservice architecture other than the first application node.

[0095] Step 430: The first application node switches to upload mode.

[0096] In this embodiment of the invention, the upload status indicates that the configuration parameters of the first application node are allowed to be updated. The first application node switches its own status to the upload status after determining that the second application node has switched to the download status, so as to indicate that the configuration parameters can be managed.

[0097] Step 440: After determining that the configuration parameters of the first application node have been updated, the first application node sends the updated configuration parameters to the second application node to instruct the second application node to load the updated configuration parameters.

[0098] In this embodiment of the invention, the first application node distributes the updated configuration parameters to the second application node. In some embodiments, the second application node may read and load the updated configuration parameters from the first application node.

[0099] In step 410, after the first application node obtains the upload instruction, it determines whether it is in an idle state; if so, it responds to the upload instruction; an idle state indicates that the application node is allowed to respond to the instruction; otherwise, it does not respond to the upload instruction.

[0100] Based on the above Figure 3 For example, application node A is the first application node. The operations and maintenance personnel send an upload command to application node A, indicating that the configuration parameters of each application node in the microservice architecture need to be updated. To ensure the accuracy, consistency and security of configuration parameter management, application node A first checks whether it is in an idle state (i.e., it first checks whether it is processing historical upload commands) and obtains the detection result.

[0101] The detection results include two scenarios: if application node A is in an idle state, it means that application node A is not currently processing other upload commands and can respond to this upload command; if the detection results also include a scenario where application node A is not in an idle state, it means that application node A is currently processing other upload commands and therefore will not respond to this upload command.

[0102] After receiving the detection results, application node A will send the results back to the front end so that operations and maintenance personnel can monitor them.

[0103] In step 420, after responding to the upload command, the first application node sends a download command to the second application node. Based on the above... Figure 3For example, after responding to the upload command, application node A sends download commands to application nodes B and C.

[0104] After receiving the download instruction, in order to ensure the accuracy, consistency and security of configuration parameter management, the second application node first checks whether it is in an idle state (i.e., whether it is processing historical download instructions).

[0105] If the second application node determines that it is in an idle state, it means that the second application node is not currently processing other download commands and can respond to this download command. If the second application node determines that it is not in an idle state, it means that the second application node is currently processing other download commands and will not respond to this download command.

[0106] In one feasible approach, after receiving the download instruction, the second application node adds a read-write lock to its own configuration parameters; the read-write lock is used to prevent write operations on the configuration parameters of the second application node. For example, the read-write lock is RWMutex.

[0107] In another feasible approach, after receiving the download instruction, the second application node adds a mutex lock (such as mutual exclusion) to its own configuration parameters to prevent write operations on the configuration parameters of the second application node.

[0108] In this embodiment of the invention, after receiving the download instruction, the second application node may also add other types of locks to its own configuration parameters, which are not specifically limited here.

[0109] In step 430, after the second application node switches its own state, it sends a response result indicating the state switch to the first application node. The response result includes "switching successful" and "switching failed"; a successful switch indicates that the second application node has switched to the download state; a failed switch indicates that the second application node has not switched to the download state.

[0110] After receiving the response, if the first application node determines that the switch was successful, it switches to the upload state; if the response determines that the switch failed, the first application node does not switch to the upload state.

[0111] After the first application node switches to the upload state, it sends the switch result to the front end so that the operation and maintenance personnel can query and monitor it.

[0112] After the first application node switches to upload mode, it receives the configuration file sent by the operations and maintenance personnel. Then, the first application node reads the parameters from the configuration file and loads them into the configuration parameters of the first application node, thereby updating the configuration parameters in the first application node.

[0113] In one feasible approach, the configuration file includes command parameters. The loading module of the first application node indexes its own configuration file based on the command parameters, reads its local configuration file, and then checks the received configuration file (e.g., checking whether the file format of the received configuration file is consistent with the file format of its own local configuration file; the file format can include JSON, properties, etc.).

[0114] If errors such as incorrect configuration file format are detected, the exception information is reported to the front end so that the operations and maintenance personnel can check it and resend the upload command after the check is correct.

[0115] If the configuration file format is detected to be correct, the first application node parses the received configuration file, obtains the parameters in the received configuration file, and then loads the parameters into its own local configuration file (such as Java memory) to update the configuration parameters.

[0116] In step 440, after updating the configuration parameters, the first application node notifies the second application node so that the second application node can update the configuration parameters.

[0117] In one feasible approach, after updating the configuration parameters, the first application node sends the updated configuration parameters to the second application node, so that the second application node calls its own loading module to load the updated parameters into its local configuration file, thereby updating the configuration parameters of the second application node.

[0118] In another feasible approach, after updating the configuration parameters, the first application node sends a loading command to the second application node, so that the second application node, after responding to the loading command, reads and obtains the updated configuration parameters from the first application node, thereby realizing the configuration parameter update of the second application node.

[0119] In this embodiment of the invention, after updating the configuration parameters, the second application node sends a loading result or update result back to the first application node. The first application node receives the loading result from the second application node based on the updated configuration parameters; when it determines that the loading result is successful, it sends a reset command to the second application node to instruct the second application node to switch to an idle state, so as to execute the next upload command.

[0120] Based on the above technical solutions, the dependence of the microservice architecture on external components or systems is reduced, thereby making the microservice architecture lightweight. Operations personnel no longer need to deploy additional databases or configuration centers within the microservice architecture, nor do they need to implement network communication between application nodes and external components or systems, saving deployment resource costs and reducing operational complexity and costs. Furthermore, application nodes only need to integrate development components to achieve distributed management and distribution of configuration parameters, eliminating the need for additional database table structures and the development of SQL CRUD logic, thus reducing development costs and difficulty.

[0121] Furthermore, this embodiment of the invention only requires managing the configuration parameters of any application node in the microservice architecture. Distributed distribution of configuration parameters can be achieved through the communication interfaces between the application nodes in the microservice architecture, reducing the complexity and workload of operation and maintenance. When the first application node fails, other nodes can be used as the first application node to manage the configuration parameters and synchronize them to other application nodes in the microservice architecture. This avoids the problem of configuration parameters being unmanageable due to the failure of a single application node, improving the flexibility of configuration parameter management.

[0122] In this embodiment of the invention, the communication method between the first application node and the second application node can be HTTP (Hypertext Transfer Protocol) network communication or other methods, and is not specifically limited here.

[0123] Based on the above Figure 3 For example, in a microservice architecture, the communication modules of each application node are pre-configured with HTTP network communication, and each application node has pre-configured transmission interfaces (such as API interfaces) corresponding to different commands, which are used to realize communication between application nodes.

[0124] To better explain the above technical solution, based on the above... Figure 3 , Figure 5 An exemplary diagram illustrates the management of configuration parameters, such as... Figure 5 As shown, it includes:

[0125] The microservice architecture includes application node A, application node B, and application node C. Application node A serves as the first application node, managing configuration parameters. Application nodes B and C serve as the second application nodes, used to synchronize the updated configuration parameters from application node A.

[0126] The operations and maintenance personnel send an upload command to application node A (such as "GET / statusSync?file=config.json"), indicating that the parameters in the "config.json" configuration file in the application node will be updated.

[0127] After receiving the upload command, application node A initiates a state synchronization request to application nodes B and C (i.e., sends download commands to application nodes B and C). After receiving the download commands, application nodes B and C add read-write locks to their local "config.json" configuration files to reserve write permissions and prevent other processes from writing to the configuration file simultaneously.

[0128] After application nodes B and C successfully acquire permissions to the configuration file, they switch their status from "idle" to "downloading" and send a response to application node A.

[0129] After application nodes B and C switch their states from "idle" to "download", application node A switches its own state from "idle" to "upload".

[0130] Based on the above Figure 5 , Figure 6 An exemplary diagram illustrates the management of configuration parameters, such as... Figure 6 As shown, it includes:

[0131] The operations and maintenance personnel modify the parameters of the "config.json" configuration file on application node A and save it, thereby updating the configuration parameters of application node A. After the configuration file is saved, the operations and maintenance personnel initiate a "configuration upload" command on application node A, which is equivalent to sending the configuration file to application node A.

[0132] Application node A reads the contents of the "config.json" configuration file and performs a format check. After the format check passes, it sends a "parameter synchronization" request to application nodes B and C, instructing them to update and synchronize their local "config.json" configuration files.

[0133] Based on the above Figure 6 , Figure 7 An exemplary diagram illustrates the management of configuration parameters, such as... Figure 7 As shown, it includes:

[0134] After receiving the loading results from application nodes B and C based on the "configuration synchronization" request, application node A determines that the loading result was successful, indicating that the configuration parameters of application nodes B and C have been successfully synchronized. Then, application node A sends a reset command to application nodes B and C.

[0135] After receiving the reset command, application nodes B and C release their write permissions to the configuration file and switch their status from "downloading" to "idle". They then report the reset result back to application node A.

[0136] After application node A determines that the status of application nodes B and C has changed from "downloading status" to "idle status", it will change its own status from "uploading status" to "idle status" and return the management result to the front-end operation and maintenance, such as a successful response.

[0137] At this point, the configuration parameters of each application node in the microservice architecture have been updated, and the status of each application node has been restored to "idle state" to await the next configuration parameter management.

[0138] Based on the same technological concept Figure 8 An exemplary schematic diagram of a configuration parameter management device provided in an embodiment of the present invention is shown. This device can execute the process of a configuration parameter management method.

[0139] like Figure 8 As shown, the device specifically includes:

[0140] Module 810 is used to obtain upload instructions;

[0141] The processing module 820 is configured to send a download instruction to the second application node in response to the upload instruction; the download instruction is used to instruct the second application node to switch to the download state; the download state indicates that the second application node is allowed to load configuration parameters; the second application node is any application node in the microservice architecture other than the first application node; the first application node is any application node in the microservice architecture;

[0142] Switch the first application node to upload mode; the upload mode indicates that the configuration parameters of the first application node are allowed to be updated.

[0143] After determining that the configuration parameters of the first application node have been updated, the updated configuration parameters are sent to the second application node to instruct the second application node to load the updated configuration parameters.

[0144] Optionally, the processing module 820 is further configured to:

[0145] After receiving the upload command, it is determined whether the first application node is in an idle state; if so, it responds to the upload command; the idle state indicates that the application node is allowed to respond to the command.

[0146] Otherwise, the upload command will not be responded to.

[0147] Optionally, the download instruction is further used to instruct the second application node to add a read-write lock to the configuration parameters of the second application node after switching to the download state; the read-write lock is used to prohibit write operations on the configuration parameters of the second application node.

[0148] Optionally, the processing module 820 is further configured to:

[0149] Before switching the first application node to the upload state, receive the response result from the second application node based on the download instruction;

[0150] Based on the response result, determine whether to switch the first application node to upload mode.

[0151] Optionally, the processing module 820 is specifically used for:

[0152] If the response result is "successful switch", then the first application node is switched to the upload state; "successful switch" means that the second application node is switched to the download state.

[0153] If the response result is a switching failure, the first application node will not be switched to the upload state; the switching failure indicates that the second application node has not been switched to the download state.

[0154] Optionally, the processing module 820 is further configured to:

[0155] After switching the first application node to upload mode, it receives the configuration file;

[0156] Read the parameters from the configuration file;

[0157] The parameters in the configuration file are loaded into the configuration parameters of the first application node.

[0158] Optionally, the processing module 820 is further configured to:

[0159] After determining that the configuration parameters of the first application node have been updated, the updated configuration parameters are sent to the second application node, and the loading result fed back by the second application node based on the updated configuration parameters is received.

[0160] When the loading result is determined to be successful, a reset command is sent to the second application node to instruct the second application node to switch to an idle state.

[0161] Based on the same technical concept, embodiments of the present invention also provide a computer device, including:

[0162] Memory, used to store program instructions;

[0163] The processor is used to call the program instructions stored in the memory and execute the management method of the above configuration parameters according to the obtained program.

[0164] Based on the same technical concept, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-mentioned configuration parameter management method.

[0165] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0166] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0167] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0168] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 Figure 1 The steps of the function specified in one or more boxes.

[0169] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for managing configuration parameters, characterized in that, include: The first application node obtains the upload instruction; The first application node can be any application node in a microservice architecture; In response to the upload command, the first application node sends a download command to the second application node; the download command is used to instruct the second application node to switch to download mode. The download status indicates that the second application node is allowed to load configuration parameters; the second application node is any application node in the microservice architecture other than the first application node; The first application node switches to upload mode; The upload status indicates that the configuration parameters of the first application node are allowed to be updated; After the first application node determines that its configuration parameters have been updated, it sends the updated configuration parameters to the second application node to instruct the second application node to load the updated configuration parameters.

2. The method as described in claim 1, characterized in that, After the first application node receives the upload instruction, it also includes: The first application node determines whether it is in an idle state; if so, it responds to the upload command; the idle state indicates that the application node is allowed to respond to the command. Otherwise, the upload command will not be responded to.

3. The method as described in claim 1, characterized in that, The download instruction is also used to instruct the second application node to add a read-write lock to the configuration parameters of the second application node after switching to the download state; the read-write lock is used to prohibit write operations on the configuration parameters of the second application node.

4. The method as described in claim 1, characterized in that, Before the first application node switches to upload mode, it also includes: The first application node receives the response result fed back by the second application node based on the download instruction; The first application node determines whether to switch to upload mode based on the response result.

5. The method as described in claim 4, characterized in that, The first application node determines whether to switch to upload mode based on the response result, including: If the response result is "successful switch", then the first application node switches to the upload state; the successful switch indicates that the second application node switches to the download state. If the response result is a switching failure, the first application node will not switch to the upload state; the switching failure indicates that the second application node has not switched to the download state.

6. The method as described in claim 1, characterized in that, After the first application node switches to upload mode, it also includes: The first application node receives the configuration file; The first application node reads the parameters from the configuration file; The first application node loads the parameters from the configuration file into the configuration parameters of the first application node.

7. The method as described in claim 1, characterized in that, After the first application node determines that its configuration parameters have been updated, and sends the updated configuration parameters to the second application node, the process further includes: The first application node receives the loading result fed back by the second application node based on the updated configuration parameters; When the first application node determines that the loading result is successful, it sends a reset command to the second application node to instruct the second application node to switch to an idle state.

8. A device for managing configuration parameters, characterized in that, include: The acquisition module is used to obtain upload instructions; The processing module is used to send a download instruction to the second application node in response to the upload instruction; The download command is used to instruct the second application node to switch to download mode; The download status indicates that the second application node is allowed to load configuration parameters; The second application node is any application node in the microservice architecture other than the first application node; The first application node can be any application node in a microservice architecture; Switch the first application node to upload mode; The upload status indicates that the configuration parameters of the first application node are allowed to be updated; After determining that the configuration parameters of the first application node have been updated, the updated configuration parameters are sent to the second application node to instruct the second application node to load the updated configuration parameters.

9. A computer device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the method according to any one of claims 1 to 7.

Images