Java background service deployment method and system based on double-node dynamic routing

Abstract

The application relates to a Java background service deployment method and system based on a dual-node dynamic route, the method obtains the health state of each node based on TCP port activity detection and / or UDP heartbeat packet detection; a node with a detection failure number exceeding a preset number is judged as a fault node, and the fault node is set as an offline state; the flow distribution weight is determined according to the real-time working state of the node; the client request is routed and distributed based on the flow distribution weight; the application improves the resource utilization rate of the node by dynamically adjusting the route distribution based on the flow distribution weight, and avoids the overloading of a single node; when a fault node appears, another node is automatically switched to respond to the request, and the fault switching time is shortened; the data consistency between the dual nodes is adjusted based on a Redis cluster and a MySql cluster. Based on the cooperation of each step, the problems of fault switching delay, low resource utilization and low data consistency in the traditional scheme are solved.

Description

Technical Field

[0001] This invention relates to the field of distributed system technology, and in particular to a Java backend service deployment method and system based on dual-node dynamic routing. Background Technology

[0002] 1. Existing Problems: Traditional single-node deployments pose a single point of failure risk, resulting in long recovery times (RTO) and impacting business continuity. In dual-node deployments, static load balancing strategies (such as round-robin) cannot dynamically perceive node load, leading to uneven resource utilization. Data synchronization delays may cause inconsistencies in node states (e.g., overselling of inventory).

[0003] 2. Existing solutions have drawbacks: The Nginx+Keepalived solution requires manual switching of faulty nodes, resulting in high operational costs. Spring Cloud's native Ribbon load balancer lacks real-time weight adjustment capabilities. Summary of the Invention

[0004] Therefore, it is necessary to provide a Java backend service deployment method and system based on dual-node dynamic routing to address the aforementioned problems.

[0005] This application provides a Java backend service deployment method based on dual-node dynamic routing, the method including:

[0006] The health status of each node is obtained based on TCP port activity detection and / or UDP heartbeat packet detection.

[0007] Nodes that fail to detect more than a preset number of times are identified as faulty nodes and are set to offline status.

[0008] Traffic allocation weights are determined based on the real-time working status of the nodes;

[0009] Based on the traffic allocation weight, client requests are routed and distributed. If the target of the route is a faulty node, the route is switched to a healthy node.

[0010] Adjusting data consistency between two nodes based on Redis cluster and MySQL cluster.

[0011] In one embodiment, determining a node whose detection failure count exceeds a preset number as a faulty node and setting the faulty node to an offline state includes: when any node continuously performs TCP port activity detection and / or UDP heartbeat packet detection, and the detection results are all failed N times in a row, the corresponding node is a faulty node, and the faulty node is automatically triggered to go offline, where N is the preset number of times.

[0012] In one embodiment, determining the traffic allocation weight based on the real-time working status of the node includes: obtaining the node's CPU utilization, memory idle rate, and request response time in real time to calculate the traffic allocation weight. The traffic allocation weight weight is calculated using the formula: Weight = (1 / request response time) × (1 - CPU utilization) × memory idle rate.

[0013] In one embodiment, adjusting the data consistency between the two nodes based on the Redis cluster and the MySQL cluster includes: when a client initiates a write operation request, ensuring that only the target object node processes and locks the data through a Redis distributed lock, releasing the lock and synchronizing it to the other node after the operation is completed; when a client initiates a read operation request, synchronizing the data from the target object node to the other node through the MySQL real-time synchronization mechanism.

[0014] In one embodiment, both nodes are Spring Boot framework.

[0015] In one embodiment, a bidirectional communication link is established between the two nodes for synchronizing caches and forwarding incomplete transaction contexts.

[0016] In one embodiment, the method further includes: automatically re-registering and restoring traffic allocation after the faulty node recovers.

[0017] In one embodiment, the method further includes: initializing node parameters, the node parameters including one or a combination of IP address, port, service name and initial traffic allocation weight.

[0018] This application provides a Java service deployment system based on dual-node dynamic routing, the system comprising:

[0019] The client module is used to initiate requests;

[0020] The Zuul gateway module is used to receive and initially filter requests.

[0021] The first and second nodes are used to handle business logic and are both deployed based on Spring Boot.

[0022] Redis clusters are used for distributed write operation control.

[0023] MySQL clusters are used for data consistency synchronization between nodes;

[0024] The Eureka registry is used to obtain the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection. The Eureka registry is also used to register service instances for the first node and the second node.

[0025] The dynamic routing engine module includes:

[0026] The calculation module is used to determine the traffic allocation weight based on the real-time working status of the nodes;

[0027] The decision module is used to route and distribute requests from client modules based on traffic allocation weights. If the target of the route is a faulty node, it switches to a healthy node.

[0028] In one embodiment, the dynamic routing engine module is implemented based on Spring Cloud Gateway and can adjust the request distribution strategy according to the real-time working status of the nodes.

[0029] One of the above technical solutions has the following advantages and beneficial effects:

[0030] In the various embodiments of the Java backend service deployment method based on dual-node dynamic routing described above, this method obtains the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection. Nodes that fail detection more than a preset number of times are identified as faulty nodes and set to offline status. Compared with traditional node fault detection methods (such as Eureka registry center relying solely on HTTP heartbeats for node fault detection), this method can significantly reduce the false positive rate. Furthermore, it determines traffic allocation weights based on the real-time working status of nodes, specifically by considering node load factors such as CPU utilization, memory idle rate, and request response time. This application assigns weights to route client requests. If the target node is a faulty node, the system automatically switches to a healthy node. Specifically, by obtaining the traffic allocation weights of each node based on its real-time operating status, the system dynamically adjusts the routing based on these weights. For example, more requests are allocated to nodes with higher traffic allocation weights, thereby improving node resource utilization and preventing overloading of a single node. However, when the target node for a response request is a faulty node, the system automatically switches to another node to handle the request. Combined with node fault detection methods, this shortens failover time. By adjusting data consistency between the two nodes based on Redis and MySQL clusters, data conflicts can be avoided in high-concurrency scenarios. This application achieves intelligent node traffic allocation based on the real-time operating status of nodes, combined with a low-false-error node fault detection method, and utilizes Redis and MySQL clusters to solve data consistency problems, thereby addressing the issues of delayed failover, low resource utilization, and low data consistency in traditional deployment solutions. Attached Figure Description

[0031] Figure 1This is one of the flowcharts for a Java backend service deployment method based on dual-node dynamic routing in one embodiment of this application;

[0032] Figure 2 This is the second flowchart of a Java backend service deployment method based on dual-node dynamic routing in one embodiment of this application;

[0033] Figure 3 This is a schematic diagram of the architecture of a Java backend service deployment system based on dual-node dynamic routing in one embodiment of this application.

[0034] The correspondence between the reference numerals and the component names is as follows:

[0035] 10 Client module, 20 Zuul gateway module, 30 Dynamic routing engine module, 40 First node, 50 Second node, 60 Eureka registry center, 71 Redis cluster, 72 MySQL cluster. Detailed Implementation

[0036] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0037] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0038] The following describes, with reference to the accompanying drawings, a Java service deployment method and system based on dual-node dynamic routing in some embodiments of the present invention.

[0039] like Figure 1 As shown in the figure, this embodiment discloses a Java backend service deployment method based on dual-node dynamic routing, the method including:

[0040] Step S200: Obtain the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection;

[0041] Step S300: Determine the nodes whose detection failure count exceeds the preset number as faulty nodes and set the faulty nodes to offline status.

[0042] Step S400: Determine the traffic allocation weight based on the real-time working status of the nodes;

[0043] Step S500: Distribute client requests by route based on traffic allocation weights. If the target of the route is a faulty node, switch to a healthy node.

[0044] Step S600: Adjust the data consistency between the two nodes based on Redis cluster 71 and MySQL cluster 72.

[0045] Among them, TCP port activity detection is used to verify whether the service port is connectable to avoid application freezing; while UDP heartbeat packet detection is used to verify whether the node process is alive.

[0046] This application discloses a Java service deployment method based on dual-node dynamic routing. This method obtains the health status of each node through TCP port activity detection and / or UDP heartbeat packet detection, and identifies nodes that fail detection more than a preset number of times as faulty nodes and sets them offline. Compared to traditional node fault detection methods (such as Eureka registry 60 which only relies on HTTP heartbeats for node fault detection), this method significantly reduces the false positive rate. Furthermore, it determines traffic allocation weights based on the real-time working status of the nodes, specifically by considering node load factors such as CPU utilization, memory idle rate, and request response time. Client requests are routed and distributed. If the target node is a faulty node, the system automatically switches to a healthy node. Specifically, by obtaining the traffic allocation weight of each node based on its real-time working status, the system dynamically adjusts the routing based on this weight. For example, more requests are allocated to nodes with higher traffic allocation weights, thereby improving node resource utilization and preventing single nodes from being overloaded. However, when the target node for a response request is a faulty node, the system automatically switches to another node to respond to the request. Combined with node fault detection methods, this shortens the failover time. By adjusting the data consistency between the two nodes based on Redis cluster 71 and MySQL cluster 72, data conflicts can be avoided in high-concurrency scenarios. This application achieves intelligent node traffic allocation based on the real-time working status of nodes, combined with a low-false-error node fault detection method, and utilizes Redis cluster 71 and MySQL cluster 72 to solve data consistency problems, thereby addressing the issues of failover latency, low resource utilization, and low data consistency in traditional deployment schemes.

[0047] In addition to the features of the above embodiments, this embodiment further defines: determining a node whose detection failure count exceeds a preset number as a faulty node and setting the faulty node to an offline state includes: when any node continuously performs TCP port activity detection and / or UDP heartbeat packet detection, and the detection results are all failures for N consecutive times, the corresponding node is a faulty node, and the faulty node is automatically triggered to go offline, where N is the preset number of times.

[0048] In one detection cycle, a node is continuously detected M times (including TCP port activity detection and UDP heartbeat packet detection, M≧N). The logic for determining a faulty node can be one or a combination of the following:

[0049] Case 1: If the results of both TCP port activity detection and UDP heartbeat packet detection fail in N consecutive tests, then the corresponding node is determined to be a faulty node.

[0050] Scenario 2: If either the TCP port activity detection or the UDP heartbeat packet detection fails in N consecutive tests, the corresponding node is determined to be a faulty node.

[0051] Scenario 3: If the total number of failed TCP port activity detection and UDP heartbeat packet detection tests in N consecutive tests is equal to or greater than N, then the corresponding node is determined to be a faulty node.

[0052] It should be noted that the dual nodes can be divided into a first node 40 and a second node 50. When the first node 40 is determined to be a faulty node during the detection, the faulty node is set to an offline state, and the faulty node stops routing and receiving new requests from the client 10. The second node 50 receives and responds to all or most of these requests.

[0053] Preferably, in this embodiment, the value of N is 3.

[0054] In the method described above, TCP port activity detection and UDP heartbeat packet detection work together to obtain the health status of each node and determine whether a node has failed according to a preset judgment logic. This not only avoids the response delay caused by long-interval detection in traditional solutions, but also has a low false positive rate, effectively supporting the service stability requirements under high concurrency scenarios.

[0055] In addition to the features of the above embodiments, this embodiment further defines: determining the traffic allocation weight based on the real-time working status of the node, including: obtaining the CPU utilization rate, memory idle rate and request response time of the node in real time to calculate the traffic allocation weight. The traffic allocation weight weight calculation formula is: Weight = (1 / request response time) × (1-CPU utilization rate) × memory idle rate.

[0056] CPU utilization, memory idle rate, and request response time are important indicators for measuring node health and performance. By monitoring these indicators, it is possible to determine whether a node is overloaded or responding slowly, thereby adjusting routing strategies. For example, if node 40 has a CPU utilization of 15%, a memory idle rate of 70%, and a request response time of 30ms, while node 50 has a CPU utilization of 50%, a memory idle rate of 50%, and a request response time of 50ms, then the traffic allocation weight for node 40 is Weight1 = 0.0198, and the traffic allocation weight for node 50 is Weight2 = 0.005. The traffic allocation weight for node 40 is 3.96 times that of node 50. Therefore, 1079.9% of client requests will be allocated to node 40, and 20.1% of requests will be allocated to node 50.

[0057] It should be noted that in other embodiments, the method can also limit the traffic allocation weight of a node to a certain set range when one or a combination of CPU utilization, memory idle rate, and request response time exceeds their corresponding threshold range. For example, when the CPU utilization of the first node 40 exceeds 90%, the traffic allocation weight of that node can be directly configured to be below 50%.

[0058] The method in the above embodiments dynamically adjusts the traffic allocation weight based on the real-time CPU utilization, memory idle rate and request response time of the nodes, thereby directing more requests to nodes with lower load, thereby improving the resource utilization of the nodes and achieving dynamic load balancing.

[0059] In addition to the features of the above embodiments, this embodiment further defines: adjusting the data consistency of the two nodes based on the Redis cluster 71 and the MySQL cluster 72, including: when the client 10 initiates a write operation request, ensuring that only the target object node processes and locks it through the Redis distributed lock, releasing the lock and synchronizing to the other node after the operation is completed; when the client 10 initiates a read operation request, synchronizing the data from the target object node to the other node through the MySQL real-time synchronization mechanism.

[0060] Specifically, taking overselling of inventory as an example, assuming the initial inventory is 10, when multiple write requests to deduct inventory from 10 are received from the client, the first node 40 receives and assigns the response. The first node 40 acquires the distributed lock for the inventory item through the Redis cluster 71, so that only the first node 40 can deduct the inventory from the inventory item. After the inventory deduction is completed, the first node 40 releases the Redis distributed lock and synchronizes the deducted inventory information to the second node 50 through the MySQLBinlog in the MySQL cluster 72.

[0061] In addition to the features of the above embodiments, this embodiment further specifies that both nodes are based on the Spring Boot framework.

[0062] It should be noted that Spring Boot is an open-source framework used to simplify application development within the Spring framework. Spring Boot features standalone operation, automatic configuration, microservice support, and health checks and monitoring. This application is based on using Spring Boot as the framework for each node, which can fully leverage its rapid development and embedded server features, while seamlessly integrating with Spring Cloud components to improve the efficiency and reliability of the entire system.

[0063] Among them, the first node 40 and the second node 50, which adopt the Spring Boot framework, can automatically register to the Eureka registry center 60. The Spring Boot framework is configured with interfaces for TCP port activity detection and UDP heartbeat packet detection, without the need for additional configuration modules.

[0064] In addition to the features of the above embodiments, this embodiment further specifies that a bidirectional communication link is established between the two nodes for synchronizing caches and forwarding incomplete transaction contexts.

[0065] The bidirectional communication link between the two nodes can serve as a redundant path for data synchronization. When one node updates data, it notifies the other node to refresh its local cache immediately through the bidirectional link to avoid dirty reads. In addition, the bidirectional communication link between the two nodes can also ensure the reliability of node failover. For example, before the first node 40 crashes, it sends the incomplete transaction context to the second node 50 to ensure transaction integrity.

[0066] In addition to the features of the above embodiments, this embodiment further defines the method as follows: when the faulty node recovers, it automatically re-registers and restores traffic allocation.

[0067] In this scenario, once a faulty node recovers, based on the Spring Boot framework used by the node, the recovered node can automatically re-register with the Eureka registry and resume traffic allocation according to a pre-defined recovery mechanism. This pre-defined recovery mechanism can employ a gradual traffic introduction strategy: after node recovery, a low initial traffic amount is allocated to the node, such as an initial traffic weight of 10%; subsequently, the traffic weight is increased in stages over time until a preset weight is reached, such as increasing traffic by 10% every 10 seconds, until the node reaches a traffic weight of 50%. During the weight recovery process, if the node exhibits abnormal performance metrics at a certain stage (such as response time exceeding a threshold), traffic growth is paused or the node remains offline. It should be noted that in other embodiments, other traffic introduction strategies can also be used to allocate traffic to nodes after fault recovery.

[0068] The method in the above embodiments, by adding a fault node recovery mechanism, enables the entire process from fault detection, traffic switching and node traffic recovery to be completed without manual intervention, which not only achieves automated closed-loop operation and maintenance, but also improves the reliability of the system.

[0069] like Figure 2 As shown, in addition to the features of the above embodiments, this embodiment further defines the method as follows: the method also includes step S100, initializing node parameters, wherein the node parameters include one or a combination of IP address, port, service name and initial traffic allocation weight.

[0070] The initial traffic allocation weights for nodes are initialized, providing a baseline for dynamic routing and load balancing based on the nodes' hardware configurations. For example, if the first node 40 handles core business and is a high-configuration server, its initial weight is 60%, and the second node 50's is 40%. Traffic will be allocated according to this ratio during system startup; for instance, 60% of requests will go to the first node 40, and 40% to the second node 50. This traffic allocation after system startup prevents low-configuration nodes from experiencing instantaneous overload.

[0071] In addition, IP address and port are basic parameters for network communication. By initializing the IP address and port of the nodes, it is ensured that the first node 40 and the second node 50 can be successfully registered, thereby enabling the gateway, client 10, etc. to locate the service instance and avoid requests from being unable to be routed correctly.

[0072] It should be understood that, although Figure 1-2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1-2At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0073] like Figure 3 As shown, this embodiment provides a Java backend service deployment system based on dual-node dynamic routing. The system includes:

[0074] Client module 10 is used to initiate requests;

[0075] Zuul gateway module 20 is used to receive and initially filter requests;

[0076] The first node 40 and the second node 50 are used to handle business logic and are both deployed based on Spring Boot.

[0077] Redis cluster 71 is used to control distributed write operations.

[0078] MySQL Cluster 72 is used for data consistency synchronization between nodes;

[0079] Eureka registry 60 is used to obtain the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection. Eureka registry 60 is also used to register service instances for the first node 40 and the second node 50.

[0080] Dynamic routing engine module 30 includes:

[0081] The calculation module is used to determine the traffic allocation weight based on the real-time working status of the nodes;

[0082] The decision module is used to route and distribute client module requests based on traffic allocation weights. If the target of the route is a faulty node, it will switch to a healthy node.

[0083] The client module 10 can be a terminal device or application used to initiate service requests (such as querying inventory or submitting orders).

[0084] Zuul gateway module 20 can act as an edge gateway, handling initial requests from client module 10 and responsible for SSL termination, authentication, and initial routing. Since Zuul gateway module 20 is located between client module 10 and dynamic routing engine module 30, after receiving all external requests, it forwards requests requiring dynamic routing to dynamic routing engine module 30. Dynamic routing engine module 30 dynamically selects the target node based on the real-time status of the backend nodes.

[0085] The system framework consists of a client module 10 communicating with a dynamic routing engine module 30, which in turn communicates with a first node 40 and a second node 50. A bidirectional communication link is established between the first node 40 and the second node 50. A Eureka registry 60 communicates with both the first node 40 and the second node 50, a Redis cluster 71 communicates with both the first node 40 and the second node 50, and a MySQL cluster 72 communicates with both the first node 40 and the second node 50. Specifically, upon system startup, the first node 40 and the second node 50 automatically send registration requests to the Eureka registry 60, which stores the node information in the registry. When the client module 10 initiates a request (such as querying or submitting an order), the dynamic routing engine module 30 matches the request path to a preset dynamic routing rule. The dynamic routing engine module 30 obtains the real-time working status of each node (such as CPU utilization, memory idle rate, and average response time) and then... The formula Weight = (1 / request response time) × (1 - CPU utilization) × memory idle rate is used to calculate the traffic allocation weight of the nodes. The nodes responding to the operation are selected and allocated according to the traffic allocation weight. During the node response request phase, when the request is a write operation, the target node competes for the distributed lock of the target resource through the Redis cluster 71 to ensure atomicity. After completing the operation, the lock is released and synchronized to another node. When the request is a read operation, the data is synchronized from the target node to another node through the real-time synchronization mechanism of the MySQL cluster 72. The system obtains the health status of each node through TCP port activity detection and / or UDP heartbeat packet detection. Nodes that fail detection more than a preset number are identified as faulty nodes. If a faulty node is found, the Eureka registry center 60 updates the status of the faulty node (such as the first node 40) to offline and allocates traffic to healthy nodes (such as the second node 50) through the dynamic routing engine module 30. The healthy node then responds to the requests issued by the client module 10. Furthermore, after a faulty node recovers, the system can automatically re-register the node with the Eureka registry center and allocate recovery traffic to the node based on a preset recovery mechanism.

[0086] This application discloses a Java backend service deployment system based on dual-node dynamic routing. This system obtains the health status of each node through TCP port activity detection and / or UDP heartbeat packet detection, and identifies nodes that fail detection more than a preset number of times as faulty nodes and sets them offline. Compared to traditional node fault detection methods (such as Eureka registry 60 which only relies on HTTP heartbeats for node fault detection), this significantly reduces the false positive rate. Furthermore, it determines traffic allocation weights based on the real-time working status of the nodes, specifically by considering node load factors such as CPU utilization, memory idle rate, and request response time. This traffic allocation is based on... The system routes and distributes requests to client module 10 based on weights. If the target node is a faulty node, the system switches to a healthy node. Specifically, by obtaining the traffic allocation weight of each node based on its real-time working status, the system dynamically adjusts the routing based on these weights. For example, it allocates more requests to nodes with higher traffic allocation weights, thereby improving node resource utilization and preventing single nodes from being overloaded. However, when the target node for a response request is a faulty node, the system automatically switches to another node to respond to the request. Combined with node fault detection methods, this shortens the failover time. By adjusting the data consistency between the two nodes based on Redis cluster 71 and MySQL cluster 72, data conflicts can be avoided in high-concurrency scenarios. This application achieves intelligent node traffic allocation based on the real-time working status of nodes, combined with a low-false-error node fault detection method, and utilizes Redis cluster 71 and MySQL cluster 72 to solve data consistency problems, thereby addressing the issues of failover latency, low resource utilization, and low data consistency in traditional deployment schemes.

[0087] like Figure 3 As shown, in addition to the features of the above embodiments, this embodiment further specifies that: the dynamic routing engine module 30 is implemented based on Spring Cloud Gateway and can adjust the request distribution strategy according to the real-time working status of the nodes.

[0088] The dynamic routing engine module 30 can be an extension module based on Spring Cloud Gateway. The dynamic routing engine module 30 may include a calculation module and a decision module. The calculation module can be used to adjust the traffic allocation weight according to the real-time working status of the node. The decision module can be used to route and distribute requests from the client module 10 based on the traffic allocation weight. For details on the calculation of the traffic allocation weight and the specific process of routing and distributing requests from the client module 10 based on the traffic allocation weight, please refer to the above content, which will not be repeated here.

[0089] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0090] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A method for deploying a Java backend service based on dual-node dynamic routing, characterized in that, include: The health status of each node is obtained based on TCP port activity detection and / or UDP heartbeat packet detection; Nodes that fail to detect more than a preset number of times are identified as faulty nodes and are set to offline status. Traffic allocation weights are determined based on the real-time operating status of the nodes; the real-time operating status includes CPU utilization, memory idle rate, and request response time. Client requests are routed and distributed based on traffic allocation weights. If the target of the route is a faulty node, the route is switched to a healthy node. When a client initiates a write operation request, a Redis distributed lock ensures that only the target object node processes and locks the data. After the operation is completed, the lock is released and the data is synchronized to another node. When a client initiates a read operation request, the data is synchronized from the target object node to another node through a MySQL real-time synchronization mechanism.

2. The Java backend service deployment method based on dual-node dynamic routing according to claim 1, characterized in that, The step of determining a node whose detection failure count exceeds a preset number as a faulty node and setting the faulty node to an offline state includes: If any node continuously performs TCP port activity checks and / or UDP heartbeat packet checks, and the results of the checks are all unsuccessful for N consecutive times, then the corresponding node is a faulty node, and the faulty node will be automatically taken offline, where N is a preset number of times.

3. The Java backend service deployment method based on dual-node dynamic routing according to claim 1, characterized in that, The process of determining traffic allocation weights based on the real-time working status of nodes includes: The CPU utilization, memory idle rate, and request response time of the nodes are obtained in real time to calculate the traffic allocation weight. The traffic allocation weight weight is calculated as follows: Weight = (1 / request response time) × (1-CPU utilization) × memory idle rate.

4. The Java backend service deployment method based on dual-node dynamic routing according to claim 1, characterized in that, Both nodes are based on the Spring Boot framework.

5. The Java backend service deployment method based on dual-node dynamic routing according to claim 4, characterized in that, A bidirectional communication link is established between the two nodes for synchronizing caches and forwarding incomplete transaction contexts.

6. The Java backend service deployment method based on dual-node dynamic routing according to claim 1, characterized in that, Also includes: Once the faulty node recovers, it will automatically re-register and resume traffic allocation.

7. The Java backend service deployment method based on dual-node dynamic routing according to claim 1, characterized in that, Also includes: Initialize node parameters, which include one or a combination of IP address, port, service name, and initial traffic allocation weight.

8. A Java backend service deployment system based on dual-node dynamic routing, characterized in that, include: The client module is used to initiate requests; The Zuul gateway module is used to receive and initially filter requests. The first and second nodes are used to handle business logic and are both deployed based on Spring Boot. Redis clusters are used for distributed write operation control. When a client initiates a write operation request, a Redis distributed lock ensures that only the target node processes and acquires the lock. After the operation is completed, the lock is released and synchronized to another node. MySQL clusters are used for data consistency synchronization between nodes; when a client initiates a read operation request, the data is synchronized from the target object node to another node through the MySQL real-time synchronization mechanism. The Eureka registry center obtains the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection. The Eureka registry center is also used to register service instances for the first node and the second node. The dynamic routing engine module includes: The calculation module is used to determine the traffic allocation weight based on the real-time working status of the nodes; the real-time working status includes CPU utilization, memory idle rate, and request response time. The decision module is used to route and distribute client module requests based on traffic allocation weights. If the target of the route is a faulty node, it will switch to a healthy node.

9. The Java backend service deployment system based on dual-node dynamic routing according to claim 8, characterized in that, The dynamic routing engine module is implemented based on Spring Cloud Gateway and can adjust the request distribution strategy according to the real-time working status of the nodes.

Images