A configuration method and device of a microservice
By using a message middleware in the microservice system to persistently store configuration information locally, the network congestion problem caused by frequent database reads of configuration information by microservices is solved, thereby improving business throughput and system response speed.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
- Filing Date
- 2024-10-29
- Publication Date
- 2026-07-31
AI Technical Summary
Microservices frequently read configuration information from the database, leading to excessive network I/O operations, resulting in network congestion and latency, which reduces the processing capacity and business throughput of the distributed system.
By transmitting configuration information through a message middleware, the second computing device can persistently store the configuration information locally. When microservices execute business logic, they can directly retrieve the configuration information from the local storage, reducing network I/O operations.
It reduces network overhead, increases the throughput of microservices per unit of time, and improves the response speed of distributed systems.
Smart Images

Figure CN119603145B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for configuring microservices. Background Technology
[0002] Distributed systems often deploy numerous microservices. These microservices rely on configuration information, such as user blacklists / whitelists and queries per second (QPS). When a microservice executes its business logic, it retrieves the necessary configuration information from the database via network input / output (I / O) operations. However, frequent database reads generate a large number of network I / O operations. Excessive I / O can lead to network congestion and latency, reducing the overall processing capacity of the distributed system and decreasing the throughput that microservices can handle per unit of time. Summary of the Invention
[0003] This application provides a microservice configuration method and apparatus to address the problem of reduced business throughput that microservices can handle per unit of time.
[0004] Firstly, this application provides a microservice configuration method. This microservice configuration method can be applied to a computer system or to a computing device that supports the configuration method for microservices implemented on the computer system. For example, the computer system may be referred to as a distributed system, and the computing device may be a server or a terminal. In one possible example, the aforementioned distributed system includes a first computing device and a second computing device, with microservices deployed on both devices. The microservice configuration method includes: the first computing device obtaining a first request carrying first configuration information of the microservices deployed on the second computing device; the second computing device subscribing to a message middleware used to transmit the first configuration information; the first computing device sending the first configuration information to the message middleware; the second computing device retrieving the first configuration information from the message middleware and persistently storing the first configuration information locally; and the first computing device receiving a configuration result sent by the second computing device, which indicates whether the second computing device successfully or failed to persist the first configuration information locally.
[0005] In this application, the first computing device and the second computing device transmit configuration information through a message middleware. After the second computing device obtains the first configuration information from the message middleware, it persists the first configuration information locally. This enables the microservice on the second computing device to obtain the first configuration information directly from the local machine without having to retrieve it from the database when executing business operations. This reduces network I / O operations, thereby reducing network overhead and increasing the business throughput that the microservice can handle per unit time.
[0006] In one possible scenario, the second computing device persists the first configuration information locally for indication: the second computing device persists the first configuration information in the memory or hard disk of the second computing device.
[0007] In one possible implementation, the message middleware is a message queue. A second computing device subscribes to the message middleware, including: the second computing device subscribes to a target topic in the message queue. A first computing device sends first configuration information to the message middleware, including: the first computing device sends the first configuration information to a group under the target topic in the message queue. The second computing device retrieves the first configuration information from the message middleware, including: the second computing device retrieves the first configuration information from the group under the target topic in the message queue.
[0008] In this application, by using a message queue as a message middleware, the first computing device and the second computing device are decoupled, and the first computing device is allowed to return immediately after sending a message without waiting for the second computing device to complete processing, thereby improving the response speed of the distributed system and further enhancing the business throughput that microservices can handle per unit time.
[0009] In one possible implementation, the message middleware is either a publish / subscribe model or an enterprise service bus.
[0010] In one possible implementation, the configuration method for the microservices described above further includes: the first computing device outputting the configuration results.
[0011] In one possible scenario, the first computing device outputs a configuration result, including: the first computing device outputs the configuration result to a front end connected to the first computing device, and then the front end displays the configuration result.
[0012] In one possible implementation, the distributed system also includes a database storing second configuration information for the microservice. The configuration time of the second configuration information is earlier than that of the first configuration information. Before the first computing device obtains the first request, the microservice configuration method further includes: the first computing device obtaining the second configuration information from the database and then persistently storing the second configuration information locally.
[0013] In this application, the first computing device can reduce the number of times the microservices on the first computing device retrieve the second configuration information from the database when performing business operations by persistently storing the second configuration information in the database locally. This reduces network I / O operations, thereby reducing network overhead and increasing the business throughput that the microservices can handle per unit time.
[0014] In one possible scenario, the aforementioned second configuration information is the configuration information of a microservice deployed on the first computing device.
[0015] In one possible implementation, the distributed system further includes a database, and the microservice configuration method further includes: a first computing device obtaining a second request carrying an identifier of first configuration information, and then sending the identifier of the first configuration information to a message middleware; wherein the message middleware is used to transmit the identifier of the first configuration information, and the identifier of the first configuration information is used to instruct the second computing device to store the first configuration information in the database. The first computing device retrieves the first configuration information stored by the second computing device from the database and outputs the first configuration information stored by the second computing device.
[0016] In this application, the first computing device and the second computing device transmit the identifier of the first configuration information through a message middleware. This enables the first computing device to transmit the identifier of the first configuration information to the second computing device through the message middleware when the user needs to confirm the first configuration information. This instructs the second computing device to send its local first configuration information to the database. The first computing device then retrieves the first configuration information stored by the second computing device from the database and outputs the aforementioned first configuration information to the user for confirmation, thus ensuring the accuracy and consistency of the configuration information.
[0017] In one possible implementation, the microservice configuration method further includes: a first computing device obtaining a second request carrying an identifier of first configuration information, and then sending the identifier of the first configuration information to a message middleware; wherein the message middleware is used to transmit the identifier of the first configuration information, and the identifier of the first configuration information is used to instruct the second computing device to store the first configuration information in the database. The first computing device verifies the first configuration information stored in the database by the second computing device and the first configuration information stored in the database by the first computing device, and outputs a verification result. The verification result is used to indicate whether they are consistent or inconsistent.
[0018] In this application, the first computing device verifies / compares the previously stored first configuration information with the first configuration information stored in the database by the second computing device to ensure that the configuration information used by the microservices in the second computing device is accurate, thereby improving the accuracy and consistency of the configuration information.
[0019] In one possible scenario, the first computing device also outputs the first configuration information stored in the database by the second computing device, as well as the first configuration information stored in the database by the first computing device.
[0020] In one possible implementation, the above microservice configuration method further includes: the first computing device storing the first configuration information in a database.
[0021] Secondly, this application provides a microservice configuration apparatus. This microservice configuration apparatus is applied to a computer system or to a computing device that supports the implementation of a microservice configuration apparatus on the computer system. The microservice configuration apparatus includes modules for executing the microservice configuration method in the first aspect or any optional implementation of the first aspect. Exemplarily, the microservice configuration apparatus includes: a first acquisition module, a subscription module, a sending module, a second acquisition module, and a receiving module.
[0022] The first acquisition module is used to acquire a first request; the first request carries: first configuration information of the microservice deployed on the second computing device.
[0023] The subscription module is used to subscribe to a message middleware; the message middleware is used to transmit the first configuration information.
[0024] The sending module is used to send the first configuration information to the message middleware.
[0025] The second acquisition module is used to acquire the first configuration information from the message middleware and persistently store the first configuration information locally.
[0026] A receiving module is used to receive the configuration result sent by the second computing device; the configuration result is used to indicate whether the second computing device has successfully or failed to persist the first configuration information to local storage.
[0027] For more detailed implementation information regarding the configuration device for microservices, please refer to the description of any of the implementation methods in the first aspect above, as well as the content of the specific implementation methods below, which will not be repeated here.
[0028] Thirdly, this application provides a microservice configuration system. The system includes a first computing device and a second computing device, on which microservices are deployed. The first computing device is used to obtain a first request carrying first configuration information of the microservices deployed on the second computing device. The second computing device is used to subscribe to a message middleware, which transmits the first configuration information. The first computing device is used to send the first configuration information to the message middleware. The second computing device is used to obtain the first configuration information from the message middleware and persistently store the first configuration information locally. The first computing device is used to receive a configuration result sent by the second computing device, the configuration result indicating whether the second computing device successfully or failed to persistently store the first configuration information locally.
[0029] For more detailed implementation information on the microservice configuration system, please refer to the description of any of the implementation methods in the first aspect above, as well as the content of the specific implementation methods below, which will not be repeated here.
[0030] Fourthly, this application provides a chip, including: a processor and an interface circuit; the interface circuit is used to obtain a first request, and the processor is used to execute the method in the first aspect or any possible implementation of the first aspect.
[0031] Fifthly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, which includes a memory and a processor. The memory stores computer instructions; when the processor executes the computer instructions, it implements the method described in the first aspect or any possible implementation of the first aspect.
[0032] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed by a processing device, implement the method described in the first aspect or any possible implementation of the first aspect.
[0033] In a seventh aspect, this application provides a computer program product comprising a computer program or instructions that, when executed by a processing device, implement the method in the first aspect or any possible implementation thereof.
[0034] The beneficial effects of aspects two through seven above can be referred to in aspect one or any possible implementation of aspect one, and will not be elaborated here. Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. Attached Figure Description
[0035] Figure 1 A schematic diagram of a computer system provided in this application;
[0036] Figure 2 A flowchart illustrating a microservice configuration method provided in this application. Figure 1 ;
[0037] Figure 3 A flowchart illustrating a microservice configuration method provided in this application. Figure 2 ;
[0038] Figure 4 A flowchart illustrating a microservice configuration method provided in this application. Figure 3 ;
[0039] Figure 5 A schematic diagram of the structure of a microservice configuration device provided in this application Figure 1 ;
[0040] Figure 6 A schematic diagram of the structure of a microservice configuration device provided in this application Figure 2 ;
[0041] Figure 7 A schematic diagram of the structure of a computing device provided in this application;
[0042] Figure 8 This application provides a schematic diagram of the structure of a computing device cluster;
[0043] Figure 9 This is a schematic diagram of the connection between computing devices provided in this application. Detailed Implementation
[0044] To address the issue of reduced business throughput that microservices can handle per unit of time, this application provides a microservice configuration method. A first computing device receives a first request carrying first configuration information of a microservice deployed on a second computing device. The second computing device subscribes to a message broker used to transmit the first configuration information. The first computing device sends the first configuration information to the message broker, and the second computing device retrieves the first configuration information from the message broker and persists it locally. The first computing device receives a configuration result from the second computing device, which indicates whether the second computing device successfully or failed to persist the first configuration information locally.
[0045] In this application, the first computing device and the second computing device transmit configuration information through a message middleware. After the second computing device obtains the first configuration information from the message middleware, it persists the first configuration information locally. This enables the microservice on the second computing device to obtain the first configuration information directly from the local machine without having to retrieve it from the database when executing business operations. This reduces network I / O operations, thereby reducing network overhead and increasing the business throughput that the microservice can handle per unit time.
[0046] To facilitate understanding, the technical terms used in this application will be introduced first.
[0047] Microservices are a software architectural style that aims to break down a single application into a set of small, independent services. These services can be developed, deployed, and scaled independently, each undertaking specific business functions.
[0048] Message middleware is a supporting software system that provides synchronous or asynchronous, reliable message transmission for application systems in a network environment, based on queue and message passing technologies. Common message middleware includes message queues, publish / subscribe models, enterprise service buses (ESBs), and lightweight messaging.
[0049] Message queues are a messaging mechanism that allows applications or devices to send and receive messages asynchronously via queues. Message queues act as intermediaries between producers (such as the first computing device described below) and consumers (such as the second computing device described below). Producers send messages to the queue, and consumers read messages from the queue. The publish / subscribe model is a messaging pattern that allows message publishers (such as the first computing device described below) to send messages to a topic, and multiple subscribers can subscribe to that topic to receive related messages. The publish / subscribe model decouples messages from subscribers through topics, allowing multiple subscribers to receive the same message. Enterprise Service Bus (OSS) is an architectural pattern that provides an integration platform for connecting and coordinating different applications, services, and devices. OSS acts as an intermediary layer, handling communication, data transformation, and routing between services or devices. Lightweight messaging is a simplified messaging mechanism, typically simple to implement and resource-efficient, suitable for small and rapidly developing applications. Lightweight messaging does not rely on complex middleware or heavyweight frameworks and uses a concise application programming interface (API) for message passing.
[0050] Reflection refers to the ability to dynamically obtain and manipulate the state information of an object (such as the second configuration information described below) at runtime, such as during the application or service's operation. For example, reflecting the second configuration from a database to a first computing device.
[0051] See Figure 1 , Figure 1 A schematic diagram of a computer system provided in this application. For example... Figure 1 As shown, the computer system includes a computing device cluster 110 and a database 120. The computing device cluster 110 and the database 120 can communicate with each other via wired or wireless means.
[0052] The aforementioned computing device cluster 110 is equipped with microservices. This application does not limit the type of business performed by the microservices, but the type may be: a microservice for providing query functions or a microservice for providing payment functions.
[0053] In this application, the computing devices included in the computing device cluster 110 provide an access interface (such as an API) to the outside world. This access interface is used to obtain first configuration information configured by the user. For a detailed description of the first configuration information, please refer to the following. Figure 2 The content shown will not be repeated here.
[0054] For example, a front-end connected to a computing device (such as one with a console) can access the computing device through the API mentioned above. The front-end can then send a first request to the computing device through the console, which carries the first configuration information configured by the user on the console.
[0055] The computing devices in computing device cluster 110 collaboratively execute and persistently store configuration information on their local storage. This local storage could be the memory or hard drive of each computing device in computing device cluster 110.
[0056] The aforementioned wired communication methods can include: Ethernet, fiber optic, and various peripheral component interconnect express (PCIe) buses, universal serial bus (USB) or unified bus (Ubus or UB), compute express link (CXL), cache coherent interconnect for accelerators (CCIX), etc., which are set up inside the computer system to connect the computing device cluster 110 and the database 120.
[0057] The aforementioned wireless communication methods can include: the Internet, wireless fidelity (WIFI), and ultra-wideband (UWB) technology, etc.
[0058] In one possible scenario, the computing devices in the aforementioned computing device cluster 110 may include one or more processing units, which may be graphics processing units (GPUs), neural network processing units (NPUs), central processing units (CPUs), field-programmable gate arrays (FPGAs), application processors (APs), modem processors, image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), tensor processing units (TPUs), application-specific integrated circuits (ASICs), discrete gates, transistor logic devices, discrete hardware components, and / or baseband processors. Alternatively, they may be processing devices including any one or more of the aforementioned processing units, such as terminals, servers, etc.
[0059] In another possible scenario, the computing devices in the aforementioned computing device cluster 110 may further include one or more memories. These memories may include volatile memory, such as random access memory (RAM). The memories may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). The memory stores executable program code or data generated during component operation, which the computing device executes to implement the functions of the components deployed on it.
[0060] For a detailed description of the computing device's structure, please refer to the following: Figures 7-9 The content shown will not be repeated here.
[0061] The computing device cluster 110 includes multiple computing devices. For example, these multiple computing devices may include computing device 111, computing device 112, and computing device 113. These multiple computing devices may communicate with each other via wired or wireless means. The computing devices may be servers, terminals, etc.
[0062] In one possible example, one or more microservices are deployed in at least one of the aforementioned computing devices.
[0063] In one possible example, the aforementioned computer system could be referred to as a distributed system, a cloud computing platform, or a cloud service.
[0064] In one possible example, the computer system described above may also include terminal 130, terminal 140, and terminal 150.
[0065] Terminals 130, 140, and 150 can be mobile phones, tablets, handheld computers, personal computers (PCs), cellular phones, personal digital assistants (PDAs), wearable devices (such as smartwatches), smart home devices (such as televisions), in-vehicle computers, game consoles, and augmented reality (AR) / virtual reality (VR) devices, etc. This application does not impose any special restrictions on the specific device form of terminals 130, 140, and 150.
[0066] In another possible example, terminals 130, 140, and 150 are set up independently and communicate with the computer system, i.e., the distributed system.
[0067] It should be noted that, Figure 1 The illustrated computer system architecture is merely an example; the types or number of devices within the system can be configured according to actual needs, and this application embodiment does not limit this. For example, the computer system may also include more computing devices and storage devices.
[0068] The following will be Figure 1 Based on the computer system shown, the implementation of the microservice configuration method provided in the embodiments of this application will be described in detail with reference to the accompanying drawings.
[0069] Figure 2 A flowchart illustrating a microservice configuration method provided in this application. Figure 1 The method provided in this embodiment can be applied to Figure 1In the computer system shown, the microservice configuration method described in this application, executed by computing device 111, is illustrated as an example. Microservices are deployed on computing device 111, and database 120 stores microservice configuration information 'a'. Configuration information 'a' was configured earlier than configuration information 'b'. Configuration information 'a' can be referred to as second configuration information, configuration information 'b' as first configuration information, and computing device 111 as first computing device. Figure 2 As shown, the configuration method for this microservice includes the following steps S210 and S220.
[0070] S210, computing device 111 obtains configuration information a from database 120.
[0071] For example, the computing device 111 obtains the configuration information a corresponding to the microservice a from the database 120 based on the microservice a deployed on the computing device 111.
[0072] For example, computing device 111 obtains configuration information a indicating the identifier of microservice a from database 120 based on the identifier of microservice a deployed on computing device 111.
[0073] The identifier of the microservice a mentioned above can be the name of the microservice a, its identity document (ID), etc.
[0074] S220, computing device 111 persistently stores configuration information a locally.
[0075] For example, the computing device 111 persistently stores the configuration information a in the memory of the computing device 111.
[0076] For example, computing device 111 persists configuration information 'a' from database 120 into memory via reflection.
[0077] For example, the computing device 111 persistently stores the configuration information a in the hard disk of the computing device 111.
[0078] It is worth noting that the above description only uses computing device 111 in the computing device cluster as an example. In other embodiments of this application, other computing devices in the computing device cluster (such as computing device 112 and computing device 113) can also obtain configuration information from database 120 and persist the configuration information locally. Thus, when the microservice on the computing device executes business, it only needs to obtain the corresponding configuration information from the local memory or hard disk, which reduces the I / O operation when the computing device obtains configuration information from database 120, speeds up the response speed when the microservice executes business, and thus improves the business throughput that the microservice can process per unit time.
[0079] Figure 2 This illustrates the content of persistently storing configuration information a, which is already stored in database 120, to computing device 111. Figure 1 , Figure 2 Based on the content shown, the computing device 111 can also broadcast the newly received configuration information (configuration information b) so that other computing devices (such as computing device 112) can obtain the configuration information b and persist it locally.
[0080] like Figure 3 As shown, Figure 3 A flowchart illustrating a microservice configuration method provided in this application. Figure 2 The method provided in this embodiment can be applied to Figure 1 In the computer system shown, microservices are deployed on computing devices 111 and 112. The microservice deployed on computing device 112 can be called microservice b, and request a can be called the first request. Figure 3 As shown, the configuration method for this microservice includes the following steps S310-S350.
[0081] S310, Computing device 111 obtains request a.
[0082] In one possible scenario, request a carries configuration information b of a microservice (microservice b) deployed on computing device 112.
[0083] In another possible scenario, request a carries the identifier of microservice b, as well as the configuration information b of microservice b.
[0084] For example, configuration information b includes any one or more of the following: network configuration, database configuration, environment variables, log configuration, message queue configuration, security configuration, rate limiting configuration, load balancing configuration, monitoring and alarm configuration, etc. of microservice b.
[0085] For example, network configuration includes: the microservice's hostname or Internet Protocol (IP) address, the port number monitored by the microservice, and the microservice's API. Database configuration includes: the database connection string and credentials used to identify the user to the database. Environment variables include: development / production environment identifiers and environment-specific configurations, such as API keys and credentials for external services. Log configuration includes: log levels and log storage paths. Message queue configuration includes: message broker addresses (such as connection information for RabbitMQ, Kafka, etc.) and queue names. Security configuration includes: authentication and authorization information, certificates and keys used for encrypted communication, and blacklists and whitelists for accessing users. Rate limiting configuration includes: QPS limits and request frequency. Load balancing includes: load balancing strategies (such as round-robin, weighted, random, etc.) and monitoring and checking configurations (such as defining health monitoring anchors and frequencies). Monitoring and alerting configuration includes: monitoring metrics (such as API call counts and response times) and alerting rules. Alert rules define when to trigger an alert, such as triggering an alert if the number of API calls exceeds 20 within 10 seconds.
[0086] In one possible implementation, the computing device 111 acquires request a, which includes: the computing device 111 acquires request a sent by terminal 130.
[0087] In one possible example, terminal 130 accesses computing device 111 via an API provided by computing device 111 to display a user interface on computing device 111. Then, the user triggers control components on the user interface using various input devices (keyboard, mouse, touchscreen, etc.) connected to terminal 130. Based on the triggering operation, terminal 130 obtains the user-configured configuration information b and sends a request a carrying the configuration information b to computing device 111.
[0088] Three possible examples are provided below for the specific implementation of the triggering operation.
[0089] Example 1: The trigger operation can be the user's confirmation of the control component via the keyboard, such as the user pressing the Enter key to confirm the configuration information b configured by the user.
[0090] Example 2: The trigger action can be a user clicking on the control component with the mouse.
[0091] For example, the user interface displays multiple control components corresponding to candidate options. Users can click on the aforementioned control components with the mouse to determine whether the candidate option corresponding to the clicked control component is the QPS threshold, the user's blacklist or whitelist, etc.
[0092] For example, the above multiple options are multiple values of QPS (such as 50, 60, 80, 85, 92, etc.), user identifiers included in the blacklist or whitelist, etc.
[0093] Example 3: The trigger operation can be a user's input operation in the control unit via the keyboard, such as the input configuration information or the content included in the configuration information (such as the QPS threshold, the user's blacklist or whitelist, etc.).
[0094] S320 and computing device 112 have a message middleware subscription.
[0095] In one possible scenario, the message broker is used to transmit configuration information b.
[0096] For example, message middleware is used to pass configuration information b between multiple computing devices included in computing device cluster 110.
[0097] In one possible scenario, the message middleware is any of the following: message queue, publish / subscribe model, enterprise service bus, or lightweight messaging.
[0098] For message middleware that is a message queue, one possible implementation is provided below, which will not be elaborated upon here. For message middleware that is a publish / subscribe model, enterprise service bus, or lightweight messaging, please refer to the description of message middleware as a message queue below, which will not be elaborated upon here.
[0099] For computing device 112 to subscribe to a message middleware, the following is one possible implementation.
[0100] The computing device 112 identifies the message middleware used by the computing device 111, and then installs the corresponding client (client library) on the computing device 112. The client is configured to connect to the server where the message middleware is located and declare the message middleware to be subscribed to, thereby enabling the computing device 112 to subscribe to the message middleware.
[0101] For example, the computing device 112 configures connection parameters such as the server's address and port number on the client to connect the client to the server where the message middleware is located.
[0102] For example, computing device 112 subscribes to a message middleware by configuring the identifier of the message middleware or the identifier of a group in the message middleware on the client.
[0103] In one possible scenario, the computing device 112 is also configured with a callback function, which is used to process messages (such as configuration information b) obtained from the message broker.
[0104] It is worth noting that the name of the message middleware that the client declares it will subscribe to is the same as the name used by computing device 111 when sending configuration information b. After subscribing to the message middleware, computing device 112 can continuously retrieve messages from the message middleware.
[0105] S330, computing device 111 sends configuration information b to message middleware.
[0106] In one possible implementation, the computing device 111 sends configuration information b to the message middleware, including: the computing device 111 sending configuration information b to the device where the message middleware is located. This device can be a server or a terminal.
[0107] In another possible implementation, the computing device 111 sends configuration information b to the message middleware, including: the computing device 111 sends configuration information b to the target topic in the message middleware.
[0108] S340, computing device 112 obtains configuration information b from message middleware and persists the configuration information b to local storage.
[0109] In one possible implementation, the computing device 112 obtains configuration information b from the message middleware, including: the computing device 112 obtains configuration information b from the message middleware by polling.
[0110] For example, computing device 112 obtains configuration information b from the target topic in the message middleware by polling.
[0111] In another possible implementation, the computing device 112 obtains configuration information b from the message middleware, including: the computing device 112 receives configuration information b pushed by the message middleware.
[0112] For example, after the computing device 112 defines a target topic, if the configuration information b sent by the computing device 111 exists under the target topic, the message middleware will push the configuration information b to the computing device 112.
[0113] In one possible implementation, the computing device 112 persistently stores the configuration information b locally, including: the computing device 112 persistently stores the configuration information b in the memory of the computing device 112.
[0114] In another possible implementation, the computing device 112 persistently stores the configuration information b locally, including: the computing device 112 persistently stores the configuration information b in the hard disk of the computing device 112.
[0115] In one possible scenario, if the computing device 112 already stores historical configuration information of microservice b (such as configuration information a mentioned above), the computing device 112 will delete the historical configuration information, thereby updating the configuration information stored locally on the computing device 112.
[0116] In one possible scenario, after the computing device 112 obtains the configuration information b from the message middleware, the method further includes: the computing device 112 performing an accuracy verification on the configuration information b. If the verification passes, the configuration information b is persistently stored locally; if the verification fails, the configuration information b is deleted.
[0117] Regarding the accuracy verification mentioned above, two possible examples are provided below.
[0118] Example 1: The computing device 112 verifies the user identifier indicated by the configuration information b.
[0119] For example, computing device 112 only persists the configuration information b configured for a specified user. The specified user includes, for example, an administrator or a user on a whitelist. The aforementioned user identifier is the identifier for the administrator, the user on the whitelist, etc.
[0120] Example 2: The computing device 112 compares the hash value of the configuration information b.
[0121] For example, computing device 112 calculates the hash value a of the obtained configuration information b, and also obtains the hash value b sent by computing device 111 through the message queue, comparing whether hash value a and hash value b are consistent. If hash value a and hash value b are consistent, the verification passes; if hash value a and hash value b are inconsistent, the verification fails. Here, hash value b is calculated by computing device 111 based on the configuration information b sent by terminal 130.
[0122] S350, computing device 111 receives the configuration result sent by computing device 112.
[0123] The configuration result is used to indicate whether the computing device 112 successfully or failed to persist the configuration information b locally.
[0124] In one possible scenario, the configuration result is represented as follows: the configuration information b is persisted to the local computing device 112 successfully or failed, that is, a field used to indicate "configuration successful" or "configuration failed". Configuration success means that the configuration information b is persisted to the local computing device 112 successfully, and configuration failure means that the configuration information b is persisted to the local computing device 111 failed.
[0125] In another possible scenario, the configuration result is represented as follows: the configuration information stored locally on computing device 112. If the configuration information stored locally on computing device 112 includes configuration information b, then the persistent storage of configuration information b on computing device 112 is successful; if the configuration information stored locally on computing device 112 does not include configuration information b, then the persistent storage of configuration information b on computing device 112 fails.
[0126] In one possible implementation, computing device 111 receives configuration results sent by computing device 112, including: computing device 111 directly receiving configuration results sent by computing device 112.
[0127] In another possible implementation, computing device 111 receives configuration results sent by computing device 112, including: computing device 111 receiving configuration results sent by computing device 112 through a message queue.
[0128] It is worth noting that the above description only takes the example of microservice b being deployed in computing device 112 in computing device cluster 110. In other embodiments of this application, other computing devices in computing device cluster 110 besides computing device 112 (such as computing device 111, computing device 113, etc.) may also deploy microservice b. In this case, computing device 111 and computing device 113 can execute the content executed by computing device 112, which will not be elaborated here.
[0129] For example, computing device 111 and computing device 112 have the same microservice b deployed on them, and computing device 111 also persists the configuration information b locally.
[0130] For example, after receiving request a, computing device 111 persists the configuration information b from request a to its local storage. This local storage could be memory or hard disk within computing device 111.
[0131] For example, computing device 111 also subscribes to a message queue, then obtains configuration information b from the message queue, and persistently stores the configuration information b locally on computing device 111.
[0132] In one possible scenario, computing device 111 outputs the configuration result.
[0133] For example, the computing device 111 outputs the configuration result to a front end connected to the computing device 111, and then the front end displays the configuration result.
[0134] For example, the aforementioned front end can be a display device or terminal, such as terminal 130, terminal 140, or terminal 150. The front end may display the configuration results in a console interface.
[0135] In one possible scenario, computing device 111 may also store configuration information b in database 120, thereby enabling backup of configuration information b or verification of configuration information persistently stored in the computing device. Verification of configuration information persistently stored in the computing device can be performed as follows. Figure 4 The descriptions of the content shown will not be repeated here.
[0136] exist Figure 3 Based on the content shown, this application also provides a possible embodiment, which illustrates the configuration method of microservices when the message middleware is a message queue. This embodiment may include the following steps ①-⑤.
[0137] Step ①: Computing device 111 obtains request a.
[0138] Step 2: Computing device 112 subscribes to the target topic in the message queue.
[0139] For example, a topic is used as a category identifier for messages (configuration information) in a message queue, and the target topic is the category identifier to which configuration information b belongs. Only computing devices that have subscribed to the target topic in the message queue can receive messages from the target topic.
[0140] In one possible example, the category identifier of the target topic matches the identifier of the microservice, such as the target topic storing only the configuration information b of microservice b.
[0141] In another possible example, the category identifier of the target topic matches the type of the microservice, such as the target topic storing only the configuration information b of the microservice b that implements the query function.
[0142] Step 3: The computing device 111 sends configuration information b to the target topic in the message queue.
[0143] Step 4: The computing device 112 retrieves the configuration information b from the target topic in the message queue and persists the configuration information b to local storage.
[0144] For example, after obtaining the configuration information b through the callback function, the computing device 112 persists the configuration information b in memory, thereby reducing the network I / O operations when the microservice retrieves the configuration information from the database 120, thus reducing network overhead and increasing the business throughput that the microservice can handle per unit time.
[0145] Step 5: Computing device 111 receives the configuration result sent by computing device 112.
[0146] For the contents of steps ① and ⑤ above, please refer to the descriptions in S310 and S350 above, and they will not be repeated here.
[0147] It is worth noting that this embodiment only describes the example of a computing device 112 deploying microservice b and then the computing device 112 subscribing to a target topic in a message queue. In other embodiments of this application, other computing devices in the computing device cluster 110 besides the computing device 112 also deploy microservice b, and these other computing devices will also subscribe to the target topic in the message queue and implement the contents of steps ③-⑤ above.
[0148] For example, the other computing devices mentioned above subscribe to the same target topic as computing device 112, so that the other computing devices and computing device 112 can obtain configuration information b.
[0149] exist Figure 3 Based on the content shown, this application also provides a possible embodiment, in which the content shown in this embodiment is used to confirm the configuration information of persistent storage of computing devices in computer cluster 110. Figure 4 A flowchart illustrating a microservice configuration method provided in this application. Figure 3 ,like Figure 4 As shown, the configuration method for this microservice includes the following steps S410-S440.
[0150] S410, Computing device 111 obtains request b.
[0151] In this context, request b carries the identifier of configuration information b.
[0152] For example, the identifier of configuration information b is the name or ID of configuration information b.
[0153] The content of request b obtained by computing device 111 can be referred to the description in S310 above, and will not be repeated here.
[0154] S420, computing device 111 sends the identifier of configuration information b to message middleware.
[0155] In one possible scenario, the message middleware is also used to transmit the identifier of configuration information b, wherein the identifier of configuration information b is used to instruct computing device 112 to store configuration information b in database 120.
[0156] For example, computing device 112 subscribes to a message middleware, and then computing device 111 sends the identifier of configuration information b to the message middleware, and computing device 112 retrieves the identifier of configuration information b from the message queue. Computing device 112 is configured with a callback function, which, after retrieving the identifier of configuration information b, sends the persistently stored configuration information b in computing device 112 to database 120 for storage.
[0157] For example, computing device 112 sends persistently stored configuration information b to a designated area in database 120. The aforementioned designated area can be pre-configured by the user in computing device 112 or computing device 111, such as configuring the address or sector of the designated area.
[0158] The identifier for the configuration information b sent by the computing device 111 to the message middleware can be referred to the description in S330 above, and will not be repeated here.
[0159] S430, computing device 111 obtains configuration information b stored in computing device 112 from database 120.
[0160] For example, computing device 111 retrieves configuration information b stored in computing device 112 from a specified area in database 120.
[0161] S440, Computing device 111 outputs configuration information b stored in computing device 112.
[0162] For example, computing device 111 outputs the configuration information b stored in computing device 112 to a front end connected to computing device 111, and then the front end displays the configuration information b stored in computing device 112.
[0163] It is worth noting that, Figure 4 The content shown is only an example of microservice b being deployed in computing device 112. In other embodiments of this application, other computing devices (such as computing device 111, computing device 113, etc.) in computing device cluster 110 besides computing device 112 can also deploy microservice b. In that case, computing device 111 and computing device 113 can execute the content executed by computing device 112 as described above, which will not be elaborated here.
[0164] For example, computing device 113 and computing device 112 have the same microservice b deployed on them. Then, computing device 113 also sends the configuration information b to database 120 for storage according to the identifier of the configuration information b. Then, computing device 111 retrieves the configuration information b stored in computing device 113 and the configuration information b stored in computing device 112 from database 120, and outputs the configuration information b stored in computing device 113 and the configuration information b stored in computing device 112 to terminal 130, which displays them, such as on the console of terminal 130.
[0165] In another possible embodiment of this application, after S430 described above, the computing device 111 verifies the configuration information b stored in the computing device 112 and the configuration information b stored in the computing device 111, and obtains a verification result. Then, the computing device 111 outputs the verification result to the terminal 130, and the console on the terminal 130 displays the verification result.
[0166] The above verification result is used to indicate whether the configuration information b stored in computing device 112 is consistent with the configuration information b stored in computing device 111, or whether the configuration information b stored in computing device 112 is inconsistent with the configuration information b stored in computing device 111.
[0167] It is understood that, in order to achieve the functions in the above embodiments, the computing device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and method steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution. Figures 2 to 4 This document describes in detail the microservice configuration method provided according to this embodiment. The following section will combine... Figure 5 This describes the configuration apparatus for microservices provided according to this embodiment.
[0168] Figure 5 A schematic diagram of the structure of a microservice configuration device provided in this application Figure 1 The microservice configuration device can be used to implement the functions of computing devices 111 and 112 in the above method embodiments, and therefore can also achieve the beneficial effects of the above method embodiments. In this embodiment, the microservice configuration device 500 can be a module (such as a chip) of computing devices 111 and 112.
[0169] like Figure 5As shown, the microservice configuration device 500 includes a first acquisition module 510, a subscription module 520, a sending module 530, a second acquisition module 540, and a receiving module 550. The microservice configuration device 500 is used to implement the above-mentioned... Figures 2 to 4 The method embodiment shown illustrates the functionality of the computing device 111. In one possible example, the specific process by which the microservice configuration device 500 implements the aforementioned microservice configuration method includes the following steps:
[0170] The first acquisition module 510 is used to acquire a first request; the first request carries: first configuration information of the microservice deployed on the second computing device.
[0171] The subscription module 520 is used to subscribe to a message middleware; the message middleware is used to transmit the first configuration information.
[0172] The sending module 530 is used to send first configuration information to the message middleware.
[0173] The second acquisition module 540 is used to acquire the first configuration information from the message middleware and persistently store the first configuration information locally.
[0174] The receiving module 550 is used to receive the configuration result sent by the second computing device; the configuration result is used to indicate whether the second computing device has successfully or failed to persist the first configuration information to local storage.
[0175] To further achieve the above Figures 2 to 4 The method embodiment shown illustrates the functionality of the computing device. This application also provides a microservice configuration apparatus, such as… Figure 6 As shown, Figure 6 A schematic diagram of the structure of a microservice configuration device provided in this application Figure 2 The microservice configuration device 500 also includes: an output module 560, a persistence module 570, and a confirmation module 580.
[0176] Output module 560 is used to output configuration results.
[0177] The persistence module 570 is used to retrieve the second configuration information from the database and persistently store it locally. The database stores the second configuration information of the microservice, and the configuration time of the second configuration information is earlier than that of the first configuration information.
[0178] The confirmation module 580 is used to obtain a second request, which carries an identifier of the first configuration information. It sends the identifier of the first configuration information to a message middleware; the message middleware is used to transmit the identifier of the first configuration information, which instructs the second computing device to store the first configuration information in a database. It retrieves the first configuration information stored by the second computing device from the database and outputs the first configuration information stored by the second computing device.
[0179] It should be noted that, in other embodiments, the first acquisition module 510, the subscription module 520, the sending module 530, the second acquisition module 540, and the receiving module 550 can all execute any step in the microservice configuration method. The steps implemented by the first acquisition module 510, the subscription module 520, the sending module 530, the second acquisition module 540, and the receiving module 550 can be specified as needed. By implementing different steps in the microservice configuration method through the first acquisition module 510, the subscription module 520, the sending module 530, the second acquisition module 540, and the receiving module 550, all functions of the microservice configuration device 500 can be achieved.
[0180] It is worth noting that the computing device according to the embodiments of this application may correspond to the microservice configuration device 500 in the embodiments of the application, and may correspond to the execution of the method according to the embodiments of this application. Figures 2 to 4 The corresponding entities, and the operations and / or functions of each module in the microservice configuration device 500, are respectively implemented to achieve the following: Figures 2 to 4 The corresponding processes of each method in the corresponding embodiments are not described in detail here for the sake of brevity.
[0181] When the microservice configuration device 500 implements the configuration method of any of the microservices shown in the foregoing figures through software, the microservice configuration device 500 and its various units can also be software modules. The microservice configuration method described above is implemented by the processor calling the software module. The processor can be a CPU, an ASIC, or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0182] A more detailed description of the microservice configuration device 500 described above can be found in the relevant descriptions in the embodiments shown in the foregoing figures, and will not be repeated here. It is understood that the microservice configuration device 500 shown in the foregoing figures is merely an example provided in this embodiment. Depending on the usage scenario, the microservice configuration device 500 may include more or fewer units, and this application does not limit it in this regard.
[0183] When the microservice configuration device 500 is implemented in hardware, this hardware can be implemented by a processor or a chip. The chip includes interface circuitry and a processor. The interface circuitry is used to receive requests (such as request a, request b) from other devices outside the processor and transmit them to the processor, or to send data from the processor (such as configuration information b) to other devices outside the processor.
[0184] The processor and interface circuitry are used, through logic circuitry or executable code instructions, to implement any of the possible implementation methods in the above embodiments. The beneficial effects can be found in the descriptions of any aspect of the above embodiments, and will not be repeated here.
[0185] It is understood that the processor in the embodiments of this application may be a CPU, NPU, or GPU, or other general-purpose processors, digital signal processors (DSPs), ASICs, FPGAs, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.
[0186] in addition, Figure 5 , Figure 6 The microservice configuration device 500 shown can also be implemented using computing devices, such as... Figure 1 The computing devices 111 and 112 shown may be, or computer systems including computing devices 111 and 112.
[0187] The method steps in the embodiments of this application can also be implemented by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a communication device. Of course, the processor and storage medium can also exist as discrete components in the communication device.
[0188] This application also provides a chip system including a processor for implementing the functions of the storage device described above. In one possible design, the chip system further includes a memory for storing program instructions and / or data. This chip system may be composed of chips or may include chips and other discrete devices.
[0189] This application also provides a computing device, please refer to... Figure 7 , Figure 7 This application provides a schematic diagram of the structure of a computing device. The computing device 700 includes a bus 702, a processor 704, a memory 706, and a communication interface 708. The processor 704, memory 706, and communication interface 708 are interconnected via the bus 702. The computing device 700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 700. For example, the computing device 700 can be the aforementioned computing device 111 or computing device 112.
[0190] The 702 bus can be a PCIe bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 7 The bus 702 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 702 may include a path for transmitting information between various components of the computing device 700 (e.g., processor 704, memory 706, communication interface 708).
[0191] Processor 704 may include any one or more processors such as CPU, GPU, FPGA, microprocessor (MP) or DSP.
[0192] The memory 706 may include volatile memory, such as RAM. The processor 704 may also include non-volatile memory, such as ROM, flash memory, HDD, or SSD.
[0193] The memory 706 stores executable program code, which the processor 704 executes to implement the functions of the aforementioned first acquisition module 510, subscription module 520, sending module 530, second acquisition module 540, and receiving module 550, thereby realizing the microservice configuration method. In other words, the memory 706 stores instructions for executing the microservice configuration method.
[0194] The communication interface 708 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 700 and other devices or communication networks. The computing device 700 can be a computer (e.g., a server) in a cloud data center, a computer in an edge data center, or a terminal.
[0195] This application also provides a computing device cluster. The computing device cluster includes at least one computing device, which can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone. For example, the computing device cluster can be the aforementioned computer system.
[0196] like Figure 8 As shown, Figure 8 This application provides a schematic diagram of a computing device cluster. The computing device cluster includes at least one computing device 700. The memory 706 of one or more computing devices 700 in the computing device cluster may store the same instructions for configuring microservices.
[0197] In some possible implementations, the memory 706 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing microservice configuration methods. In other words, a combination of one or more computing devices 700 can jointly execute instructions for executing microservice configuration methods.
[0198] It should be noted that the memory 706 in different computing devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the microservice configuration method's functionality. That is, the instructions stored in the memory 706 of different computing devices 700 can implement the functionality of one or more modules among the first acquisition module 510, subscription module 520, sending module 530, second acquisition module 540, and receiving module 550.
[0199] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN). Figure 9 One possible implementation is shown. For example... Figure 9 As shown, Figure 9 This application provides a schematic diagram of a connection between computing devices, where two computing devices 700A and 700B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 706 in computing device 700A stores instructions for executing the functions of the first acquisition module 510, the sending module 530, and the receiving module 550. Simultaneously, the memory 706 in computing device 700B stores instructions for executing the functions of the subscription module 520 and the second acquisition module 540.
[0200] It should be understood that Figure 9 The functions of the computing device 700A shown can also be performed by multiple computing devices 700. Similarly, the functions of the computing device 700B can also be performed by multiple computing devices 700.
[0201] This application also provides a computer program product containing instructions. This computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any available medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to execute the microservice configuration method described above.
[0202] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a microservice configuration method.
[0203] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a DVD; or it can be a semiconductor medium, such as an SSD.
[0204] In the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments are consistent and can be referenced mutually. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and inherent logic.
Claims
1. A method for configuring microservices, characterized in that, The method is applied to a distributed system, the distributed system including a first computing device and a second computing device, wherein microservices are deployed on the first computing device and the second computing device; the method includes: The first computing device receives a first request; the first request carries: first configuration information of a microservice deployed on the second computing device; The second computing device subscribes to a message middleware; the message middleware is used to transmit the first configuration information. The first computing device sends first configuration information to the message middleware; The second computing device obtains the first configuration information from the message middleware and persists the first configuration information to local storage; The first computing device receives the configuration result sent by the second computing device; the configuration result is used to indicate whether the second computing device successfully or unsuccessfully persists the first configuration information to local storage.
2. The method of claim 1, wherein, The message middleware is a message queue; the second computing device subscribes to the message middleware, including: The second computing device subscribes to the target topic in the message queue; The first computing device sends first configuration information to the message middleware, including: The first computing device sends first configuration information to the target topic in the message queue; The second computing device obtains the first configuration information from the message middleware, including: The second computing device obtains the first configuration information from the target topic in the message queue.
3. The method according to claim 1, characterized in that, The message middleware is a publish / subscribe model or an enterprise service bus.
4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The first computing device outputs the configuration result.
5. The method according to any one of claims 1 to 3, characterized in that, The distributed system further includes a database storing second configuration information for microservices. The configuration time of the second configuration information is earlier than the configuration time of the first configuration information. Before the first computing device obtains the first request, the method further includes: The first computing device obtains the second configuration information from the database; The first computing device persistently stores the second configuration information locally.
6. The method according to any one of claims 1 to 3, characterized in that, The distributed system also includes a database, and the method further includes: The first computing device receives a second request; the second request carries an identifier of the first configuration information. The first computing device sends an identifier of the first configuration information to a message middleware; the message middleware is used to transmit the identifier of the first configuration information, and the identifier of the first configuration information is used to instruct the second computing device to store the first configuration information in the database. The first computing device retrieves the first configuration information stored by the second computing device from the database; The first computing device outputs the first configuration information stored in the second computing device.
7. The method of claim 5, wherein, The method further includes: The first computing device stores the first configuration information in the database.
8. The method of claim 6, wherein, The method further includes: The first computing device stores the first configuration information in the database. 9.A configuration system of microservices, characterized in that, The system includes a first computing device and a second computing device, and microservices are deployed on the first computing device and the second computing device. The first computing device is used to obtain the first request; The first request carries: first configuration information of the microservice deployed on the second computing device; The second computing device is used to subscribe to a message middleware; the message middleware is used to transmit the first configuration information. The first computing device is used to send first configuration information to the message middleware; The second computing device is configured to obtain the first configuration information from the message middleware and persistently store the first configuration information locally; The first computing device is configured to receive the configuration result sent by the second computing device; The configuration result is used to indicate whether the second computing device successfully or failed to persist the first configuration information locally.
10. A cluster of computing devices, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 8.
11. A computer readable storage medium, characterized in that, The storage medium stores a computer program or instructions, which, when executed by a computing device, implement the method of any one of claims 1 to 8.
12. A computer program product comprising computer programs or instructions, characterized in that, When the computer program or instructions are executed by a computing device, the method of any one of claims 1 to 8 is implemented.