CN117768394A - 一种负载均衡处理方法、装置、存储介质及电子装置 - Google Patents
一种负载均衡处理方法、装置、存储介质及电子装置 Download PDFInfo
- Publication number
- CN117768394A CN117768394A CN202211131470.2A CN202211131470A CN117768394A CN 117768394 A CN117768394 A CN 117768394A CN 202211131470 A CN202211131470 A CN 202211131470A CN 117768394 A CN117768394 A CN 117768394A
- Authority
- CN
- China
- Prior art keywords
- load balancing
- service provider
- information
- service
- policy
- 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.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title abstract description 20
- 238000012545 processing Methods 0.000 claims abstract description 75
- 238000000034 method Methods 0.000 claims abstract description 46
- 230000004044 response Effects 0.000 claims description 30
- 238000004590 computer program Methods 0.000 claims description 16
- 230000008569 process Effects 0.000 claims description 14
- 238000002156 mixing Methods 0.000 claims description 10
- 238000001914 filtration Methods 0.000 claims description 5
- 238000012216 screening Methods 0.000 claims description 2
- 230000008878 coupling Effects 0.000 abstract description 4
- 238000010168 coupling process Methods 0.000 abstract description 4
- 238000005859 coupling reaction Methods 0.000 abstract description 4
- 238000003032 molecular docking Methods 0.000 description 14
- 238000010586 diagram Methods 0.000 description 12
- 230000006399 behavior Effects 0.000 description 11
- 230000010365 information processing Effects 0.000 description 9
- 238000012423 maintenance Methods 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000007717 exclusion Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请提供了一种负载均衡处理方法、装置、存储介质及电子装置，该方法包括：接收来自服务消费者的业务请求，获取应用程序编程接口API网关的性能统计信息，并根据性能统计信息判断API网关是否满足重新配置的负载均衡策略的加载条件，在API网关满足加载条件的情况下，根据预先存储的应用性能管理APM全量信息和重新配置的负载均衡策略确定目标服务提供者实例，其中，目标服务提供者实例用于处理业务请求。本申请可以解决现有技术中传统的API网关负载均衡策略仅依赖API网关自身采集数据，不够灵活和及时性差的问题，丰富了API网关可获取的数据维度，能够提供更多、更符合服务实际运行情况的负载均衡策略，并且具备低耦合性、低复杂度的特点。
Description
技术领域
本申请涉及分布式系统领域，具体而言，涉及一种负载均衡处理方法、装置、存储介质及电子装置。
背景技术
为了解决传统单体应用的痛点，微服务已经成为云原生的重要定义，同时业界中越来越多的公司都采用了微服务架构，例如Amazon、eBay和NetFlix，且其规模也都呈爆发式增长。根据相关业内趋势报告显示微服务已经进入到了成熟期，作为主流架构被广泛的采用。微服务架构及其规模增长也带来了一系列挑战，例如客户端到微服务应用间访问通信需要满足日益增长的治理诉求。作为首选的应用程序编程接口(ApplicationProgramming 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网关不满足所述加载条件的情况下，根据已配置的负载均衡策略确定所述目标服务提供者实例。
根据本申请的又一个实施例，还提供了一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被处理器运行时执行上述任一项方法实施例中的步骤。
根据本申请的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
本申请在保证API网关性能的前提下，基于应用性能管理APM系统采集的全部应用程序各个维度的服务运行信息和用户重新配置的负载均衡策略进行负载均衡处理，丰富了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包括一个网络适配器(NetworkInterface 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/OutputOperations 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任一项中所述的方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211131470.2A CN117768394A (zh) | 2022-09-16 | 2022-09-16 | 一种负载均衡处理方法、装置、存储介质及电子装置 |
| PCT/CN2023/118931 WO2024056042A1 (zh) | 2022-09-16 | 2023-09-14 | 一种负载均衡处理方法、装置、存储介质及电子装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211131470.2A CN117768394A (zh) | 2022-09-16 | 2022-09-16 | 一种负载均衡处理方法、装置、存储介质及电子装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117768394A true CN117768394A (zh) | 2024-03-26 |
Family
ID=90274245
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211131470.2A Pending CN117768394A (zh) | 2022-09-16 | 2022-09-16 | 一种负载均衡处理方法、装置、存储介质及电子装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN117768394A (zh) |
| WO (1) | WO2024056042A1 (zh) |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9900377B2 (en) * | 2015-08-07 | 2018-02-20 | International Business Machines Corporation | Dynamic healthchecking load balancing gateway |
| CN108206852B (zh) * | 2016-12-20 | 2020-12-22 | 华为技术有限公司 | 一种微服务框架下的基于会话的服务实例管理方法及设备 |
| CN113810443A (zh) * | 2020-06-16 | 2021-12-17 | 中兴通讯股份有限公司 | 资源管理方法、系统、代理服务器及存储介质 |
| CN112532683A (zh) * | 2020-10-30 | 2021-03-19 | 北京盛和信科技股份有限公司 | 一种基于微服务架构下的边缘计算方法和设备 |
| CN112751761A (zh) * | 2020-12-28 | 2021-05-04 | 中国农业银行股份有限公司 | 交易路由的回切方法、中间系统和业务处理系统 |
| CN112968943B (zh) * | 2021-02-01 | 2023-04-07 | 国网安徽省电力有限公司 | 一种电力协同平台 |
| CN113765695A (zh) * | 2021-03-26 | 2021-12-07 | 北京京东拓先科技有限公司 | 一种网关管理方法、装置、设备及计算机可读存储介质 |
-
2022
- 2022-09-16 CN CN202211131470.2A patent/CN117768394A/zh active Pending
-
2023
- 2023-09-14 WO PCT/CN2023/118931 patent/WO2024056042A1/zh unknown
Also Published As
| Publication number | Publication date |
|---|---|
| WO2024056042A1 (zh) | 2024-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112087312B (zh) | 一种提供边缘服务的方法、装置和设备 | |
| US9491079B2 (en) | Remote monitoring and controlling of network utilization | |
| US10958568B2 (en) | Topology aware load balancing engine | |
| US11570262B2 (en) | Methods, systems, and computer readable media for rank processing for network function selection | |
| US11202240B2 (en) | Systems and methods for managing and monitoring communication sessions | |
| CN102281190B (zh) | 负载均衡装置组网方法以及服务器、客户端接入方法 | |
| US20220014434A1 (en) | Slice Resource Deployment Method and Apparatus, and Slice Manager and Computer Storage Medium | |
| CN108965461A (zh) | 服务治理方法、装置及dubbo服务系统 | |
| WO2006046486A1 (ja) | 資源管理システム、資源情報提供方法、及び、プログラム | |
| CN109417492A (zh) | 一种网络功能nf管理方法及nf管理设备 | |
| CN101926124A (zh) | 网际协议服务水平协定路由器自动配置 | |
| KR101448413B1 (ko) | Atca-기반 장비에서 통신 트래픽을 스케줄링하기 위한 방법 및 장치 | |
| CN108259605B (zh) | 一种基于多数据中心的数据调用系统及方法 | |
| CN111770026B (zh) | 一种网络流量控制方法和装置 | |
| CN110380981B (zh) | 一种流量分发方法及设备 | |
| CN102845042B (zh) | 一种应用层多个活动物理接口的带宽聚集系统及方法 | |
| US11595471B1 (en) | Method and system for electing a master in a cloud based distributed system using a serverless framework | |
| CN117768394A (zh) | 一种负载均衡处理方法、装置、存储介质及电子装置 | |
| CN102986196B (zh) | 分布于通信结构上的节点利用具有多准则选择的拓扑服务器访问网络 | |
| CN106210120A (zh) | 一种服务器的推荐方法及其装置 | |
| US11894978B1 (en) | Computing power scheduling methods, apparatus, electronic devices and storage media | |
| CN112422305B (zh) | 通信设备的升级方法及装置 | |
| CN116055496B (zh) | 一种监控数据采集方法、装置、电子设备及存储介质 | |
| WO2022174675A1 (zh) | 算力信息的处理方法、第一网络设备及系统 | |
| WO2024093851A1 (zh) | 一种物联网设备心跳检测的方法、系统以及通信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |