WO2024056042A1 - 一种负载均衡处理方法、装置、存储介质及电子装置 - Google Patents

一种负载均衡处理方法、装置、存储介质及电子装置 Download PDF

Info

Publication number
WO2024056042A1
WO2024056042A1 PCT/CN2023/118931 CN2023118931W WO2024056042A1 WO 2024056042 A1 WO2024056042 A1 WO 2024056042A1 CN 2023118931 W CN2023118931 W CN 2023118931W WO 2024056042 A1 WO2024056042 A1 WO 2024056042A1
Authority
WO
WIPO (PCT)
Prior art keywords
load balancing
service provider
information
instance
reconfigured
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2023/118931
Other languages
English (en)
French (fr)
Inventor
倪进权
刘学生
徐代刚
孟照星
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to EP23864772.1A priority Critical patent/EP4572288A4/en
Publication of WO2024056042A1 publication Critical patent/WO2024056042A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1017—Server selection for load balancing based on a round robin mechanism
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs

Definitions

  • Embodiments of the present disclosure relate to the field of distributed systems, and specifically, to a load balancing processing method, device, storage medium and electronic device.
  • microservices In order to solve the pain points of traditional monolithic applications, microservices have become an important definition of cloud native. At the same time, more and more companies in the industry have adopted microservice architecture, such as Amazon, eBay and NetFlix, and their scale has also experienced explosive growth. . According to relevant industry trend reports, microservices have entered a mature stage and are widely adopted as a mainstream architecture. Microservice architecture and its scale growth also bring a series of challenges, such as client-to-microservice application access communication that needs to meet increasing governance requirements. As the preferred Application Programming Interface (API) gateway, it can transfer functionality from individual microservices to the gateway, thereby simplifying the implementation of each microservice by integrating cross-domain issues into a single layer.
  • API Application Programming Interface
  • API gateways provide several functions such as load balancing, authentication and authorization, rate limiting, logging and tracking.
  • Load balancing is a very critical part of the high-availability design of distributed systems. One of the characteristics of a distributed system is to support rapid expansion. After the cluster is expanded, how to dispatch network requests to one or more nodes in the cluster depends on the load balancing strategy. Load balancing is very critical in handling high concurrency, easing network pressure, and supporting capacity expansion. Different load balancing strategies can be selected in different application scenarios.
  • API gateway load balancing strategies there are two main types of traditional API gateway load balancing strategies: one is polling strategy, weighted polling, random strategy, and hash strategy; the other is minimum response time and minimum number of concurrency strategies; the first four The first one belongs to the independent algorithm class. They do not depend on the actual status and real processing situation of the back-end service instance. The latter two need to decide the final strategy implementation based on the real processing situation of the back-end service instance, but the data relied on here is The API gateway itself collects statistics, and the statistics can only be obtained after the back-end service instance has completed the request response.
  • the algorithm of the first strategy is theoretical and cannot adapt to the complexity and dynamics of microservice architecture.
  • traditional load balancing strategies such as polling and weighting assume that the processing performance of each node is fixed.
  • this premise is not practical in scenarios where expansion and contraction occur at any time and the resources used by microservices are subject to change and competition. It is already difficult to establish, which makes these "strategies” unable to achieve "equilibrium” in the true sense.
  • the second type of strategy only determines the load balancing strategy based on the API gateway's own information.
  • This technical solution has shortcomings such as post-event adjustment and insufficient timeliness.
  • some common strategies for selecting load nodes based on response time and response code although relatively accurate, have shortcomings such as post-event adjustment, insufficient timeliness, and single dimension.
  • Embodiments of the present disclosure provide a load balancing processing method, device, storage medium and electronic device to at least solve the problems in related technologies that the traditional API gateway load balancing strategy only relies on the API gateway itself to collect data, which is inflexible and timely.
  • a load balancing processing method which method includes:
  • a target service provider instance is determined based on the pre-stored application performance management APM full information and the reconfigured load balancing policy, where the target service provider instance is To process the business request;
  • the target service provider instance is determined according to the configured load balancing policy.
  • a load balancing processing device includes:
  • the receiving module is configured to receive business requests from service consumers
  • a judgment module configured to obtain performance statistical information of the application programming interface API gateway, and judge whether the API gateway meets the loading conditions of the reconfigured load balancing policy based on the performance statistical information;
  • the first load balancing module is configured to determine the target service provider instance based on the pre-stored full amount of application performance management APM information and the reconfigured load balancing policy when the API gateway satisfies the loading condition, wherein, The target service provider instance is used to process the service request;
  • the second load balancing module is configured to determine the target service provider instance according to the configured load balancing policy when the API gateway does not meet the loading condition.
  • a load balancing processing system is also provided, and the system includes:
  • the API gateway is configured to receive business requests from service consumers, obtain performance statistics of the application programming interface API gateway, and determine whether the API gateway meets the loading conditions of the reconfigured load balancing policy based on the performance statistics;
  • An intelligent load balancer configured to determine the target service provider instance based on the pre-stored full amount of application performance management APM information and the reconfigured load balancing policy when the API gateway satisfies the loading condition, wherein: The target service provider instance is used to process the service request;
  • the API gateway is also configured to determine the target service provider instance according to the configured load balancing policy when the API gateway does not meet the loading condition.
  • a computer-readable storage medium is also provided.
  • a computer program is stored in the storage medium, wherein the computer program executes any of the above method embodiments when run by a processor. steps in.
  • an electronic device including a memory and a processor.
  • a computer program is stored in the memory, and the processor is configured to run the computer program to perform any of the above. Steps in method embodiments.
  • Figure 1 is a hardware structural block diagram of a load balancing processing method according to an embodiment of the present disclosure
  • Figure 2 is a flow chart of a load balancing processing method according to an embodiment of the present disclosure
  • FIG. 3 is a structural block diagram of a load balancing processing system according to another embodiment of the present disclosure.
  • Figure 4 is a flow chart of a load balancing processing method according to another embodiment of the present disclosure.
  • Figure 5 is a flow chart of a load balancing method based on node IO in an embodiment of the present disclosure
  • Figure 6 is a flow chart of a load balancing method according to another embodiment of the present disclosure.
  • FIG. 7 is a block diagram of a load balancing processing device according to an embodiment of the present disclosure.
  • Figure 8 is a structural block diagram of an API gateway independently performing load balancing in an embodiment of the present disclosure
  • Figure 9 is a structural block diagram of an API gateway and an intelligent load balancer jointly performing load balancing in an embodiment of the present disclosure
  • Figure 10 is a schematic diagram of the gateway control plane UI in an embodiment of the present disclosure.
  • Figure 1 is a hardware structural block diagram of a load balancing processing method according to an embodiment of the present disclosure.
  • the hardware single board may include one or more (only one is shown in Figure 1)
  • the processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 configured to store data, wherein the above-mentioned mobile terminal may also include a transmission device configured to have a communication function.
  • device 106 and input and output devices 108 are examples of a communication function.
  • the structure shown in Figure 1 is only illustrative, and it does not limit the structure of the above-mentioned mobile terminal.
  • the mobile terminal may also include more or fewer components than shown in FIG. 1 , or have a different configuration than shown in FIG. 1 .
  • the memory 104 may be configured to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the load balancing processing method in the embodiment of the present disclosure.
  • the processor 102 runs the computer program stored in the memory 104, thereby Execute various functional applications and load balancing processing, that is, implement the above method.
  • Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
  • the memory 104 may further include memory located remotely relative to the processor 102, and these remote memories may be connected to the mobile terminal through a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.
  • the transmission device 106 is arranged to receive or send data via a network.
  • Specific examples of the above-mentioned network may include wireless networks provided by communication providers.
  • the transmission device 106 includes a network adapter (Network Interface Controller, NIC for short), which can be connected to other network devices through a base station to communicate with the Internet.
  • the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is configured to communicate with the Internet wirelessly.
  • NIC Network Interface Controller
  • FIG. 2 is a flow chart of a load balancing processing method according to an embodiment of the present disclosure. As shown in Figure 2, the process includes the following steps:
  • Step S202 receive a service request from a service consumer
  • Step S204 obtain the performance statistical information of the application programming interface API gateway, and determine whether the API gateway meets the loading conditions of the reconfigured load balancing policy based on the performance statistical information;
  • Step S206 If the API gateway satisfies the loading condition, determine the target service provider instance based on the pre-stored application performance management APM full information and the reconfigured load balancing policy, where the target service provider instance is used to process all Describe business requests;
  • Step S208 If the API gateway does not meet the loading condition, determine the target service provider instance according to the configured load balancing policy.
  • the service consumer in step S202 is the service request initiator, which usually refers to the application client.
  • the above step S204 may specifically include: determining whether the performance statistical information is less than a preset performance statistical information threshold, wherein the performance statistical information includes at least one of the following: gateway forwarding error rate, gateway CPU Occupancy rate, gateway memory occupancy rate; when the performance statistics information is less than the performance statistics information threshold, it is determined that the API gateway meets the loading condition; when the performance statistics information is greater than or equal to the performance statistics information In the case of a threshold, it is determined that the API gateway does not meet the loading condition.
  • the API gateway can be configured in advance through the gateway control plane UI.
  • the loading condition is set to the Central Processing Unit (Central Processing Unit, referred to as CPU) CPU usage is less than 70%, and the performance of the API gateway is prioritized. Then load the reconfigured load balancing policy. If the API gateway resources are insufficient, forcibly loading the reconfigured load balancing policy will lead to reduced overall performance, such as longer request response times.
  • CPU Central Processing Unit
  • the reconfigured load balancing policy in the above step S204 is an abstract load balancing policy, which is also the expected behavior of the system, and is used to represent the user's expectations for the load balancing processing results.
  • the reconfigured load balancing strategy is set based on the operation information collected and counted by the Application Performance Management (APM) system.
  • the dimensions of the operation information include: events, performance, indicators, and call chains.
  • the reconfigured load balancing strategy can be configured based on any operating information collected by the APM system. For example, if users are more concerned about business response speed, they can consider load balancing based on node bandwidth and service response delay.
  • reconfigured load balancing strategies include but are not limited to the following strategies:
  • Load balancing is performed based on the number of restarted applications on the node where the service provider instance is located;
  • Load balancing is performed based on the input and output IO of the node where the service provider instance is located;
  • the reconfigured load balancing policy can be set to different policy levels.
  • the corresponding lower-level policy will be automatically displayed for the user to select. For example, if you select load balancing based on the dynamic processing capability of the service provider instance, options for measuring the processing capability of the service provider instance will pop up, such as the processing time of a single request (dynamic processing capability), the processing success rate of multiple requests, and service The number of application restarts for the provider instance, etc.
  • step S206 may specifically include the following steps:
  • Step S2062 Determine one or more service providers according to the service request, where each service provider is configured with at least one service provider instance;
  • Step S2064 Filter out the target service running information corresponding to the reconfigured load balancing policy and service provider from all APM information;
  • Step S2066 Generate a service provider instance pool based on the reconfigured load balancing policy and target service running information
  • Step S2068 Determine the target service provider instance from the service provider instance pool according to the configured load balancing policy.
  • the service provider in the above step S2062 is the business request processor, which usually refers to the application server.
  • each service provider may have multiple copies with business processing capabilities. That is, a service provider instance.
  • step S2066 may specifically include:
  • all service provider instances that satisfy each reconfigured load balancing strategy are selected according to the target service running information to form a service provider sub-instance pool;
  • the set mixed relationship processes multiple service provider sub-instance pools to obtain a service provider instance pool, where the mixed relationship includes one of the following: AND, OR, NOT.
  • the mixed relationship is AND, which means that the service provider instance needs to satisfy multiple reconfigured load balancing at the same time; the mixed relationship is OR, which means that the service provider instance only needs to satisfy any one of the reconfigured load balancing; the mixed relationship is No, indicating that service provider instances that satisfy any reconfigured load balancing need to be eliminated.
  • the policy relationship can also be set to non or regular.
  • Non means excluding all service provider instances that meet the reconfigured load balancing policy
  • regular means a string Matching mode, as long as the target service running information contains the specific parameters set in the reconfigured load balancing policy, it is deemed to satisfy the load balancing policy.
  • the entire process of running the load balancing processing method also includes obtaining and storing the APM full information from the APM system through an interface that conforms to the preset specifications, wherein the APM full information includes the APM full information collected by the APM system. And collect statistics on the running information of all service provider instances.
  • the preset specification is the OpenTelemetry specification.
  • HTTP HyperText Transfer Protocol
  • TCP Transmission Control Protocol
  • step S208 may specifically include the following steps:
  • Step S2082 Determine one or more service providers according to the service request, where each service provider is configured There is at least one service provider instance configured;
  • Step S2084 Obtain the service running information corresponding to the service provider instance collected by the API gateway;
  • Step S2086 Determine the target service provider instance according to the service running information and the configured load balancing strategy, where the configured load balancing strategy includes: polling strategy, weighted polling strategy, random strategy, Hash strategy, minimum response time strategy, minimum concurrency strategy.
  • the configured load balancing strategy is a traditional load balancing strategy. Specifically, the polling strategy allocates each request to different service provider instances one by one in chronological order; the weighted polling strategy is based on the set weight. Distribution, the weight is proportional to the access rate of business requests; the hash strategy assigns each request according to the hash result of the access IP, and business requests from the same IP will be assigned to a fixed service provider instance; the minimum response time strategy is Prioritize allocation to the service provider instance with the shortest response time.
  • the problem that the traditional API gateway load balancing strategy in related technologies only relies on the API gateway itself to collect data, which is not flexible enough and has poor timeliness, can be solved.
  • the loading conditions of the load balancing strategy prioritize the performance of the API gateway and enrich the data dimensions available to the API gateway through the APM system, thereby providing more load balancing strategies that are more in line with the actual operation of the service.
  • FIG. 3 is a structural block diagram of a load balancing processing system according to another embodiment of the present disclosure. As shown in Figure 3, the load balancing processing system includes the following structure:
  • API gateway 301 is configured to receive business requests from service consumers, obtain performance statistics of the application programming interface API gateway, and determine whether the API gateway meets the loading conditions of the reconfigured load balancing policy based on the performance statistics. ;
  • the intelligent load balancer 302 is configured to determine the target service provider instance based on the pre-stored full application performance management APM information and the reconfigured load balancing policy when the API gateway satisfies the loading condition, wherein, The target service provider instance is used to process the service request;
  • the API gateway 301 is also configured to determine the target service provider instance according to the configured load balancing policy when the API gateway does not meet the loading condition.
  • the loading condition of the reconfigured load balancing policy is the calling condition of the intelligent load balancer 302, and a pluggable coupling connection is used between the intelligent load balancer 302 and the API gateway 301.
  • the load balancing processing system also includes a gateway control plane UI, which is configured to receive the desired abstract load balancing policy/behavior set by the user and provide it to the entire system.
  • a gateway control plane UI which is configured to receive the desired abstract load balancing policy/behavior set by the user and provide it to the entire system.
  • Various load balancing strategies include load balancing based on business indicators and load balancing based on the dynamic processing capabilities of service instances.
  • the gateway control plane UI can add reconfigured load balancing strategies based on the configured load balancing strategies (polling, weight, hash, random). After each load balancing strategy is selected, a submenu will pop up, and the relevant indicator values can be set in the submenu. For example, specific bit/s can be set in the submenu of load balancing based on node bandwidth, and service custom business indicator items can be filled in in the submenu of load balancing based on the service provider instance's business indicator capabilities. When the relevant indicators of the node where the service provider instance is located or the service itself are lower than the threshold set above, the service instance will be removed from the available load balancing service instance pool.
  • the gateway control plane UI is also set to set the policy relationship (non, regular) and mixed relationship of the reconfigured load balancing policy. Relation (and, or, not).
  • the intelligent load balancer 302 specifically includes:
  • the information docking unit is configured to obtain service operation information from the cloud native APM;
  • the database is set to store the operating information obtained by the information docking unit
  • the information processing and policy calculation unit is configured to filter out the target service running information from the database according to the reconfigured load balancing policy
  • the policy generation unit is configured to determine the service provider instance pool based on the target service running information.
  • the information docking unit is an agent component that docks with the APM system through a standard protocol to collect operating information such as distributed call chain data.
  • the information collected by the APM system includes events, performance, indicators, call chain and other dimensions, such as CPU, IO, memory usage information, etc., as well as information that can reflect the service business processing capabilities (processing time, error rate, number of restarts, etc.).
  • the information processing and policy calculation unit may be specifically configured to filter out the target service operation information corresponding to the reconfigured load balancing policy and the service provider from the full amount of APM information.
  • the policy generation unit may be specifically configured to filter out all services that satisfy the reconfigured load balancing policy based on the target service running information when a reconfigured load balancing policy is set in advance.
  • Provider instances form a service provider instance pool; when multiple reconfigured load balancing strategies are set in advance, all service provider instances that satisfy each reconfigured load balancing strategy are filtered out based on the target service running information.
  • Form a service provider sub-instance pool process multiple service provider sub-instance pools according to a preset mixed relationship to obtain a service provider instance pool, wherein the mixed relationship includes one of the following: AND, OR, NOT .
  • the API gateway 301 is also configured to determine the target service provider instance according to the configured load balancing policy when the service provider instance pool contains multiple service provider instances.
  • the API gateway 301 is also configured to forward the service request to the target service provider instance after determining the target service provider instance; when the target service provider instance responds to the service request Finally, return the service request response to the service consumer.
  • FIG. 4 is a flow chart of a load balancing processing method according to another embodiment of the present disclosure, which is applied to the above load balancing processing system. As shown in Figure 4, the load balancing processing method specifically includes the following steps:
  • Step S401 The system obtains the desired abstract load balancing policy/behavior through the UI/interface;
  • Step S402 The information docking unit obtains various information by docking with the APM.
  • the docking process uses standard protocols, usually HTTP/TCP protocols, but must comply with the OpenTelemetry specification;
  • Step S403 The API gateway decides whether to execute the plug-in intelligent load balancer based on the static configuration of the API gateway and its own performance statistics;
  • Step S404 Filter valid information according to the user's desired behavior (reconfigured load balancing policy), calculate the specific load balancing policy, and generate an available service provider instance pool;
  • Step S405 In the process of forwarding the request to the service provider, the API gateway continues to implement the traditional load balancing strategy (configured load balancing strategy) and selects a specific target service provider instance to send the request.
  • the traditional load balancing strategy configured load balancing strategy
  • the gateway control plane UI provides the option of setting different abstract load balancing strategies for different services, such as load balancing based on the CPU occupancy of the service provider instance, input and output based on the node where the service provider is located.
  • Output) IO for load balancing, load balancing based on service business indicators, and dynamic processing capabilities based on service instances. Efforts are made to carry out various load balancing strategies such as load balancing.
  • the system control plane UI will pop up options used to measure the service instance's processing capabilities, such as the processing time of a single request (dynamic processing capability), the processing time of multiple requests Processing success rate, service instance application restart times, etc., through further selection, the true behavioral expectations of the system can be clearly described.
  • step S402 of this embodiment because the APM system has a unified OpenTelemetry specification, the docking can be completed in accordance with the standard. At the same time, because the APM has completed the interaction and data collection of all applications, the intelligent load balancer can use this to implement the application itself.
  • the real state decoupling eliminates the need to interact with large-scale applications one by one and count their runtime data, which greatly reduces the implementation load of the intelligent balancing loader and greatly improves robustness.
  • step S403 may specifically include that after the actual service request reaches the API gateway, the API gateway will first collect the resource occupancy of the gateway itself, including the gateway forwarding error rate, gateway CPU memory occupancy, and gateway memory occupancy. , determine whether the current gateway resource occupancy can support the continued invocation of the intelligent load balancer to implement the enhanced load balancing strategy.
  • the calling condition can be configured on the API gateway through the gateway control plane UI (for example, set to CPU usage less than 70% threshold). If it is judged that the API gateway resources are insufficient (that is, the CPU usage is greater than or equal to 70%), then jump Through the intelligent load balancer, jump directly to step S405, and use the traditional and simple load balancing strategy that comes with the API gateway for forwarding. Otherwise, continue to step S404.
  • the gateway control plane UI for example, set to CPU usage less than 70% threshold.
  • step S404 may specifically include the information processing and policy calculation unit obtaining and filtering out valid relevant information from the database according to the reconfigured load balancing policy (system expected behavior) by the intelligent balancing loader, assuming that the system expects The behavior is based on the bandwidth load of the node where the service instance is located (that is, the service instance with a higher real-time bandwidth of the node is preferred to forward the request, which can improve the business response speed).
  • the information processing and policy calculation unit will based on the service instance information. , filter out from the full amount of information: the corresponding information between service provider instances and nodes, and node real-time bandwidth statistics.
  • the policy generation unit generates an available service instance pool (which contains one or more alternative service instances) based on the filtered information, and returns the service instance pool to the API gateway.
  • step S405 may specifically include returning the actual business request to the API gateway, and in the process of forwarding the request to the service provider, in the available service instance pool, implementing the traditional and simple Load balancing strategy (configured load balancing strategy), selects a specific target service provider instance to send the request, and returns the request response to the client after the service provider responds to the request.
  • traditional and simple Load balancing strategy configured load balancing strategy
  • the configured load balancing policies include: polling policy, weighted polling policy, random policy, hashing policy, minimum response time policy, and minimum concurrency policy.
  • the functional richness and intelligence of the cloud native API gateway under the microservice architecture can be enhanced, the load balancing strategy of the gateway can be enhanced, and large-scale complex systems can be solved. Energy saving, consumption reduction, operation and maintenance and other issues.
  • FIG. 5 is a flow chart of a load balancing method based on node IO in an embodiment of the present disclosure.
  • This method is applied to a network management system deployed on a PaaS platform. Due to the tight resources in the on-site environment, a unified deployment of control nodes and computing nodes is used. , a large number of business applications and platform applications are deployed on these nodes, and resource grabbing (such as disk IO) often occurs, and access to a certain microservice often encounters lags or even failures. When encountering these When a problem occurs, the service provider finds through locating that the problem only occurs on one of the nodes. In addition, the service provider instance on the node is working normally. Therefore, the user's expected behavior is to adjust the load balancing strategy based on the node IO situation.
  • the load balancing processing method specifically includes the following steps:
  • Step S501 set the target service-related information through the UI/interface, and the reconfigured load balancing policy is set to "Load balancing based on node IO", specifying to exclude the number of read and write operations per second (Input/Output Operations Per Second, Instances on nodes (referred to as IOPS) less than 1K;
  • Step S502 The intelligent load balancer connects to the APM through a standard protocol to obtain various information
  • Step S503 The service consumer/client initiates an actual service request
  • Step S504 The API gateway dynamically calls the intelligent load balancer.
  • the intelligent load balancer filters the effective information and calculates the specific load balancing strategy according to the expected behavior of the system (abstract load balancing strategy);
  • Step S505 The API gateway further selects a specific service provider instance to send the request according to the configured load balancing policy (traditional load balancing policy) from the available service provider instance pool.
  • the configured load balancing policy traditional load balancing policy
  • step S501 may specifically include the following steps:
  • Step S5011 fill in the address information of the target service provider (corresponding to multiple service provider instances) through the gateway control plane UI;
  • Step S5012 the reconfigured load balancing policy is set to "load balancing based on node IO";
  • Step S5013 in the submenu, the load balancing policy related indicators are set to "Exclude when IOPS ⁇ 1k".
  • step S502 may specifically include the following steps:
  • Step S5021 configure the APM system address information according to the gateway control plane UI, or the operation and maintenance personnel configure the third-party APM system address information through the gateway control plane UI;
  • Step S5022 The information docking unit reads the APM service information using the standard protocol (HTTP) through periodic querying (for example, querying once every 10 seconds), calls the APM standard interface (that is, the interface that complies with the standard specification OpenTelemetry in the APM field), and obtains All operation and maintenance information.
  • HTTP standard protocol
  • APM standard interface that is, the interface that complies with the standard specification OpenTelemetry in the APM field
  • the docking unit can select different methods such as periodic acquisition, dynamic monitoring of changes, publishing/subscription, etc. to complete the full information acquisition according to the actual application scenario.
  • Step S5023 The information docking unit stores all the obtained information in the database for use by the information processing and policy generation unit of the intelligent load balancer that may be called later.
  • the information collected by the APM system includes events, performance, indicators, call chain and other dimensions, such as CPU, IO, memory usage information, etc., as well as information that can reflect the service business processing capabilities (processing time, error rate, number of restarts, etc.).
  • step S504 may specifically include the following steps:
  • Step S5041 the specific service request reaches the API gateway
  • Step S5042 The API gateway decides whether to continue calling the intelligent load balancing server based on the gateway's own performance statistics. For example, when it is found that the memory usage of the gateway itself is too high (>90%), the intelligent load balancer will no longer be loaded and the system will jump to step S505 to use the traditional load balancing strategy. If all indicators of the API gateway do not exceed the standard, load the intelligent load balancer and jump to step S5043 to continue processing.
  • Step S5043 The intelligent load balancer filters valid information from the database containing all APM information based on the service provider instance list information, and first obtains the service provider instance list and node corresponding information.
  • Step S5044 The intelligent load balancer continues to obtain node information from the database that stores full APM information based on the reset load balancing policy, filters out relevant node operation and maintenance information, and further obtains the IOPS indicators of these nodes.
  • Step S5045 The intelligent load balancer finds the nodes that need to be excluded based on the detailed information of the reconfigured load balancing policy (exclude when IOPS ⁇ 1k), and further converts them into a corresponding list of excluded instances.
  • the service provider instances include A ⁇ B ⁇ C, and the node where C is located has an IOPS of 0.5K, so the excluded instance list contains C.
  • Step S5046 the intelligent load balancer puts all service provider instances into the service provider instance pool, and returns the result according to step S5045, removes the C instance from the available service instance pool (forward selection can also be used), and generates available services.
  • Provider instance pool (A ⁇ B).
  • Step S5047 Return the output result of step S5046 to the API gateway.
  • step S505 may specifically include the following steps:
  • Step S5051 the API gateway continues the business request forwarding process, selects a specific target service provider instance from the available service instance pool, and forwards the request to the instance for processing;
  • Step S5052 After receiving the business request, the selected target service provider instance completes the processing and sends a response to the API gateway, and the gateway sends the response back to the client (the initiator of the business request).
  • Figure 6 is a flow chart of a load balancing method according to another embodiment of the present disclosure. It provides a flow chart of a load balancing method based on node bandwidth and service response delay. This method is applied to use business response speed as a The first consideration is the scenario, and resources are relatively sufficient. Therefore, the service provider instance with the smallest average delay of historical processing requests and the largest current node bandwidth is given priority as the first choice for load balancing to ensure that the business can be processed as quickly as possible. Speed response.
  • the load balancing processing method in this embodiment specifically includes the following steps:
  • Step S601 the reconfigured load balancing policy is set to "load balancing based on node bandwidth” and “load balancing based on service response delay”;
  • Step S602 The intelligent load balancer connects to the APM through a standard protocol to obtain various information
  • Step S603 The service consumer/client initiates an actual service request
  • Step S604 The API gateway dynamically calls the intelligent load balancer.
  • the intelligent load balancer filters the effective information and calculates the specific load balancing strategy according to the expected behavior of the system (abstract load balancing strategy);
  • Step S605 The API gateway further selects a specific service provider instance to send the request according to the configured load balancing policy (traditional load balancing policy) from the available service provider instance pool.
  • the configured load balancing policy traditional load balancing policy
  • step S601 may specifically include the following steps:
  • Step S6011 Fill in the address information of the target service through the gateway control plane UI;
  • Step S6012 the first load balancing policy is set to "load balancing based on node bandwidth"
  • Step S6013 in the submenu, the load balancing policy-related policy is set to: "node with the largest bandwidth";
  • Step S6014 the second load balancing policy is set to "load balancing based on service response delay"
  • Step S6015 in the submenu, the load balancing policy-related policy is set to: "Service instance with the smallest delay";
  • step S6016 the reconfigured load balancing policy is set to a mixed policy of the two policy relationships in steps S6012 and S6014, and the mixed relationship is "AND".
  • steps S6011 to S6016 the richness of load balancing can be greatly improved to meet the diversity of needs.
  • more load balancing strategies can be mixed, and the mixing methods are also diverse (including AND, OR, NOT, regular, etc.).
  • Step S6021 configure the APM system address information according to the gateway control plane UI, or the operation and maintenance personnel configure the third-party APM system address information through the gateway control plane UI;
  • Step S6022 The information docking unit of the intelligent load balancer reads the APM service information using the standard protocol (HTTP) through periodic query (for example, query once every minute), and calls the APM standard interface (that is, OpenTelemetry, which complies with the standard specification in the APM field). interface) to obtain all operation and maintenance information;
  • HTTP standard protocol
  • APM standard interface that is, OpenTelemetry, which complies with the standard specification in the APM field). interface
  • the intelligent load balancer-information docking unit can select different methods such as periodic acquisition, dynamic monitoring of changes, and publish/subscribe to complete the full information acquisition according to the actual application scenario.
  • Step S6023 The intelligent load balancer-information docking unit stores the full amount of APM information in the database for use by the intelligent load balancer information processing and policy generation unit that may be called later.
  • the service running information collected in step S6023 includes dimensions such as events, performance, indicators, and call chains, such as CPU, IO, memory usage information, etc.; and for example, information that can reflect the service business processing capabilities (processing time, error rate, number of restarts, etc.).
  • step S604 may specifically include the following steps:
  • Step S6041 the specific service request reaches the API gateway
  • Step S6042 The API gateway decides whether to call the intelligent load balancing server based on the gateway's own performance statistics
  • the API gateway will regularly collect its own performance statistics during daily operation, such as CPU occupancy rate. If it finds that the gateway's own CPU occupancy rate is too high (>80%) when receiving a business request, it will no longer load the intelligent load balancer and jump to step S605 to use the traditional load balancing strategy (configured load balancing strategy). If the API gateway CPU occupancy rate does not exceed the standard, the intelligent load balancer is loaded and the process is continued at step S6043.
  • CPU occupancy rate configured load balancing strategy
  • Step S6043 The business request processing process jumps to the intelligent load balancer execution stage.
  • the intelligent load balancer information processing and policy calculation unit obtains relevant information of the target service from the database stored in step S602 according to the business request. Since the desired load balancing strategy is "load balancing based on node bandwidth and load balancing based on service response delay", steps S6044 to S6047 are entered to obtain relevant information and perform policy calculation.
  • Step S6044 The intelligent load balancer-information processing and policy calculation unit filters out relevant node operation and maintenance information based on the obtained node information where the service provider instance is located, and further obtains real-time bandwidth indicator information of these nodes and requests for each service instance. processing delay information;
  • Step S6045 The information processing and policy calculation unit finds the node with the optimal bandwidth based on the load balancing policy details (selecting the node with the "largest" bandwidth), and further converts it into a corresponding service provider instance list (service provider sub-instance) pool).
  • the service provider instance includes A ⁇ B ⁇ C ⁇ D ⁇ E, and the node where A ⁇ B ⁇ C is located has the optimal bandwidth, then select A ⁇ B ⁇ C;
  • Step S6046 The information processing and policy calculation unit finds the instance list (service provider sub-instance pool) with the smallest service processing delay based on the load balancing policy details (the "minimum" delay service instance). For example, the service provider instance has A ⁇ B ⁇ C ⁇ D ⁇ E, among which B ⁇ C ⁇ E has the smallest processing delay, then select B ⁇ C ⁇ E;
  • Step S6047 The intelligent load balancer takes the intersection of the two instance lists in steps S6045 and S6046 based on the load balancing policy details (the mixed relationship between the two policies is AND), that is, the service provider instance B ⁇ C provides available services. or instance pool;
  • Step S6048 Return the output result of step S6047 to the API gateway.
  • step S605 may specifically include the following steps:
  • Step S6051 The API gateway continues request forwarding processing, selects a target service provider instance from the service provider instance pool according to the configured load balancing policy (traditional load balancing policy), and forwards the business request to the target service provider instance for processing. ;
  • the configured load balancing policy traditional load balancing policy
  • Step S6052 After receiving the business request, the selected target service provider instance completes the business processing and sends a response to the API gateway, and the gateway sends the response back to the client (service consumer);
  • a load balancing processing device is also provided.
  • Figure 7 is a diagram according to the embodiment of the present disclosure.
  • the block diagram of the load balancing processing device of the embodiment is shown in Figure 7.
  • the load balancing processing device includes:
  • the receiving module 702 is configured to receive business requests from service consumers
  • the judgment module 704 is configured to obtain the performance statistical information of the application programming interface API gateway, and judge whether the API gateway meets the loading conditions of the reconfigured load balancing policy based on the performance statistical information;
  • the first load balancing module 706 is configured to determine a target service provider instance according to the pre-stored application performance management APM full information and the reconfigured load balancing strategy when the API gateway meets the loading condition, wherein the target service provider instance is used to process the business request;
  • the second load balancing module 708 is configured to determine the target service provider instance according to the configured load balancing policy when the API gateway does not meet the loading condition.
  • the judgment module 704 is configured to judge whether the performance statistical information is less than a preset performance statistical information threshold, wherein the performance statistical information includes at least one of the following: gateway forwarding error rate, gateway CPU usage rate, gateway memory occupancy rate; when the performance statistics information is less than the performance statistics information threshold, it is determined that the API gateway meets the loading condition; when the performance statistics information is greater than or equal to the performance statistics information threshold In this case, it is determined that the API gateway does not meet the loading condition.
  • the first load balancing module 706 includes:
  • a first determining unit configured to determine one or more service providers according to the service request, wherein each service provider is configured with at least one service provider instance;
  • a filtering unit configured to filter out target service operation information corresponding to the reconfigured load balancing policy and the service provider from the full APM information
  • a generating unit configured to generate a service provider instance pool according to the reconfigured load balancing policy and the target service running information
  • the first load balancing unit is configured to determine a target service provider instance from the service provider instance pool according to the configured load balancing policy.
  • the generation unit is further configured to filter out all service provider instances that satisfy the reconfigured load balancing policy based on the target service running information when a reconfigured load balancing policy is set in advance.
  • Service provider instance pool when multiple reconfigured load balancing strategies are set in advance, all service provider instances that satisfy each reconfigured load balancing strategy are selected based on the target service running information to form a service provider.
  • Sub-instance pool process multiple service provider sub-instance pools according to a preset mixed relationship to obtain a service provider instance pool, wherein the mixed relationship includes one of the following: AND, OR, NOT.
  • the load balancing processing device also includes:
  • the docking module is configured to obtain and store the APM full information from the APM system through an interface that complies with the OpenTelemetry specification, where the APM full information includes the running information of all service provider instances collected and counted by the APM system.
  • the business processing module is configured to forward the business request to the target service provider instance after determining the target service provider instance; and return the business request response after the target service provider instance responds to the business request. to consumers of said services.
  • the second load balancing module 708 includes:
  • a first determining unit configured to determine one or more service providers according to the service request, wherein each service provider is configured with at least one service provider instance;
  • the acquisition unit is configured to obtain the service running information collected by the API gateway and corresponding to the service provider instance;
  • the second load balancing unit is configured to determine the target service provider instance based on the service running information and the configured load balancing policy, where the configured load balancing policy includes: polling policy, weighted polling Strategy, random strategy, hash strategy, minimum response time strategy, minimum concurrency strategy.
  • a method for dynamically combining an API gateway load balancing strategy with an APM system is provided.
  • the APM system is coupled with a pluggable intelligent load balancer.
  • the API gateway When the performance of the API gateway is poor, the API When the coupling connection between the gateway and the intelligent load balancer is disconnected, the API gateway performs load balancing independently; when the performance of the API gateway is good, the API gateway and the intelligent load balancer are coupled and connected, and the API gateway and the intelligent load balancer jointly perform load balancing.
  • Figure 8 is a structural block diagram of an API gateway independently performing load balancing in an embodiment of the present disclosure.
  • the service consumer 801 directly sends a service request to the API gateway 802.
  • the API gateway 802 can obtain the addresses of all service instances through service discovery (Service Discovery).
  • the API gateway 802 The configured load balancing strategy (traditional load balancing strategy) is executed when forwarding service requests to service provider 803.
  • the configured load balancing strategies include: polling strategy, weighted polling, random strategy, hash strategy, and minimum response. Time, minimum concurrency strategy.
  • Figure 9 is a structural block diagram of an API gateway and an intelligent load balancer jointly performing load balancing in an embodiment of the present disclosure. As shown in Figure 9, the API gateway obtains information from the APM system in a decoupled manner.
  • the API gateway is coupled and connected with the intelligent load balancer, and the intelligent load balancer can obtain the operation and maintenance data of all applications or resource pools connected to the APM system from the cloud native APM system.
  • the dimensions of operation and maintenance data include call chains, logs, indicators, events, etc.
  • FIG 10 is a schematic diagram of the gateway control plane UI in an embodiment of the present disclosure. As shown in Figure 10, users can register services for each service on the API gateway control interface.
  • the load balancing strategy can be set for the service provider through the gateway control plane UI. Based on the configured load balancing strategy (polling, weight, hash, random, etc.), a new reconfigured Load balancing strategy. After each load balancing strategy is selected, a submenu pops up and the relevant indicator values are set in the submenu. For example, the specific bit/s can be set in the submenu of node bandwidth load, and service custom indicator items can be filled in in the submenu of business indicator capacity load of service instance. When a service instance is located on the node or related indicators of the service itself, When it is lower than the threshold set above, the service instance will be removed from the available load balancing service instance pool.
  • Embodiments of the present disclosure also provide a computer-readable storage medium that stores a computer program, wherein the computer program executes the steps in any of the above method embodiments when run by a processor.
  • the computer-readable storage medium may include but is not limited to: U disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM) , mobile hard disk, magnetic disk or optical disk and other media that can store computer programs.
  • ROM read-only memory
  • RAM random access memory
  • mobile hard disk magnetic disk or optical disk and other media that can store computer programs.
  • Embodiments of the present disclosure also provide an electronic device, including a memory and a processor.
  • a computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.
  • the above-mentioned electronic device may further include a transmission device and an input-output device, wherein the transmission device is connected to the above-mentioned processor, and the input-output device is connected to the above-mentioned processor.
  • each module or each step of the above-mentioned embodiments of the present disclosure can be implemented by a general computing device, and they can be concentrated on a single computing device, or distributed among multiple computing devices. over a network, they may be implemented with program code executable by a computing device, such that they may be stored in a storage device for execution by the computing device, and in some cases, may be executed in a sequence different from that described here.
  • the steps shown or described may be implemented by fabricating them separately into individual integrated circuit modules, or by fabricating multiple modules or steps among them into a single integrated circuit module. As such, disclosed embodiments are not limited to any specific combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

本公开实施例提供了一种负载均衡处理方法、装置、存储介质及电子装置，该方法包括：接收来自服务消费者的业务请求，获取应用程序编程接口API网关的性能统计信息，并根据性能统计信息判断API网关是否满足重新配置的负载均衡策略的加载条件，在API网关满足加载条件的情况下，根据预先存储的应用性能管理APM全量信息和重新配置的负载均衡策略确定目标服务提供者实例，其中，目标服务提供者实例用于处理业务请求。

Description

一种负载均衡处理方法、装置、存储介质及电子装置
相关申请的交叉引用
本公开基于2022年9月16日提交的发明名称为“一种负载均衡处理方法、装置、存储介质及电子装置”的中国专利申请202211131470.2，并且要求该专利申请的优先权，通过引用将其所公开的内容全部并入本公开。
技术领域
本公开实施例涉及分布式系统领域，具体而言，涉及一种负载均衡处理方法、装置、存储介质及电子装置。
背景技术
为了解决传统单体应用的痛点，微服务已经成为云原生的重要定义，同时业界中越来越多的公司都采用了微服务架构，例如Amazon、eBay和NetFlix，且其规模也都呈爆发式增长。根据相关业内趋势报告显示微服务已经进入到了成熟期，作为主流架构被广泛的采用。微服务架构及其规模增长也带来了一系列挑战，例如客户端到微服务应用间访问通信需要满足日益增长的治理诉求。作为首选的应用程序编程接口(Application Programming Interface，简称API)网关可以将功能从单个微服务转移到网关，从而通过将跨领域问题整合到一个层级中来简化每个微服务的实现。
通常API网关会提供负载均衡、身份验证和授权、速率限制、日志记录跟踪等几个方面的功能。负载均衡是分布式系统的高可用设计中非常关键的一环。分布式系统的特性之一就是支持快速扩展，而集群扩展之后，如何将网络请求派发到集群中的一个或多个节点上处理需要依赖负载均衡策略。负载均衡在处理高并发，缓解网络压力，以及支持扩容等方面非常关键，在不同的应用场景下，可以选择不同的负载均衡策略。
一般而言，传统的API网关负载均衡策略主要有如下两类：一类是轮询策略、加权轮询、随机策略、哈希策略；另一类是最小响应时间、最小并发数策略；前四种属于独立算法类，它们不依赖于后端服务实例的实际状态与真实处理情况，后两种则需要以后端服务实例的真实处理情况为依据来决策最终的策略实施，但这里依赖的数据由API网关自身统计，并且统计实际是在后端服务实例已经完成请求响应后才能得到。
虽然上面这几种API网关的已配置的负载均衡策略至今依然广泛地被使用，能够让请求更高效、更均匀的得到处理。但随着云原生项目的规模爆发，用户和技术架构有了一些新的变化，对负载均衡的功能提出了更高的要求，从此可以看出传统解决方案中存在一些技术缺点：
第一策略的算法偏理论，不能适应微服务架构的复杂性和动态性。例如传统轮询和加权等负载均衡策略，其假设的前提是各个节点的处理性能是固定不变的，但这一前提在扩缩容随时发生、微服务使用的资源存在变化争夺的场景下实际是已经很难成立，从而导致这些“策略”无法实现真正意义上的“均衡”。
第二类策略仅依据API网关自身信息决策负载均衡策略。这种技术方案下存在事后调整，不够及时等缺点。例如常见的一些根据响应时间和响应码来选择负载节点策略，虽然相对准确，但存在事后调整、不够及时、维度单一等缺点。
针对相关技术中传统API网关负载均衡策略仅依赖API网关自身采集数据，不够灵活和及时性差的问题，还没有解决方法。
发明内容
本公开实施例提供了一种负载均衡处理方法、装置、存储介质及电子装置，以至少解决相关技术中传统API网关负载均衡策略仅依赖API网关自身采集数据，不够灵活和及时性差的问题。
根据本公开的一个实施例，提供了一种负载均衡处理方法，所述方法包括：
接收来自服务消费者的业务请求；
获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
根据本公开的另一个实施例，提供了一种负载均衡处理装置，所述装置包括：
接收模块，设置为接收来自服务消费者的业务请求；
判断模块，设置为获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
第一负载均衡模块，设置为在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
第二负载均衡模块，设置为在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
根据本公开的另一个实施例，还提供了一种负载均衡处理系统，所述系统包括：
API网关，设置为接收来自服务消费者的业务请求，获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
智能负载均衡器，设置为在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
所述API网关，还设置为在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
根据本公开的又一个实施例，还提供了一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被处理器运行时执行上述任一项方法实施例中的步骤。
根据本公开的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
附图说明
图1是本公开实施例的负载均衡处理方法的硬件结构框图；
图2是根据本公开实施例的负载均衡处理方法的流程图；
图3是本公开另一实施例的负载均衡处理系统的结构框图；
图4是本公开另一实施例的负载均衡处理方法的流程图；
图5是本公开实施例中根据节点IO进行负载均衡处理方法的流程图；
图6是根据本公开的另一实施例进行负载均衡处理方法的流程图；
图7是根据本公开实施例的负载均衡处理装置的框图；
图8是本公开实施例中API网关独立进行负载均衡的结构框图；
图9是本公开实施例中API网关与智能负载均衡器共同进行负载均衡的结构框图；
图10是本公开实施例中的网关控制面UI的示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本公开的实施例。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
本公开实施例中所提供的方法实施例可以在移动终端、计算机终端、云服务器或者类似的运算装置中执行。以运行在计算机终端上为例，图1是本公开实施例的负载均衡处理方法的硬件结构框图，如图1所示，硬件单板可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和设置为存储数据的存储器104，其中，上述移动终端还可以包括设置为通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
存储器104可设置为存储计算机程序，例如，应用软件的软件程序以及模块，如本公开实施例中的负载均衡处理方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及负载均衡处理处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106设置为经由一个网络接收或者发送数据。上述的网络具体实例可包括通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其设置为通过无线方式与互联网进行通讯。
在本实施例中提供了一种负载均衡处理方法，图2是根据本公开实施例的负载均衡处理方法的流程图，如图2所示，该流程包括如下步骤：
步骤S202，接收来自服务消费者的业务请求；
步骤S204，获取应用程序编程接口API网关的性能统计信息，并根据性能统计信息判断API网关是否满足重新配置的负载均衡策略的加载条件；
步骤S206，在API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和重新配置的负载均衡策略确定目标服务提供者实例，其中，目标服务提供者实例用于处理所述业务请求；
步骤S208，在API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定目标服务提供者实例。
在本实施例中，上述步骤S202中的服务消费者即业务请求发起者，通常指应用程序客户端。
在本实施例中，上述步骤S204具体可以包括：判断所述性能统计信息是否小于预设的性能统计信息阈值，其中，所述性能统计信息，包括以下至少之一：网关转发错误率、网关CPU占用率、网关内存占用率；在所述性能统计信息小于所述性能统计信息阈值的情况下，确定所述API网关满足所述加载条件；在所述性能统计信息大于或等于所述性能统计信息阈值的情况下，确定所述API网关不满足所述加载条件。
具体的，可以预先通过网关控制面UI对API网关进行配置，例如，将加载条件设置为中央处理器(Central Processing Unit，简称CPU)CPU占用率小于70％，在优先保证API网关性能的情况下再加载重新配置的负载均衡策略。如果在API网关资源不足的情况下强行加载重新配置的负载均衡策略会导致整体性能降低，例如请求响应时间较长等。
在本实施例中，上述步骤S204中的重新配置的负载均衡策略是一种抽象的负载均衡策略，也是系统期望行为，用于表示用户对负载均衡处理结果的期望。具体的，重新配置的负载均衡策略是根据应用性能管理(Application Performance Management，简称APM)系统采集并统计的运行信息进行设置的，所述运行信息的维度包括：事件、性能、指标、调用链。重新配置的负载均衡策略可以根据APM系统采集的任意运行信息进行配置的，例如，用户更关注业务响应速度，可以考虑针对节点带宽和服务响应时延进行负载均衡。
进一步的，所述重新配置的负载均衡策略包括但不限于以下策略：
根据服务提供者实例的应用重启次数进行负载均衡；
根据服务提供者实例的应用重启时长进行负载均衡；
根据服务提供者实例所在节点的重启应用个数进行负载均衡；
根据服务提供者实例所在节点输入输出IO进行负载均衡；
根据服务提供者实例的实时带宽进行负载均衡；
根据服务提供者实例的历史错误率进行负载均衡；
根据服务提供者实例的业务指标能力进行负载均衡；
根据服务提供者实例的单个请求的处理时长进行负载均衡；
根据服务提供者实例的多个请求的处理成功率进行负载均衡；
根据服务提供者实例的中央处理器CPU占用率进行负载均衡；
根据服务提供者实例的响应时间进行负载均衡。
在本实施例中，重新配置的负载均衡策略可以设置不同的策略等级，在用户界面(User Interface，简称UI)选中上级策略时，会自动显示对应的下一级策略供用户选择。例如，选择按服务提供者实例的动态处理能力进行负载均衡，会弹出用来衡量服务提供者实例处理能力的选项，例如单个请求处理时长(动态处理能力)、多个请求的处理成功率、服务提供者实例的应用重启次数等。
在本实施例中，上述步骤S206具体可以包括以下步骤：
步骤S2062，根据业务请求确定一个或多个服务提供者，其中，每个服务提供者配置有至少一个服务提供者实例；
步骤S2064，从APM全量信息中过滤出与重新配置的负载均衡策略和服务提供者对应的目标服务运行信息；
步骤S2066，根据重新配置的负载均衡策略和目标服务运行信息生成服务提供者实例池；
步骤S2068，根据已配置的负载均衡策略从服务提供者实例池中确定目标服务提供者实例。
在本实施例中，上述步骤S2062中的服务提供者即业务请求处理者，通常指应用程序服务器，在微服务架构的应用下，每个服务提供者可能拥有多个具备业务处理能力的副本，即服务提供者实例。
在本实施例中，上述步骤S2066具体可以包括：
在预先设置一个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息筛选出满足所述重新配置的负载均衡策略的全部服务提供者实例组成服务提供者实例池；
在预先设置多个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息分别筛选出满足每一个重新配置的负载均衡策略的全部服务提供者实例组成服务提供者子实例池；根据预先设置的混合关系对多个所述服务提供者子实例池进行处理得到服务提供者实例池，其中，所述混合关系包括以下之一：与、或、非。
具体的，混合关系为与，表示服务提供者实例需要同时满足多个重新配置的负载均衡；混合关系为或，表示服务提供者实例只需要满足任意一个重新配置的负载均衡就可以；混合关系为非，表示需要剔除掉满足任意一个重新配置的负载均衡的服务提供者实例。
进一步的，在预先设置一个重新配置的负载均衡策略的情况下，也可以设置策略关系为非或正则，非表示排除满足所述重新配置的负载均衡策略的全部服务提供者实例，正则表示字符串匹配模式，只要目标服务运行信息中包含重新配置的负载均衡策略中设置的具体参数，就视为满足负载均衡策略。
在本实施例中，在负载均衡处理方法运行的整个过程中还包括通过符合预设规范的接口从APM系统获取并存储所述APM全量信息，其中，所述APM全量信息包含所述APM系统采集并统计的全部服务提供者实例的运行信息，所述预设规范为OpenTelemetry规范。
具体的，通常使用超文本传输协议(HyperText Transfer Protocol，简称HTTP)或传输控制协议(Transmission Control Protocol，简称TCP)等标准协议对接APM系统，可以根据实际应用场景，选择周期获取、动态监听变化、发布/订阅等不同的方式从APM系统中读取APM全量信息，获取的APM全量信息被存储到数据库中，并等待在步骤S206中被调用。
在本实施例中，上述步骤S208具体可以包括以下步骤：
步骤S2082，根据所述业务请求确定一个或多个服务提供者，其中，每个服务提供者配 置有至少一个服务提供者实例；
步骤S2084，获取API网关采集的与所述服务提供者实例对应的服务运行信息；
步骤S2086，根据所述服务运行信息和已配置的负载均衡策略确定所述目标服务提供者实例，其中，所述已配置的负载均衡策略，包括：轮询策略、加权轮询策略、随机策略、哈希策略、最小响应时间策略、最小并发数策略。
在本实施例中，已配置的负载均衡策略为传统负载均衡策略，具体的，轮训策略为每个请求按时间顺序逐一分配到不同的服务提供者实例；加权轮询策略为按照设置的权重进行分配，权重与业务请求访问率成正比；哈希策略为每个请求按访问ip的哈希结果分配，来自同一ip的业务请求会被分给固定的一个服务提供者实例；最小响应时间策略为优先分配给响应时间最短的服务提供者实例。
在本实施例中，通过上述步骤S202至S208，可以解决相关技术中传统的API网关负载均衡策略仅依赖API网关自身采集数据，不够灵活和及时性差的问题，通过判断API网关是否满足重新配置的负载均衡策略的加载条件，优先保证了API网关性能，并通过APM系统丰富了API网关可获取的数据维度，从而提供更多、更符合服务实际运行情况的负载均衡策略。
图3是本公开另一实施例的负载均衡处理系统的结构框图，如图3所示，负载均衡处理系统包括以下结构：
API网关301，设置为接收来自服务消费者的业务请求，获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
智能负载均衡器302，设置为在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
API网关301，还设置为在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
在本实施例中，重新配置的负载均衡策略的加载条件即智能负载均衡器302的调用条件，智能负载均衡器302与API网关301之间采用可插拔的耦合连接。
在本实施例中，负载均衡处理系统还包括网关控制面UI，设置为接收用户设置的期望的抽象负载均衡策略/行为，并提供给整个系统。例如可以通过网关控制面UI为不同服务分别设置根据应用重启次数进行负载均衡、根据应用重启时长进行负载均衡、按服务实例中央处理器(Central Processing Unit，简称CPU)占用率进行负载均衡、按服务业务指标进行负载均衡、按服务实例动态处理能力进行负载均衡等各种负载均衡策略。
进一步的，网关控制面UI可以在已配置的负载均衡策略(轮询、权重、哈希、随机)基础上，新增重新配置的负载均衡策略。每个负载均衡策略被选择后会弹出子菜单，在子菜单中对相关指标数值进行设置。例如，在按节点带宽进行负载均衡的子菜单中可对具体bit/s进行设置，在按服务提供者实例业务指标能力进行负载均衡的子菜单中可以填写服务自定义业务指标项，当某个服务提供者实例所在节点或服务自身的相关指标低于前述设置的阈值时，则该服务实例将从可用的负载均衡服务实例池中剔除。
网关控制面UI还设置为设置重新配置的负载均衡策略的策略关系(非、正则)和混合关 系(与、或、非)。
在本实施例中，智能负载均衡器302具体还包括：
信息对接单元，设置为从云原生APM获取服务运行信息；
数据库，设置为存储信息对接单元获取的运行信息；
信息处理与策略计算单元，设置为根据重新配置的负载均衡策略从数据库中过滤出目标服务运行信息；
策略生成单元，设置为根据目标服务运行信息确定服务提供者实例池。
在本实施例中，信息对接单元是一种通过标准协议对接APM系统采集分布式调用链数据等运行信息的代理组件。APM系统采集的信息包括事件、性能、指标、调用链等维度，例如CPU、IO、内存占用信息等，又例如能够反映服务业务处理能力的信息(处理时长、错误率、重启次数等)。
在本实施例中，信息处理与策略计算单元，具体还可以设置为从所述APM全量信息中过滤出与所述重新配置的负载均衡策略和所述服务提供者对应的目标服务运行信息。
在本实施例中，策略生成单元，具体还可以设置为在预先设置一个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息筛选出满足所述重新配置的负载均衡策略的全部服务提供者实例组成服务提供者实例池；在预先设置多个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息分别筛选出满足每一个重新配置的负载均衡策略的全部服务提供者实例组成服务提供者子实例池；根据预先设置的混合关系对多个所述服务提供者子实例池进行处理得到服务提供者实例池，其中，所述混合关系包括以下之一：与、或、非。
在本实施例中，API网关301，还设置为在服务提供者实例池中包含多个服务提供者实例的情况下，根据已配置的负载均衡策略确定目标服务提供者实例。
在本实施例中，API网关301，还设置为在确定目标服务提供者实例之后，将所述业务请求转发给所述目标服务提供者实例；在所述目标服务提供者实例响应所述业务请求后，将业务请求响应返回给所述服务消费者。
图4是本公开另一实施例的负载均衡处理方法的流程图，应用于上面的负载均衡处理系统，如图4所示，负载均衡处理方法具体包括以下几个步骤：
步骤S401，系统通过UI/接口获取期望的抽象负载均衡策略/行为；
步骤S402，信息对接单元通过对接APM获取各项信息，对接过程使用标准协议，通常使用HTTP/TCP协议，但一定符合OpenTelemetry规范；
步骤S403，API网关依据API网关的静态配置以及自身的性能统计信息决策是否执行外挂的智能负载均衡器；
步骤S404，根据用户期望行为(重新配置的负载均衡策略)，过滤有效信息，计算具体的负载均衡策略，生成可用的服务提供者实例池；
步骤S405，API网关在转发请求到服务提供者的过程中，继续实施传统负载均衡策略(已配置的负载均衡策略)，选择具体的目标服务提供者实例发送请求。
在本实施例的步骤S401中，网关控制面UI提供为不同服务设置不同的抽象负载均衡策略的选项，如按服务提供者实例CPU占用率进行负载均衡、按服务提供者所在节点输入输出(Input Output)IO进行负载均衡、按服务业务指标进行负载均衡、按服务实例动态处理能 力进行负载均衡等各种负载均衡策略。当“按服务实例动态处理能力进行负载均衡”策略选项被选中时，系统控制面UI会弹出用来衡量服务实例处理的能力的选项，例如单个请求处理时长(动态处理能力)、多个请求的处理成功率、服务实例应用重启次数等，通过进一步选择，就能清晰的描述出对系统的真实行为期望。
在本实施例的步骤S402中，由于APM系统具有统一OpenTelemetry规范，因此对接可以按照标准完成，同时由于APM已经完成对所有应用的交互与数据采集，因此智能负载均衡器能够借此实现与应用自身的真实状态解耦，不再需要通过与规模庞大的应用逐个交互、统计其运行时数据，极大降低了智能均衡负载器的实现负载度，大幅提升健壮性。
在本实施例中，步骤S403具体可以包括，当实际的业务请求到达API网关之后，API网关会首先收集网关自身的资源占用情况，包括网关转发错误率、网关CPU内存占用率、网关内存占用率，判断当前的网关资源占用情况是否可以支撑继续调用智能均衡负载器来实现增强的负载均衡策略。
具体的，调用条件可以通过网关控制面UI对API网关进行配置(例如设置为CPU占用率小于70％阈值)，如果判断API网关资源已经不足(即CPU占用率大于或等于70％)，则跳过智能负载均衡器，直接跳转到步骤S405，使用API网关自带的传统的、简单的负载均衡策略进行转发。否则继续步骤S404。
在本实施例中，步骤S404具体可以包括，智能均衡负载器根据重新配置的负载均衡策略(系统期望行为)，由信息处理与策略计算单元从数据库中获取并过滤出有效相关信息，假设系统期望的行为是按服务实例所在节点带宽负载(即优先选择节点实时带宽更高的服务实例转发请求，这样可以提高业务响应速度)，则在此步骤中，信息处理与策略计算单元会根据服务实例信息，从全量信息中过滤出：服务提供者实例与节点对应信息、节点实时带宽统计信息。接着由策略生成单元根据过滤出的信息，生成可用的服务实例池(其中包含1个或多个备选的服务实例)，并将该服务实例池返回给API网关。
在本实施例中，步骤S405具体可以包括，实际的业务请求回到API网关中，在转发请求到服务提供者的过程中，在可用的服务实例池中，再二次实现传统的、简单的负载均衡策略(已配置的负载均衡策略)，选择出具体的目标服务提供者实例发送请求，并在服务提供者响应完请求后，将请求响应返回给客户端。
具体的，已配置的负载均衡策略包括：轮询策略、加权轮询策略、随机策略、哈希策略、最小响应时间策略、最小并发数策略。
在本实施例中，通过上述步骤S401至步骤S405中的负载均衡方法，可以增强微服务架构下的云原生API网关的功能丰富性与智能性，增强网关的负载均衡策略，解决大规模复杂系统节能降耗、运维等难题。
图5是本公开实施例中根据节点IO进行负载均衡处理方法的流程图，该方法应用于一种基于PaaS平台部署网管系统，由于现场环境资源紧张，使用的是控制节点与计算节点合一部署，大量的业务应用和平台应用共同部署在这些节点上，常常会出现资源抢夺(例如磁盘IO)的情况，也会常常遇到访问某个微服务出现卡顿甚至失败的情况，当遇到这些问题时，服务提供者通过定位发现问题只在其中某个节点发生，另外节点上的服务提供者实例工作正常，因此用户期望行为是根据节点IO情况来调整负载均衡策略。
如图5所示，负载均衡处理方法具体包括以下几个步骤：
步骤S501，通过UI/接口设置目标服务相关信息，重新配置的负载均衡策略被设置为“根据节点IO进行负载均衡”，指定排除掉每秒进行读写操作的次数(Input/Output Operations Per Second，简称IOPS)小于1K的节点上实例；
步骤S502，智能负载均衡器通过标准协议对接APM获取各项信息；
步骤S503，服务消费者/客户端发起实际的业务请求；
步骤S504，API网关动态调用智能负载均衡器，智能负载均衡器根据系统期望行为(抽象的负载均衡策略)，过滤有效信息，计算具体的负载均衡策略；
步骤S505，API网关在从可用的服务提供者实例池中，按照已配置的负载均衡策略(传统负载均衡策略)，进一步选择具体的服务提供者实例发送请求。
在本实施例中，步骤S501具体可以包括以下步骤：
步骤S5011，通过网关控制面UI填写目标服务提供者的地址信息(对应多个服务提供者实例)；
步骤S5012，重新配置的负载均衡策略被设置为“根据节点IO进行负载均衡”；
步骤S5013，在子菜单中，负载均衡策略相关指标被设置为“IOPS＜1k时排除”。
在本实施例中，步骤S502具体可以包括以下步骤：
步骤S5021，根据网关控制面UI配置APM系统地址信息，或运维人员通过网关控制面UI配置第三方APM系统地址信息；
步骤S5022，信息对接单元通过周期性查询(例如10秒查询一次)的方式，以标准协议(HTTP)读取APM服务信息，调用APM标准接口(即符合APM领域的标准规范OpenTelemetry的接口)，获取所有运维信息。
具体的，在步骤S5022中，对接单元可以根据实际应用场景，选择周期获取、动态监听变化、发布/订阅等不同的方式完成全量信息获取。
步骤S5023，信息对接单元将获取的全量信息存储到数据库中，以供后续可能会被调用的智能负载均衡器的信息处理与策略生成单元使用。APM系统采集的信息包括事件、性能、指标、调用链等维度，例如CPU、IO、内存占用信息等，又例如能够反映服务业务处理能力的信息(处理时长、错误率、重启次数等)。
在本实施例中，步骤S504具体可以包括以下步骤：
步骤S5041，具体的业务请求到达API网关；
步骤S5042，API网关根据网关自身的性能统计信息，决策是否继续调用智能均衡负载器。例如，当发现网关自身内存占用率已经过高(＞90％)，则不再加载智能负载均衡器，跳转至步骤S505使用传统负载均衡策略。如果API网关各项指标均未超标，则加载智能负载均衡器，跳转至步骤S5043继续处理。
步骤S5043，智能负载均衡器根据服务提供者实例列表信息，从存有APM全量信息的数据库中过滤有效信息，首先获取服务提供者实例列表与节点对应信息。
步骤S5044，智能负载均衡器继续根据重新设置的负载均衡策略，从存有APM全量信息的数据库中获取节点信息，过滤出相关节点运维信息，并进一步获取这些节点的IOPS指标。
步骤S5045，智能负载均衡器根据重新配置的负载均衡策略的详细信息(IOPS＜1k时排除)，找出需要排除的节点，并进一步换算成对应的排除实例列表。例如服务提供者实例有A\B\C，其中C所在的节点IOPS为0.5K，因此排除实例列表包含C。
步骤S5046，智能负载均衡器将所有服务提供者实例放入服务提供者实例池，并根据步骤S5045返回结果，将C实例从可用服务实例池中剔除(也可以正向选择)，生成可用的服务提供者实例池(A\B)。
步骤S5047，将步骤S5046的输出结果返回给API网关。
在本实施例中，步骤S505具体可以包括以下步骤：
步骤S5051，API网关继续业务请求转发处理，从可用的服务实例池中挑选具体的一个目标服务提供者实例，将请求转发给该实例进行处理；
步骤S5052：被选中的目标服务提供者实例收到业务请求后完成处理，发送响应给API网关，网关将响应回传给客户端(业务请求发起者)。
图6是根据本公开的另一实施例进行负载均衡处理方法的流程图，提供了一种根据节点带宽和服务响应时延进行负载均衡处理方法的流程图，该方法应用于以业务响应速度作为第一考虑的场景，且资源较为充足，因此优先选择历史处理请求平均时延最小、当前所在节点带宽最大的服务提供者实例来作为负载均衡时的第一选择，以保障业务能够以最快的速度响应。
如图6所示，本实施例中的负载均衡处理方法具体包括以下几个步骤：
步骤S601，重新配置的负载均衡策略被设置为“根据节点带宽进行负载均衡”且“根据服务响应时延负载均衡”；
步骤S602，智能负载均衡器通过标准协议对接APM获取各项信息；
步骤S603，服务消费者/客户端发起实际的业务请求；
步骤S604，API网关动态调用智能负载均衡器，智能负载均衡器根据系统期望行为(抽象的负载均衡策略)，过滤有效信息，计算具体的负载均衡策略；
步骤S605，API网关在从可用的服务提供者实例池中，按照已配置的负载均衡策略(传统负载均衡策略)，进一步选择具体的服务提供者实例发送请求。
在本实施例中，步骤S601具体可以包括以下步骤：
步骤S6011，通过网关控制面UI填写目标服务的地址信息；
步骤S6012，第一负载均衡策略被设置为“根据节点带宽进行负载均衡”；
步骤S6013，在子菜单中，负载均衡策略相关策略被设置为：“带宽最大的节点”；
步骤S6014，第二负载均衡策略被设置为“根据服务响应时延负载均衡”；
步骤S6015，在子菜单中，负载均衡策略相关策略被设置为：“时延最小的服务实例”；
步骤S6016，重新配置的负载均衡策略被设置为：步骤S6012和步骤S6014中两种策略关系的混合策略，混合关系为“与”。
具体的，通过步骤S6011至步骤S6016可以大幅度提升负载均衡的丰富性，满足需求多样性。通过选择多种负载均衡策略和混合关系可以实现更多的负载均衡策略的混合，且混合的方式也是多样的(包含与、或、非、正则等)。
步骤S6021，根据网关控制面UI配置APM系统地址信息，或运维人员通过网关控制面UI配置第三方APM系统地址信息；
步骤S6022，智能负载均衡器的信息对接单元通过周期性查询(例如1分钟查询一次)的方式，以标准协议(HTTP)读取APM服务信息，调用APM标准接口(即符合APM领域的标准规范OpenTelemetry的接口)，获取所有运维信息；
具体的，步骤S6022中的查询，智能负载均衡器-信息对接单元可以根据实际应用场景，选择周期获取、动态监听变化、发布/订阅等不同的方式完成全量信息获取。
步骤S6023，智能负载均衡器-信息对接单元将APM全量信息存储到数据库中供后续可能会被调用的智能负载均衡器信息处理与策略生成单元使用。
具体的，步骤S6023中采集的服务运行信息包括事件、性能、指标、调用链等维度，例如CPU、IO、内存占用信息等；又例如能够反映服务业务处理能力的信息(处理时长、错误率、重启次数等)。
在本实施例中，步骤S604具体可以包括以下步骤：
步骤S6041，具体的业务请求到达API网关；
步骤S6042，API网关根据网关自身的性能统计信息，决策是否调用智能均衡负载器；
具体的，API网关在日常运行过程中会定期采集自身性能统计信息，例如CPU占用率，如果在收到业务请求时，发现网关自身CPU占用率已经过高(＞80％)，则不再加载智能负载均衡器，跳转至步骤S605使用传统负载均衡策略(已配置的负载均衡策略)。如果API网关CPU占用率未超标，则加载智能负载均衡器，跳转至步骤S6043继续处理。
步骤S6043，业务请求处理流程跳转进入智能负载均衡器执行阶段，智能负载均衡器信息处理与策略计算单元关根据业务请求，从步骤S602存储的数据库中获取目标服务的相关信息。由于期望的负载均衡策略是“根据节点带宽进行负载均衡和根据服务响应时延负载均衡”，所以进入步骤S6044至S6047获取相关信息，并进行策略计算。
步骤S6044，智能负载均衡器-信息处理与策略计算单元根据获取到的服务提供者实例所在节点信息，过滤出相关节点运维信息，并进一步获取这些节点的实时带宽指标信息以及各服务实例对请求的处理时延信息；
步骤S6045，信息处理与策略计算单元根据负载均衡策略详信息(选择带宽“最大”的节点)，找出带宽最优的节点，并进一步换算成对应的服务提供者实例列表(服务提供者子实例池)。例如服务提供者实例有A\B\C\D\E，其中A\B\C所在节点带宽最优，则选择A\B\C；
步骤S6046，信息处理与策略计算单元根据负载均衡策略详信息(时延“最小”服务实例)，找业务处理时延最小的实例列表(服务提供者子实例池)。例如服务提供者实例有A\B\C\D\E，其中B\C\E处理时延最小，则选择B\C\E；
步骤S6047，智能负载均衡器根据负载均衡策略详信息(两种策略的混合关系为与)，取步骤S6045、S6046中两个实例列表的交集，即服务提供者实例B\C为可用的服务提供者实例池；
步骤S6048，将步骤S6047的输出结果返回给API网关。
在本实施例中，步骤S605具体可以包括以下步骤：
步骤S6051，API网关继续请求转发处理，按照已配置的负载均衡策略(传统负载均衡策略)从服务提供者实例池中挑选目标服务提供者实例，将业务请求转发给该目标服务提供者实例进行处理；
步骤S6052，被选中的目标服务提供者实例收到业务请求后完成业务处理，发送响应给API网关，网关将响应回传给客户端(服务消费者)；
根据本公开实施例的另一方面，还提供了一种负载均衡处理装置，图7是根据本公开实 施例的负载均衡处理装置的框图，如图7所示，负载均衡处理装置包括：
接收模块702，设置为接收来自服务消费者的业务请求；
判断模块704，设置为获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
第一负载均衡模块706，设置为在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
第二负载均衡模块708，设置为在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
在本实施例中，判断模块704，设置为判断所述性能统计信息是否小于预设的性能统计信息阈值，其中，所述性能统计信息，包括以下至少之一：网关转发错误率、网关CPU占用率、网关内存占用率；在所述性能统计信息小于所述性能统计信息阈值的情况下，确定所述API网关满足所述加载条件；在所述性能统计信息大于或等于所述性能统计信息阈值的情况下，确定所述API网关不满足所述加载条件。
在本实施例中，第一负载均衡模块706包括：
第一确定单元，设置为根据所述业务请求确定一个或多个服务提供者，其中，每个服务提供者配置有至少一个服务提供者实例；
过滤单元，设置为从所述APM全量信息中过滤出与所述重新配置的负载均衡策略和所述服务提供者对应的目标服务运行信息；
生成单元，设置为根据所述重新配置的负载均衡策略和所述目标服务运行信息生成服务提供者实例池；
第一负载均衡单元，设置为根据所述已配置的负载均衡策略从所述服务提供者实例池中确定目标服务提供者实例。
在本实施例中，生成单元还设置为在预先设置一个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息筛选出满足所述重新配置的负载均衡策略的全部服务提供者实例组成服务提供者实例池；在预先设置多个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息分别筛选出满足每一个重新配置的负载均衡策略的全部服务提供者实例组成服务提供者子实例池；根据预先设置的混合关系对多个所述服务提供者子实例池进行处理得到服务提供者实例池，其中，所述混合关系包括以下之一：与、或、非。
在本实施例中，负载均衡处理装置还包括：
对接模块，设置为通过符合OpenTelemetry规范的接口从APM系统获取并存储所述APM全量信息，其中，所述APM全量信息包含所述APM系统采集并统计的全部服务提供者实例的运行信息。
业务处理模块，设置为在确定目标服务提供者实例之后，将所述业务请求转发给所述目标服务提供者实例；在所述目标服务提供者实例响应所述业务请求后，将业务请求响应返回给所述服务消费者。
在本实施例中，第二负载均衡模块708包括：
第一确定单元，设置为根据所述业务请求确定一个或多个服务提供者，其中，每个服务提供者配置有至少一个服务提供者实例；
获取单元，设置为获取API网关采集的与所述服务提供者实例对应的服务运行信息；
第二负载均衡单元，设置为根据所述服务运行信息和已配置的负载均衡策略确定所述目标服务提供者实例，其中，所述已配置的负载均衡策略，包括：轮询策略、加权轮询策略、随机策略、哈希策略、最小响应时间策略、最小并发数策略。
根据本公开的另一实施例，还提供了一种API网关负载均衡策略与APM系统动态结合的方法，APM系统与可插拔的智能负载均衡器耦合连接，在API网关性能较差时，API网关与智能负载均衡器的耦合连接断开，由API网关独立进行负载均衡；在API网关性能较好时，API网关与智能负载均衡器耦合连接，由API网关与智能负载均衡器共同进行负载均衡。
图8是本公开实施例中API网关独立进行负载均衡的结构框图。
如图8所示，在API网关独立进行负载均衡时，服务消费者801直接发送服务请求到API网关802，API网关802可以通过服务发现(Service Discovery)获取所有服务实例的地址，API网关802在转发服务请求到服务提供者803的过程中执行已配置的负载均衡策略(传统负载均衡策略)，已配置的负载均衡策略包括：轮询策略、加权轮询、随机策略、哈希策略、最小响应时间、最小并发数策略。
图9是本公开实施例中API网关与智能负载均衡器共同进行负载均衡的结构框图，如图9所示，API网关采用解耦方式从APM系统中获取信息。
在本实施例中，API网关与智能负载均衡器耦合连接，智能负载均衡器能够从云原生APM系统中获取与APM系统相连的所有应用或资源池的运维数据。运维数据的维度包括调用链、日志、指标、事件等。
图10是本公开实施例中的网关控制面UI的示意图，如图10所示，用户可以在API网关控制界面针对每项服务进行服务注册。
在本实施例中，用于可以通过网关控制面UI对服务提供者设置负载均衡策略，在已配置的负载均衡策略(轮询、权重、哈希、随机等)基础上，新增重新配置的负载均衡策略。每个负载均衡策略被选择后，后弹出子菜单，在子菜单中对相关指标数值进行设置。例如按节点带宽负载的子菜单中可对具体bit/s进行设置、按服务实例业务指标能力负载的子菜单中可以填写服务自定义指标项，当某个服务实例所在节点或服务自身的相关指标低于前述设置的阈值时，则该服务实例将从可用的负载均衡服务实例池中剔除。
本公开的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被处理器运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本公开的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施 例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本公开实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开实施例不限制于任何特定的硬件和软件结合。
以上所述仅为本公开的优选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开实施例可以有各种更改和变化。凡在本公开实施例的原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (13)

  1. 一种负载均衡处理方法，所述方法包括：
    接收来自服务消费者的业务请求；
    获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
    在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
    在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
  2. 根据权利要求1所述的方法，其中，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，包括：
    根据所述业务请求确定一个或多个服务提供者，其中，每个服务提供者配置有至少一个服务提供者实例；
    从所述APM全量信息中过滤出与所述重新配置的负载均衡策略和所述服务提供者对应的目标服务运行信息；
    根据所述重新配置的负载均衡策略和所述目标服务运行信息生成服务提供者实例池；
    根据所述已配置的负载均衡策略从所述服务提供者实例池中确定目标服务提供者实例。
  3. 根据权利要求2所述的方法，其中，根据所述重新配置的负载均衡策略和所述目标服务运行信息生成服务提供者实例池，包括：
    在预先设置一个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息筛选出满足所述重新配置的负载均衡策略的全部服务提供者实例组成服务提供者实例池；
    在预先设置多个重新配置的负载均衡策略的情况下，根据所述目标服务运行信息分别筛选出满足每一个重新配置的负载均衡策略的全部服务提供者实例组成服务提供者子实例池；根据预先设置的混合关系对多个所述服务提供者子实例池进行处理得到服务提供者实例池，其中，所述混合关系包括以下之一：与、或、非。
  4. 根据权利要求1所述的方法，其中，所述方法还包括：
    通过符合预设规范的接口从APM系统获取并存储所述APM全量信息，其中，所述APM全量信息包含所述APM系统采集并统计的全部服务提供者实例的运行信息。
  5. 根据权利要求1所述的方法，其中，所述方法还包括：
    在确定目标服务提供者实例之后，将所述业务请求转发给所述目标服务提供者实例；
    在所述目标服务提供者实例响应所述业务请求后，将业务请求响应返回给所述服务消费者。
  6. 根据权利要求1所述的方法，其中，所述重新配置的负载均衡策略是根据APM系统采集并统计的运行信息进行设置的，所述运行信息的维度包括：事件、性能、指标、调用链。
  7. 根据权利要求6所述的方法，其中，所述重新配置的负载均衡策略包括：
    根据服务提供者实例的应用重启次数进行负载均衡；
    根据服务提供者实例的应用重启时长进行负载均衡；
    根据服务提供者实例所在节点的重启应用个数进行负载均衡；
    根据服务提供者实例所在节点输入输出IO进行负载均衡；
    根据服务提供者实例的实时带宽进行负载均衡；
    根据服务提供者实例的历史错误率进行负载均衡；
    根据服务提供者实例的业务指标能力进行负载均衡；
    根据服务提供者实例的单个请求的处理时长进行负载均衡；
    根据服务提供者实例的多个请求的处理成功率进行负载均衡；
    根据服务提供者实例的中央处理器CPU占用率进行负载均衡；
    根据服务提供者实例的响应时间进行负载均衡。
  8. 根据权利要求1所述的方法，其中，根据已配置的负载均衡策略确定所述目标服务提供者实例，包括：
    根据所述业务请求确定一个或多个服务提供者，其中，每个服务提供者配置有至少一个服务提供者实例；
    获取API网关采集的与所述服务提供者实例对应的服务运行信息；
    根据所述服务运行信息和已配置的负载均衡策略确定所述目标服务提供者实例，其中，所述已配置的负载均衡策略，包括：轮询策略、加权轮询策略、随机策略、哈希策略、最小响应时间策略、最小并发数策略。
  9. 根据权利要求1所述的方法，其中，根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件，包括：
    判断所述性能统计信息是否小于预设的性能统计信息阈值，其中，所述性能统计信息，包括以下至少之一：网关转发错误率、网关CPU占用率、网关内存占用率；
    在所述性能统计信息小于所述性能统计信息阈值的情况下，确定所述API网关满足所述加载条件；
    在所述性能统计信息大于或等于所述性能统计信息阈值的情况下，确定所述API网关不满足所述加载条件。
  10. 一种负载均衡处理装置，所述装置包括：
    接收模块，设置为接收来自服务消费者的业务请求；
    判断模块，设置为获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
    第一负载均衡模块，设置为在所述API网关满足所述加载条件的情况下，根据预先存储的应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
    第二负载均衡模块，设置为在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
  11. 一种负载均衡处理系统，所述系统包括：
    API网关，设置为接收来自服务消费者的业务请求，获取应用程序编程接口API网关的性能统计信息，并根据所述性能统计信息判断所述API网关是否满足重新配置的负载均衡策略的加载条件；
    智能负载均衡器，设置为在所述API网关满足所述加载条件的情况下，根据预先存储的 应用性能管理APM全量信息和所述重新配置的负载均衡策略确定目标服务提供者实例，其中，所述目标服务提供者实例用于处理所述业务请求；
    所述API网关，还设置为在所述API网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
  12. 一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被处理器运行时执行所述权利要求1至9任一项中所述的方法。
  13. 一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至9任一项中所述的方法。
PCT/CN2023/118931 2022-09-16 2023-09-14 一种负载均衡处理方法、装置、存储介质及电子装置 Ceased WO2024056042A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP23864772.1A EP4572288A4 (en) 2022-09-16 2023-09-14 METHOD AND APPARATUS FOR CHARGE BALANCING TREATMENT, STORAGE SUPPORT AND ELECTRONIC DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211131470.2 2022-09-16
CN202211131470.2A CN117768394A (zh) 2022-09-16 2022-09-16 一种负载均衡处理方法、装置、存储介质及电子装置

Publications (1)

Publication Number Publication Date
WO2024056042A1 true WO2024056042A1 (zh) 2024-03-21

Family

ID=90274245

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/118931 Ceased WO2024056042A1 (zh) 2022-09-16 2023-09-14 一种负载均衡处理方法、装置、存储介质及电子装置

Country Status (3)

Country Link
EP (1) EP4572288A4 (zh)
CN (1) CN117768394A (zh)
WO (1) WO2024056042A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118819819A (zh) * 2024-06-04 2024-10-22 华能信息技术有限公司 一种基于负载均衡的多数据库处理方法
CN119583655A (zh) * 2024-11-06 2025-03-07 北京奇艺世纪科技有限公司 业务请求的路由方法、装置、设备及存储介质
CN119862017A (zh) * 2025-03-21 2025-04-22 苏州元脑智能科技有限公司 服务调度的方法及电子设备、存储介质和计算机程序
CN120128592A (zh) * 2025-03-17 2025-06-10 紫金山实验室 服务调用请求传输方法、设备、存储介质和程序产品
WO2026045701A1 (zh) * 2024-08-29 2026-03-05 苏州元脑智能科技有限公司 存储设备的适配方法、存储设备、存储介质和电子设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118524139B (zh) * 2024-05-10 2025-02-25 佛山众陶联供应链服务有限公司 Android应用请求转发到不同环境和指定ip服务的方法及系统
CN121070533A (zh) * 2024-06-05 2025-12-05 云智能资产控股（新加坡）私人股份有限公司 一种调度方法、系统、服务设备、计算机程序产品及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170041385A1 (en) * 2015-08-07 2017-02-09 International Business Machines Corporation Dynamic healthchecking load balancing gateway
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备
CN112532683A (zh) * 2020-10-30 2021-03-19 北京盛和信科技股份有限公司 一种基于微服务架构下的边缘计算方法和设备
CN112751761A (zh) * 2020-12-28 2021-05-04 中国农业银行股份有限公司 交易路由的回切方法、中间系统和业务处理系统
CN112968943A (zh) * 2021-02-01 2021-06-15 国网安徽省电力有限公司 一种电力协同平台
CN113765695A (zh) * 2021-03-26 2021-12-07 北京京东拓先科技有限公司 一种网关管理方法、装置、设备及计算机可读存储介质
WO2021254331A1 (zh) * 2020-06-16 2021-12-23 中兴通讯股份有限公司 资源管理方法、系统、代理服务器及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109218355B (zh) * 2017-06-30 2021-06-15 华为技术有限公司 负载均衡引擎，客户端，分布式计算系统以及负载均衡方法
CN111083213B (zh) * 2019-12-09 2022-09-02 苏宁云计算有限公司 一种通信方法及系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170041385A1 (en) * 2015-08-07 2017-02-09 International Business Machines Corporation Dynamic healthchecking load balancing gateway
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备
WO2021254331A1 (zh) * 2020-06-16 2021-12-23 中兴通讯股份有限公司 资源管理方法、系统、代理服务器及存储介质
CN112532683A (zh) * 2020-10-30 2021-03-19 北京盛和信科技股份有限公司 一种基于微服务架构下的边缘计算方法和设备
CN112751761A (zh) * 2020-12-28 2021-05-04 中国农业银行股份有限公司 交易路由的回切方法、中间系统和业务处理系统
CN112968943A (zh) * 2021-02-01 2021-06-15 国网安徽省电力有限公司 一种电力协同平台
CN113765695A (zh) * 2021-03-26 2021-12-07 北京京东拓先科技有限公司 一种网关管理方法、装置、设备及计算机可读存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4572288A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118819819A (zh) * 2024-06-04 2024-10-22 华能信息技术有限公司 一种基于负载均衡的多数据库处理方法
WO2026045701A1 (zh) * 2024-08-29 2026-03-05 苏州元脑智能科技有限公司 存储设备的适配方法、存储设备、存储介质和电子设备
CN119583655A (zh) * 2024-11-06 2025-03-07 北京奇艺世纪科技有限公司 业务请求的路由方法、装置、设备及存储介质
CN120128592A (zh) * 2025-03-17 2025-06-10 紫金山实验室 服务调用请求传输方法、设备、存储介质和程序产品
CN119862017A (zh) * 2025-03-21 2025-04-22 苏州元脑智能科技有限公司 服务调度的方法及电子设备、存储介质和计算机程序

Also Published As

Publication number Publication date
EP4572288A1 (en) 2025-06-18
CN117768394A (zh) 2024-03-26
EP4572288A4 (en) 2025-11-26

Similar Documents

Publication Publication Date Title
WO2024056042A1 (zh) 一种负载均衡处理方法、装置、存储介质及电子装置
EP3905589B1 (en) Slice resource deployment method and apparatus, and slice manager and computer storage medium
CN109618002B (zh) 一种微服务网关优化方法、装置及存储介质
CN109218355B (zh) 负载均衡引擎，客户端，分布式计算系统以及负载均衡方法
EP2972855B1 (en) Automatic configuration of external services based upon network activity
CN108370341B (zh) 资源配置方法、虚拟网络功能管理器和网元管理系统
WO2021254331A1 (zh) 资源管理方法、系统、代理服务器及存储介质
WO2006046486A1 (ja) 資源管理システム、資源情報提供方法、及び、プログラム
CN107872402A (zh) 全局流量调度的方法、装置及电子设备
US20160344582A1 (en) Call home cluster
WO2020019472A1 (zh) 服务节点的评分方法、域名系统dns调度方法及服务器
US8918537B1 (en) Storage array network path analysis server for enhanced path selection in a host-based I/O multi-path system
CN118449860A (zh) 一种虚拟网络功能部署方案的确定方法、装置及存储介质
JP2016051446A (ja) 計算機システム、計算機、負荷分散方法及びそのプログラム
CN107659460A (zh) 一种配置api访问量的方法
CN114443293A (zh) 一种大数据平台的部署系统及方法
CN112055347A (zh) 一种多网关协同工作方法及系统
CN118413536B (zh) 一种基于边缘计算的资源处理方法及装置
CN116055496B (zh) 一种监控数据采集方法、装置、电子设备及存储介质
WO2026036453A1 (zh) 云网环境的资源配置方法、装置及电子设备
CN118433127A (zh) 一种基于业务感知的流量控制方法
CN110309225B (zh) 数据处理方法及系统
CN111813621A (zh) 基于Flume数据中台的数据处理方法、装置、设备及介质
US11595471B1 (en) Method and system for electing a master in a cloud based distributed system using a serverless framework
CN108718285B (zh) 云计算集群的流量控制方法、装置及服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23864772

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023864772

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2501001694

Country of ref document: TH

ENP Entry into the national phase

Ref document number: 2023864772

Country of ref document: EP

Effective date: 20250313

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2023864772

Country of ref document: EP