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

Abstract

The invention relates to a Java background service deployment method and system based on double-node dynamic routing, and the method comprises the steps: obtaining the health state of each node based on TCP port activity detection and / or UDP heartbeat packet detection; judging the nodes of which the detection failure times exceed the preset times as fault nodes, and setting the fault nodes to be in an offline state; determining a traffic allocation weight according to the real-time working state of the node; performing routing distribution on the client request based on the traffic distribution weight; route distribution is dynamically adjusted based on the traffic allocation weight, the resource utilization rate of the nodes is improved, and the situation that the load of a single node is too heavy is avoided; when a fault node occurs, the other node is automatically switched to respond to the request, so that the fault switching time is shortened; and the data consistency between the double nodes is adjusted based on the Redis cluster and the MySql cluster. Based on cooperation of the steps, the problems of failure switching delay, low resource utilization and low data consistency in a traditional scheme are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed systems, and particularly to a method and system for deploying a Java background service based on dual-node dynamic routing. Background Art

[0002] 1. Existing problems: Traditional single-node deployment has a risk of single-point failure, a long recovery time objective (RTO), and affects business continuity. In dual-node deployment, static load balancing strategies (such as round-robin) cannot dynamically sense node load, resulting in uneven resource utilization. Data synchronization delays may lead to inconsistent states between nodes (such as inventory overselling).

[0003] 2. Defects of existing solutions: The Nginx + Keepalived solution requires manual switching of faulty nodes, with high operation and maintenance costs. The native Ribbon load balancing in Spring Cloud lacks the ability to adjust real-time weights. Summary of the Invention

[0004] Based on this, it is necessary to provide a method and system for deploying a Java background service based on dual-node dynamic routing in view of the above problems.

[0005] A method for deploying a Java background service based on dual-node dynamic routing provided by this application includes:

[0006] Obtaining the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection;

[0007] Determining a node with the number of detection failures exceeding a preset number as a faulty node and setting the faulty node to an offline state;

[0008] Determining the traffic allocation weight according to the real-time working state of the node;

[0009] Routing and distributing client requests based on the traffic allocation weight, and switching to a healthy node if the routing target object is a faulty node;

[0010] Adjusting the data consistency between the dual nodes based on the Redis cluster and the MySql cluster.

[0011] In one embodiment, the determining a node with the number of detection failures exceeding 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 consecutive N detection results are all failures, the corresponding node is a faulty node, and the faulty node is automatically triggered to go offline, where N is the preset number.

[0012] In one embodiment, determining the traffic allocation weight according to the real-time working state of the node includes: obtaining the CPU usage rate, memory free rate, and request response time of the node in real time to calculate the traffic allocation weight. The calculation formula for the traffic allocation weight Weight is: Weight = (1 / request response time) × (1 - CPU usage rate) × memory free rate.

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

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

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

[0016] In one embodiment, the method further includes: when the failed node recovers, automatically re-registering and resuming traffic allocation.

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

[0018] A Java service deployment system based on dual-node dynamic routing provided by the present application, the system includes:

[0019] A client module for initiating requests;

[0020] A Zuul gateway module for receiving and initially filtering requests;

[0021] A first node and a second node for processing business logic, both deployed based on Spring Boot;

[0022] A Redis cluster for distributed write operation control;

[0023] A MySql cluster for data consistency synchronization between nodes;

[0024] An Eureka registration center for obtaining the health status of each node based on TCP port liveness detection and / or UDP heartbeat packet detection, and the Eureka registration center is also used for registering service instances by the first node and the second node;

[0025] Dynamic routing engine module, including:

[0026] A calculation module for determining the traffic allocation weight according to the real-time working state of the node;

[0027] A decision module for routing and distributing requests from the client module based on the traffic allocation weight. If the routing target object is a faulty node, it switches to the traffic allocation weight of the 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 state of the node.

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

[0030] In each of the above embodiments of the Java background service deployment method based on dual-node dynamic routing, the method obtains the health status of each node by detecting the TCP port activity and / or UDP heartbeat packet, determines the node with the detection failure times exceeding the preset number as a faulty node, and sets the faulty node to the offline state. Compared with the traditional node fault detection method (such as the Eureka registry only relying on HTTP heartbeat for node fault detection), it can greatly reduce the misjudgment rate; by determining the traffic allocation weight according to the real-time working state of the node, specifically reflected in determining the traffic allocation weight of each node according to the load conditions of the node, such as the CPU usage rate, memory free rate, and request response time of the node; by routing and distributing client requests based on the traffic allocation weight, if the routing target object is a faulty node, it automatically switches to a healthy node. Specifically, after obtaining the traffic allocation weight of each node according to the real-time working state of the node, it dynamically adjusts the routing distribution based on the traffic allocation weight, for example, allocating more requests to the node with a high traffic allocation weight, thereby improving the resource utilization rate of the node and avoiding overloading of a single node; however, when the target object node for the response request is a faulty node, it automatically switches, and another node responds to the request. Combining with the node fault detection method, it can shorten the fault switching time; by adjusting the data consistency between the dual nodes based on the Redis cluster and the MySql cluster, data conflicts can be avoided in high-concurrency scenarios. This application realizes intelligent allocation of node traffic based on the real-time working state of the node, combines with a node fault judgment method with low misjudgment, and uses the Redis cluster and the MySql cluster to solve the data consistency problem, thereby solving the problems of long fault switching delay, low resource utilization, and low data consistency in the traditional deployment scheme. Description of the Drawings

[0031] Figure 1It is one of the flowcharts of the Java background service deployment method based on dual-node dynamic routing in an embodiment of the present application;

[0032] Figure 2 It is the second flowchart of the Java background service deployment method based on dual-node dynamic routing in an embodiment of the present application;

[0033] Figure 3 It is the schematic architecture diagram of the Java background service deployment system based on dual-node dynamic routing in an embodiment of the present application;

[0034] Among them, the corresponding relationship 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, 71 Redis cluster, 72 MySql cluster. Detailed implementation manners

[0036] In order to more clearly understand the above objects, features and advantages of the present invention, the present invention will be further described in detail below with reference to the drawings and specific implementation manners. It should be noted that, without conflict, the embodiments of the present application and the features in the embodiments may be combined with each other.

[0037] Many specific details are set forth in the following description in order to fully understand the present invention. However, the present invention may be implemented in other ways different from those described herein. Therefore, the protection scope of the present invention is not limited by the specific embodiments disclosed below.

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

[0039] As Figure 1 shown, this embodiment discloses a Java background service deployment method based on dual-node dynamic routing, and the method includes:

[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 with the number of detection failures exceeding the preset number as faulty nodes and set the faulty nodes to the offline state

[0042] Step S400: Determine the traffic distribution weight according to the real-time working state of the nodes;

[0043] Step S500: Route and distribute the client requests based on the traffic allocation weight. If the routing target object is a faulty node, switch to a healthy node.

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

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

[0046] The Java service deployment method based on dual-node dynamic routing disclosed in this application. This method obtains the health status of each node through TCP port activity detection and / or UDP heartbeat packet detection, and determines the node with the detection failure times exceeding the preset number as a faulty node, and sets the faulty node to the offline state. Compared with the traditional node failure detection method (such as the Eureka registry 60 only relying on HTTP heartbeat for node failure detection), it can greatly reduce the misjudgment rate; by determining the traffic allocation weight according to the real-time working state of the node, specifically reflected by determining the traffic allocation weight of each node according to the load conditions of the node, such as the CPU usage rate, memory free rate, and request response time of the node, etc.; by routing and distributing the client requests based on the traffic allocation weight, if the routing target object is a faulty node, it will automatically switch to a healthy node. Specifically, after obtaining the traffic allocation weight of each node according to the real-time working state of the node, dynamically adjust the routing distribution based on the traffic allocation weight of the node. For example, allocate more requests to the node with a high traffic allocation weight, so as to improve the resource utilization rate of the node and avoid overloading a single node; however, when the target object node for the response request is a faulty node, it will automatically switch, and another node will respond to the request. Cooperating with the node failure detection method, it can shorten the failure switching time; by adjusting the data consistency between the two nodes based on the Redis cluster 71 and the MySql cluster 72, data conflicts can be avoided in high-concurrency scenarios. This application realizes intelligent allocation of node traffic based on the real-time working state of the node, cooperates with a node failure judgment method with low misjudgment, and uses the Redis cluster 71 and the MySql cluster 72 to solve the data consistency problem, thus solving the problems of long failure switching delay, low resource utilization, and low data consistency in the traditional deployment scheme.

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

[0048] Among them, in one detection cycle, the nodes are continuously detected M times (including TCP port activity detection and UDP heartbeat packet detection, M≥N). The determination logic of the faulty nodes can be one or a combination of the following situations:

[0049] Situation 1: If in N consecutive detections, the detection results of both TCP port activity detection and UDP heartbeat packet detection are detection failures, then the corresponding node is determined to be a faulty node;

[0050] Situation 2: If in N consecutive detections, any one of the detection results of TCP port activity detection or UDP heartbeat packet detection is a detection failure, then the corresponding node is determined to be a faulty node;

[0051] Situation 3: If in N consecutive detections, the total number of detection failures in TCP port activity detection and UDP heartbeat packet detection 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 the first node 40 and the second node 50. When the first node 40 is determined to be a faulty node during detection, the faulty node is set to the offline state, and the routing of the faulty node to receive new requests from the client 10 is stopped, and all or most of the operations are received and responded by the second node 50.

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

[0054] In the method of the above embodiment, by the collaborative work of TCP port activity detection and UDP heartbeat packet detection, the health status of each node is obtained and whether the node fails is judged according to the preset determination logic, which not only avoids the response delay caused by long-interval detection in the traditional scheme, but also has a low misjudgment rate and effectively supports the service stability requirements in the high-concurrency scenario.

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

[0056] Among them, CPU usage rate, memory free rate, and request response time are important metrics for measuring the health status and performance of nodes. By monitoring these metrics, it is possible to determine whether a node is overloaded and whether the response is slow, and thus adjust the routing strategy. Exemplarily, the CPU usage rate of the first node 40 is 15%, the memory free rate is 70%, and the request response time is 30 ms. The CPU usage rate of the second node 50 is 50%, the memory free rate is 50%, and the request response time is 50 ms. Then, the traffic allocation weight Weight1 of the first node 40 is 0.0198, and the traffic allocation weight Weight2 of the second node 50 is 0.005. The traffic allocation weight of the first node 40 is 3.96 times that of the second node 50. Therefore, 79.9% of the requests from the client 10 will be allocated to the first node 40, and 20.1% of the requests will be allocated to the second node 50.

[0057] It should be noted that in other embodiments, the method may further define that when one or a combination of the CPU usage rate, memory free rate, and request response time exceeds its corresponding threshold range, the traffic allocation weight of the node can be directly configured to be within a certain set range. For example, when the CPU usage rate of the first node 40 exceeds 90%, the traffic allocation weight of the node is directly configured to be less than 50%.

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

[0059] In addition to the features of the above embodiments, this embodiment further defines: adjusting the data consistency of the dual 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, and releasing the lock and synchronizing it to another node after the operation is completed; when the client 10 initiates a read operation request, synchronizing the data from the target object node to another node through the MySql real-time synchronization mechanism.

[0060] Specifically, taking inventory overselling as an example, assuming the initial inventory is 10, when multiple write requests for deducting inventory are received from the client 10, the first node 40 that obtains and is allocated first responds. The first node 40 obtains the distributed lock of the inventory item through the Redis cluster 71, so that only the first node 40 can deduct the inventory of 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 defines that both nodes are Spring Boot frameworks.

[0062] It should be noted that Spring Boot is an open-source framework used to simplify the application development of the Spring framework. Spring Boot has features such as independent operation, automatic configuration, microservice support, and health detection and monitoring. Based on using Spring Boot as the framework for each node in this application, the characteristics of rapid development and embedded server can be fully utilized, and at the same time, seamless integration with the components of Spring Cloud can be achieved to improve the efficiency and reliability of the entire system.

[0063] Among them, the first node 40 and the second node 50 adopting the Spring Boot framework can be automatically registered to the Eureka registration center 60, and 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 defines that a bidirectional communication link is established between the two nodes for synchronizing caches and forwarding uncompleted transaction contexts.

[0065] Among them, establishing a bidirectional communication link between the two nodes can be used as a redundant path for data synchronization. When a certain node updates data, the other node is notified through the bidirectional link to immediately refresh the local cache to avoid dirty reads; in addition, the bidirectional communication link between the two nodes can also ensure the reliability of node failure switching. For example, the first node 40 sends the uncompleted transaction context to the second node 50 before going down to ensure transaction integrity.

[0066] In addition to the features of the above embodiments, this embodiment further defines that the method further includes: when the failed node recovers, automatically re-registering and resuming traffic allocation.

[0067] Among them, when the failed node recovers, based on the node using the Spring Boot framework, the recovered node can automatically re-register in the Eureka registry 60, and restore traffic allocation based on a pre-set recovery mechanism. The pre-set recovery mechanism can adopt a progressive traffic introduction strategy, specifically: after the node recovers, allocate a low quota of initial traffic to the node, such as an initial traffic weight of 10%; subsequently, increase the traffic weight by time stages until the preset weight is reached, such as increasing the traffic by 10% every 10 seconds until the node reaches a traffic weight of 50%; among them, during the weight recovery process, if the node has abnormal performance indicators (such as response time exceeding the threshold, etc.) at a certain stage, suspend the traffic growth or continue to set the node to the offline state. It should be noted that in other embodiments, other traffic introduction strategies can also be used to allocate traffic to the node after fault recovery.

[0068] In the method of the above embodiment, by adding a fault node recovery mechanism, the whole process from fault detection, traffic switching to node traffic recovery does not require manual intervention, which not only realizes automated closed-loop operation and maintenance, but also improves the reliability of the system.

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

[0070] Among them, initializing the initial traffic allocation weight of the node can provide a benchmark for dynamic routing and load balancing according to the hardware configuration of the node. Exemplarily, if the first node 40 undertakes the core business and the first node 40 is a high-end server, the initial weight of the first node 40 is 60%, and the second node 50 is 40%. When the system starts, the traffic will be allocated according to this ratio, such as 60% of the requests to the first node 40 and 40% to the second node 50. After the system starts, the traffic will be allocated according to this, avoiding instantaneous overload of low-end nodes.

[0071] In addition, the IP address and port are basic parameters for network communication. By initializing the IP address and port of the node, it is ensured that the first node 40 and the second node 50 can be successfully registered, so that the gateway, the client 10, etc. can locate the service instance, avoiding incorrect routing of requests.

[0072] It should be understood that although Figure 1-2 the steps in the flowchart are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, Figure 1-2At least a part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages do not necessarily need to be executed and completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages does not necessarily need to be sequential, but can be executed alternately or in turns with at least a part of other steps or sub-steps or stages of other steps.

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

[0074] A client module 10, used to initiate requests;

[0075] A Zuul gateway module 20, used to receive and preliminarily filter requests;

[0076] A first node 40 and a second node 50, used to process business logic, both deployed based on Spring Boot;

[0077] A Redis cluster 71, used to perform distributed write operation control;

[0078] A MySql cluster 72, used for data consistency synchronization between nodes;

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

[0080] A dynamic routing engine module 30, including:

[0081] A calculation module, used to determine the traffic allocation weight according to the real-time working status of the nodes;

[0082] A decision module, used to perform routing distribution on the requests of the client module based on the traffic allocation weight. If the routing target object is a faulty node, it will switch to a healthy node;

[0084] Among them, the client module 10 can be a terminal device or application used to initiate service requests (such as querying inventory, submitting orders).

[0085] The Zuul gateway module 20 can act as an edge gateway to process the initial requests of the client module 10, and is responsible for SSL termination, authentication, and preliminary routing. Based on the fact that the Zuul gateway module 20 is located between the client module 10 and the dynamic routing engine module 30, after receiving all external requests, the Zuul gateway module 20 forwards the requests that need dynamic routing to the dynamic routing engine module 30, and the dynamic routing engine module 30 dynamically selects the target object node according to the real-time status of the backend nodes.

[0086] The framework of the system is that the client module 10 is in communication with the dynamic routing engine module 30, the dynamic routing engine module 30 is in communication with the first node 40 and the second node 50 respectively, a two-way communication link is established between the first node 40 and the second node 50, the Eureka registration center 60 is in communication with the first node 40 and the second node 50 respectively, the Redis cluster 71 is in communication with the first node 40 and the second node 50 respectively, and the MySql cluster 72 is in communication with the first node 40 and the second node 50 respectively; specifically, when the system is started, the first node 40 and the second node 50 automatically send a registration request to the Eureka registration center 60, and the Eureka registration center 60 stores the node information in the registration table; when the client module 10 initiates a request (such as querying an order or submitting an order), the dynamic routing engine module 30 matches the preset dynamic routing rules according to the request path, and the dynamic routing engine module 30 obtains the real-time working status of each node (such as CPU usage, memory idle rate, average response time), and calculates the response time according to the real-time working status of each node. Formula Weight = (1 / request response time) × (1-CPU usage) × memory idle rate, calculate the traffic distribution weight of the node, select the node that responds to the operation according to the traffic distribution weight and distribute it to the responding node; in the node response request stage, when the request is a write operation, the target object node competes for the distributed lock of the target resource through the Redis cluster 71 to ensure atomicity, releases the lock after completing the operation and synchronizes to another node; when the request is a read operation, the data is synchronized from the target object node to another node through the MySql cluster 72 real-time synchronization mechanism; the system obtains the health status of each node through TCP port activity detection and / or UDP heartbeat packet detection, and determines the node with more than a preset number of detection failures as a faulty node. If a faulty node occurs, the Eureka registration center 60 updates the status of the faulty node (such as the first node 40) to the offline state, and distributes the traffic to the healthy node (such as the second node 50) through the dynamic routing engine module 30, and the healthy node responds to the request issued by the client module 10. Furthermore, after the faulty node is restored, the system can automatically re-register the node with the Eureka registration center 60 and restore traffic distribution to the node based on a preset recovery mechanism.

[0087] A Java background service deployment system based on dual-node dynamic routing disclosed in this application. This system obtains the health status of each node through TCP port activity detection and / or UDP heartbeat packet detection, determines the nodes with the number of detection failures exceeding the preset number as faulty nodes, and sets the faulty nodes to the offline state. Compared with traditional node fault detection methods (such as the Eureka registry that only relies on HTTP heartbeats for node fault detection), it can greatly reduce the misjudgment rate; it determines the traffic distribution weight according to the real-time working state of the nodes, specifically by determining the traffic distribution weight of each node according to the load conditions of the nodes, such as the CPU usage rate, memory free rate, and request response time of the nodes; it performs routing distribution on the requests of the client module 10 based on the traffic distribution weight. If the routing target object is a faulty node, it switches to a healthy node. Specifically, after obtaining the traffic distribution weights of each node according to the real-time working state of the nodes, it dynamically adjusts the routing distribution based on the traffic distribution weights of the nodes. For example, it allocates more requests to the nodes with high traffic distribution weights, thereby improving the resource utilization rate of the nodes and avoiding overloading of a single node; however, when the target object node for the response request is a faulty node, it automatically switches, and another node responds to the request. Combining with the node fault detection method, it can shorten the fault switching time; it adjusts the data consistency of the dual nodes based on the Redis cluster 71 and the MySql cluster 72, and can avoid data conflicts in high-concurrency scenarios. This application realizes intelligent allocation of node traffic based on the real-time working state of the nodes, combines with a node fault judgment method with low misjudgment, and uses the Redis cluster 71 and the MySql cluster 72 to solve the data consistency problem, thereby solving the problems of long fault switching delay, low resource utilization, and low data consistency in traditional deployment solutions.

[0088] As Figure 3 shown, in addition to the features of the above embodiments, this embodiment further defines 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 state of the nodes.

[0089] Among them, the dynamic routing engine module 30 can be an extended module based on Spring Cloud Gateway. The dynamic routing engine module 30 can include a calculation module and a decision-making module. The calculation module can be used to adjust the traffic distribution weight according to the real-time working state of the nodes, and the decision-making module can be used to perform routing distribution on the requests of the client module 10 based on the traffic distribution weight. For the calculation of the traffic distribution weight and the specific content process of performing routing distribution on the requests of the client module 10 based on the traffic distribution weight, reference can be made to the above content and will not be elaborated here.

[0090] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, 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, it should be considered as the scope described in this specification.

[0091] The above embodiments only express several implementation manners of the present invention, and the description is relatively specific and detailed, but it should not be understood as a limitation to the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the invention patent should be subject to the appended claims.

Claims

1. A method for deploying a Java background service based on dual-node dynamic routing, characterized in that include: Obtain the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection; Nodes whose detection failures exceed a preset number are judged as faulty nodes and are set to offline state; Determine the traffic distribution weight based on the real-time working status of the node; Route and distribute client requests based on traffic distribution weights. If the routing target is a faulty node, switch to a healthy node. Adjust data consistency between two nodes based on Redis cluster and MySQL cluster.

2. The method for deploying a Java background service based on a dual-node dynamic route according to claim 1, wherein The step of determining a node whose detection failure times exceed 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.

3. The method for deploying a Java background service based on a dual-node dynamic routing according to claim 1, wherein Determining the traffic distribution weight according to the real-time working status of the node includes: The traffic distribution weight is calculated by obtaining the node's CPU usage, memory idle rate, and request response time in real time. The traffic distribution weight calculation formula is: Weight = (1 / request response time) × (1-CPU usage) × memory idle rate.

4. The method for deploying a Java background service based on a dual-node dynamic routing according to claim 1, characterized in that, The data consistency adjustment between two nodes based on the Redis cluster and the MySql cluster includes: When a client initiates a write operation request, the Redis distributed lock ensures that it is only processed and locked by the target object node. After the operation is completed, the lock is released and synchronized to another node. When the 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.

5. The Java background service deployment method based on dual-node dynamic routing according to claim 1, wherein Both nodes use the Spring Boot framework.

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

7. The method for deploying a Java background service based on a dual-node dynamic routing according to claim 1, wherein Also includes: When the failed node recovers, it automatically re-registers and resumes traffic distribution.

8. The method for deploying a Java background service based on a dual-node dynamic routing according to claim 1, characterized in that, Also includes: Initialize node parameters, where the node parameters include one or a combination of IP address, port, service name, and initial traffic distribution weight.

9. A Java background service deployment system based on dual-node dynamic routing, characterized in that, include: Client module, used to initiate requests; Zuul gateway module, used to receive and initially filter requests; The first and second nodes are used to process business logic and are both deployed based on Spring Boot; Redis cluster, used for distributed write operation control; MySql cluster, used for data consistency synchronization between nodes; The Eureka registration center obtains the health status of each node based on TCP port activity detection and / or UDP heartbeat packet detection. The Eureka registration center is also used to register service instances for the first node and the second node. Dynamic routing engine module, including: A calculation module is used to determine the traffic distribution weight according to the real-time working status of the node; The decision module is used to route and distribute client module requests based on traffic distribution weights. If the routing target object is a faulty node, it switches to a healthy node.

10. The Java background service deployment system based on dual-node dynamic routing according to claim 9, 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 nodes.

Images