Unified scheduling method and system for multi-manufacturer load balancing equipment and storage medium

Through the unified scheduling method and system of multi-vendor load balancing equipment, the existing cloud load balancing solutions cannot meet the enterprise's detailed needs and low security problems, and realize efficient and secure load balancing configuration and customized application services.

CN120583039APending Publication Date: 2025-09-02太保科技有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510731356.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-06-03
Publication Date
2025-09-02

AI Technical Summary

Technical Problem

The existing cloud load balancing docking solutions cannot meet the enterprises' detailed needs for resource management and have low security problems.

Method used

It provides a unified scheduling method and system for multi-vendor load balancing equipment. It directly responds to user load balancing requests through the cloud, configures designated load balancing equipment, and uses a double-layer load balancing virtual IP with application firewall when interacting with external networks to improve security.

Benefits of technology

It realizes simple and efficient load balancing configuration, improves security and configuration efficiency, and can provide customized configurations for different designated applications to improve performance and user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120583039A_ABST
    Figure CN120583039A_ABST
Patent Text Reader

Abstract

The invention provides a unified scheduling method and system for multi-manufacturer load balancing equipment and a storage medium, and the unified scheduling system for the multi-manufacturer load balancing equipment comprises a terminal, a cloud end and a plurality of pieces of load balancing equipment. The cloud end is suitable for configuring a first load balancing virtual IP, an application firewall and a second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving flow data and carrying out data interaction with the second load balancing virtual IP, and the application firewall is suitable for filtering and checking data in data interaction; the at least one specified load balancing device is adapted to receive traffic data through the second load balancing virtual IP. Through the setting, when the specified application interacts with the cloud through the external network, the double-layer load balancing virtual IP with the application firewall is adopted, and the safety can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application mainly relates to the field of cloud load balancing technology, and in particular to a unified scheduling method, system and storage medium for multi-vendor load balancing devices. Background Art

[0002] Currently, cloud computing is becoming a hot topic in the information technology field. As the number of cloud users increases, user usage scenarios are becoming increasingly complex. Cloud Load Balancing (LoadBalancer) is a SaaS-based load balancing method in the cloud environment. It is a method that distributes user requests for applications on the client to multiple application servers running in the cloud environment. It aims to maximize the performance and reliability of applications by distributing the load, i.e., work tasks, across multiple operating units for execution, thereby collaboratively completing work tasks. By building on the existing network structure, Cloud Load Balancing provides a transparent, inexpensive and effective method to expand the bandwidth of servers and network devices, increase throughput, enhance network data processing capabilities, and improve network availability and flexibility.

[0003] Existing cloud load balancing integration solutions involve several steps: 1. The cloud management platform calls the vendor's API to initiate a request. 2. The vendor creates a load policy. 3. Once the load policy is finalized, detailed information is fed back to the cloud management platform. However, this cloud load balancing integration solution has limitations. As enterprises increasingly implement granular resource management and application scale and density increase, directly using the vendor's top-level interface is no longer sufficient to meet enterprise needs. Furthermore, existing cloud load balancing integration solutions are also vulnerable to cyberattacks and lack security. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide a unified scheduling method, system and storage medium for multi-vendor load balancing devices, directly respond to users' load balancing requests through the cloud and configure designated load balancing devices to handle load balancing requests according to load balancing policies, and use a double-layer load balancing virtual IP with an application firewall when the designated application interacts with the cloud through an external network to improve security.

[0005] To solve the above technical problems, the present application provides a unified scheduling system for multi-vendor load balancing devices, the system including: a terminal, a cloud and multiple load balancing devices; wherein the terminal is used to respond to the user's load balancing application operation for a specified application and send a load balancing request to the cloud; the cloud is used to receive the load balancing request and allocate and configure at least one specified load balancing device for the load balancing request from multiple load balancing devices, and the at least one specified load balancing device is used to provide services for the specified application; when the at least one specified load balancing device does not interact with the external network, the cloud is suitable for configuring a first load balancing virtual IP, and the at least one specified load balancing device is suitable for receiving traffic data of the specified application through the first load balancing virtual IP; when the at least one specified load balancing device interacts with the external network, the cloud is suitable for configuring the first load balancing virtual IP, an application firewall and a second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving traffic data and interacting with the second load balancing virtual IP, the application firewall is suitable for filtering and checking data in the data interaction, and the at least one specified load balancing device is suitable for receiving traffic data through the second load balancing virtual IP.

[0006] Optionally, the cloud is specifically used to: generate a unique load instance corresponding to a specified application according to a load balancing request, the unique load instance including various configuration information generated according to the load balancing request; select at least one load balancing device to be configured from multiple load balancing devices according to the unique load instance; and send configuration information to the selected at least one load balancing device to be configured to obtain at least one specified load balancing device.

[0007] Optionally, the cloud includes at least one virtual private cloud, which is bound to at least one functional domain, each functional domain corresponds to a business requirement, and the functional domain includes at least one IP address segment; each virtual private cloud also includes at least one subnet, and the network segment of the subnet is allocated from the functional domain of the corresponding virtual private cloud; the configuration information includes a first load balancing virtual IP, and when the cloud generates the first load balancing virtual IP based on the load balancing request, it is specifically used to: determine the business requirement corresponding to the load balancing request; and allocate an IP from a subnet corresponding to the business requirement as the first load balancing virtual IP.

[0008] Optionally, each virtual private cloud also corresponds to at least one load balancing device, and each load balancing device corresponds to a functional domain. When the cloud side selects at least one load balancing device to be configured from multiple load balancing devices based on a unique load instance, it is specifically used to: determine the virtual private cloud and functional domain corresponding to the unique load instance; and use each load balancing device corresponding to the functional domain in the virtual private cloud as the load balancing device to be configured.

[0009] Optionally, the cloud is further configured to: reserve an unassigned IP address of the subnet as a reserved IP address; and the load balancing request includes the reserved IP address specified by the user.

[0010] Optionally, the cloud is further used to allocate multiple ports from the first load balancing virtual IP, and traffic data generated by different demand parties using designated applications are sent to at least one designated load balancing device through corresponding ports.

[0011] Optionally, when the load balancing request includes an SSL offload domain name and a primary domain name selected by the user, the cloud is also used to: generate and bind a primary certificate and a backup certificate for the primary domain name, and deploy the primary certificate and the backup certificate to at least one designated load balancing device, wherein, when the primary certificate has not expired, the at least one designated load balancing device uses the primary certificate, and when the primary certificate expires, the at least one designated load balancing device uses the backup certificate.

[0012] Optionally, when the load balancing request includes a context jump and the first load balancing virtual IP only includes one port for receiving traffic data, the cloud is also used to: configure a corresponding jump load balancing device for each document root of the URL address in the traffic data from at least one designated load balancing device, and after receiving the traffic data at the port, send the traffic data to the jump load balancing device corresponding to the document root.

[0013] In order to solve the above technical problems, the present application provides a unified scheduling method for multi-vendor load balancing devices, which is applicable to terminals, including: responding to a user's load balancing application operation for a specified application, obtaining the user's system configuration information and load balancing port configuration information for the specified application; generating a load balancing request based on the system configuration information and the load balancing port configuration information; sending a load balancing request to the cloud to obtain at least one specified load balancing device corresponding to the specified application, and the at least one specified load balancing device is used to provide services for the specified application, wherein, when the at least one specified load balancing device does not interact with the external network, the cloud is suitable for configuring a first load balancing virtual IP, and the at least one specified load balancing device is suitable for receiving traffic data of the specified application through the first load balancing virtual IP; when the at least one specified load balancing device interacts with the external network, the cloud is suitable for configuring the first load balancing virtual IP, an application firewall, and a second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving traffic data and interacting with the second load balancing virtual IP, the application firewall is suitable for filtering and checking data in the data interaction, and the at least one specified load balancing device is suitable for receiving traffic data through the second load balancing virtual IP.

[0014] In order to solve the above technical problems, the present application provides a unified scheduling method for multi-vendor load balancing devices, which is applicable to the cloud, including: receiving a load balancing request sent by a terminal, the load balancing request is generated according to the user's load balancing application operation for a specified application on the terminal; allocating and configuring at least one designated load balancing device for the load balancing request from multiple load balancing devices, and the at least one designated load balancing device is used to provide services for the specified application, wherein, when the at least one designated load balancing device does not interact with the external network, the cloud is suitable for configuring a first load balancing virtual IP, and the at least one designated load balancing device is suitable for receiving traffic data of the specified application through the first load balancing virtual IP; when the at least one designated load balancing device interacts with the external network, the cloud is suitable for configuring the first load balancing virtual IP, an application firewall and a second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving traffic data and interacting with the second load balancing virtual IP, the application firewall is suitable for filtering and checking data in the data interaction, and the at least one designated load balancing device is suitable for receiving traffic data through the second load balancing virtual IP.

[0015] Optionally, at least one designated load balancing device is allocated and configured for a load balancing request from multiple load balancing devices, including: generating a unique load instance corresponding to a designated application according to the load balancing request, the unique load instance containing various configuration information generated according to the load balancing request; selecting at least one load balancing device to be configured from multiple load balancing devices according to the unique load instance; and sending configuration information to the selected at least one load balancing device to be configured to obtain at least one designated load balancing device.

[0016] Optionally, the cloud includes at least one virtual private cloud, the virtual private cloud is bound to at least one functional domain, each functional domain corresponds to a business requirement, and the functional domain includes at least one IP address segment; each virtual private cloud also includes at least one subnet, and the network segment of the subnet is allocated from the functional domain of the corresponding virtual private cloud; the configuration information includes a first load balancing virtual IP, and the first load balancing virtual IP is generated according to the load balancing request, further including: determining the business requirement corresponding to the load balancing request; allocating an IP from a subnet corresponding to the business requirement as the first load balancing virtual IP.

[0017] Optionally, each virtual private cloud also corresponds to at least one load balancing device, each load balancing device corresponds to a functional domain, and at least one load balancing device to be configured is selected from multiple load balancing devices based on a unique load instance, further including: determining the virtual private cloud and functional domain corresponding to the unique load instance; and using each load balancing device corresponding to the functional domain in the virtual private cloud as the load balancing device to be configured.

[0018] Optionally, it also includes: allocating multiple ports from the first load balancing virtual IP, and sending traffic data generated by different demand parties using designated applications to at least one designated load balancing device through corresponding ports.

[0019] Optionally, when the load balancing request includes a context jump and the first load balancing virtual IP only includes one port for receiving traffic data, the method also includes: configuring a corresponding jump load balancing device for each document root of the URL address in the traffic data from at least one designated load balancing device, and after the port receives the traffic data, sending the traffic data to the jump load balancing device corresponding to the document root.

[0020] To solve the above technical problems, the present application provides a computer-readable medium storing computer program code, which, when executed by a processor, implements the above-mentioned unified scheduling method for multi-vendor load balancing devices.

[0021] Compared with the prior art, the present application has the following advantages: on the one hand, when the specified load balancing device corresponding to the specified application needs to interact with the external network, a first load balancing virtual IP, an application firewall, and a second load balancing virtual IP are configured, so that the specified application exchanges data with the first load balancing virtual IP, the first load balancing virtual IP and the second load balancing virtual IP, and the second load balancing virtual IP and the specified load balancing device exchange data, and the data exchanged between the first load balancing virtual IP and the second load balancing virtual IP is filtered and inspected by the application firewall, thereby improving security. On the other hand, configuration information is directly sent to the load balancing device without using a plug-in, thereby achieving simple and efficient load balancing configuration; a unique load instance containing various configuration information is generated according to the load balancing request, so that the load balancing service of the corresponding specified application is uniformly managed through the unique load instance, thereby improving configuration efficiency; the configuration information includes port IP, port number, context jump, listening protocol, listening configuration, SSL offloading domain name, enabling X-Forward-For, HTTP Profile, iRules policy, TCP idle timeout, health check and session persistence, etc., which can achieve specific functions, thereby providing customized configuration for different specified applications and improving the performance and user experience of the specified application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are included to provide a further understanding of the present application. They are incorporated into and constitute a part of this application. The accompanying drawings illustrate embodiments of the present application and, together with this specification, serve to explain the principles of the present application. In the accompanying drawings:

[0023] Figure 1 This is a structural diagram of a unified scheduling system for multi-vendor load balancing devices according to an embodiment of the present application;

[0024] Figure 2 This is a flow chart of how a cloud allocates a designated load balancing device from multiple load balancing devices to a load balancing request in a unified scheduling system for load balancing devices from multiple vendors according to an embodiment of the present application;

[0025] Figure 3 According to this application Figure 2 A schematic diagram of a process for generating a first load balancing virtual IP in accordance with a load balancing request in a unified scheduling system for multi-vendor load balancing devices in the illustrated embodiment;

[0026] Figure 4 According to this application Figure 2 Schematic diagram of the traffic model of the double-layer load balancing mode with application firewall in the embodiment shown;

[0027] Figure 5 According to this application Figure 2 A schematic flow chart of the sub-steps of step S12 in the illustrated embodiment;

[0028] Figure 6 This is a flow chart of a unified scheduling method for multi-vendor load balancing devices executed at a terminal according to an embodiment of the present application;

[0029] Figure 7 is a flowchart of a unified scheduling method for multi-vendor load balancing devices executed in the cloud according to an embodiment of the present application; and

[0030] Figure 8 According to this application Figure 7 A schematic diagram of the cloud architecture of the illustrated embodiment. DETAILED DESCRIPTION

[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the following is a brief introduction to the drawings required for describing the embodiments. Obviously, the drawings described below are merely examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without inventive effort. Unless otherwise apparent from the context or otherwise noted, the same reference numerals in the figures represent the same structure or operation.

[0032] As used in this application and the claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not intended to refer to the singular but may include the plural. Generally speaking, the terms "comprises" and "include" only indicate the inclusion of the steps and elements specifically identified, and these steps and elements do not constitute an exclusive list. A method or apparatus may also include other steps or elements.

[0033] Unless otherwise specifically stated, the relative arrangement of the parts and steps, numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present application. At the same time, it should be understood that, for ease of description, the sizes of the various parts shown in the drawings are not drawn according to actual proportional relationships. The techniques, methods and equipment known to those of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, the techniques, methods and equipment should be considered as part of the authorization specification. In all examples shown and discussed here, any specific values ​​should be interpreted as being merely exemplary and not as limitations. Therefore, other examples of the exemplary embodiments may have different values. It should be noted that similar numbers and letters represent similar items in the following figures, and therefore, once an item is defined in one figure, it does not need to be further discussed in subsequent figures.

[0034] Flowcharts are used in this application to illustrate the operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the various steps may be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0035] Example 1

[0036] Figure 1 This is a structural diagram of a unified scheduling system for multi-vendor load balancing devices according to an embodiment of the present application. Figure 1As shown, the unified scheduling system 100 for multi-vendor load balancing devices includes: multiple terminals 10, a cloud 20, and multiple load balancing devices 30. It should be noted that in this embodiment, the terminal 10 refers to a device that can provide users with load balancing application operations for designated applications and has communication capabilities. The implementation form of the terminal 10 may vary in different application scenarios. For example, in some scenarios, the terminal 10 may be a user-side mobile phone, tablet computer, computer device, etc., and the user can perform application operations through plug-ins, applications, or browsers provided by the terminal 10. In this embodiment, the cloud 20 is a device that can directly connect to the load balancing device 30 and perform load balancing based on the user's application operations and load balancing policies. In some embodiments, the cloud 20 can be implemented as a server, including conventional servers, cloud servers, cloud hosts, virtual centers, and other servers, but this embodiment does not limit this. The server device mainly includes a processor, hard disk, memory, system bus, etc., similar to the general computer architecture, and will not be further described. In addition, in this embodiment, the designated application refers to an application that has not yet been launched, such as an application program (APP). Accordingly, the user is the person who manages the designated application. In this embodiment, the user configures load balancing for the specified application through a load balancing application operation, thereby dispersing the user's request pressure on the specified application after the specified application is launched. The user is a person who uses the specified application through the client. The corresponding implementation form of the client can refer to the implementation form of the terminal 10 above, which will not be repeated here.

[0037] Continue to refer to Figure 1In this embodiment, the terminal 10 is primarily used to respond to a user's load balancing request and send a load balancing request to the cloud 20. The load balancing request may include system configuration information and load balancing port configuration information. Specifically, the system configuration information is used to enable the cloud 20 to identify the virtual private cloud (VPC) to which the terminal 10 belongs. The system configuration information may include the system, functional area, function type, custom virtual IP, etc. In this embodiment, the systems include critical information systems and non-critical information systems. Functional areas include development, system integration testing (SIT testing), user acceptance testing (UAT testing), and production. Function types include WEB, APP, and DB. The load balancing port configuration information may include the port IP, number of ports, context jump, listening protocol, listening configuration, SSL offload domain name, enabling X-Forward-For, HTTP Profile, iRules policy, TCP idle timeout, health check, and session persistence. It will be understood that each item in the load balancing port configuration information represents a specific function that can be provided by the unified scheduling system 100 for multi-vendor load balancing devices. It should be noted that the various contents of the above-mentioned system configuration information and load balancing port configuration information will be described later in conjunction with the specific functions of the unified scheduling system 100 for multi-vendor load balancing devices. In some optional embodiments, the terminal 10 may include an electronic display screen, through which the user can initiate application operations. The electronic display screen may include a liquid crystal display and a touch panel. If the electronic display screen includes a touch panel, the electronic display screen can be implemented as a touch screen, which can receive input signals from the user to obtain the user's application operations. Of course, in other optional embodiments, the terminal 10 may include physical buttons or voice input devices for providing application operations to the user, which are not described here.

[0038] In this embodiment, the cloud 20 is primarily used to receive load balancing requests and allocate and configure at least one designated load balancing device from multiple load balancing devices 30 for the load balancing request. It should be noted that the load balancing devices 30 in this embodiment can come from different manufacturers. Furthermore, in this embodiment, the cloud 20 centrally manages load balancing devices 30 from different manufacturers and configures a corresponding designated load balancing device from multiple load balancing devices 30 for a specified application based on the load balancing request. It is understandable that conventional cloud systems often implement load balancing configuration through existing open source plug-ins, such as OpenStack. This inevitably involves lengthy calls to existing open source plug-ins. Furthermore, due to the differences between load balancing devices 30 from different manufacturers, unified management of these devices is difficult, resulting in a cumbersome and inefficient load balancing configuration process and the inability to quickly and conveniently implement certain specific functions. The following describes the specific methods by which the unified scheduling system 100 for multi-vendor load balancing devices in this embodiment achieves simple and efficient load balancing configuration and specific functions.

[0039] First, in this embodiment, cloud 20 includes at least one virtual private cloud (VPN). It should be noted that the VPNs are network-isolated, and each VPN can be allocated to one or more users. Each VPN is bound to at least one functional domain. Each functional domain includes at least one IP address segment, and each functional domain corresponds to a service requirement. Specifically, in this embodiment, each service requirement is configured based on the system, functional area, and function type information contained in the user's load balancing request. Based on the differences in this information, load balancing requests from different users are classified into different purposes, i.e., different service requirements, and functional domains corresponding to each service requirement are then assigned. Each VPN also includes at least one subnet, and the network segment of each subnet is allocated from the functional domain of the corresponding VPN. For example, in this embodiment, when VPN 20 configures a subnet for a VPN, it is configured to select an IP address from an IP address segment contained in a functional domain of the VPN as the network segment of the subnet, and to have the subnet inherit the service requirements of the functional domain, so that the configured subnet can subsequently be used for load balancing requests with the same service requirement. It should be noted that in this embodiment, the subnet includes the subnet to which the host IP belongs and the subnet to which the load balancing virtual IP belongs. Accordingly, when the system configuration information includes the load balancing virtual IP or host IP, the cloud 20 first determines the corresponding subnet based on the load balancing virtual IP or host IP, then determines the corresponding functional domain based on the subnet, and finally determines the virtual private cloud based on the functional domain, thereby implementing the function of identifying the virtual private cloud based on the system configuration information. Each virtual private cloud also corresponds to at least one load balancing device 30, and each load balancing device 30 corresponds to a functional domain. It is understood that each load balancing device 30 will subsequently be used for load balancing requests with the same business requirements.

[0040] Next, refer to Figure 1 and Figure 2 In this embodiment, the cloud 20 can allocate a designated load balancing device for a load balancing request from multiple load balancing devices 30, and its function implementation includes the following steps.

[0041] Step S11 is to generate a unique load instance corresponding to the specified application according to the load balancing request. The unique load instance includes various configuration information generated according to the load balancing request. Among them, the configuration information includes the first load balancing virtual IP. In step S11, when the cloud 20 generates the first load balancing virtual IP according to the load balancing request, it refers to Figure 1 and Figure 3Its functional implementation includes the following sub-steps. Step S111 is to determine the business demand corresponding to the load balancing request. Specifically, in step S111 of this embodiment, the cloud 20 determines the business demand and virtual private cloud corresponding to the load balancing request based on the system configuration information in the load balancing request. Step S112 is to allocate an IP from a subnet corresponding to the business demand as the first load balancing virtual IP. Specifically, in step S112 of this embodiment, the cloud 20 determines the subnet corresponding to the business demand in the virtual private cloud corresponding to the load balancing request, and then allocates an IP from the subnet as the first load balancing virtual IP. It can be seen that through the configuration of the virtual private cloud, business demand, subnet, etc. by the cloud 20 in the above text, each subnet corresponds to a business demand one by one, and then the load balancing request can be matched with the corresponding subnet through steps S111 and S112, thereby quickly allocating the first load balancing virtual IP, thereby realizing classified management of various designated applications according to their uses.

[0042] In this embodiment, the configuration information also corresponds to load balancing port configuration information, i.e., the configuration information may also include port IP, port number, context jump, listening protocol, listening configuration, SSL offloading domain name, enabling X-Forward-For, HTTP Profile, iRules policy, TCP idle timeout, health check, and session persistence. In this embodiment, cloud 20 is also used to reserve unassigned IP addresses in the subnet as reserved IP addresses. Users can specify an IP address as a reserved IP address in the port IP address field. That is, after the user actively selects the corresponding IP address as the load balancing virtual IP address, cloud 20 will use the reserved IP address in the configuration information as the first load balancing virtual IP address, thereby enabling the designation of the functional domain corresponding to the specified application. In this embodiment, the user can select one or more ports for a specified application through the port number. Cloud 20 then allocates one or more ports, such as 443, 80, etc., to the first load balancing virtual IP address. Specifically, when the port number is multiple, cloud 20 is used to allocate multiple ports from the first load balancing virtual IP address. Traffic data generated by different demand parties using the specified application is sent to at least one designated load balancing device via the corresponding ports. In this embodiment, multiple ports corresponding to the same designated application all provide the same service. By setting multiple ports for a designated application, users can perform functions such as source identification, precise traffic control and distribution, and grayscale release for users of the designated application, thereby optimizing the performance of the designated application.

[0043] When the load balancing request includes a context jump, i.e., the configuration information includes a context jump, and the first load balancing virtual IP includes only one port for receiving traffic data, i.e., the number of ports is one, the cloud 20 is configured to configure a corresponding jump load balancing device for each document root in the URL address of the traffic data from at least one designated load balancing device. After receiving the traffic data at the port, the cloud 20 sends the traffic data to the jump load balancing device corresponding to the document root. For example, when the designated application includes two services, a login verification service and a specific business service, the cloud 20 configures at least one load balancing device 30 corresponding to each of the login verification service and the specific business service. When the traffic data corresponds to the login verification service, the cloud 20 sends the traffic data to the corresponding load balancing device 30 for processing based on the document root identifying the login verification service in the URL address of the traffic data. Correspondingly, when the traffic data corresponds to a specific business service, the cloud 20 sends the traffic data to the corresponding load balancing device 30 for processing based on the document root identifying the specific business service in the URL address of the traffic data. In this embodiment, the listening protocol is the network protocol used to receive and process traffic data generated by user request operations on the designated application, and specifically includes HTTP, HTTPS, TCP, and UDP.

[0044] In this embodiment, the cloud 20 determines whether the designated application is an external HTTP application by analyzing the monitoring configuration, that is, whether the corresponding designated load balancing device needs to interact with the external network. When at least one designated load balancing device does not interact with the external network (such as the Internet), that is, the designated application is not an external HTTP application, the cloud 20 is suitable for configuring a first load balancing virtual IP, and at least one designated load balancing device is suitable for receiving the traffic data of the designated application through the first load balancing virtual IP. When at least one designated load balancing device interacts with the external network, that is, the designated application is an external HTTP application, the cloud 20 configures a two-layer load balancing mode with an application firewall. Specifically, refer to Figure 4 In a two-tier load balancing mode with an application firewall, the cloud 20 is adapted to configure a first load balancing virtual IP, namely VIP1, an application firewall, namely WAF, and a second load balancing virtual IP, namely VIP2. The first load balancing virtual IP is adapted to receive traffic data and exchange data with the second load balancing virtual IP. The application firewall is adapted to filter and inspect data in the data exchange. At least one designated load balancing device is adapted to receive traffic data through the second load balancing virtual IP. It is understandable that Figure 4The rectangular box enclosing the first load balancing virtual IP, application firewall, second load balancing virtual IP, and designated load balancing device indicates that the first load balancing virtual IP, application firewall, second load balancing virtual IP, and designated load balancing device are located within the cloud, while the designated application is located outside the cloud. Furthermore, in this embodiment, "within the cloud" refers to the scope managed by cloud 20. In this embodiment, the application firewall is a Web Application Firewall (WAF). In this embodiment, the first load balancing virtual IP is exposed to users of the designated application, while the second load balancing virtual IP and application firewall are invisible to users, thus unaware of their presence and preventing network attacks, enhancing security. In this embodiment, cluster management is used for the application firewall, which configures the cluster IP and port, access keys, the application firewall port range to be allocated, and the cluster node addresses. Each virtual private cloud is bound to a cluster. When using the application firewall, an unused application firewall port is allocated from the application firewall port range to be allocated. When the application firewall device is upgraded, cloud 20 configures the version number of the newly written new version driver in the cluster. When an application firewall device is switched, Cloud 20 imports the configuration of the original application firewall device into the new one and then replaces the old information with the new one in the cluster. By dividing application firewall devices into multiple clusters and binding them to different virtual private clouds, the application firewall requirements of each specific application can be easily managed. The number and configuration of application firewall devices can be dynamically adjusted based on the traffic data characteristics of specific applications in the virtual private cloud, improving security.

[0045] When a load balancing request includes an SSL offload domain name and a user-selected primary domain name, cloud 20 generates and binds a primary certificate and a backup certificate to the primary domain name, and deploys the primary and backup certificates to at least one designated load balancing device. While the primary certificate remains valid, the at least one designated load balancing device uses the primary certificate; when the primary certificate expires, the at least one designated load balancing device uses the backup certificate. In this embodiment, cloud 20 enables primary and backup certificate switching, improving the efficiency of certificate operations and maintenance, as well as enhancing security and stability.

[0046] In this embodiment, enabling X-Forward-For refers to inserting source address information into the HTTP header to identify the client IP address of the user of a specified application. In this embodiment, HTTP Profiles define and manage the behavior and characteristics of HTTP traffic, defining how the load balancing device handles HTTP traffic, such as adding headers, compression, and session persistence. In this embodiment, iRules policies refer to flexible traffic control and management through iRules rules, such as traffic distribution, content modification, security control, session persistence, and preprocessing. In this embodiment, TCP Idle Timeout supports customization of the TCP Idle Timeout and zero window timeout. In this embodiment, health checks are used to detect the activity of the load balancing device 30, including configuration items such as the check type, HTTP method, request URL, expected response code, check interval, timeout period, and maximum number of repetitions. In this embodiment, session persistence is used to ensure the continuity of user sessions and enhance data processing consistency. In this embodiment, cloud 20 supports source address session persistence, cookie session persistence, APP_Cookie session persistence, cookie session persistence (encrypted), and UserAgent session persistence; supports configuration of session persistence time; and supports customization of cookie names for cookie session persistence.

[0047] Step S12 is to select at least one load balancing device to be configured from multiple load balancing devices 30 according to the unique load instance. Figure 5 , step S12 of this embodiment includes the following sub-steps. Step S121 is to determine the virtual private cloud and functional domain corresponding to the unique load instance, that is, to determine the virtual private cloud and functional domain through the first load balancing virtual IP in the unique load instance. Step S122 is to use each load balancing device 30 corresponding to the functional domain in the virtual private cloud as the load balancing device to be configured. In this embodiment, all load balancing devices 30 are divided by functional domain, and the load balancing devices 30 that can meet the corresponding business needs can be screened in advance, so that when selecting a specified load balancing device, the load balancing device 30 that meets the requirements can be conveniently selected as the load balancing device to be configured, avoiding the problem of confirming one by one whether the load balancing device 30 is available for the specified application. In addition, the method of corresponding the load balancing device 30 to the functional domain adopted in this embodiment can also adjust the number of load balancing devices 30 corresponding to each functional domain in a targeted manner according to the needs of all users, thereby optimizing the load balancing effect of the specified application.

[0048] Step S13 distributes configuration information to at least one selected load balancing device to be configured, thereby obtaining at least one designated load balancing device. In this embodiment, the cloud 20 matches the APIs for each load balancing device to be configured, and then distributes configuration information to the corresponding load balancing device to be configured by sequentially calling the APIs, thereby obtaining the designated load balancing device. It should be noted that the management, modification, and recovery of load balancing for a designated application are uniformly performed on the unique load instance corresponding to the designated application. That is, the cloud 20 can uniformly manage the load balancing of a designated application through the unique load instance, thereby enabling simple and efficient load balancing configuration, as well as the configuration of various specific functions.

[0049] In this embodiment, the cloud 20 can also migrate the load balancing configuration of the load balancing device 30. Specifically, if the configuration information corresponding to the original load balancing device 30 exists on the cloud 20, for example, on the corresponding unique load instance, the cloud 20 directly sends all the configuration information to the new load balancing device 30, thereby replacing the original load balancing device 30 with the new load balancing device 30, and then providing load balancing services for the designated application through the new load balancing device 30. If the configuration information corresponding to the original load balancing device 30 is not completely available on the cloud 20, the cloud 20 extracts the configuration list containing the configuration information from the original load balancing device 30, imports the configuration list into the new load balancing device 30, and then provides load balancing services for the designated application through the new load balancing device 30.

[0050] The above has explained the details of implementing load balancing applications for specified applications through the unified scheduling system 100 of multi-vendor load balancing devices. Next, other embodiments will be used to explain the operations performed by the terminal 10 and the cloud 20 in the unified scheduling system 100 of multi-vendor load balancing devices.

[0051] Example 2

[0052] Figure 6 2 is a flow chart of a unified scheduling method for multi-vendor load balancing devices according to an embodiment of the present application. When the unified scheduling method 200 for multi-vendor load balancing devices is executed at a terminal, it may include the following steps.

[0053] Step S21 is to respond to the user's load balancing application request operation for the specified application and obtain the user's system configuration information and load balancing port configuration information for the specified application. It is understandable that the user performs the load balancing application operation through the terminal, and then the terminal obtains the system configuration information and load balancing port configuration information based on the user's load balancing application operation. Exemplarily, the terminal can display the system configuration information and load balancing port configuration information that the user needs to fill in to the user, and the user fills in the required content through the load balancing application operation, so that the terminal obtains the required system configuration information and load balancing port configuration information. It should be noted that the system configuration information and load balancing port configuration information have been described in Example 1 and will not be repeated here.

[0054] Step S22 generates a load balancing request based on the system configuration information and the load balancing port configuration information. In this embodiment, the terminal integrates the acquired system configuration information and the load balancing port configuration information to generate a load balancing request that can be received by the cloud. It is understood that the integration may include data encryption, data compression, etc.

[0055] Step S23 involves sending a load balancing request to the cloud to obtain at least one designated load balancing device corresponding to the specified application. The at least one designated load balancing device is used to provide services for the specified application. When the at least one designated load balancing device does not interact with an external network, the cloud is adapted to configure a first load balancing virtual IP, and the at least one designated load balancing device is adapted to receive traffic data for the specified application via the first load balancing virtual IP. When the at least one designated load balancing device interacts with an external network, the cloud is adapted to configure the first load balancing virtual IP, an application firewall, and a second load balancing virtual IP. The first load balancing virtual IP is adapted to receive traffic data and exchange data with the second load balancing virtual IP. The application firewall is adapted to filter and inspect data in the data exchange, and the at least one designated load balancing device is adapted to receive traffic data via the second load balancing virtual IP. In this embodiment, after step S23, the cloud also sends configuration result information to the terminal. The terminal receives and displays the configuration result information to the user. The configuration result information indicates whether the configuration is successful or failed. It should be noted that this embodiment only describes content related to the terminal and does not limit the cloud.

[0056] Example 3

[0057] First, in this embodiment, the cloud includes at least one virtual private cloud. It should be noted that the virtual private clouds are network-isolated, and each virtual private cloud can be allocated to one or more users. Each virtual private cloud is bound to at least one functional domain. Each functional domain includes at least one IP address segment, and each functional domain corresponds to a service requirement. Specifically, in this embodiment, each service requirement is configured based on the system, functional area, and function type information contained in the user's load balancing request. Different users' load balancing requests are classified into different purposes, i.e., different service requirements, based on the differences in this information. Functional domains corresponding to each service requirement are then assigned. Each virtual private cloud also includes at least one subnet, and the network segment of each subnet is allocated from the functional domain of the corresponding virtual private cloud. For example, in this embodiment, when the cloud configures a subnet for a virtual private cloud, it is configured to select an IP address from an IP address segment contained in a functional domain of the virtual private cloud as the network segment of the subnet, and to have the subnet inherit the service requirements of the functional domain. This allows the configured subnet to be used for subsequent load balancing requests with the same service requirement. Each virtual private cloud also corresponds to at least one load balancing device, and each load balancing device corresponds to a functional domain. It is understandable that each load balancing device is subsequently used for load balancing requests with the same business requirements.

[0058] then, Figure 7 This is a flow chart of a unified scheduling method for multi-vendor load balancing devices according to an embodiment of the present application. When the unified scheduling method 300 for multi-vendor load balancing devices is executed in the cloud, it may include the following steps.

[0059] Step S31 receives a load balancing request from a terminal. The load balancing request is generated based on a user's load balancing request for a specified application on the terminal. It is understood that in step S31, the cloud can parse and process the received load balancing request to generate subsequent executable instructions or operations. Step S32 allocates and configures at least one designated load balancing device from multiple load balancing devices for the load balancing request. The at least one designated load balancing device is used to provide services for the specified application. In step S32, in this embodiment, the cloud first generates a unique load instance corresponding to the specified application based on the load balancing request. The unique load instance includes the configuration information generated based on the load balancing request. The cloud then selects at least one load balancing device to be configured from the multiple load balancing devices based on the unique load instance. Finally, the cloud sends the configuration information to the selected at least one load balancing device to be configured, resulting in at least one designated load balancing device. It should be noted that in this embodiment, the cloud also configures the designated load balancing device based on the specific requirements of the load balancing request. This embodiment describes the cloud's execution of three configurations: a two-tier load balancing mode with an application firewall, multi-port allocation, and document root redirection. Furthermore, this embodiment does not limit the functions that the cloud can perform in this application.

[0060] Regarding the two-tier load balancing mode with an application firewall, in this embodiment, when at least one designated load balancing device does not interact with an external network, the cloud is adapted to configure a first load balancing virtual IP, and the at least one designated load balancing device is adapted to receive traffic data of a designated application through the first load balancing virtual IP. Accordingly, when the designated load balancing device needs to interact with an external network, a two-tier load balancing mode with an application firewall can be configured in response to user requests. Specifically, when at least one designated load balancing device interacts with an external network, the cloud is adapted to configure a first load balancing virtual IP, an application firewall, and a second load balancing virtual IP. The first load balancing virtual IP is adapted to receive traffic data and exchange data with the second load balancing virtual IP. The application firewall is adapted to filter and inspect data in the data exchange, and the at least one designated load balancing device is adapted to receive traffic data through the second load balancing virtual IP. In this embodiment, the first load balancing virtual IP is exposed to users of the designated application, while the second load balancing virtual IP and the application firewall are invisible to users, thereby preventing users from being aware of the situation, preventing network attacks, and enhancing security.

[0061] For multi-port allocation, the cloud in this embodiment allocates multiple ports from the first load balancing virtual IP address. Traffic data generated by different demanders using a specified application is sent to at least one designated load balancing device via the corresponding ports. In other words, in this embodiment, the cloud can configure multiple ports for a given application, all of which provide the same service. These ports enable source identification, precise traffic control and distribution, and phased releases for users of a given application, thereby optimizing the performance of the given application.

[0062] Document root redirection is applicable when the first load balancing virtual IP address only contains one port for receiving traffic data. For this scenario, the cloud side assigns at least one redirect load balancing device to each document root from among the designated load balancing devices. Subsequently, when traffic data sent by a designated application contains a document root in the URL address, the cloud side distributes the traffic data to the corresponding redirect load balancing device based on the document root, and has the redirect load balancing device process the traffic data.

[0063] The above has explained some of the functions of the cloud, and now we will explain the software architecture that implements the above functions on the cloud. Figure 8The cloud layer 21 includes a user interaction layer 211, a service management layer 212, a driver adaptation layer 213, and a device cluster 214. The user interaction layer 211 includes a user portal 2111 and a network administrator console 2112. It is understood that the user portal 2111 is user-oriented, while the network administrator console is cloud-based administrator-oriented, and is configured with different permissions to call corresponding functional modules in the service management layer 212. The service management layer 212 includes functional modules such as an SDN module 2121, a load balancing service module 2122, and other modules 2123. The SDN module 2121 includes a VPC submodule 21211, a functional domain submodule 21212, a subnet submodule 21213, and an IP management submodule 21214. It is understood that the VPC submodule 21211 is used to manage virtual private clouds, the functional domain submodule 21212 is used to manage functional domains, the subnet submodule 21213 is used to manage subnets, and the IP management submodule 21214 is used to allocate and reserve IP addresses. The load balancing service module 2122 includes a core submodule 21221, a policy configuration submodule 21222, and a dynamic configuration delivery submodule 21223. The core submodule 21221 provides users with load balancing application, modification, and revocation functions, interacts with the cloud infrastructure, manages unique load instances, and drives other modules to jointly complete load balancing services. The policy configuration submodule 21222 generates corresponding configuration information based on load balancing requests, and the dynamic configuration delivery submodule 21223 sends the configuration information to the corresponding module in the driver adaptation layer 213. Other modules 2123 include a certificate service submodule 21231, an application firewall service submodule 21232, and a device management center 21233. The certificate service submodule 21231 provides certificate-related services such as mounting and switching primary and backup certificates. The application firewall service submodule 21232 provides application firewall services, and the device management center 21233 manages the load balancing device 31. The driver adaptation layer 213 includes a load balancing driver module 2131 and an application firewall driver module 2132. The load balancing driver module 2131 is used to send driver information to the corresponding load balancing device 31, and the application firewall driver module 2132 is used to send driver information to the corresponding application firewall device 32. The device cluster 214 includes the load balancing devices 31 and application firewall devices 32 managed by the cloud 21.

[0064] In addition, the present application also proposes a computer-readable medium storing computer program code, which, when executed by a processor, implements the above-mentioned unified scheduling method 300 for multi-vendor load balancing devices executed in the cloud.

[0065] The basic concepts have been described above. It will be apparent to those skilled in the art that the above disclosures are merely examples and do not limit the present application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and revisions to the present application. Such modifications, improvements, and revisions are suggested in the present application and remain within the spirit and scope of the exemplary embodiments of the present application.

[0066] At the same time, this application uses specific terms to describe the embodiments of this application. For example, "one embodiment," "an embodiment," and / or "some embodiments" refer to a certain feature, structure, or characteristic related to at least one embodiment of this application. Therefore, it should be emphasized and noted that "one embodiment," "an embodiment," or "an alternative embodiment" mentioned twice or multiple times in different locations in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of this application may be appropriately combined.

[0067] Some aspects of the present application can be performed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The above hardware or software can be referred to as "data blocks", "modules", "engines", "units", "components" or "systems". The processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors or combinations thereof. In addition, various aspects of the present application may be expressed as computer products located in one or more computer-readable media, which include computer-readable program code. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, tapes...), optical disks (e.g., compact disks CDs, digital versatile disks DVDs...), smart cards, and flash memory devices (e.g., cards, sticks, key drives...).

[0068] A computer-readable medium may include a propagated data signal embodying computer program code, for example, in baseband or as part of a carrier wave. The propagated signal may be in a variety of forms, including electromagnetic, optical, etc., or a suitable combination thereof. A computer-readable medium may be any computer-readable medium other than a computer-readable storage medium that can be connected to an instruction execution system, apparatus, or device to communicate, propagate, or transmit the program for use. The program code on the computer-readable medium may be transmitted via any suitable medium, including radio, cable, fiber optic cable, radio frequency signal, or similar medium, or any combination of the above.

[0069] Similarly, it should be noted that, in order to simplify the description of this application and thus facilitate understanding of one or more embodiments of the application, the foregoing description of the embodiments of this application sometimes combines multiple features into a single embodiment, figure, or description thereof. However, this disclosure method does not mean that the subject matter of this application requires more features than those recited in the claims. In fact, the features of an embodiment may be fewer than all the features of the individual embodiments disclosed above.

[0070] Although the present application has been described with reference to the current specific embodiments, ordinary technicians in this technical field should recognize that the above embodiments are only used to illustrate the present application, and various equivalent changes or substitutions can be made without departing from the spirit of the present application. Therefore, as long as the changes and modifications to the above embodiments are within the scope of the essential spirit of the present application, they will fall within the scope of the claims of the present application.

Claims

1. A unified scheduling system for multi-vendor load balancing equipment, characterized in that: The system includes: a terminal, a cloud, and multiple load balancing devices; The terminal is used to respond to the user's load balancing application operation for the specified application and send a load balancing request to the cloud; The cloud is used to receive the load balancing request, and allocate and configure at least one designated load balancing device from the multiple load balancing devices for the load balancing request, wherein the at least one designated load balancing device is used to provide services for the designated application; When the at least one designated load balancing device does not interact with an external network, the cloud is adapted to configure a first load balancing virtual IP, and the at least one designated load balancing device is adapted to receive traffic data of the designated application through the first load balancing virtual IP; When the at least one designated load balancing device interacts with an external network, the cloud is suitable for configuring the first load balancing virtual IP, the application firewall and the second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving the traffic data and interacting with the second load balancing virtual IP, the application firewall is suitable for filtering and inspecting the data in the data interaction, and the at least one designated load balancing device is suitable for receiving the traffic data through the second load balancing virtual IP.

2. The unified scheduling system for multi-vendor load balancing devices according to claim 1, characterized in that: The cloud is specifically used for: Generate a unique load instance corresponding to the specified application according to the load balancing request, wherein the unique load instance includes various configuration information generated according to the load balancing request; Selecting at least one load balancing device to be configured from the multiple load balancing devices according to the unique load instance; The configuration information is delivered to the selected at least one load balancing device to be configured to obtain the at least one designated load balancing device.

3. The unified scheduling system for multi-vendor load balancing devices according to claim 2, characterized in that: The cloud comprises at least one virtual private cloud, the virtual private cloud is bound to at least one functional domain, each functional domain corresponds to a business requirement, and the functional domain comprises at least one IP address segment; Each of the virtual private clouds further comprises at least one subnet, wherein the network segment of the subnet is allocated from the functional domain of the corresponding virtual private cloud; The configuration information includes the first load balancing virtual IP address. When the cloud generates the first load balancing virtual IP address according to the load balancing request, the cloud is specifically configured to: Determining the service requirement corresponding to the load balancing request; Allocate an IP from one of the subnets corresponding to the service demand as the first load balancing virtual IP.

4. The unified scheduling system for multi-vendor load balancing devices according to claim 3, characterized in that: Each of the virtual private clouds further corresponds to at least one load balancing device, and each load balancing device corresponds to one of the functional domains. When the cloud selects at least one load balancing device to be configured from the multiple load balancing devices according to the unique load instance, the cloud is specifically configured to: Determining the virtual private cloud and the functional domain corresponding to the unique load instance; Each of the load balancing devices corresponding to the functional domain in the virtual private cloud is used as the load balancing device to be configured.

5. The unified scheduling system for multi-vendor load balancing devices according to claim 3, characterized in that: The cloud is further configured to: reserve unassigned IP addresses of the subnet as reserved IP addresses; The load balancing request includes the reserved IP specified by the user.

6. The unified scheduling system for multi-vendor load balancing devices according to claim 3, characterized in that: The cloud is also used to allocate multiple ports from the first load balancing virtual IP, and the traffic data generated by different demand parties using the designated application is sent to the at least one designated load balancing device through the corresponding ports.

7. The unified scheduling system for multi-vendor load balancing devices according to claim 1, characterized in that: When the load balancing request includes an SSL offload domain name and a primary domain name selected by the user, the cloud is further configured to: Generate and bind a primary certificate and a backup certificate for the primary domain name, and deploy the primary certificate and the backup certificate to the at least one designated load balancing device, wherein when the primary certificate is not expired, the at least one designated load balancing device adopts the primary certificate, and when the primary certificate is expired, the at least one designated load balancing device adopts the backup certificate.

8. The unified scheduling system for multi-vendor load balancing devices according to claim 1, characterized in that: When the load balancing request includes a context jump, and the first load balancing virtual IP includes only one port for receiving the traffic data, the cloud is further configured to: A corresponding jump load balancing device is configured for each document root of the URL address in the traffic data from the at least one designated load balancing device, and after the port receives the traffic data, the traffic data is sent to the jump load balancing device corresponding to the document root.

9. A unified scheduling method for multi-vendor load balancing equipment, characterized in that: Applicable to terminals, including: In response to a user's load balancing application request for a specified application, the user obtains system configuration information and load balancing port configuration information for the specified application; Generate a load balancing request according to the system configuration information and the load balancing port configuration information; Sending the load balancing request to the cloud to obtain at least one designated load balancing device corresponding to the designated application, wherein the at least one designated load balancing device is used to provide services for the designated application, Wherein, when the at least one designated load balancing device does not interact with an external network, the cloud is adapted to configure a first load balancing virtual IP, and the at least one designated load balancing device is adapted to receive traffic data of the designated application through the first load balancing virtual IP; When the at least one designated load balancing device interacts with an external network, the cloud is suitable for configuring the first load balancing virtual IP, the application firewall and the second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving the traffic data and interacting with the second load balancing virtual IP, the application firewall is suitable for filtering and inspecting the data in the data interaction, and the at least one designated load balancing device is suitable for receiving the traffic data through the second load balancing virtual IP.

10. A unified scheduling method for multi-vendor load balancing equipment, characterized in that: Available in the cloud, including: Receiving a load balancing request sent by a terminal, wherein the load balancing request is generated according to a user's load balancing application operation on the terminal; Allocate and configure at least one designated load balancing device for the load balancing request from a plurality of load balancing devices, wherein the at least one designated load balancing device is used to provide services for the designated application. Wherein, when the at least one designated load balancing device does not interact with an external network, the cloud is adapted to configure a first load balancing virtual IP, and the at least one designated load balancing device is adapted to receive traffic data of the designated application through the first load balancing virtual IP; When the at least one designated load balancing device interacts with an external network, the cloud is suitable for configuring the first load balancing virtual IP, the application firewall and the second load balancing virtual IP, the first load balancing virtual IP is suitable for receiving the traffic data and interacting with the second load balancing virtual IP, the application firewall is suitable for filtering and inspecting the data in the data interaction, and the at least one designated load balancing device is suitable for receiving the traffic data through the second load balancing virtual IP.

11. The unified scheduling method for multi-vendor load balancing devices according to claim 10, characterized in that: Allocating and configuring at least one designated load balancing device for the load balancing request from a plurality of load balancing devices includes: Generate a unique load instance corresponding to the specified application according to the load balancing request, wherein the unique load instance includes various configuration information generated according to the load balancing request; Selecting at least one load balancing device to be configured from the multiple load balancing devices according to the unique load instance; The configuration information is delivered to the selected at least one load balancing device to be configured to obtain the at least one designated load balancing device.

12. The unified scheduling method for multi-vendor load balancing devices according to claim 11, characterized in that: The cloud comprises at least one virtual private cloud, the virtual private cloud is bound to at least one functional domain, each functional domain corresponds to a business requirement, and the functional domain comprises at least one IP address segment; Each of the virtual private clouds further comprises at least one subnet, wherein the network segment of the subnet is allocated from the functional domain of the corresponding virtual private cloud; The configuration information includes the first load balancing virtual IP, and generating the first load balancing virtual IP according to the load balancing request further includes: Determining the service requirement corresponding to the load balancing request; Allocate an IP from one of the subnets corresponding to the service demand as the first load balancing virtual IP.

13. The unified scheduling method for multi-vendor load balancing devices according to claim 12, characterized in that: Each of the virtual private clouds further corresponds to at least one load balancing device, each of the load balancing devices corresponds to one of the functional domains, and selecting at least one load balancing device to be configured from the multiple load balancing devices according to the unique load instance further includes: Determining the virtual private cloud and the functional domain corresponding to the unique load instance; Each of the load balancing devices corresponding to the functional domain in the virtual private cloud is used as the load balancing device to be configured.

14. The unified scheduling method for multi-vendor load balancing devices according to claim 12, wherein: Also includes: Multiple ports are allocated from the first load balancing virtual IP, and the traffic data generated by different demand parties using the designated application is sent to the at least one designated load balancing device through the corresponding ports.

15. The unified scheduling method for multi-vendor load balancing devices according to claim 10, characterized in that: When the load balancing request includes a context jump, and the first load balancing virtual IP includes only one port for receiving the traffic data, the method further includes: A corresponding jump load balancing device is configured for each document root of the URL address in the traffic data from the at least one designated load balancing device, and after the port receives the traffic data, the traffic data is sent to the jump load balancing device corresponding to the document root.

16. A computer-readable medium storing computer program code, wherein when executed by a processor, the computer program code implements the unified scheduling method for multi-vendor load balancing devices according to any one of claims 9 to 15.