CN117640642B - 一种api网关负载均衡方法 - Google Patents

Abstract

本发明公开了一种API网关负载均衡方法，属于API网关技术领域。本方案通过正常服务节点链表和异常服务节点链表保存每个微服务对应的节点信息。在正常服务节点链表中按照链表结点链接顺序，循环获取目标服务节点，并向目标服务节点转发API请求，把TCP连接建立失败的服务节点从正常服务节点链表中移到异常服务节点链表。定时从异常服务节点链表中按照顺序获取服务节点进行心跳检测，将有正常心跳响应的节点从异常服务节点链表中移到正常服务节点链表。本发明的方案，不需要申请连续性的内存块，不存在频繁的申请和释放内存块的操作，内存占用量平稳，不会出现大的波动，因而不会导致严重的内存碎片化问题，系统响应时间和运行状态稳定。

Description

一种API网关负载均衡方法

技术领域

本发明涉及API网关技术领域，尤其涉及一种API网关负载均衡方法。

背景技术

基于互联网应用的快速发展和普及，用户量越来越大，服务请求数量越来越多，为了保证服务的稳定运行，需要在代理转发层面保证转发每个服务节点的高效与稳定性。

图1为微服务架构下API网关负载均衡结构框图，如图1所示，微服务架构下，系统提供了多种微服务，每个微服务下有多个服务节点，API网关用于服务节点负载均衡。传统的API网关，使用数组存储服务节点信息，采用数组切片的方式访问和修改数组元素，比如在数组中增加新节点，或者删除数组中的某个节点。具体地，代理转发层会使用两个数组存储单个服务对应的节点信息，一个数组用于存储正常服务节点信息，一个数组用于存储异常服务节点信息。服务节点可以正常建立TCP连接即为正常，服务节点建立TCP连接失败即为异常。网关进程在正常服务节点信息列表中，随机生成数组索引，根据数组索引从数组中获取服务节点信息进行转发处理；心跳检测进程在异常服务节点信息列表中，遍历异常服务节点进行心跳检测，如果某个服务节点恢复正常，则把此服务节点的节点信息存储到正常服务节点信息列表的首节点。

系统运行过程中，每个服务节点都有可能随时上线、下线，服务节点数经常变化，而数组的内存必须是连续的，在系统底层，数组元素个数变化时，会重新申请内存，服务长时间运行，会导致内存碎片化严重，系统性能低下。比如：原来正常服务节点数量是N，如果有1个服务节点出问题，通过数组切片操作删除1个服务节点，那么正常服务节点数量就变成N-1，假设每个服务节点的存储空间为K，数组的数量发生变化时，会向系统重新申请一块(N-1)*K的连续空间，原来的N*K连续空间等到系统进行垃圾回收时释放，释放前进程占用的总内存为(N + N-1）*K；下次服务节点数量变化时，又继续申请连续空间，如果系统变量之间的内存空间过小，那么内存碎片化就会越来越严重，长时间运行容易造成服务响应时间过长。

频繁的数组切片操作需要频繁申请和释放内存，会长时间造成CPU阻塞，服务节点越多，性能越低。比如：如果服务节点数量为1000，每个服务节点占用255字节内存，则服务节点数组约占用24.9KB内存，如果运行过程中有服务节点数量发生变化，每变化一次，则需要重新申请一个大小为24.9KB+m*255B的新内存块，其中，m为变化的服务节点数量，服务节点数量增加时，m为正，服务节点数量减少时，m为负。所以，整个系统越复杂，服务越多，服务节点数越多，变化次数也相应越多，频繁申请内存越多。以某车联网为例，日均请求量15亿左右，节点数量约为1.1万，每节点占用255字节，一次内存申请就要大约2.7MB内存，如果1小时变化10次，10小时就大约需要重新申请270MB内存。服务运行时间长了之后，内存碎片化会非常严重，系统响应时间变长、稳定性变差，甚至有时需要通过定时重启系统才可以短暂地恢复系统性能。

发明内容

本发明要解决的技术问题是：微服务架构下，API网关通过数组存储节点信息进行负载均衡导致的内存碎片化严重、系统响应时间变长、稳定性变差的问题。

为实现上述目的，本发明提供了一种API网关负载均衡方法，所述方法包括以下步骤：

步骤S1，API网关为每个微服务创建两个链表，用于存储该微服务对应的服务节点的信息，其中，正常服务节点链表用于保存正常服务节点的节点信息，异常服务节点链表用于保存异常服务节点的节点信息，所述正常服务节点链表和异常服务节点链表均为循环链表；

步骤S2，API网关接收API请求，将API请求与微服务建立一一对应关系；

步骤S3，从API请求对应的微服务的正常服务节点链表中，按照链表结点指针链接顺序，获取目标服务节点，向所述目标服务节点转发API请求；

步骤S4，如果向所述目标服务节点转发API请求时，建立TCP连接失败，则把所述目标服务节点对应的链表结点从正常服务节点链表里移除，并加入到异常服务节点链表，然后跳回到步骤S3；

步骤S5，定时从异常服务节点链表中按照指针链接顺序，依次获取服务节点进行心跳检测，如果所述服务节点有正常心跳响应，则把所述服务节点对应的链表结点从异常服务节点链表中移除，并加入到正常服务节点链表。

优选的，所述步骤S1中，与服务节点可以正常建立TCP连接即为正常服务节点，与服务节点建立TCP连接失败即为异常服务节点。

优选的，所述步骤S1中，所述链表的每个结点用于存储一个服务节点的节点信息，每个链表结点包含一个数据域和一个指针域，所述指针域指向下一个结点。

优选的，所述步骤S1之后，还包括：

步骤S1B，使用头指针和尾指针记录链表首结点和尾结点的位置。

优选的，所述步骤S3中，所述数据域存储的是服务节点实际物理内存的地址指针。

优选的，所述服务节点实际物理内存存储的信息包括服务节点的IP、端口号、URL。

优选的，所述步骤S3中，在获取目标服务节点的时候，通过转发结点指针保存当前读取的结点的位置，每转发一个请求，所述转发结点指针向前移动一个链表结点。

优选的，所述步骤S3之后，还包括：

步骤S4A，如果向目标服务节点转发API请求时，TCP连接成功，但是转发请求失败，将请求失败提示语返回给请求方。

优选的，所述步骤S4中，从正常服务节点链表中移除的目标服务节点对应的链表结点，被加入到异常服务节点链表尾指针指向的链表结点和头指针指向的链表结点之间。

优选的，所述步骤S5中，从异常服务节点链表中移除的链表结点，被加入到正常服务节点链表尾指针指向的链表结点和头指针指向的链表结点之间。

本发明提供了一种使用链表来查询服务节点进而进行负载均衡的方法。对于系统中的每个微服务，通过两个链表来保存该微服务对应的节点信息，其中正常服务节点链表用于保存正常服务节点的节点信息，异常服务节点链表用于保存异常服务节点的节点信息。在正常服务节点链表中按照链表结点链接顺序，循环获取目标服务节点，并向目标服务节点转发API请求，如果某个服务节点建立TCP连接失败，则把该服务节点信息从正常服务节点链表中移除，加入到异常服务节点链表。定时从异常服务节点链表中按照顺序获取服务节点进行心跳检测，如果某个服务节点有正常心跳响应，则把该节点从异常服务节点链表中移除，加入到正常服务节点链表。本发明的方案，每个服务节点的信息单独存储，不需要申请连续性的内存块，当服务节点数量变化时，通过控制链表指针进行链表结点的插入和删除操作，不存在频繁的申请和释放内存块的操作，在服务运行过程中，内存占用量平稳，不会出现大的波动，因而不会导致严重的内存碎片化问题，系统响应时间和运行状态稳定。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明一种API网关负载均衡方法涉及的微服务架构下API网关负载均衡结构框图。

图2为本发明一种API网关负载均衡方法实施例提供的的步骤示意图。

图3为本发明一种API网关负载均衡方法实施例提供的链表结构及操作示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明总的思路是：对于系统中的每个微服务，通过两个循环链表来保存该微服务对应的节点信息，其中正常服务节点链表用于保存正常服务节点的节点信息，异常服务节点链表用于保存异常服务节点的节点信息，链表结点里保存的是服务结点实际物理内存地址指针。在正常服务节点链表中按照链表结点链接顺序循环获取目标服务节点，并向目标服务节点转发API请求，如果某个服务节点建立TCP连接失败，则把该服务节点信息从正常服务节点链表中移除，加入到异常服务节点链表。定时从异常服务节点链表中按照顺序取服务节点进行心跳检测，如果某个服务节点有正常心跳响应，则把该节点从异常服务节点链表中移除，加入到正常服务节点链表。

下面结合说明书附图对本发明实施例作进一步详细描述。应当理解，此处所描述的实施例仅用于说明和解释本发明，并不用于限定本发明。

本发明适用于微服务架构下API网关的负载均衡，也适用于类似高并发多服务节点系统的负载均衡。

图2为本发明一种API网关负载均衡方法实施例提供的的步骤示意图。如图2所示，本发明实施例提供了一种API网关负载均衡方法，所述方法包括以下步骤：

步骤S1，API网关为每个微服务创建两个链表，用于存储该微服务对应的服务节点的信息，其中，正常服务节点链表用于保存正常服务节点的节点信息，异常服务节点链表用于保存异常服务节点的节点信息，所述正常服务节点链表和异常服务节点链表均为循环链表；

本发明实施例中，如图1所示，API网关需要处理来自多个微服务的API请求，因此，对于每个微服务，都需要进行服务节点的信息维护。

所述步骤S1中，与服务节点可以正常建立TCP连接即为正常服务节点，与服务节点建立TCP连接失败即为异常服务节点。

本发明实施例中，通过向服务节点发送HTTP HEAD请求的方式，与服务节点建立TCP连接，测试服务节点TCP连接是否正常，服务是否可达。

图3为本发明一种API网关负载均衡方法实施例提供的链表结构及操作示意图。如图3所示，本发明实施例中，所述链表为循环链表，链表的每个结点用于存储一个服务节点的节点信息，每个链表结点包含一个数据域和一个指针域，所述指针域指向下一个结点。所述数据域存储的是服务节点实际物理内存的地址指针。所述服务节点实际物理内存存储的信息包括服务节点的IP、端口号、URL。

服务节点的信息既可以直接存储在链表结点的数据域，也可以单独申请物理存储空间进行存储，在链表结点的数据域中，存放实际物理存储空间的地址指针。通常，当服务节点的信息占用字节数较少时，可以直接将服务节点信息存储在链表结点的数据域中，反之，则可以单独申请物理存储空间用于存储服务节点信息。将服务节点信息单独存储，可以方便后续服务节点信息的扩展。物理节点实际物理内存存储的信息除了服务节点的IP、端口号、URL等，还可以用于存储其它信息，比如服务节点的编号、CPU占用率等状态信息、服务节点是否有效的标识信息等。

所述步骤S1之后，还包括：

步骤S1B，使用头指针和尾指针记录链表首结点和尾结点的位置。

本发明实施例中，没有单独设置链表头结点，因此，需要使用头指针和尾指针记录链表的首结点和尾结点，方便后续对链表进行插入、移除操作。

步骤S2，API网关接收API请求，将API请求与微服务建立一一对应关系；

本发明实施例中，API请求对应于多个微服务，需要由API网关进行路由转发，将API请求与微服务建立对应关系，确定应该处理对应API请求的微服务。

步骤S3，从API请求对应的微服务的正常服务节点链表中，按照链表结点指针链接顺序，获取目标服务节点，向所述目标服务节点转发API请求；

所述步骤S3中，在获取目标服务节点的时候，通过转发结点指针保存当前读取的结点的位置，每转发一个请求，所述转发结点指针向前移动一个链表结点。如此一来，将会按照链表结点指针链接方向，顺序循环遍历各服务节点，进行请求转发，每个服务节点转发的请求数基本是趋向于平均的。也可以结合各服务节点信息中的CPU占用率等字段进行服务节点选取策略优化。

所述步骤S3之后，还包括：

步骤S4A，如果向目标服务节点转发API请求时，TCP连接成功，但是转发请求失败，将请求失败提示语返回给请求方。

如果向目标服务节点转发API请求时，TCP连接成功，但是转发请求失败，说明目标服务节点是正常工作的，此时，可能是API请求的参数不正确，将目标服务节点返回的信息返回给请求方。

步骤S4，如果向所述目标服务节点转发API请求时，建立TCP连接失败，则把所述目标服务节点对应的链表结点从正常服务节点链表里移除，并加入到异常服务节点链表，然后跳回到步骤S3；

如果向目标节点转发API请求时，建立TCP连接失败，说明目标服务节点状态异常，无法访问，此时，从正常服务节点链表中获取目标节点的下一个链表结点，将API请求转发到所述链表结点对应的服务节点，直到转发成功或者遍历完所有服务节点或者TCP连接成功但是请求转发失败。

所述步骤S4中，从正常服务节点链表中移除的目标服务节点对应的链表结点，被加入到异常服务节点链表尾指针指向的链表结点和头指针指向的链表结点之间。

如图3所示，从正常服务节点链表中左边第一个链表结点获取目标服务节点信息，进行请求转发，如果转发成功，下一个API请求到来时，从左边第二个链表结点获取目标服务节点信息，进行请求转发，依次类推，当正常服务节点链表中的最右边一个链表结点对应的服务节点转发完请求之后，下一个API请求到来时，再从左边第一个链表结点获取目标服务节点信息，进行请求转发，如此循环。如果从正常服务节点链表中左边第一个链表结点获取目标服务节点信息，进行请求转发，但是建立TCP连接失败，则将该链表结点从正常服务结点链表移除，添加到异常服务结点链表中最右边一个链表结点和最左边一个链表结点中间，即异常服务结点链表中尾指针指向的链表结点和头指针指向的链表结点之间。

步骤S5，定时从异常服务节点链表中按照指针链接顺序，依次获取服务节点进行心跳检测，如果所述服务节点有正常心跳响应，则把所述服务节点对应的链表结点从异常服务节点链表中移除，并加入到正常服务节点链表。

本发明实施例中，通过向目标服务节点发送HTTP HEAD请求的方式，进行心跳检测。心跳检测的周期可以根据具体需要设定和调整。

所述步骤S5中，从异常服务节点链表中移除的链表结点，被加入到正常服务节点链表尾指针指向的链表结点和头指针指向的链表结点之间。

如图3所示，在每个心跳检测周期，从异常服务节点链表头指针对应的结点，比如图3中左边第一个链表结点获取目标服务节点信息，进行心跳检测，如果检测正常，即有正常的心跳响应，则将该链表结点从异常服务节点链表中移除，添加到正常服务结点链表中最右边一个链表结点和最左边一个链表结点中间，即正常服务结点链表中尾指针指向的链表结点和头指针指向的链表结点之间。如果异常服务节点链表中左边第一个链表结点没有心跳响应，则从左边第二个链表结点获取服务节点信息，进行心跳检测，依次类推，当异常服务节点链表中的最右边一个链表结点即尾结点指针对应的结点对应的服务节点心跳检测完毕之后，停止本检测周期的心跳检测工作。

需要说明的是，图3中所示的正常服务结点链表和异常服务结点链表为双向循环列表，本发明一些实施例中没有用到prev指针域，在本发明另一些实施例中，可以用prev指针域进行问题定位与追溯。因此，prev指针域并不是必需的，可以根据实际需求进行设置。另外，图3中的链表结构没有设置链表头结点，如果有必要，也可以设置链表头结点。

本发明提供了一种使用链表来查询服务节点进而进行负载均衡的方法。对于系统中的每个微服务，通过两个链表来保存该微服务对应的节点信息，其中正常服务节点链表用于保存正常服务节点的节点信息，异常服务节点链表用于保存异常服务节点的节点信息。在正常服务节点链表中按照链表结点链接顺序，循环获取目标服务节点，并向目标服务节点转发API请求，如果某个服务节点建立TCP连接失败，则把该服务节点信息从正常服务节点链表中移除，加入到异常服务节点链表。定时从异常服务节点链表中按照顺序获取服务节点进行心跳检测，如果某个服务节点有正常心跳响应，则把该节点从异常服务节点链表中移除，加入到正常服务节点链表。本发明的方案，每个服务节点的信息单独存储，不需要申请连续性的内存块，当服务节点数量变化时，通过控制链表指针进行链表结点的插入和删除操作，不存在频繁的申请和释放内存块的操作，在服务运行过程中，内存占用量平稳，不会出现大的波动，因而不会导致严重的内存碎片化问题，系统响应时间和运行状态稳定。

以上仅为本发明的具体实施方式，不能以此来限定本发明的范围，本技术领域内的一般技术人员根据本创作所作的均等变化，以及本领域内技术人员熟知的改变，都应仍属本发明涵盖的范围。

Claims (5)

1.一种API网关负载均衡方法，其特征在于，所述方法包括以下步骤：

步骤S1，API网关为每个微服务创建两个链表，用于存储该微服务对应的服务节点的信息，其中，正常服务节点链表用于保存正常服务节点的节点信息，异常服务节点链表用于保存异常服务节点的节点信息，所述正常服务节点链表和异常服务节点链表均为循环链表；

步骤S2，API网关接收API请求，将API请求与微服务建立一一对应关系；

步骤S3，从API请求对应的微服务的正常服务节点链表中，按照链表结点指针链接顺序，获取目标服务节点，向所述目标服务节点转发API请求；

步骤S4，如果向所述目标服务节点转发API请求时，建立TCP连接失败，则把所述目标服务节点对应的链表结点从正常服务节点链表里移除，并加入到异常服务节点链表，然后跳回到步骤S3；

步骤S5，定时从异常服务节点链表中按照指针链接顺序，依次获取服务节点进行心跳检测，如果所述服务节点有正常心跳响应，则把所述服务节点对应的链表结点从异常服务节点链表中移除，并加入到正常服务节点链表；

所述步骤S1中，所述链表的每个结点用于存储一个服务节点的节点信息，每个链表结点包含一个数据域和一个指针域，所述指针域指向下一个结点；

所述步骤S1之后，还包括：

步骤S1B，使用头指针和尾指针记录链表首结点和尾结点的位置；

所述步骤S3中，在获取目标服务节点的时候，通过转发结点指针保存当前读取的结点的位置，每转发一个请求，所述转发结点指针向前移动一个链表结点；

所述步骤S4中，从正常服务节点链表中移除的目标服务节点对应的链表结点，被加入到异常服务节点链表尾指针指向的链表结点和头指针指向的链表结点之间；

所述步骤S5中，从异常服务节点链表中移除的链表结点，被加入到正常服务节点链表尾指针指向的链表结点和头指针指向的链表结点之间。

2.根据权利要求1所述的API网关负载均衡方法，其特征在于，所述步骤S1中，与服务节点可以正常建立TCP连接即为正常服务节点，与服务节点建立TCP连接失败即为异常服务节点。

3.根据权利要求1所述的API网关负载均衡方法，其特征在于，所述步骤S3中，所述数据域存储的是服务节点实际物理内存的地址指针。

4.根据权利要求3所述的API网关负载均衡方法，其特征在于，所述服务节点实际物理内存存储的信息包括服务节点的IP、端口号、URL。

5.根据权利要求1所述的API网关负载均衡方法，其特征在于，所述步骤S3之后，还包括：

步骤S4A，如果向目标服务节点转发API请求时，TCP连接成功，但是转发请求失败，将请求失败提示语返回给请求方。