System and method for realizing load balancing processing for hybrid cloud deployment scene
By designing a global coordination center and a local coordination center in a hybrid cloud deployment scenario, dynamically compute the weight of service instances and adjusting the load balancing strategy, the problem that traditional load balancing strategies cannot adapt to hybrid cloud deployment is solved, and efficient and accurate load balancing processing is achieved.
Patent Information
- Application Number
- CN202411576903.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-06
- Publication Date
- 2025-03-25
AI Technical Summary
In hybrid cloud deployment scenarios, traditional registry-based load balancing strategies cannot effectively achieve load balancing between service instances because there are differences between instances in virtual machine clusters and instances in container cloud clusters.
A system is designed, including a global coordination center and a local coordination center. By summarizing and monitoring the service instance information of each computer room, combining the hardware information collected by Prometheus, the weight information of the instance is calculated, and the load balancing strategy is dynamically adjusted.
It realizes automatic service discovery, status monitoring and dynamic weight changes in hybrid cloud deployment environment, ensuring the accuracy and wide application scope of load balancing.
Smart Images

Figure CN119697186A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of software services, and in particular to the field of hybrid deployment of containers and virtual machine clusters, and specifically refers to a system and method for implementing load balancing processing for hybrid cloud deployment scenarios. Background Art
[0002] Software services can be deployed in two ways: virtual machine cluster deployment, that is, the service is deployed on a separate virtual machine; container cloud deployment, that is, the service is deployed in a k8s cluster. When the virtual machine cluster is deployed separately, the existing load balancing technology can be applied; when the container cloud is deployed separately, the k8s cluster can provide the corresponding load balancing function. In hybrid cloud deployment, services are deployed in both virtual machine clusters and K8S clusters. There is a one-to-one relationship between the number of running instances in the virtual machine cluster and the number of entries registered in the registry center, but in the k8S cluster, the backend of an entry registered in the registry center may correspond to multiple running instances, so when implementing load balancing for each instance of the service, the traditional load balancing strategy based on the registry center is no longer applicable. Summary of the invention
[0003] The purpose of the present invention is to overcome the shortcomings of the above-mentioned prior art and provide a system and method for implementing load balancing processing for hybrid cloud deployment scenarios which are simple to operate, highly accurate and have a wide range of applications.
[0004] In order to achieve the above objectives, the system and method for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention are as follows:
[0005] The main features of the system for implementing load balancing processing for hybrid cloud deployment scenarios are as follows:
[0006] The global coordination center is used to aggregate the instance information of services in all computer rooms and calculate the instance weight information in combination with the hardware information collected by Prometheus.
[0007] The local coordination center is connected to the global coordination center, and is used to monitor the instance information deployed in the virtual machine cluster and the container cloud cluster of the computer room, and complete the interaction of the instance information with the global coordination center.
[0008] Preferably, the global coordination center includes:
[0009] HTTP server, used to process administrator requests and provide service restart, health check, and message queue consumption status query functions;
[0010] GRPC server, connected to the local coordination center, for reporting service status information, processing message confirmation, service status and weight change information;
[0011] The consumer module is used to read information from the message queue, monitor message loss and report it, maintain the persistence of service status and consumption offset, and convey service messages to the local coordination center through the GRPC server;
[0012] The weight calculation module is used to obtain monitoring indicators from Prometheus, calculate weight changes, and transmit them to the local coordination center through the GRPC server.
[0013] Preferably, the local coordination center comprises:
[0014] A communication module, connected to the global coordination center, used to communicate with the global coordination center based on GRPC to implement the logic of reporting instance information and receiving instance information;
[0015] The virtual machine cluster monitoring module is connected to the consul cluster and is used to monitor using the watch mechanism based on Consul. It registers a monitoring cache for each service and obtains service instance change information.
[0016] The container cloud cluster monitoring module is connected to the container cloud cluster to monitor the changes in the number of backend pods of the corresponding service instances.
[0017] Preferably, the operation steps of the local coordination center are as follows:
[0018] After the local coordination center is started, it obtains all service instance information currently deployed in the computer room from Consul, reports it to the global coordination center, and starts monitoring the service instance information of this computer room. After receiving the changes, it reports them to the global coordination center.
[0019] After the global coordination center receives the change or a new local coordination center comes online, it recalculates the weight information and pushes the result to all local coordination centers. The local coordination center will send the weight information to Consul.
[0020] The method for implementing load balancing processing for hybrid cloud deployment scenarios using the above system has the following main features: the method includes the following steps, the method includes steps after the global coordination center is started, and steps after the local coordination center is started, the steps after the global coordination center is started and the steps after the local coordination center is started are performed independently, and the steps after the global coordination center is started specifically include the following operation steps:
[0021] (1-1) Start the HTTP service responsible for managing the operation of the operator and use the read-write lock strategy to ensure the security of processing concurrent HTTP management requests;
[0022] (1-2) Read the Pulsar offset from RocksDB and start consuming from Pulsar using this offset as the starting point;
[0023] (1-3) Waiting for connection;
[0024] (1-4) When processing a service discovery request, determine the target partition based on the message ID, append the sent message count and send it, wait for the ACK message to confirm, update the message count, and send the message count to the local coordination center;
[0025] (1-5) Read service status change messages from the message queue, record message counts, and check for value jumps to identify message loss;
[0026] (1-6) Perform weight calculation and send the changed service weight information to the local coordination center via GRPC;
[0027] The steps after the local coordination center is started specifically include the following steps:
[0028] (2-1) Establish communication with Consul and obtain the list of services currently registered on Consul;
[0029] (2-2) Filter out service instances belonging to the computer room from the obtained service list;
[0030] (2-3) Monitor the instance status of the filtered service instances;
[0031] (2-4) Establish a GRPC connection with the global coordination center and register the callback processing mechanism.
[0032] Preferably, the step (1-2) further comprises the following steps:
[0033] If the corresponding log of Pulsar has been cleaned up, an error will be reported and the system will wait for another global coordination center copy to be designated for recovery.
[0034] Preferably, the steps (1-3) further include the following steps:
[0035] When a new GRPC connection is established, a snapshot of the current service is obtained and sent to the local coordination center.
[0036] Preferably, the steps (1-5) further include the following steps:
[0037] If a message is found to be lost, an early warning is issued, and the message and its queue offset are persisted as a transaction to ensure the consistency of the service status snapshot and consumption progress; after processing, the service status change information is returned to the local coordination center through GRPC.
[0038] Preferably, the steps (1-6) specifically include the following steps:
[0039] (1-6.1) The weight calculation module subscribes to service status changes and stores all health instance information in the local cache.
[0040] (1-6.2) Pull monitoring information from Prometheus for each service at regular intervals to obtain the CPU usage, core limit, and physical node name of the service instance. Use the node name to query the number of CPU cores and total usage of the node.
[0041] (1-6.3) Take the minimum value between the idle rate / core number value of the service itself and the idle rate / core number value of the physical node as the weight of the service;
[0042] (1-6.4) Send the changed service weight information to the local coordination center via GRPC.
[0043] Preferably, the step (2-3) specifically comprises the following steps:
[0044] (2-3.1) Determine whether the filtered service instance is a virtual machine instance or a container cloud instance. If it is a virtual machine instance, proceed to step (2-3.2); if it is a container cloud instance, proceed to step (2-3.3);
[0045] (2-3.2) Use Consul's watch mechanism to monitor instance status;
[0046] (2-3.3) Use the list-watch mechanism in the kubernetes cluster to monitor instance status.
[0047] Preferably, the step (2-3.3) specifically includes the following steps:
[0048] For the weight information sent by the global coordination center, send the weight information to Consul;
[0049] GRPC connection uses the ack mechanism and automatic retry mechanism. If the local coordination center does not receive the ack message within a fixed time after sending, it will retry the sending;
[0050] If the connected global coordination center instance fails and cannot provide external services, it will try to switch to another global coordination center instance.
[0051] The system and method for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention are used to solve the load balancing problem under hybrid cloud deployment on the basis of service discovery and service observability. In a hybrid deployment environment, this system can realize automatic service discovery, service status monitoring and dynamic weight change, and has a wide range of applications. BRIEF DESCRIPTION OF THE DRAWINGS
[0052] Figure 1 A schematic diagram of the structure of a system for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention.
[0053] Figure 2 A structural diagram of the service model architecture of the system for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention.
[0054] Figure 3 A schematic diagram of the service access process of the system for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention.
[0055] Figure 4 A schematic diagram of the monitoring data collection process of the system for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention. DETAILED DESCRIPTION
[0056] In order to more clearly describe the technical content of the present invention, further description is given below in conjunction with specific embodiments.
[0057] The system for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention includes:
[0058] The global coordination center is used to aggregate the instance information of services in all computer rooms and calculate the instance weight information in combination with the hardware information collected by Prometheus.
[0059] The local coordination center is connected to the global coordination center, and is used to monitor the instance information deployed in the virtual machine cluster and the container cloud cluster of the computer room, and complete the interaction of the instance information with the global coordination center.
[0060] As a preferred embodiment of the present invention, the global coordination center includes:
[0061] HTTP server, used to process administrator requests and provide service restart, health check, and message queue consumption status query functions;
[0062] GRPC server, connected to the local coordination center, for reporting service status information, processing message confirmation, service status and weight change information;
[0063] The consumer module is connected to pulsar and is used to read information from the message queue, monitor message loss and report it, maintain the persistence of service status and consumption offset, and convey service messages to the local coordination center through the GRPC server;
[0064] The weight calculation module connects to the query proxy to obtain monitoring indicators from Prometheus, calculate weight changes, and transmit them to the local coordination center through the GRPC server.
[0065] As a preferred embodiment of the present invention, the local coordination center comprises:
[0066] A communication module, connected to the global coordination center, used to communicate with the global coordination center based on GRPC to implement the logic of reporting instance information and receiving instance information;
[0067] The virtual machine cluster monitoring module is connected to the consul cluster and is used to monitor using the watch mechanism based on Consul. It registers a monitoring cache for each service and obtains service instance change information.
[0068] The container cloud cluster monitoring module is connected to the container cloud cluster to monitor the changes in the number of backend pods of the corresponding service instances.
[0069] As a preferred embodiment of the present invention, the operation steps of the local coordination center when working are as follows:
[0070] After the local coordination center is started, it obtains all service instance information currently deployed in the computer room from Consul, reports it to the global coordination center, and starts monitoring the service instance information of this computer room. After receiving the changes, it reports them to the global coordination center.
[0071] After the global coordination center receives the change or a new local coordination center comes online, it recalculates the weight information and pushes the result to all local coordination centers. The local coordination center will send the weight information to Consul.
[0072] The method for implementing load balancing processing for hybrid cloud deployment scenarios using the above system of the present invention includes the following steps, wherein the method includes steps after the global coordination center is started and steps after the local coordination center is started, and the steps after the global coordination center is started and the steps after the local coordination center is started are performed independently, wherein the steps after the global coordination center is started specifically include the following operation steps:
[0073] (1-1) Start the HTTP service responsible for managing the operation of the operator and use the read-write lock strategy to ensure the security of processing concurrent HTTP management requests;
[0074] (1-2) Read the Pulsar offset from RocksDB and start consuming from Pulsar using this offset as the starting point;
[0075] (1-3) Waiting for connection;
[0076] (1-4) When processing a service discovery request, determine the target partition based on the message ID, append the sent message count and send it, wait for the ACK message to confirm, update the message count, and send the message count to the local coordination center;
[0077] (1-5) Read service status change messages from the message queue, record message counts, and check for value jumps to identify message loss;
[0078] (1-6) Perform weight calculation and send the changed service weight information to the local coordination center via GRPC;
[0079] The steps after the local coordination center is started specifically include the following steps:
[0080] (2-1) Establish communication with Consul and obtain the list of services currently registered on Consul;
[0081] (2-2) Filter out service instances belonging to the computer room from the obtained service list;
[0082] (2-3) Monitor the instance status of the filtered service instances;
[0083] (2-4) Establish a GRPC connection with the global coordination center and register the callback processing mechanism.
[0084] As a preferred embodiment of the present invention, the step (1-2) further comprises the following steps:
[0085] If the corresponding log of Pulsar has been cleaned up, an error will be reported and the system will wait for another global coordination center copy to be designated for recovery.
[0086] As a preferred embodiment of the present invention, the steps (1-3) further include the following steps:
[0087] When a new GRPC connection is established, a snapshot of the current service is obtained and sent to the local coordination center.
[0088] As a preferred embodiment of the present invention, the steps (1-5) further include the following steps:
[0089] If a message is found to be lost, an early warning is issued, and the message and its queue offset are persisted as a transaction to ensure the consistency of the service status snapshot and consumption progress; after processing, the service status change information is returned to the local coordination center through GRPC.
[0090] As a preferred embodiment of the present invention, the steps (1-6) specifically include the following steps:
[0091] (1-6.1) The weight calculation module subscribes to service status changes and stores all health instance information in the local cache.
[0092] (1-6.2) Pull monitoring information from Prometheus regularly for each service to obtain the CPU usage, core limit, and physical node name of the service instance, and use the node name to query the number of CPU cores and total usage of the node;
[0093] (1-6.3) Take the minimum value between the idle rate / core number value of the service itself and the idle rate / core number value of the physical node as the weight of the service;
[0094] (1-6.4) Send the changed service weight information to the local coordination center via GRPC.
[0095] As a preferred embodiment of the present invention, the step (2-3) specifically comprises the following steps:
[0096] (2-3.1) Determine whether the filtered service instance is a virtual machine instance or a container cloud instance. If it is a virtual machine instance, proceed to step (2-3.2); if it is a container cloud instance, proceed to step (2-3.3);
[0097] (2-3.2) Use Consul's watch mechanism to monitor instance status;
[0098] (2-3.3) Use the list-watch mechanism in the kubernetes cluster to monitor instance status.
[0099] As a preferred embodiment of the present invention, the step (2-3.3) specifically includes the following steps:
[0100] For the weight information sent by the global coordination center, send the weight information to Consul;
[0101] GRPC connection uses the ack mechanism and automatic retry mechanism. If the local coordination center does not receive the ack message within a fixed time after sending, it will retry the sending;
[0102] If the connected global coordination center instance fails and cannot provide external services, it will try to switch to another global coordination center instance.
[0103] Traditional load balancing solutions can only be applied to virtual machine clusters or container cloud clusters, and cannot be well adapted to the hybrid deployment scenarios of the two.
[0104] In the specific implementation of the present invention, the overall system can be divided into two parts: a global coordination center and a local coordination center. The global coordination center is responsible for summarizing the instance information of services in all computer rooms, and calculating the weight information of the instance in combination with the hardware information collected by Prometheus; the local coordination center is mainly responsible for monitoring the instance information deployed in the virtual machine cluster and container cloud cluster of the computer room, and completing the interaction of instance information with the global coordination center.
[0105] The global coordination center can be divided into four modules: HTTP server, GRPC server, consumer, and weight calculation. The HTTP server is responsible for processing administrator requests, providing service restart, health check, message queue consumption query and other functions. The HTTP server is mainly used to process administrator requests, hot modification of services during system operation, and monitoring of operating status, not for customer service; the GRPC server is responsible for reporting service status information, processing message confirmation, service status and weight change information; the consumer module connects to pulsar, reads information from the message queue, monitors message loss and reports, maintains persistence of service status and consumption offset, and transmits service messages to the local coordination center through the GRPC server; the weight calculation module connects to the query proxy, is responsible for obtaining monitoring indicators from Prometheus, calculating weight changes, and transmitting them to the local coordination center through the GRPC server.
[0106] The local coordination center can be divided into a communication module, a virtual machine cluster monitoring module, and a container cloud cluster monitoring module. The communication module is responsible for communicating with the global coordination center based on GRPC to implement the logic of reporting instance information and receiving instance information. When the local coordination center reports the information of all service instance entries registered in Consul, it will query the number of running instances corresponding to the instance entries; the virtual machine cluster monitoring module uses the watch mechanism based on Consul to monitor, registers a monitoring cache for each service, and obtains service instance change information; the container cloud cluster monitoring module is responsible for monitoring the changes in the number of backend pods of the corresponding service instances.
[0107] The main process of the local coordination center is: after startup, it will obtain all service instance information deployed in the current computer room from Consul, report to the global coordination center, and start monitoring the service instance information of this computer room, and report to the global coordination center after receiving changes; after the global coordination center receives changes or a new local coordination center comes online, it recalculates the weight information and pushes the results to all local coordination centers. The local coordination center will send the weight information to Consul.
[0108] When the Global Coordination Center is started (for the first time or after a crash), it goes through the following steps:
[0109] 1. Start the HTTP service to manage the operation of the operator, including the creation and allocation of resources; use the read-write lock strategy to ensure the security of processing concurrent HTTP management requests, and effectively handle requests such as server restart and health status detection.
[0110] 2. Read the Pulsar offset from RocksDB and start consuming from Pulsar with this offset as the starting point. If the corresponding log in Pulsar has been cleared, an error will be reported and the administrator needs to specify another global coordination center copy for recovery.
[0111] 3. Wait for connection. When a new GRPC connection is established, the consumer needs to suspend consumption and KV storage writing, then obtain the current service snapshot and send it to the local coordination center.
[0112] 4. When processing a service discovery request, determine the target Partition based on the message ID, append the sent message count and send it, wait for the ACK message to confirm, update the message count, and finally send the message count to the local coordination center.
[0113] 5. Read the service status change message from the message queue, record the message count with the global coordination center ID (Partition) as the key, and check the value jump to identify message loss. Issue an alert when a message is lost, and then persist the message and its queue offset as a transaction to ensure the consistency of the service status snapshot and consumption progress. After processing, return the service status change information to the local coordination center through GRPC.
[0114] 6. The workflow executed in parallel with service discovery is weight calculation. The weight calculation module subscribes to service status changes and stores all healthy instance information in the local cache. For each service, monitoring information is pulled from Prometheus at regular intervals to obtain the CPU usage, core limit, and physical node name of the service instance. The node name is then used to query the number of CPU cores and total usage of the node. The minimum value between the instance's own idle rate / core number and the physical node's idle rate / core number is taken as the service weight. Finally, the changed service weight information is sent to the local coordination center via GRPC.
[0115] After the local coordination center is started, it will go through the following steps:
[0116] 1. Establish communication with Consul and obtain the service list currently registered on Consul;
[0117] 2. Filter out the service instances belonging to the computer room from the obtained service list;
[0118] 3. For the filtered service instances, there are two cases. If it is a virtual machine instance, use Consul's watch mechanism to monitor the instance status; if it is a container cloud instance, use the list-watch mechanism in the kubernetes cluster to monitor the instance status;
[0119] 4. Establish a GRPC connection with the global coordination center and register the callback processing mechanism: For the weight information sent by the global coordination center, send the weight information to Consul; GRPC connection uses the ack mechanism and automatic retry mechanism. If the local coordination center does not receive the ack information within a fixed time after the sending is completed, it will retry the sending; when the connected global coordination center instance fails and cannot provide services to the outside world, it will try to switch to other global coordination center instances.
[0120] After deployment, it can automatically discover service instances deployed in virtual machine clusters and container cloud clusters; it can monitor the status of service instances and synchronize the status between multiple computer rooms; and by collecting system load, it can dynamically calculate the weights between various service instances.
[0121] The specific implementation scheme of this embodiment can refer to the relevant description in the above embodiment, which will not be repeated here.
[0122] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.
[0123] It should be noted that, in the description of the present invention, the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" refers to at least two.
[0124] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention belong.
[0125] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution device. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.
[0126] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the corresponding program may be stored in a computer-readable storage medium, which, when executed, includes one of the steps of the method embodiment or a combination thereof.
[0127] In addition, each functional unit in each embodiment of the present invention may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.
[0128] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.
[0129] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.
[0130] The system and method for implementing load balancing processing for hybrid cloud deployment scenarios of the present invention are used to solve the load balancing problem under hybrid cloud deployment on the basis of service discovery and service observability. In a hybrid deployment environment, this system can realize automatic service discovery, service status monitoring and dynamic weight change, and has a wide range of applications.
[0131] In this specification, the present invention has been described with reference to specific embodiments thereof. However, it is apparent that various modifications and variations may be made without departing from the spirit and scope of the present invention. Therefore, the specification and drawings should be regarded as illustrative rather than restrictive.
Claims
1. A system for implementing load balancing processing for hybrid cloud deployment scenarios, characterized in that: The system comprises: The global coordination center is used to aggregate the instance information of services in all computer rooms and calculate the instance weight information in combination with the hardware information collected by Prometheus. The local coordination center is connected to the global coordination center, and is used to monitor the instance information deployed in the virtual machine cluster and the container cloud cluster of the computer room, and complete the interaction of the instance information with the global coordination center.
2. The system for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 1, characterized in that: The global coordination center includes: HTTP server, used to process administrator requests and provide service restart, health check, and message queue consumption status query functions; GRPC server, connected to the local coordination center, for reporting service status information, processing message confirmation, service status and weight change information; The consumer module is used to read information from the message queue, monitor message loss and report it, maintain the persistence of service status and consumption offset, and convey service messages to the local coordination center through the GRPC server; The weight calculation module is used to obtain monitoring indicators from Prometheus, calculate weight changes, and transmit them to the local coordination center through the GRPC server.
3. The system for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 1, characterized in that: The local coordination centers include: A communication module, connected to the global coordination center, for implementing logic for reporting instance information and logic for receiving instance information; The virtual machine cluster monitoring module is connected to the consul cluster and is used to monitor using the watch mechanism based on Consul. It registers a monitoring cache for each service and obtains service instance change information. The container cloud cluster monitoring module is connected to the container cloud cluster to monitor the changes in the number of backend pods of the corresponding service instances.
4. The system for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 1, characterized in that: The operation steps of the local coordination center are as follows: After the local coordination center is started, it obtains all service instance information currently deployed in the computer room from Consul, reports it to the global coordination center, and starts monitoring the service instance information of this computer room. After receiving the changes, it reports them to the global coordination center. After the global coordination center receives the change or a new local coordination center comes online, it recalculates the weight information and pushes the result to all local coordination centers. The local coordination center will send the weight information to Consul.
5. A method for implementing load balancing processing for hybrid cloud deployment scenarios based on the system of claim 1, characterized in that: The method includes steps after the global coordination center is started and steps after the local coordination center is started. The steps after the global coordination center is started and the steps after the local coordination center is started are performed independently, wherein the steps after the global coordination center is started specifically include the following operation steps: (1-1) Start the HTTP service responsible for managing the operation of the operator and use the read-write lock strategy to ensure the security of processing concurrent HTTP management requests; (1-2) Read the Pulsar offset from RocksDB and start consuming from Pulsar using this offset as the starting point; (1-3) Waiting for connection; (1-4) When processing a service discovery request, determine the target partition based on the message ID, append the sent message count and send it, wait for the ACK message to confirm, update the message count, and send the message count to the local coordination center; (1-5) Read service status change messages from the message queue, record message counts, and check for value jumps to identify message loss; (1-6) Perform weight calculation and send the changed service weight information to the local coordination center via GRPC; The steps after the local coordination center is started specifically include the following steps: (2-1) Establish communication with Consul and obtain the list of services currently registered on Consul; (2-2) Filter out service instances belonging to the computer room from the obtained service list; (2-3) Monitor the instance status of the filtered service instances; (2-4) Establish a GRPC connection with the global coordination center and register the callback processing mechanism.
6. The method for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 5, characterized in that: The steps (1-2) further include the following steps: If the corresponding log of Pulsar has been cleaned up, an error will be reported and the system will wait for another global coordination center copy to be designated for recovery.
7. The method for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 5, characterized in that: The steps (1-3) further include the following steps: When a new GRPC connection is established, a snapshot of the current service is obtained and sent to the local coordination center.
8. The method for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 5, characterized in that: The steps (1-5) further include the following steps: If a message is found to be lost, an early warning is issued, and the message and its queue offset are persisted as a transaction to ensure the consistency of the service status snapshot and consumption progress; after processing, the service status change information is returned to the local coordination center through GRPC.
9. The method for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 5, characterized in that: The steps (1-6) specifically include the following steps: (1-6.1) The weight calculation module subscribes to service status changes and stores all health instance information in the local cache; (1-6.2) Pull monitoring information from Prometheus regularly for each service to obtain the CPU usage, core limit, and physical node name of the service instance, and use the node name to query the number of CPU cores and total usage of the node; (1-6.3) Take the minimum value between the idle rate / core number value of the service itself and the idle rate / core number value of the physical node as the weight of the service; (1-6.4) Send the changed service weight information to the local coordination center via GRPC.
10. The method for implementing load balancing processing for hybrid cloud deployment scenarios according to claim 5, characterized in that: The steps (2-3) specifically include the following steps: (2-3.1) Determine whether the filtered service instance is a virtual machine instance or a container cloud instance. If it is a virtual machine instance, proceed to step (2-3.2); if it is a container cloud instance, proceed to step (2-3.3); (2-3.2) Use Consul's watch mechanism to monitor instance status; (2-3.3) Use the list-watch mechanism in the kubernetes cluster to monitor instance status; Wherein, the step (2-3.3) specifically includes the following steps: For the weight information sent by the global coordination center, send the weight information to Consul; GRPC connection uses the ack mechanism and automatic retry mechanism. If the local coordination center does not receive the ack message within a fixed time after sending, it will retry the sending; If the connected global coordination center instance fails and cannot provide external services, it will try to switch to another global coordination center instance.