A method for batch release of distributed applications

Abstract

The application discloses a kind of distributed application batch release method, it is characterized in that, for user, provide a one-key node release configuration and the program entrance of the deployment center of monitoring, in DeployCenter, after the node search range that needs to be released is selected and configuration update is completed, one-key can be completed node batch upgrade, DeployCenter is preset with a finite state machine, reach the solidification of all operations of operation and maintenance personnel in node batch upgrade, replace the operation of operation and maintenance personnel by program, replace the number of operation and maintenance personnel by thread number, so that the process efficiency of application node batch release is greatly improved, unified process control can be accurately and timely found in the process of release Abnormal and make interrupt processing, compared with original multi-person operation, greatly reduce the possibility of error caused by communication effect.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed search application, in particular to a method for batch release of distributed application. BACKGROUND

[0002] With the current heat of e-commerce platforms, merchants hope to publish more and more products to e-commerce platforms, and consumers also hope to quickly and accurately find the goods they need on e-commerce platforms. To meet the needs of merchants and consumers, e-commerce platforms usually establish a mechanism for quickly indexing goods on the technical level, and such a mechanism is usually completed by a distributed search system with large capacity, high throughput and high performance.

[0003] As the number of products on the market increases, people's demand for the search speed of e-commerce search platforms is getting higher and higher. It is inevitable to expand the underlying search nodes of the search platform horizontally and vertically to achieve high capacity, high throughput and high performance, which in turn leads to an expansion in the number of search nodes. Under the background of traditional manual operation and maintenance, when updating the configuration or version of each node in a large-scale search cluster, the following operations need to be performed on each search node:

[0004] (1) Check the current search node business traffic, control the distributed system routing, and cut off the search node business traffic to ensure that real user search requests are not disturbed.

[0005] (2) Check the current search node business data update task, suspend the data update task, and ensure the integrity of the product data is not damaged.

[0006] (3) Close the search node application, modify the configuration, and re-release and start.

[0007] (4) Manually check and test the search node after it is started to ensure that it can normally respond to search requests.

[0008] (5) Control the distributed system routing, restore the search node business traffic, and add it to the search cluster again.

[0009] Repeat the above steps (1) to (5) several times, and ensure that each search node in a non-working state does not affect the overall availability of the distributed system until all search nodes in the cluster are re-released.

[0010] As mentioned above, in the face of huge cluster size, manual operation has problems of low efficiency, easy to make mistakes, operation repetition, etc., which may affect server hardware load, and even directly affect the real user experience. Moreover, such high repetitive work is a great waste of human resources for operation and maintenance personnel. Therefore, it is an urgent need to design an automatic batch release system that can automatically control the release steps and improve the release efficiency.

[0011] Therefore, there is a need for a risk-controllable and highly efficient distributed application batch release method. SUMMARY

[0012] The technical problem to be solved by the present application is to overcome the shortcomings of the prior art, solve the security and efficiency problems of large-scale release of general search platform clusters, and provide a distributed application batch release method based on a finite state machine.

[0013] To solve the above technical problems, the present application provides a distributed application batch release method, characterized in that it comprises the following steps:

[0014] Step 1: In the DeployCenter, a plurality of filtering options are preset to filter out the nodes to be upgraded that meet the target conditions and check them;

[0015] Step 2: Edit the node parameters in the DeployCenter and save them. The DeployCenter uses the UMC to update the configuration information of the nodes to be updated in batches;

[0016] Step 3: The DeployCenter performs one-key release, and the batch release process is automatically run;

[0017] Step 4: In the batch release process, the DeployCenter follows and records the release status of each node. When all nodes in the current batch have been executed and the status is normal, the release process continues, the nodes that have completed normal release provide external services, and if any node produces an abnormal status during the release process, the one-key release process is forcibly terminated, external user requests on the abnormal node are cut off, and an alarm feedback is executed.

[0018] In step 1, a finite state machine is preset in the DeployCenter, and more than one node release state and more than one release execution process are preset in the finite state machine; the above steps are mapped to the states and transitions of the finite state machine, including corresponding one state of the finite state machine for the result condition generated by each step, and corresponding one transition of the finite state machine for the process of the subsequent step determined by each step according to the result; an input event triggered is preset to release a specified version in the nth node.

[0019] The finite state machine in the step 1 is TaskExecutor, including 14 preset node publishing states and 8 publishing execution processes;

[0020] The 14 node publishing states are: UNUPDATE, UPDATEDED, FLOW_START, NETFLOW_CLOSED, STOPPED, DEPLOYING, DEPLOYED, STARTING, STARTED, CHECKING, CHECKED, NETFLOW_OPEN, FLOW_END, and ERROR.

[0021] The 8 publishing execution processes are:

[0022] Step 101, close node service traffic, cut off all service traffic existing on the node on the traffic distribution to ensure that the user request is not affected, and set the publishing state of the node to the NETFLOW_CLOSED state in the state machine. When the node is in the service traffic closing state, the search service router will no longer send a request to the node, thereby cutting off the user traffic. If any exception occurs in the process and the traffic cannot be cut off, the publishing state of the node is set to the ERROR state.

[0023] Step 102, stop the node using UMC. After the node is stopped, the publishing state is set to STOPPED. If any exception occurs in the process, it is set to the ERROR state.

[0024] Step 103, check whether the state of the node in the search cluster is Down to ensure that it has exited the cluster. After completion, the publishing state of the node is set to the STOPPED state, which is used to mark that the node has been completely closed and exited the cluster. If the node cluster state is still not switched to Down after waiting for more than 5 minutes, it indicates that the node has not completely exited the cluster. At this time, the publishing state of the node is set to the ERROR state.

[0025] Step 104, republish, publish the new version of the node using UMC. During the publishing process, the publishing state of the node is set to STARTING. After successful publishing, it is set to STARTED. If it still fails to publish or an unknown exception occurs after waiting for more than 5 minutes, it is set to the ERROR state.

[0026] Step 105, start the node, start the new version of the node using UMC to make the application start using the new configuration. During the publishing process, the publishing state of the node is set to DEPLOYING. After successful publishing, it is set to DEPLOYED. If it still fails to start or an unknown exception occurs after waiting for more than 5 minutes, it is set to the ERROR state.

[0027] Step 106, check the node cluster state, the node will automatically join the cluster after normal start, at this time check the node cluster state, confirm the state of the node in the cluster is Active, ensure that it has been restored and joined the cluster, set the release state of the node to CHECKING during the checking process, if it is still not started successfully or produces unknown exception after waiting for more than 5 minutes, set it to ERROR;

[0028] Step 107, check the node available state, use node check test cases, check the normal function of the node, set the release state of the node to CHECKED after all test cases pass, if there is an abnormal execution result of the check case, set it to ERROR;

[0029] Step 108, restore node traffic, restore the traffic state of the node to start on the traffic distribution, allow normal user requests to enter.

[0030] In the step 4, the batch release process further includes the following steps:

[0031] Step 401: DeployCenter accepts the ID sequence of the target node and completes the update operation on the specified configuration field in UMC, at this time DeployCenter sets the node state in the cache to all UPDATED;

[0032] Step 402: DeployCenter queries the business distribution information and machine distribution information of each node in the meta database of UMC, and encapsulates a plurality of data objects into the batch cutting process with the ID of the node as the primary key;

[0033] Step 403: batch cutting process, in the cutting process, a kind of node isolation cutting method is designed, including: a, b are two independent businesses, shardN represents the Nth shard of the business, replicaN represents the Nth node of the shard, wherein there are A, B, C, D nodes:

[0034] A node has: a-shard1-replica1, b-shard1-replica1;

[0035] B node has: a-shard2-replica1, b-shard2-replica1;

[0036] C node has: a-shard1-replica2, b-shard1-replica2;

[0037] D node has: a-shard2-replica2, b-shard2-replica2;

[0038] The four nodes are divided into two groups of AB and CD, the nodes after grouping are published in parallel in the respective groups, and the groups are published in series, which are completely isolated;

[0039] Step 404: Each group enters the TaskExecutor, and after entering, the publishing process is completely free from manual intervention, the state machine operates automatically, a number of threads equal to the batch size are started for parallel publishing, each thread shares the same cache for recording states, and if a problem occurs in the publishing process of any thread, an ERROR state record exists in the cache;

[0040] Step 405: During the sequential batch execution, if there is an ERROR state record in the cache generated by the previous batch, the next batch is not allowed to enter the TaskExecutor, and the overall process is exited, otherwise the publishing operation of all batches will continue to be executed until all node publishing is completed.

[0041] The application has the following beneficial effects: through the rule design of SeperateRule and the publishing state and publishing execution process design in TaskExecutor, all operations of the operation and maintenance personnel in the node batch upgrade are solidified, so that each thread in the TaskExecutor execution process achieves the effect of simulating the same number of operation and maintenance personnel operations. The program replaces the operation and maintenance personnel operation, and the number of threads replaces the number of operation and maintenance personnel, so that the process efficiency of the application node batch publishing is greatly improved. The unified process control by DeployCenter can accurately and timely find the exception in the publishing process and make interruption processing, compared with the original multi-person operation, greatly reducing the possibility of mistakes caused by communication. BRIEF DESCRIPTION OF DRAWINGS

[0042] Figure 1 The method flowchart of the exemplary embodiment of the application;

[0043] Figure 2 The execution flowchart of the SeparateRule in the exemplary embodiment of the application;

[0044] Figure 3 The specific implementation architecture diagram in the exemplary embodiment of the application. DETAILED DESCRIPTION

[0045] DeployCenter: deployment center.

[0046] UMC: cloud application platform software, which is a software basic platform supporting the construction of business application software under cloud computing technology, mainly helping enterprises to realize application software cloudization, unified cloud application architecture, establishment of cloud application life cycle management, and construction of development and operation integrated engineering platform.

[0047] TaskExecutor: node publishing state machine executor.

[0048] The application will be further described below in conjunction with the accompanying drawings and exemplary embodiments:

[0049] As Figure 1 shown in the specific embodiments of the application, a method for distributed application batch publishing is provided, which provides a program portal of a one-key node publishing configuration and monitoring deployment center (hereinafter referred to as: DeployCenter) for users. In the DeployCenter, the node batch upgrade can be completed by one key after selecting the node search range to be published and completing the configuration update. The specific steps include:

[0050] Step 1: Select the target application node; filter out the to-be-upgraded nodes that meet the target conditions and make a check mark through a plurality of preset filtering options in the DeployCenter; preset a finite state machine in the DeployCenter, preset more than one node publishing state and more than one publishing execution flow in the finite state machine; map the above steps to the state (State) and transition (Transition) of the finite state machine, including corresponding one state of the finite state machine for the result condition generated by each step, corresponding the transition of one state of the finite state machine for the flow of the subsequent step determined according to the result of each step; preset the input event (Input) triggered to publish the specified version in the nth node.

[0051] The finite state machine is TaskExecutor, which includes 14 kinds of node publishing states and 8 publishing execution flows;

[0052] The 14 kinds of node publishing states are: UNUPDATE, UPDATED, FLOW_START, NETFLOW_CLOSED, STOPPED, DEPLOYING, DEPLOYED, STARTING, STARTED, CHECKING, CHECKED, NETFLOW_OPEN, FLOW_END, and ERROR.

[0053] The 8 publishing execution flows are:

[0054] Step 101, Close node traffic, by cutting off all traffic of the node existing on the traffic distribution to ensure that the user request is not affected. The release state of the node is set to NETFLOW_CLOSED in the state machine, when the node is in the traffic closed state, the search service router will no longer send requests to the node, thereby cutting off user traffic. If any exception occurs in the process, the release state of the node is set to ERROR.

[0055] Step 102, Stop node using UMC, after the node is stopped, the release state is set to STOPPED, and any exception in the process is set to ERROR.

[0056] Step 103, Check the state of the node in the search cluster, ensure that it has exited the cluster, and after completion, the release of the node is set to the STOPPED state, which is used to mark that the node has been completely closed and exited the cluster. If the node cluster state is waiting for more than 5 minutes and still not switched to Down, it means that the node has not completely exited the cluster, at which time the release state of the node is set to ERROR.

[0057] Step 104, Re-release, release the new version of the node using UMC, set the release state of the node to DEPLOYING during the release process, to DEPLOYED after successful release, or to ERROR if waiting for more than 5 minutes without successful release or unknown exception.

[0058] Step 105, Start node, start the new version of the node using UMC, so that the application starts using the new configuration, set the release state of the node to STARTING during the release process, to STARTED after successful release, or to ERROR if waiting for more than 5 minutes without successful start or unknown exception.

[0059] Step 106, Check node cluster state, after the node is normally started, it will automatically join the cluster, at which time the node cluster state is checked to confirm that the state of the node in the cluster is Active, ensuring that it has been restored and joined the cluster, set the release state of the node to CHECKING during the checking process, or to ERROR if waiting for more than 5 minutes without successful start or unknown exception.

[0060] Step 107, Check node available state, use node verification test cases to check the normal function of the node, set the release state of the node to CHECKED after all test cases pass, or to ERROR if there is an exception in the execution result of the verification test case.

[0061] Step 108, Restore node traffic, restore the traffic state of the node to open on the traffic distribution, allowing normal user requests to enter.

[0062] Step 2: version update; edit node parameters in DeployCenter and save, DeployCenter uses UMC to batch update the configuration information of the nodes to be updated;

[0063] Step 3: split batch; according to the principle of "different nodes on the same shard cannot appear on the same node" generated by business security requirements, the nodes to be updated are divided into several batches for batch execution, DeployCenter performs one-key release, and the batch release process automatically runs;

[0064] Step 4: In the batch release process, DeployCenter follows and records the release status of each node, confirms whether the release status of each node is not ERROR, that is, judges whether all batches are executed; when all nodes in the current batch are executed and the status is normal, the current batch is successfully released; continue the release process, the nodes that have completed normal release provide external service, if any node produces abnormal status in the release process, the one-key release process is forced to stop, and the external user request on the abnormal node is cut off, the current release operation is ended and alarm feedback is executed.

[0065] As shown in Figure 2 , in step 4, the batch release process further includes the following steps:

[0066] Step 401: DeployCenter accepts the ID sequence of the target node and completes the update operation on the specified configuration field in UMC, at this time DeployCenter sets all node states in the cache to UPDATED;

[0067] Step 402: DeployCenter queries the business distribution information and machine distribution information of each node in the meta database of UMC, and encapsulates a plurality of data objects (SearcherReplicaDefine) into the batch cutting process with the ID of the node as the primary key;

[0068] Step 403: batch cutting process, in the cutting process, a kind of node isolation cutting method (abbreviated as SeperateRule) is designed, including: a, b are two independent businesses, shardN represents the Nth shard of the business, replicaN represents the Nth node of the shard, wherein there are A, B, C, D nodes:

[0069] A node has: a-shard1-replica1, b-shard1-replica1;

[0070] B node has: a-shard2-replica1, b-shard2-replica1;

[0071] On C node: a-shard1-replica2, b-shard1-replica2;

[0072] On D node: a-shard2-replica2, b-shard2-replica2;

[0073] According to the principle of "different nodes on the same shard cannot appear on different nodes" generated by the business security requirement, the four nodes are divided into two groups of AB and CD, and the nodes after grouping will be published in parallel in the respective groups, and any error of any node in the parallel publishing process will not affect the integrity of the business data, and the groups are published in series, completely isolated;

[0074] Step 404: Each group enters TaskExecutor, and after entering, the publishing process is completely free from manual intervention, and the state machine operates by itself, and the same number of threads as the batch number are started for parallel publishing, and each thread shares the same cache for recording state, and if any thread has a problem in the publishing process, there will be an ERROR state record in the cache;

[0075] Step 405: During the execution of the sequential batch, if there is an ERROR state record in the cache generated by the previous batch, the DeployCenter controls and does not allow the next batch to enter TaskExecutor, and the overall process exits. Otherwise, the publishing operation of all batches will continue to be executed until all nodes are published.

[0076] In order to make the purpose, technical solution description of the present application more clear, the present application will be further described in detail in combination with the drawings of the present application and specific embodiments: Figure 3 And specific embodiments:

[0077] Step S1-1 in the user interface, the user submits the node list and configuration that need to be updated

[0078] Step S1-2: The node list and configuration that need to be updated are updated in the metadata database of UMC, at this time, it is ensured that the nodes to be republished will use the new configuration for deployment and startup.

[0079] Step S2-1 in the user interface, the user clicks one-key publishing

[0080] Step S2-2: The node list enters DeployCenter

[0081] Step S2-3 DeployCenter gets node details by querying the database, encapsulates them as SearchReplicaDefine objects, and cuts them according to the SeparateRule, into several batches. The specific cutting logic is, for example: a, b are two independent businesses, shardN represents the Nth shard of the business, and replicaN represents the Nth node of the shard

[0082] On the A node: a-shard1-replica1, b-shard1-replica1

[0083] On the B node: a-shard2-replica1, b-shard2-replica1

[0084] On the C node: a-shard1-replica2, b-shard1-replica2

[0085] On the D node: a-shard2-replica2, b-shard2-replica2

[0086] The SeperateRule divides the four nodes into two groups, AB and CD, according to the principle that the same shard cannot appear on different nodes. The purpose of this is to ensure that even if the AB group fails, the AB two nodes cannot work normally, and the CD two nodes can still provide complete and normal services to users.

[0087] Step S3 Deploycenter starts to control the execution of the real publishing process, and sends SearchReplicaDefine into TaskExecutor multi-threaded concurrent execution in batches

[0088] In the multi-threaded TaskExcutor:

[0089] Step S4 According to the current SearchReplicaDefine record, cut off all business traffic on the current node

[0090] Step S5 stops the application process of the current node by UMC, monitors the Zookeeper recording the cluster state, and records the publishing cache state of the current node in the DeployNoteCache as STOPED if the state of the current stopped node is Down. If the state of the current stopped node is not displayed as Down in the Zookeeper, 15s of waiting is performed to ensure that the node is consistent with the real state in the cluster record state, and the maximum waiting is 30 rounds. If the consistency is not achieved after 30 rounds, it is determined that the stopping task fails, the publishing cache state of the current node is recorded in the DeployNoteCache as ERROR, and the process is exited.

[0091] Step S6 redeploys the current node by UMC. The new configuration used for deployment has been updated in the metadata database of the UMC, so the newly deployed application is the parameter configuration that has been updated. The publishing interface of the UMC is a synchronous interface, and the time consumption is unstable. Therefore, during the publishing process, the publishing cache state of the current node is set as DEPLOYING, and is set as DEPLOYED after the publishing is completed. If the action fails, considering the possibility of network interference, the action is executed again for retry. During the retry, the publishing cache state is kept as DEPLOYING. If the retry fails, the state is set as ERROR, and the process is exited.

[0092] Step S7-1 starts the current node by UMC. Due to the change of the configuration and the complexity of the application, the time consumption of the starting is unstable. Therefore, during the starting process, the publishing cache state of the current node is set as STARTING. If the starting fails, considering the possibility of network interference, the action is executed again for retry. During the retry, the publishing cache state is kept as STARTING. If the retry fails, the state is set as ERROR, and the process is exited.

[0093] Step S7-2 monitors the Zookeeper recording the cluster state. If the state of the current node is Active, the publishing cache state is recorded as STARTED. If the state of the current started node is not displayed as Active in the Zookeeper, 15s of waiting is performed to ensure that the node is correctly started and recognized by the system. The maximum waiting is 30 rounds. If the consistency is not achieved after 30 rounds, it is determined that the stopping task fails, the publishing cache state of the current node is recorded in the DeployNoteCache as ERROR, and the process is exited.

[0094] The node started in step S8 cannot be used immediately, and needs to be tested by using the test case encapsulated in SearchReplicaDefine to ensure normal service, and DeployCenter simulates the request of a user to request the test of the current node, and in the test process, the release cache state is set to CHECKING, and once the test case fails, the release cache state is set to ERROR and exits.

[0095] In step S9, all service traffics on the current node are recovered according to the record in SearchReplicaDefine.

[0096] Each thread in the multi-thread of TaskExcutor performs the operations of S4-S9 on each node, and interacts with and records the shared DeployNoteCache, and before each batch execution, it is checked whether the DeployNoteCache exists ERROR record, if it exists, the batch task is not executed, otherwise it is executed until the end of each batch release.

[0097] SeperateRule guarantees that each batch is independent and does not affect the overall service, and cooperates with the overall serial execution logic and cache check, which can block the possibility of all occurring failures, and due to the concurrent operation in each batch, the efficiency is still greatly improved compared with manual operation.

[0098] The beneficial effects achieved by the application are: through the rule design of SeperateRule and the release state and release execution process design in TaskExecutor, all operations of the operation and maintenance personnel in the batch upgrade of the node are solidified, so that each thread in the TaskExecutor execution process achieves the effect of simulating the operation of the same number of operation and maintenance personnel. The program replaces the operation of the operation and maintenance personnel, and the number of threads replaces the number of operation and maintenance personnel, so that the process efficiency of the application node batch release is greatly improved. The unified process control by DeployCenter can accurately and timely find the exception in the release process and make interruption processing, which greatly reduces the possibility of mistakes caused by communication compared with the original multi-person operation.

[0099] The application also has other various implementation manners, and those skilled in the art can make various corresponding changes and modifications according to the application without departing from the spirit and essence of the application, and these corresponding changes and modifications should all belong to the protection scope of the claims of the application

[0100] The above embodiments do not limit the application in any way, and any other improvements and applications made by equivalent transformation to the above embodiments all belong to the protection scope of the application.

Claims

1. A method for distributed application bulk release, the method comprising: The method comprises the following steps: step 1: selecting the nodes to be upgraded that meet the target conditions by presetting filtering options in the DeployCenter and checking them; step 2: editing the node parameters in the DeployCenter and saving, and the DeployCenter uses the UMC to update the configuration information of the nodes to be updated in batches; step 3: the DeployCenter performs one-key release, and the batch release process is automatically run; step 4: in the batch release process, the DeployCenter follows and records the release states of the nodes, when all the nodes in the current batch are executed and the states are all normal, the release process is continued, the nodes that have completed the normal release provide external services, if any node produces an abnormal state in the release process, the one-key release process is forced to stop, the external user request on the abnormal node is cut off, and an alarm feedback is executed; In the step 1, a finite state machine is preset in the DeployCenter, more than one node release state and more than one release execution process are preset in the finite state machine; the preset node release state and the execution process step are mapped to the state and transition of the finite state machine, including that the result condition generated by each step corresponds to a state of the finite state machine, and the flow of the subsequent step determined according to the result corresponds to the transition of a state of the finite state machine; The input event triggered by the preset is used to release the specified version in the nth node; In the step 1, the finite state machine is a TaskExecutor, including 14 preset node release states and 8 release execution processes; the 14 node release states are UNUPDATE, UPDATED, FLOW_START, NETFLOW_CLOSED, STOPPED, DEPLOYING, DEPLOYED, STARTING, STARTED, CHECKING, CHECKED, NETFLOW_OPEN, FLOW_END and ERROR; and the 8 release execution processes are: Step 101, closing the node business flow, cutting off the flow of all businesses existing on the node on the flow distribution to ensure that the user request is not affected, setting the release state of the node to the NETFLOW_CLOSED state in the state machine, when the node is in the business flow closing state, the search service router will no longer send a request to the node, thereby cutting off the user flow, if any exception occurs in the process and the flow is not cut off, the release state of the node is set to the ERROR; Step 102, stopping the node by using the UMC, setting the release state to STOPPED after the node is stopped, and setting to the ERROR if any exception occurs in the process; Step 103, check if the node's state in the search cluster is Down, ensure that it has exited the cluster, after completion, release the node to the STOPPED state, used to mark the node has been completely closed and exited the cluster, if the node cluster state is waiting for more than 5 minutes and still not switched to Down, it means that the node has not completely exited the cluster, at this time the node release state is set to ERROR; Step 104, re-release, use UMC to release the new version of the node, set the node release state to STARTING during the release process, set it to STARTED after successful release, set it to ERROR if it still fails to release or produces unknown exceptions after waiting for more than 5 minutes; Step 105, start the node, use UMC to start the new version of the node, make the application start with the new configuration, set the node release state to DEPLOYING during the release process, set it to DEPLOYED after successful release, set it to ERROR if it still fails to start or produces unknown exceptions after waiting for more than 5 minutes; Step 106, check the node cluster state, the node will automatically join the cluster after normal startup, at this time check the node cluster state, confirm that the node's state in the cluster is Active, ensure that it has recovered and joined the cluster, set the node release state to CHECKING during the checking process, set it to ERROR if it still fails to start or produces unknown exceptions after waiting for more than 5 minutes; Step 107, check the node's available state, use node verification test cases to check if the node's function is normal, set the node release state to CHECKED after all test cases pass, set it to ERROR if there are exceptions in the execution results of the verification cases; Step 108, restore node traffic, restore the node's traffic state to open on traffic allocation, allow normal user requests to enter.

2. The method for batch releasing distributed applications of claim 1, wherein: In step 4, the batch release process further includes the following steps: step 401: DeployCenter accepts the ID sequence of the target node and completes the update operation on the specified configuration field in UMC, at this time DeployCenter sets all node states in the cache to UPDATED; step 402: DeployCenter queries the business distribution information and machine distribution information of each node in the meta database of UMC, and encapsulates a plurality of data objects into the batch cutting process with the ID of the node as the primary key; step 403: batch cutting process, in the cutting process, a kind of node isolation cutting method is designed, including: a, b are two independent businesses, shardN represents the Nth shard of the business, replicaN represents the Nth node of the shard, wherein there are A, B, C, D nodes: A node has: a-shard1-replica1, b-shard1-replica1; B node has: a-shard2-replica1, b-shard2-replica1; C node has: a-shard1-replica2, b-shard1-replica2; D node has: a-shard2-replica2, b-shard2-replica2; the four nodes are divided into two groups AB and CD, the nodes after grouping are released in parallel within the respective groups, and the groups are released in series between the groups, which are completely isolated; step 404: each group enters TaskExecutor, after entering, the release process is completely free from manual intervention, the state machine operates automatically, a plurality of threads with the same number as the batch are started for parallel release, each thread shares the same cache for recording state, and if a problem occurs in the release process of any thread, there is an ERROR state record in the cache; step 405: in the process of sequential batch execution, if there is an ERROR state record in the cache generated by the previous batch, DeployCenter controls and does not allow the next batch to enter TaskExecutor, the overall process exits, otherwise the release operation of all batches will continue to be executed until all nodes are released.

Images