Load balancing method, system, device and storage medium

Abstract

The application provides a load balancing method, system, device and storage medium. The system comprises a message middleware deployed on any server in a RabbitMQ cluster, a business network card and a management network card, a first load balancer corresponding to the business network card, and a second load balancer corresponding to the management network card; the business network card and the management network card respectively receive and forward business traffic and non-business traffic in a business request; wherein the business request is a request sent by a client, the client is a producer module or a consumer module in the RabbitMQ cluster, the business traffic is the traffic of user business, and the non-business traffic is a function request to the message middleware; the first load balancer and the second load balancer respectively distribute the business traffic and the non-business traffic to the respective corresponding servers, so that the respective corresponding servers respectively perform corresponding processing on the business traffic and the non-business traffic. The method of the application improves the load balancing efficiency.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a load balancing method, system, device, and storage medium. Background Technology

[0002] Load balancing refers to distributing business requests across multiple servers, such as FTP servers, web servers, core enterprise application servers, and other primary task servers, to collaboratively complete tasks. Built upon the existing network infrastructure, load balancing provides a transparent, cost-effective, and efficient method to expand server and network device bandwidth, enhance network data processing capabilities, increase throughput, and improve network availability and flexibility.

[0003] In load balancing, existing technologies use servers with a single network interface card (NIC) bound to a single load balancer. This single load balancer is responsible for both traffic distribution and managing the plugins of the RabbitMQ message middleware. These two functions are in opposition to each other.

[0004] Therefore, existing technologies suffer from low load balancing efficiency because a single load balancer needs to handle the plugin management function of the message middleware RabbitMQ. Summary of the Invention

[0005] This application provides a load balancing method, system, device, and storage medium to solve the technical problem of low load balancing efficiency in the prior art.

[0006] In a first aspect, this application provides a load balancing system, comprising: a message middleware, a service network interface card (NIC), and a management NIC deployed on any server in a RabbitMQ cluster; a first load balancer corresponding to the service NIC; and a second load balancer corresponding to the management NIC.

[0007] The service network interface card (NIC) and the management NIC receive and forward service traffic and non-service traffic from service requests, respectively. The service request is a request sent by a client, which is either a producer module or a consumer module in the RabbitMQ cluster. The service traffic is the traffic of user services, and the non-service traffic is a function request to the message middleware.

[0008] The first load balancer and the second load balancer respectively distribute the service traffic and the non-service traffic to their respective servers, so that the respective servers can process the service traffic and the non-service traffic accordingly.

[0009] Optionally, the first load balancer is deployed with a first listener and a first load balancer instance, and the second load balancer is deployed with a second listener and a second load balancer instance.

[0010] The first load balancer and the second load balancer then distribute the service traffic and the non-service traffic to their respective servers, including:

[0011] The first listener and the second listener listen to their respective ports and forward the service traffic and the non-service traffic to the first load balancer instance and the second load balancer instance, respectively.

[0012] The first load balancing instance and the second load balancing instance determine the first server corresponding to the service traffic and the second server corresponding to the non-service traffic according to a preset load balancing algorithm, and distribute the service traffic and the non-service traffic to the first server and the second server respectively through the service network card and the management network card; wherein, the first server and the second server are either servers in the RabbitMQ cluster.

[0013] Optionally, the service network interface card (NIC) and the management NIC respectively receive and forward service traffic and non-service traffic from service requests, including:

[0014] The service network interface card (NIC) receives the first sub-service traffic sent by the client through the server where the service NIC is located, and sends the first sub-service traffic to the first load balancer.

[0015] The service network interface card receives the second sub-service traffic sent by the client through the RabbitMQ dashboard carried by the message middleware, and sends the second sub-service traffic to the first load balancer;

[0016] The management network interface card receives non-service traffic sent by the client through the target tool and sends the non-service traffic to the second load balancer.

[0017] Optionally, the first sub-service traffic includes at least one of the following: connection requests, message production requests, message consumption requests, and message confirmation requests between the producer module and the consumer module;

[0018] The second sub-service traffic includes at least one of the following: information viewing requests, monitoring requests, and management requests for the RabbitMQ cluster;

[0019] The non-business traffic includes at least one of the following: message middleware management requests, resource creation requests, resource modification requests, resource query requests, resource deletion requests, and password reset requests.

[0020] Optionally, the first listener and the second listener each listen on their respective corresponding ports, including:

[0021] The first listener is used to listen on the port of the AMQP protocol; wherein, the port of the AMQP protocol is the port between the client and the server;

[0022] The second listener is used to listen to the port of the message middleware management tool.

[0023] Optionally, the message middleware is in mirror mode.

[0024] Optionally, the target tool is a console, a target browser, or a cloud computing service.

[0025] Secondly, this application provides a load balancing method applied to a load balancing system, the load balancing system comprising: a message middleware, a service network interface card (NIC), and a management NIC deployed on any server in a RabbitMQ cluster; a first load balancer corresponding to the service NIC; and a second load balancer corresponding to the management NIC; the method comprising:

[0026] The service network interface card (NIC) and the management NIC receive and forward service traffic and non-service traffic from service requests, respectively. The service request is a request sent by a client, which is either a producer module or a consumer module in the RabbitMQ cluster. The service traffic is the traffic of user services, and the non-service traffic is a function request to the message middleware.

[0027] The first load balancer and the second load balancer respectively distribute the service traffic and the non-service traffic to their respective servers, so that the respective servers can process the service traffic and the non-service traffic accordingly.

[0028] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0029] The memory stores computer-executed instructions;

[0030] The processor executes computer execution instructions stored in the memory to implement the method described in the second aspect.

[0031] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described in the second aspect.

[0032] The load balancing system provided in this application includes: a message middleware, a service network interface card (NIC), and a management NIC deployed on any server in a RabbitMQ cluster; a first load balancer corresponding to the service NIC; and a second load balancer corresponding to the management NIC. The service NIC and the management NIC respectively receive and forward service traffic and non-service traffic from service requests. The service requests are requests sent by clients, where the clients are producer or consumer modules in the RabbitMQ cluster; the service traffic is user service traffic; and the non-service traffic is functional requests to the message middleware. The first load balancer and the second load balancer respectively distribute the service traffic and non-service traffic to their respective servers, so that the respective servers can process the service traffic and non-service traffic accordingly.

[0033] This application features dual network cards (NIC) for both business and management. By binding different NICs to load balancers, business traffic and non-business traffic within business requests are separated, thereby increasing the requests per second and concurrency of the RabbitMQ cluster. Compared with existing technologies, this application's load balancing system with the above structure can improve load balancing efficiency. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0035] Figure 1 This is a schematic diagram of the structure of a load balancing system provided in an embodiment of this application;

[0036] Figure 2 This is a schematic diagram of the structure of a load balancing system provided in an embodiment of this application;

[0037] Figure 3 A flowchart illustrating a load balancing method provided in an embodiment of this application;

[0038] Figure 4 A flowchart illustrating another load balancing method provided in an embodiment of this application;

[0039] Figure 5 A flowchart illustrating yet another load balancing method provided in an embodiment of this application;

[0040] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0041] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0042] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0043] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0044] In existing technologies, message middleware is an important component of distributed systems. It is a queue that receives, stores, and distributes messages, and applications communicate by reading and writing messages from the message middleware's queue.

[0045] RabbitMQ is an open-source message middleware written in Erlang that implements the Advanced Message Queuing Protocol (AMQP). Currently, RabbitMQ offers three modes: single-node, normal cluster, and mirrored cluster. Mirrored clusters can synchronize data across other nodes, ensuring that even if a single node fails, services can still be provided through a single access address, guaranteeing no data loss. RabbitMQ features regular messages, broadcast messages, private messages, and delayed messages. Producers send messages to RabbitMQ exchanges, which route the messages to queues. Exchanges support four routing methods: Direct, Topic, Headers, and Fanout, and also support exchange composition and customization.

[0046] Load balancing refers to distributing workloads (including user services, functional requests, and other tasks) across multiple servers, such as FTP servers, web servers, core enterprise application servers, and other major task servers, to collaboratively complete tasks. Built upon the existing network infrastructure, load balancing provides a transparent, cost-effective, and efficient method to expand server and network device bandwidth, enhance network data processing capabilities, increase throughput, and improve network availability and flexibility. For load balancing, existing technologies propose a cluster load balancing method based on message middleware and Aspect-Oriented Programming (AOP). This method, when a business system's traffic is concentrated on one or more virtual hosts (Vhosts), can decompose / map the Vhost into multiple Vhosts and distribute them across different Broker nodes. Furthermore, all switches under the same Vhost can be stored on different Broker nodes.

[0047] Load balancing in RabbitMQ has the following drawbacks:

[0048] (1) In standalone mode, RabbitMQ cannot meet users' high availability requirements, while having relatively low performance bottlenecks. Although the normal cluster mode can improve RabbitMQ's message throughput, if a node fails, messages will become inaccessible, and messages in queues that are not persisted will be lost, thus failing to guarantee persistence. The mirrored cluster mode solves the high availability problem, but there is still room for optimization.

[0049] (2) RabbitMQ's port 5672 provides external communication services, while its port 15672 provides both a management interface (Unit Interval, UI) and internal API (Application Programming Interface) functions such as "Virtual Host (Vhost) Management" and "User Management." These API functions allow users to perform related operations on the cloud provider's console. However, a single network interface card or network must simultaneously handle both user business and cloud provider console functions, which inevitably reduces the network's transmission capacity.

[0050] (3) In existing technologies, servers are equipped with a single network interface card (NIC), which is bound to a single load balancer. This single load balancer is responsible for both traffic distribution and managing the plugin functionality of the RabbitMQ message middleware; these two functions are contradictory. Specifically, although a single load balancer can listen on both ports 5672 and 15672 simultaneously, this still cannot achieve optimal performance. Furthermore, RabbitMQ's plugin management function may create new listening ports on this load balancer, such as ports 61613 / 61614 for Rabbitmq_Stomp, port 15674 for Rabbitmq_Web_Stomp, ports 1883 / 8883 for Rabbitmq_Mqtt, and port 15675 for Rabbitmq_Web_Mqtt. These listening ports further reduce the efficiency of load balancing, thereby affecting port 5672 corresponding to user services and reducing some performance.

[0051] The load balancing system provided in this application aims to solve the above-mentioned technical problems of the prior art.

[0052] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0053] Example 1:

[0054] Figure 1 This is a schematic diagram of a load balancing system provided in an embodiment of this application. Figure 1 As shown, the system includes: a message middleware 10, a service network interface card 11 and a management network interface card 12 deployed on any server in the RabbitMQ cluster, a first load balancer 21 corresponding to the service network interface card 11, and a second load balancer 22 corresponding to the management network interface card 12.

[0055] It should be understood that "server" can refer to devices such as computers, and the message middleware 10 deployed on any server in the RabbitMQ cluster can refer to RabbitMQ. This RabbitMQ includes elements such as queues, exchanges, and routing. The first load balancer 21 and the second load balancer 22 can be deployed on servers in the RabbitMQ cluster other than the server where the service network interface card 11 is located. All servers are used to form a backbone pool, which may also be called a cloud pool, resource pool, etc. Furthermore, the servers in this application communicate within an intranet. The service network interface card 11 corresponds to a service layer, while the management network interface card 12 corresponds to a management layer.

[0056] The service network interface card 11 and the management network interface card 12 respectively receive and forward service traffic and non-service traffic from service requests. Service requests are sent by clients, which are either producer or consumer modules in the RabbitMQ cluster. Service traffic refers to user service traffic, while non-service traffic refers to functional requests to the message middleware 10. It should be understood that service traffic refers to user service traffic, and non-service traffic refers to functional traffic from the cloud service provider console.

[0057] The first load balancer 21 and the second load balancer 22 respectively distribute business traffic and non-business traffic to their respective servers, so that the respective servers can process the business traffic and non-business traffic accordingly.

[0058] This application embodiment features a dual network interface card (NIC) for both service and management. By binding different NICs to load balancers, service traffic and non-service traffic within service requests are separated, thereby increasing the Requests Per Second (QPS) and Total Transactions Per Second (TPS) of the RabbitMQ cluster. Compared to existing technologies, this application embodiment's load balancing system with the above structure improves load balancing efficiency.

[0059] One possible implementation is, such as Figure 2 As shown, the first load balancer 21 is equipped with a first listener 211 and a first load balancer instance 212, and the second load balancer 22 is equipped with a second listener 221 and a second load balancer instance 222.

[0060] Then the first load balancer 21 and the second load balancer 22 respectively distribute service traffic and non-service traffic to their respective servers, including:

[0061] The first listener 211 and the second listener 221 listen to their respective ports and forward business traffic and non-business traffic to the first load balancer instance 212 and the second load balancer instance 222, respectively.

[0062] Specifically, the first listener and the second listener each listen on their respective ports, including:

[0063] The first listener is used to listen on the AMQP protocol port; the AMQP protocol port is the port between the client and the server.

[0064] The second listener is used to listen to the port of the message middleware management tool.

[0065] The first load balancing instance and the second load balancing instance determine the first server corresponding to the business traffic and the second server corresponding to the non-business traffic according to the preset load balancing algorithm, and distribute the business traffic and non-business traffic to the first server and the second server respectively through the business network card and the management network card; wherein the first server and the second server are either servers in the RabbitMQ cluster.

[0066] In one possible implementation, the message middleware is in mirror mode.

[0067] The load balancing system proposed in this embodiment enables a dual-NIC load balancing method under a message middleware cluster. Based on the mirroring mode of the message middleware RabbitMQ, this method separates user service traffic from cloud service console functional traffic by binding the service NIC and management NIC to load balancers respectively. Each NIC creates its own corresponding listener and backend server group, maximizing network performance optimization and improving RabbitMQ's requests per second / concurrency.

[0068] In one possible implementation, the service network interface card (NIC) and the management NIC respectively receive and forward service traffic and non-service traffic from service requests, including:

[0069] The service network interface card (NIC) receives the first sub-service traffic sent by the client through the server where the service NIC is located, and sends the first sub-service traffic to the first load balancer.

[0070] The service network interface card (NIC) receives the second sub-service traffic sent by the client via the RabbitMQ dashboard carried by the message middleware, and then forwards the second sub-service traffic to the first load balancer. It should be understood that the RabbitMQ dashboard, also known as the RabbitMQ Dashboard, is a front-end web UI. Users, after obtaining RabbitMQ usage permissions, have the authority to operate the dashboard.

[0071] The management network interface card (NIC) receives non-business traffic sent by clients through the target tool and forwards the non-business traffic to the secondary load balancer. It should be understood that the target tool can be a console, a target browser, or a cloud computing service.

[0072] Specifically, users create components through the console. That is, users can create Vhosts, queues, etc. through the console / browser / China Unicom Cloud page, so that the client can send these functional requests to RabbitMQ through the browser.

[0073] It should be noted that the aforementioned non-business traffic can be created as a second sub-business traffic through the RabbitMQ dashboard. Compared with creating it through the RabbitMQ dashboard, creating it through the target tool has the advantages of being simple, intuitive, and concise.

[0074] In one possible implementation, the first sub-business traffic includes at least one of the following: connection requests between the producer module and the consumer module, message production requests, message consumption requests, and message confirmation requests.

[0075] This first sub-business traffic consists of RabbitMQ's main service requests, enabling producers and consumers to connect to the RabbitMQ server and send and receive messages through servers in the RabbitMQ cluster. Users can send this service request after obtaining the RabbitMQ product.

[0076] In this embodiment, the producer module and the consumer module are connected via RabbitMQ. The producer module publishes message production requests to RabbitMQ, and the consumer module consumes messages through RabbitMQ. Compared to non-business traffic, the first sub-business traffic is traffic of a different type and obtained through different devices.

[0077] The second sub-service traffic includes at least one of the following: requests to view information, monitor, and manage the RabbitMQ cluster. It should be understood that the second sub-service traffic consists of requests sent through the RabbitMQ Dashboard. Users can view, monitor, and manage the RabbitMQ cluster through the RabbitMQ Dashboard.

[0078] Non-business traffic includes at least one of the following: message middleware management requests, resource creation requests, resource modification requests, resource query requests, resource deletion requests, and password reset requests. In other words, non-business traffic includes functional requests from the cloud provider's front-end console. These functional requests are used to implement functions such as Vhost management, user management, queue management, and switch management. Users can perform operations such as creating, modifying, querying, deleting, and resetting passwords for resources through the console.

[0079] In summary, the first sub-service traffic, the second sub-service traffic, and the non-service traffic mentioned above are requests from different sources. The first and second sub-service traffic are both user-initiated requests, while the non-service traffic requests functions provided by the operator and is created by the RabbitMQ message middleware user through the console.

[0080] This application embodiment sends service requests from different sources to the corresponding network interface cards, which can avoid the impact of non-service traffic on load balancing and improve load balancing efficiency.

[0081] In summary, the load balancing system in this embodiment directs the functional traffic of the cloud vendor console into the management network interface card (NIC), while user business traffic flows into the business NIC. These two types of traffic are isolated and do not interfere with each other. The functional traffic of the cloud vendor console has its own corresponding second management NIC and second load balancer, preventing it from preempting network resources for user services. This improves RabbitMQ's network performance and throughput to a certain extent. Furthermore, each of the two NICs is bound to a load balancer and corresponding listeners, and through a unique entry address (e.g., a load balancer VIP) or a higher-level elastic public IP address, multi-node load balancing of RabbitMQ in mirrored cluster mode is achieved, further reducing the pressure on individual nodes in the RabbitMQ cluster and improving service performance.

[0082] Example 2:

[0083] Figure 3 This is a flowchart illustrating a load balancing method provided in an embodiment of this application. The load balancing method is applied to a load balancing system, which includes: a message middleware deployed on any server in a RabbitMQ cluster, a service network interface card (NIC), a management NIC, a first load balancer corresponding to the service NIC, and a second load balancer corresponding to the management NIC. Figure 3 As shown, the load balancing method includes:

[0084] S1, the business network interface card (NIC), and the management NIC receive and forward business traffic and non-business traffic from business requests, respectively. Business requests are requests sent by clients, which are either producer or consumer modules in the RabbitMQ cluster. Business traffic is the traffic of user services, and non-business traffic is the functional requests to the message middleware.

[0085] S2, the first load balancer, and the second load balancer distribute business traffic and non-business traffic to their respective servers, so that the respective servers can process the business traffic and non-business traffic accordingly.

[0086] Optionally, the first load balancer is deployed with a first listener and a first load balancer instance, and the second load balancer is deployed with a second listener and a second load balancer instance.

[0087] The first and second load balancers then distribute service traffic and non-service traffic to their respective servers, including:

[0088] The first listener and the second listener listen to their respective ports and forward business traffic and non-business traffic to the first load balancer instance and the second load balancer instance, respectively.

[0089] The first load balancing instance and the second load balancing instance determine the first server corresponding to the business traffic and the second server corresponding to the non-business traffic according to the preset load balancing algorithm, and distribute the business traffic and non-business traffic to the first server and the second server respectively through the business network card and the management network card; wherein the first server and the second server are either servers in the RabbitMQ cluster.

[0090] Optionally, the service network interface card (NIC) and the management NIC respectively receive and forward service traffic and non-service traffic from service requests, including:

[0091] The service network interface card (NIC) receives the first sub-service traffic sent by the client through the server where the service NIC is located, and sends the first sub-service traffic to the first load balancer.

[0092] The service network card receives the second sub-service traffic sent by the client through the RabbitMQ dashboard carried by the message middleware, and sends the second sub-service traffic to the first load balancer;

[0093] Manage network interface cards (NICs), receive non-business traffic sent by clients through the target tool, and send the non-business traffic to the second load balancer.

[0094] like Figure 4 As shown, different types of requests, such as non-business traffic, first sub-business traffic, and second sub-business traffic, can all interact with the RabbitMQ cluster in different ways.

[0095] like Figure 5 As shown, the first load balancer can be abstracted as the first load balancer corresponding to the user's network interface card (NIC), and this first load balancer creates a corresponding first listener. On one hand, the first load balancer undertakes the user's own business operations, including producer-consumer connections, message production and consumption, message acknowledgment, etc. On the other hand, users can view, monitor, and manage the RabbitMQ cluster through the RabbitMQ Dashboard front-end UI. Both aspects expose two ports, 5672 and 15672, so the first load balancer corresponding to the user's NIC listens on both ports simultaneously.

[0096] The second load balancer can be abstracted as a second load balancer corresponding to the management network interface card (NIC), and this second load balancer creates a corresponding second listener. The second load balancer inherits the basic functions of the cloud provider console message middleware, including vhost management, user management, queue management, and switch management. Since these functions are implemented by indirectly calling the RabbitMQ Dashboard's internal API, and the RabbitMQ Dashboard's service port is 15672, the second load balancer only listens on port 15672.

[0097] Optionally, the first sub-business traffic includes at least one of the following: connection requests between the producer module and the consumer module, message production requests, message consumption requests, and message confirmation requests;

[0098] The second sub-business traffic includes at least one of the following: requests to view information, monitor, and manage RabbitMQ clusters;

[0099] Non-business traffic includes at least one of the following: message middleware management requests, resource creation requests, resource modification requests, resource query requests, resource deletion requests, and password reset requests.

[0100] Optionally, the first listener and the second listener listen to their respective corresponding ports, including:

[0101] The first listener is used to listen on the AMQP protocol port; where the AMQP protocol port is the port between the client and the server.

[0102] The second listener is used to listen to the port of the message middleware management tool.

[0103] Optionally, the message middleware is in mirror mode.

[0104] Optionally, the target tool can be a console, a target browser, or a cloud computing service. The load balancing method provided in this embodiment is similar in principle and technical effect to the load balancing system described above, and will not be repeated here.

[0105] According to embodiments of this application, this application also provides an electronic device and a readable storage medium.

[0106] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device includes a receiver 60, a transmitter 61, at least one processor 62, and a memory 63. The electronic device composed of the above components can be used to implement the above-described specific embodiments of this application, which will not be described in detail here.

[0107] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the methods described above.

[0108] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0109] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart 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 performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0110] It should be understood that the above system embodiments are merely illustrative, and the system of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components can be combined, or integrated into another system, or some features can be ignored or not executed.

[0111] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0112] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0113] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0114] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as these combinations of technical features do not contradict each other, they should be considered within the scope of this specification.

[0115] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0116] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A load balancing system, characterized in that, include: The message middleware, the service network interface card (NIC), and the management NIC are deployed on any server in the RabbitMQ cluster. A first load balancer corresponding to the service NIC and a second load balancer corresponding to the management NIC are also included. The service network interface card (NIC) and the management NIC receive and forward service traffic and non-service traffic from service requests, respectively. The service request is a request sent by a client, which is either a producer module or a consumer module in the RabbitMQ cluster. The service traffic is the traffic of user services, and the non-service traffic is a function request to the message middleware. The first load balancer and the second load balancer respectively distribute the service traffic and the non-service traffic to their respective servers, so that the respective servers can process the service traffic and the non-service traffic accordingly. The service network interface card (NIC) and the management NIC respectively receive and forward service traffic and non-service traffic from service requests, including: The service network interface card (NIC) receives the first sub-service traffic sent by the client through the server where the service NIC is located, and sends the first sub-service traffic to the first load balancer. The service network interface card receives the second sub-service traffic sent by the client through the RabbitMQ dashboard carried by the message middleware, and sends the second sub-service traffic to the first load balancer; The management network interface card receives non-service traffic sent by the client through the target tool and sends the non-service traffic to the second load balancer.

2. The system according to claim 1, characterized in that, The first load balancer is deployed with a first listener and a first load balancer instance, and the second load balancer is deployed with a second listener and a second load balancer instance. The first load balancer and the second load balancer then distribute the service traffic and the non-service traffic to their respective servers, including: The first listener and the second listener listen to their respective ports and forward the service traffic and the non-service traffic to the first load balancer instance and the second load balancer instance, respectively. The first load balancing instance and the second load balancing instance determine the first server corresponding to the service traffic and the second server corresponding to the non-service traffic according to a preset load balancing algorithm, and distribute the service traffic and the non-service traffic to the first server and the second server respectively through the service network card and the management network card; wherein, the first server and the second server are either servers in the RabbitMQ cluster.

3. The system according to claim 1, characterized in that, The first sub-service traffic includes at least one of the following: connection requests, message production requests, message consumption requests, and message confirmation requests between the producer module and the consumer module; The second sub-service traffic includes at least one of the following: information viewing requests, monitoring requests, and management requests for the RabbitMQ cluster; The non-business traffic includes at least one of the following: message middleware management requests, resource creation requests, resource modification requests, resource query requests, resource deletion requests, and password reset requests.

4. The system according to claim 2, characterized in that, The first listener and the second listener each listen on their respective ports, including: The first listener is used to listen on the port of the AMQP protocol; wherein, the port of the AMQP protocol is the port between the client and the server; The second listener is used to listen to the port of the message middleware management tool.

5. The system according to any one of claims 1 to 4, characterized in that, The message middleware is in mirror mode.

6. The system according to claim 1, characterized in that, The target tool is a console, a target browser, or a cloud computing service.

7. A load balancing method, applied to a load balancing system, characterized in that, The load balancing system includes: a message middleware, a service network interface card (NIC), and a management NIC deployed on any server in the RabbitMQ cluster; a first load balancer corresponding to the service NIC; and a second load balancer corresponding to the management NIC; the method includes: The service network interface card (NIC) and the management NIC receive and forward service traffic and non-service traffic from service requests, respectively. The service request is a request sent by a client, which is either a producer module or a consumer module in the RabbitMQ cluster. The service traffic is the traffic of user services, and the non-service traffic is a function request to the message middleware. The first load balancer and the second load balancer respectively distribute the service traffic and the non-service traffic to their respective servers, so that the respective servers can process the service traffic and the non-service traffic accordingly. The service network interface card (NIC) and the management NIC respectively receive and forward service traffic and non-service traffic from service requests, including: The service network interface card (NIC) receives the first sub-service traffic sent by the client through the server where the service NIC is located, and sends the first sub-service traffic to the first load balancer. The service network interface card receives the second sub-service traffic sent by the client through the RabbitMQ dashboard carried by the message middleware, and sends the second sub-service traffic to the first load balancer; The management network interface card receives non-service traffic sent by the client through the target tool and sends the non-service traffic to the second load balancer.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in claim 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in claim 7.

Images