A method for hot deployment of a WMS system and a MES system

Abstract

The application relates to the technical field of hot deployment, and discloses a WMS system and MES system hot deployment implementation method, which comprises the following steps: acquiring an available instance set of service instances in a target system; determining a deployment strategy according to the number of instances in the available instance set and a preset environment type; when the deployment strategy is a multi-node master-backup rotation strategy, identifying a master node instance and a backup node instance in the available instance set, performing baseline correction on the traffic distribution weight of the master node instance and the backup node instance; performing update and restart operations on the backup node instance, and performing health detection after the restart; adjusting the traffic distribution weight of the master node instance and the backup node instance after passing the health detection; performing update and restart operations on the master node instance, and performing health detection after the restart; and adjusting the traffic distribution weight of the master node instance and the backup node instance after passing the health detection. The overall unavailability risk caused by the simultaneous restart of the double nodes is effectively avoided, and the system availability is improved.

Description

Technical Field

[0001] This invention relates to the field of hot deployment technology, and in particular to a method for hot deployment of WMS and MES systems. Background Technology

[0002] Warehouse Management System (WMS) and Manufacturing Execution System (MES) are core business systems in the digital transformation of manufacturing enterprises. WMS is responsible for warehousing, inbound and outbound operations, and inventory scheduling, while MES is responsible for production execution, data acquisition, process control, and task scheduling. The two typically have frequent interface interactions and collaborative operations. With increasing business continuity requirements, WMS and MES services need to minimize downtime during version upgrades, defect fixes, and configuration updates to ensure uninterrupted warehousing and shop floor operations.

[0003] Currently, with the widespread adoption of containerization and microservice architecture, WMS and MES system services are often deployed using Docker containers, and instance management and traffic weight allocation are achieved through service registration and discovery centers such as Nacos. For service update scenarios, common deployment methods include: directly restarting a single instance service, simultaneously deploying multiple instances, or using traditional blue-green deployment and canary deployment. Among these, directly restarting a single instance is simple but causes significant service interruption; simultaneously deploying multiple instances is more efficient but concentrates risks, easily leading to overall unavailability; traditional blue-green or canary deployments are mostly used in internet scenarios and have not been deeply adapted to the characteristics of the coupled interfaces of WMS and MES systems, industrial network environments, and post-deployment rollback strategies.

[0004] In addition, existing technologies also disclose failover schemes for primary-backup switching based on service health status, such as Chinese invention patent applications with publication numbers CN119621441A and CN121691345A. These schemes mainly solve the problem of passive recovery after service anomalies, such as achieving high availability by detecting node status, allocating weights, and removing faulty nodes. Their technical motivation is to quickly switch after a failure, rather than to deploy without service interruption during proactive upgrades.

[0005] In summary, the existing solutions generally have the following shortcomings: First, there is a lack of differentiated deployment strategies for single-node testing environments and multi-node production environments, which cannot meet the actual needs of parallel deployment of WMS and MES systems in multiple environments.

[0006] Second, the lack of a closed-loop control system of weight verification, rotation restart, health detection, and traffic rollback makes it difficult to achieve a smooth transfer of traffic during proactive upgrades.

[0007] Third, the health detection methods are relatively simple, relying mainly on network heartbeat or general interface detection, which cannot truly reflect the availability of WMS and MES at the business level.

[0008] Fourth, it lacks a timeout fallback and secondary restart recovery mechanism, resulting in insufficient recovery capabilities when upgrade anomalies occur.

[0009] Therefore, how to achieve smooth hot deployment of container services without stopping services or with only minimal downtime when upgrading, fixing defects, or updating configurations of WMS and MES systems is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0010] The technical problem this invention aims to solve is: how to achieve hot deployment with no service interruption or low-awareness service interruption when WMS and MES systems are actively upgrading versions or fixing defects.

[0011] To address the aforementioned technical problems, this invention provides a method for hot deployment of a WMS system and a MES system, comprising the following steps: Obtain the set of available service instances in the target system; the target system is a WMS system or a MES system. The deployment strategy is determined based on the number of instances in the available instance set and the preset environment type; the deployment strategy includes a single-node direct restart strategy and a multi-node master-slave rotation strategy. When the deployment strategy is the multi-node primary / backup rotation strategy, the primary node instance and the backup node instance in the available instance set are identified, and baseline correction is performed on the traffic allocation weight of the primary node instance and the backup node instance, so that the primary node instance carries all traffic and the backup node instance carries zero traffic. Perform update and restart operations on the backup node instance, and perform a health check after restarting; Once the backup node instance passes the health check, the traffic allocation weight between the primary node instance and the backup node instance is adjusted to switch all traffic to the backup node instance. Perform update and restart operations on the master node instance, and perform a health check after restarting; Once the primary node instance passes the health check, the traffic allocation weights between the primary node instance and the backup node instance are adjusted again to switch all traffic back to the primary node instance.

[0012] Furthermore, the health check specifically includes: Perform health checks periodically according to the preset polling interval; If the health check fails for a consecutive first preset time period, a compensation restart operation will be triggered. If the health check fails after a cumulative period exceeding the second preset time since the first restart, the deployment is deemed a failure and terminated.

[0013] Furthermore, the health check also includes performing at least one business interface probe on the target instance; the business interface probe includes: Call the menu query interface and verify the validity of the returned structure; call the work order query interface and verify the reachability of the core business interface; call the user verification and login interface and determine that the authentication link is normal based on the preset error semantics. The instance is deemed healthy when all probe links meet the preset conditions.

[0014] Furthermore, obtaining the set of available service instances in the target system specifically includes: Retrieve the list of target service instances from the Nacos service registry and filter out the instances that are in the enabled state; For each instance, the container name is read remotely from its IP address to form a set of available instances containing the IP address, weight, and container name.

[0015] Furthermore, determining the deployment strategy based on the number of instances in the available instance set and the preset environment type specifically includes: If the number of instances in the available instance set is less than or equal to 1, and the preset environment type is a test environment, then the single-node direct restart strategy is executed. If the number of instances in the available instance set is less than or equal to 1, and the preset environment type is a production environment, then it is determined that the hot deployment conditions are not met and the process is terminated. If the number of instances in the available instance set is greater than 1, then the multi-node primary / backup rotation strategy is determined.

[0016] Furthermore, when the deployment strategy is the multi-node primary / standby rotation strategy, identifying the primary node instance and standby node instance in the available instance set, and performing baseline correction on the traffic allocation weights of the primary node instance and the standby node instance, specifically includes: According to the container naming rules, instances that do not contain the preset backup identifier are identified as the master node instance, and instances that contain the preset backup identifier are identified as the backup node instance. Perform weight capability verification. If weight modification fails, automatically repair the Nacos protocol mapping and retry. The weight of the master node instance is adjusted to a first preset value, and the weight of the backup node instance is adjusted to a second preset value; wherein, the first preset value represents carrying all traffic, and the second preset value represents carrying zero traffic.

[0017] Furthermore: The step of switching all traffic to the backup node instance specifically involves: adjusting the weight of the backup node instance to the first preset value and adjusting the weight of the primary node instance to the second preset value. The step of switching all traffic back to the master node instance specifically involves restoring the weight of the master node instance to the first preset value and restoring the weight of the backup node instance to the second preset value.

[0018] Furthermore, the step of performing update and restart operations on the backup node instance or the master node instance specifically includes: Copy the release files into the container directory of the target instance; Restart the container.

[0019] Furthermore, the traffic allocation weight is the load allocation traffic ratio parameter managed by the Nacos service registry center; the target system is deployed using Docker containers.

[0020] Furthermore, the preset environment type is determined by at least one of the following parameters: remote IP address, Nacos port, API container naming rules, Web API directory, and environment name.

[0021] Compared with the prior art, the present invention has at least the following beneficial effects: This invention dynamically selects between a single-node direct restart or a multi-node primary / standby rotation strategy based on the number of available instances and the environment type. In multi-node scenarios, it first performs weight baseline correction on the primary and standby nodes, then sequentially completes the rotation upgrade and health checks of the standby and primary nodes, and achieves smooth traffic switching and rollback after each stage. Thus, when WMS and MES systems are upgraded or defect-fixed, it can achieve smooth hot deployment with no service interruption or only minimal service interruption, effectively avoiding the overall unavailability risk caused by simultaneous restart of two nodes, reducing the probability of interruption in warehouse management and production execution, and improving system availability and release security. Attached Figure Description

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

[0023] Figure 1 This is the overall flowchart disclosed in this invention.

[0024] Figure 2 This is the timing diagram of the primary and backup node rotation and weight switching disclosed in this invention. Detailed Implementation

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

[0026] This invention aims to provide a hot deployment algorithm for WMS & MES systems, applicable to containerized deployment environments of Warehouse Management Systems (WMS) and Manufacturing Execution Systems (MES). In typical application scenarios, WMS and MES systems use Docker containers for service encapsulation, and manage service instances and dynamically allocate traffic weights through the Nacos service registration and discovery center. When version upgrades, bug fixes, or configuration updates are required, the system administrator or automated deployment platform triggers the hot deployment process described in this embodiment, thereby completing service updates while minimizing disruption to business access.

[0027] Please see Figure 1 The entire hot deployment process starts from startup and goes through parameter initialization, instance discovery, node quantity determination, primary / standby identification and weight baseline correction, standby node rotation restart and traffic takeover, primary node rotation restart and traffic switchback, and finally ends. The following is a detailed explanation of this method.

[0028] Step 1: Parameter initialization and environment preparation.

[0029] In this solution, when a hot deployment task is triggered, an initialization operation is performed first. The system obtains the environment parameters of the target WMS or MES system. These parameters include, but are not limited to: remote IP address, Nacos service port, API container naming rules, Web API directory path, and the current environment name (e.g., identifying whether it is a test or production environment). Based on the obtained parameters, the system constructs a Docker controller and a Nacos controller. The Docker controller is responsible for subsequent operations on container instances, including file copying and container restarting; the Nacos controller is responsible for operations on the service registry, including querying service instances and modifying instance weights.

[0030] It's important to note that during the initialization phase, the system also performs a conversion between logical service names and registry service names. In practice, internal logical service names may use underscores, while the Nacos registry typically requires service names to use hyphens. Therefore, the system automatically converts underscores to hyphens to ensure that the target service's registration information in Nacos can be correctly retrieved.

[0031] Step 2: Instance discovery and construction of the available instance set.

[0032] After initialization, the system retrieves a list of all instances of the target service from the Nacos service registry. Specifically, the Nacos controller calls the API provided by Nacos, passing in the service name, to obtain information on all instances currently registered under that service. Each instance's information includes at least its IP address, port number, current weight value, and enabled status.

[0033] The system filters the obtained list of instances, retaining only those with a true "enabled" status. For each filtered instance, the system uses its IP address to remotely execute commands to retrieve the name of the target container running on the host machine containing that IP. The container name can be obtained via the Docker API or remote shell commands. After this processing, the system forms a set of available instances. Each element in this set of available instances contains at least the instance's IP address, current weight value, and container name.

[0034] It's important to note that the construction process for the available instance set takes into account the actual accessibility of the instances. If an instance is marked as enabled in Nacos, but its corresponding container cannot be read on the physical host, then that instance will not be included in the available instance set. This mechanism avoids misjudgments caused by container anomalies.

[0035] Step 3: Determine the number of nodes and select a deployment strategy.

[0036] After obtaining a set of available instances, the system determines the number of instances in the set and selects the appropriate deployment strategy based on the determination result and the preset environment type.

[0037] Specifically: Step 3.1: If the number of available instances is less than or equal to 1, the system further checks whether the current environment is a test environment. The test environment information comes from the environment name parameter obtained during the initialization phase. If the current environment is a test environment and the number of instances is 1, the system allows the direct restart strategy to be executed.

[0038] The direct restart strategy involves not switching traffic, but directly performing update and restart operations on the single instance. This strategy is suitable for functional verification environments because test environments have lower requirements for business continuity, and short-term service interruptions are acceptable.

[0039] Step 3.2: If the number of available instances is less than or equal to 1, but the current environment is a production environment, the system determines that the hot deployment conditions are not met, throws an exception, and terminates the entire deployment process. This design is because production environments require high availability, and single-node deployment cannot achieve uninterrupted upgrades; forcibly executing such an operation could lead to business interruption. Therefore, the system uses an abnormal termination to prompt operations personnel to check the environment configuration or expand the number of nodes.

[0040] Step 3.3: If the number of available instances is greater than 1, the system will enter a multi-node primary / standby rotation strategy. This is the core deployment mode of this invention, suitable for production environments or pre-production environments requiring high availability.

[0041] Step 4: Identification of primary and backup nodes and correction of weight baseline.

[0042] Specifically, once a multi-node primary / standby rotation strategy is adopted, the system identifies the primary / standby roles of instances in the available instance set. This identification is based on container naming rules. In actual deployments, operations personnel agree on naming conventions for different container instances of the same service. For example, instances without a specific identifier are designated as primary nodes, while instances with the identifiers "bak" or "backup" are designated as standby nodes. Following this rule, the system identifies instances without a preset standby identifier as primary node instances and instances with a preset standby identifier as standby node instances.

[0043] After role identification is complete, the system performs weight baseline correction. The purpose of weight baseline correction is to establish a clear initial state—that is, the primary node carries all business traffic, and the backup node carries no traffic. To achieve this goal, the system first performs weight capability verification, that is, attempts to modify the weight values ​​of the primary and backup nodes through the Nacos controller. If the modification fails, the system automatically repairs the Nacos protocol mapping and retryes to ensure that the weight modification operation is successful.

[0044] After successfully modifying the weights, the weight of the primary node instance is set to 100, and the weight of the standby node instance is set to 0. In Nacos' load balancing mechanism, the weight value determines the proportion of traffic allocated to that instance. A weight of 100 means the instance receives all requests, while a weight of 0 means the instance receives no requests. Through this baseline correction, the system ensures that all user requests are processed by the primary node before subsequent rotation operations begin, with the standby nodes in an idle, standby state.

[0045] It should be noted that the weight of the primary node instance is set to 100, and the weight of the standby node instance is set to 0. The values ​​in this description are not percentages. In Nacos' load balancing mechanism, nodes allocate traffic according to their instance weight ratios. Nodes with a weight greater than 0 participate in traffic distribution, while those with a weight equal to 0 do not receive requests. Currently, the primary node has a weight of 100, and the standby node has a weight of 0; all traffic is handled by the primary node.

[0046] Step 5, Backup Node Rotation: Restart and Health Check.

[0047] After completing the weight baseline correction, the system enters the first phase of the rotation operation, which involves updating and restarting the standby node. Specific operations include: copying the required program files and configuration files for this release into the specified directory of the standby node container; and then restarting the container via the Docker controller.

[0048] After the restart operation is initiated, the system enters a health waiting phase. This step aims to ensure that traffic switching only occurs after the node has fully recovered its service capabilities following the restart.

[0049] In one specific embodiment, the system performs a health check on the backup node at 5-second intervals. This health check sequentially performs the following probes: First, the menu query interface is called. The system sends a request to the backup node to retrieve the menu structure and verifies whether the returned data structure meets expectations. If the returned data format is correct and contains the necessary fields, the check is considered successful.

[0050] Second, the system calls the work order query interface. It sends a work order list query request to the backup node to verify whether the core business interface is reachable and can return data normally. Work order query is one of the most basic operations in WMS and MES systems, and the availability of this interface directly reflects the system's ability to handle core business processes.

[0051] Third, the user verification and login interface is invoked. The system simulates user login behavior, sending a username and password, and checks whether the returned result contains preset error semantics (such as username or password mismatch). The reason for using preset error semantics instead of requiring a completely successful login is that in an automated detection environment, genuine and valid user credentials are usually unavailable. By checking whether the detection system can correctly identify invalid credentials and return specific error messages, it can be determined whether the authentication chain is working properly.

[0052] If all three probe links meet the preset conditions, the system determines that the standby node instance is healthy. If any probe fails, the health check is deemed to have failed, and the system returns to the health waiting phase. The system performs the above health check every 5 seconds. If the health check fails for 5 consecutive minutes (i.e., 60 check cycles), the system triggers a compensatory restart operation. This involves restarting the standby node container again to resolve any service disruptions that may have been caused by occasional issues during startup. After the compensatory restart, the system continues to perform health checks every 5 seconds.

[0053] If more than 20 minutes have passed since the initial restart and the backup node still fails the health check, the system determines that the deployment has failed, terminates the entire hot deployment process, and throws an exception. This timeout exit mechanism avoids indefinite waiting and ensures the controllability of the deployment process.

[0054] Step 6: Switch traffic to the backup node.

[0055] Once the standby node successfully passes the health check, the system performs a traffic switching operation. Specifically, the system modifies the weight values ​​of the primary and standby nodes through the Nacos controller—setting the standby node's weight to 100 and the primary node's weight to 0. This weight swap ensures that all subsequent user requests are distributed to the standby node, while the primary node no longer receives new requests.

[0056] At this point, the backup node officially takes over all business traffic. Since the backup node has completed the program update, users have actually begun using the new version of the service. The primary node, however, remains in the old version state and no longer processes business requests.

[0057] Step 7, Master Node Rotation: Restart and Health Check.

[0058] In a further proposed solution, after traffic is switched to the backup node, the system enters the second phase of the rotation operation, which involves updating and restarting the primary node. Similar to the backup node, the update operation for the primary node includes copying the published files into a specified directory within the primary node container, and then restarting the container.

[0059] After the master node restarts, the system also enters a health waiting phase. In one specific embodiment, the same health detection mechanism as the backup node is applied to the master node—checking the menu interface, work order interface, and authentication interface every 5 seconds; if they fail for 5 consecutive minutes, a compensatory restart is triggered; if they fail for more than 20 minutes in total, the deployment is deemed a failure and terminated.

[0060] It should be noted that during the primary node's restart and health check, the backup node continues to handle all business traffic, so users are unaware of it. The primary node's update process has no impact on online services.

[0061] Step 8: Traffic is switched back to the master node.

[0062] After the primary node successfully passes the health check, the system performs a traffic rollback operation. The system then modifies the weight values ​​of the primary and backup nodes again through the Nacos controller—restoring the primary node's weight to 100 and the backup node's weight to 0. At this point, traffic returns to the primary node, and the backup node once again enters an idle standby state.

[0063] At this point, the primary node has completed the program update, becoming the new version of the service instance and handling all business traffic. The backup node, while still running the new version of the program, does not receive traffic and serves only as a backup node for the next hot deployment.

[0064] The entire hot deployment process is now successfully completed. Users may experience only a very brief connection fluctuation during the weight switching process, but there will be no complete service interruption.

[0065] In addition, to ensure the traceability and maintainability of the hot deployment process, the system records stage logs for the entire deployment process at each critical operation step. These stage logs include instance discovery logs, weight adjustment logs, restart action logs, health check result logs, and exception information logs; when any critical step fails, an exception is thrown, and finally, an alarm mechanism notifies the operations and maintenance personnel.

[0066] In some specific implementations, the technical solution of the present invention fully considers the differences between the test environment and the production environment of WMS and MES systems in actual enterprise deployments. Therefore, the test environment typically has only one service instance and allows for brief interruptions; the production environment typically has two or more instances and requires non-stop upgrades.

[0067] Please see Figure 2 It demonstrates the timing of primary / standby node rotation and weight switching. Specifically: Initially, the master node has a weight of 100, the backup node has a weight of 0, and all traffic flows to the master node.

[0068] Phase 1: The system performs update and restart operations on the standby node. The upward arrow in the diagram represents the restart action. After restarting, the system performs a health check, which is represented by multiple round-trip arrows in the diagram indicating periodic polling checks.

[0069] Phase Two: After the backup node passes the health check, the system modifies the weights, setting the backup node weight to 100 and the primary node weight to 0. At this point, traffic is switched to the backup node.

[0070] Phase 3: The system performs update and restart operations on the master node, which is also accompanied by health checks.

[0071] Phase 4: After the primary node passes the health check, the system modifies the weights again, restoring the primary node's weight to 100 and the backup node's weight to 0. Traffic is then switched back to the primary node.

[0072] This sequence diagram clearly illustrates the alternating update process of the primary and backup nodes on the timeline, as well as the two flips of the weight values. This process ensures that at any given time, at least one node is processing a business request.

[0073] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for hot deployment of a WMS system and a MES system, characterized in that, Includes the following steps: Obtain the set of available service instances in the target system; the target system is a WMS system or a MES system. The deployment strategy is determined based on the number of instances in the available instance set and the preset environment type; the deployment strategy includes a single-node direct restart strategy and a multi-node master-slave rotation strategy. When the deployment strategy is the multi-node primary / backup rotation strategy, the primary node instance and the backup node instance in the available instance set are identified, and baseline correction is performed on the traffic allocation weight of the primary node instance and the backup node instance, so that the primary node instance carries all traffic and the backup node instance carries zero traffic. Perform update and restart operations on the backup node instance, and perform a health check after restarting; Once the backup node instance passes the health check, the traffic allocation weight between the primary node instance and the backup node instance is adjusted to switch all traffic to the backup node instance. Perform update and restart operations on the master node instance, and perform a health check after restarting; Once the primary node instance passes the health check, the traffic allocation weights between the primary node instance and the backup node instance are adjusted again to switch all traffic back to the primary node instance.

2. The method for hot deployment of WMS and MES systems according to claim 1, characterized in that, The health check specifically includes: Perform health checks periodically according to the preset polling interval; If the health check fails for a consecutive first preset time period, a compensation restart operation will be triggered. If the health check fails after a cumulative period exceeding the second preset time since the first restart, the deployment is deemed a failure and terminated.

3. The method for hot deployment of WMS and MES systems according to claim 1 or 2, characterized in that, Health checks also include performing at least one business interface probe on the target instance; the business interface probe includes: Call the menu query interface and verify the validity of the returned structure; call the work order query interface and verify the reachability of the core business interface; call the user verification and login interface and determine that the authentication link is normal based on the preset error semantics. The instance is deemed healthy when all probe links meet the preset conditions.

4. The method for hot deployment of WMS and MES systems according to claim 1, characterized in that, The acquisition of the available instance set of service instances in the target system specifically includes: Retrieve the list of target service instances from the Nacos service registry and filter out the instances that are in the enabled state; For each instance, the container name is read remotely from its IP address to form a set of available instances containing the IP address, weight, and container name.

5. The method for hot deployment of WMS and MES systems according to claim 1, characterized in that, The step of determining the deployment strategy based on the number of instances in the available instance set and the preset environment type specifically includes: If the number of instances in the available instance set is less than or equal to 1, and the preset environment type is a test environment, then the single-node direct restart strategy is executed. If the number of instances in the available instance set is less than or equal to 1, and the preset environment type is a production environment, then it is determined that the hot deployment conditions are not met and the process is terminated. If the number of instances in the available instance set is greater than 1, then the multi-node primary / backup rotation strategy is determined.

6. The method for hot deployment of WMS and MES systems according to claim 1, characterized in that, When the deployment strategy is the multi-node primary / standby rotation strategy, the primary node instance and the standby node instance in the available instance set are identified, and baseline correction is performed on the traffic allocation weights of the primary node instance and the standby node instance, specifically including: According to the container naming rules, instances that do not contain the preset backup identifier are identified as the master node instance, and instances that contain the preset backup identifier are identified as the backup node instance. Perform weight capability verification. If weight modification fails, automatically repair the Nacos protocol mapping and retry. The weight of the master node instance is adjusted to a first preset value, and the weight of the backup node instance is adjusted to a second preset value; wherein, the first preset value represents carrying all traffic, and the second preset value represents carrying zero traffic.

7. The method for hot deployment of WMS and MES systems according to claim 6, characterized in that: The step of switching all traffic to the backup node instance specifically involves: adjusting the weight of the backup node instance to the first preset value and adjusting the weight of the primary node instance to the second preset value. The step of switching all traffic back to the master node instance specifically involves restoring the weight of the master node instance to the first preset value and restoring the weight of the backup node instance to the second preset value.

8. The method for hot deployment of WMS and MES systems according to claim 1, characterized in that, The update and restart operations performed on the backup node instance or the master node instance specifically include: Copy the release files into the container directory of the target instance; Restart the container.

9. The method for hot deployment of WMS and MES systems according to claim 1, characterized in that, The traffic allocation weight is the load allocation traffic ratio parameter managed by the Nacos service registry center; the target system is deployed using Docker containers.

10. The method for hot deployment of WMS system and MES system according to claim 1, characterized in that, The preset environment type is determined by at least one of the following parameters: remote IP, Nacos port, API container naming rules, Web API directory, and environment name.

Images