CN110912972A

CN110912972A - 一种业务处理方法、***、电子设备及可读存储介质

Info

Publication number: CN110912972A
Application number: CN201911083305.2A
Authority: CN
Inventors: 王洪泉; 吴栋
Original assignee: Beijing Inspur Data Technology Co Ltd
Current assignee: Beijing Inspur Data Technology Co Ltd
Priority date: 2019-11-07
Filing date: 2019-11-07
Publication date: 2020-03-24
Anticipated expiration: 2039-11-07
Also published as: CN110912972B

Abstract

本申请公开了一种业务处理方法，区别于现有技术Ingress+Service+Pod的架构，本申请提供了一种新Ingress+Pod的新架构，新Ingress中通过额外增设自定义控制器，不仅可实现对下层Pod运行状态的被动监听，通过负载工具还能够实现主动式的健康检查，使得在接收到传入的待处理业务时，可以及时的确定当前的可用Pod，并将其下发。由于去除了传统方案中的Service层，其弊端也就不复存在。换句话说，由于通过对不必要层次的精简和整合，克服了传统方案中Service层的弊端，提升了服务注册发现的效率，可有效防止由于Pod状态更新不及时出现的业务中断现象。本申请还公开了一种业务处理***、电子设备及可读存储介质，具有上述有益效果。

Description

一种业务处理方法、***、电子设备及可读存储介质

技术领域

本申请涉及Kubernetes技术领域，特别涉及一种应用在Ingress层的业务处理方法、***、电子设备及可读存储介质。

背景技术

随着信息技术的发展，云计算已经逐步成为了业界的发展热点，云计算技术也逐渐被应用到教育、科学、文化、公安、政府、卫生、高性能计算、电子商务、物联网等多个领域，随之云计算服务平台的使用量和活跃度也与日俱增。随着云计算的发展，云计算集群越来越庞大，越来越复杂，如何利用好集群资源，既满足业务需求，又节能减排提高资源使用率，将是技术工作者必须攻关的难题。

Kubernetes本身提供了一套服务注册发现的方案：Ingress+Service，即Kubernetes通过Service负载多个副本pod服务，并通过轮询的方式等实现负载均衡。这一方案的架构示意图可参见图1。即Service作为Ingress的下层、作为各Pod的上层，处于中间层，其设计之初是将Service作为各Pod总代理的角色来实现负载均衡。但是Service设计的本身有难以解决的弊病：不能主动感知pod应用的异常，只能通过被动监听Pod状态、被动接受Pod应用的异常通知，当node down掉后(Pod建立在node上)，Kubernetes通常超过5分钟才能将其认定为异常状态，在此之前Service仍会将负载分配给该Pod。但实际上该Pod已经无法对负载进行处理，处于不可用状态，因此就会导致业务未被处理、依赖于此的后续业务无法进行进行，导致业务中断等问题。

该服务注册发现方案在使用之初，其5分钟的区离时间是能够满足当时的要求，而随着信息技术的发展、要求的逐步提高，该区离时间已经无法满足当前的要求。因此，如何提供一种更优的服务注册发现方案，提升服务注册发现效率、防止业务中断等问题，是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种业务处理方法、***、电子设备及可读存储介质，旨在提升服务注册发现效率、防止业务中断的发生。

为实现上述目的，本申请提供了一种应用于Kubernetes中Ingress层的业务处理方法，该方法包括：

接收传入的待处理业务；

根据所述待处理业务，通过自定义控制器获取可用Pod列表；所述自定义控制器预置在所述Ingress层中，所述自定义控制器与各Pod建立有数据连接，可通过主动式的健康检查机制确定各Pod中的可用Pod，所述可用Pod列表中记录有各所述可用Pod的身份信息；

根据预设负载均衡策略从所述可用Pod列表中选定目标Pod；

将所述待处理业务下发给所述目标Pod。

可选的，根据所述待处理业务，通过自定义控制器获取可用Pod列表，包括：

确定所述待处理业务的目标资源类型；预先为每种待处理业务设置有相应的资源类型；

确定与所述目标资源类型对应的初始Pod列表；所述初始Pod列表中包括所有被分配处理资源类型为所述目标资源类型的Pod的身份信息；

控制所述自定义控制器将所述初始Pod列表中的身份信息全部刷新到Nginx中；

控制所述Nginx对每个Pod执行健康检查操作，得到各所述可用Pod；

根据各所述可用Pod的身份信息生成所述可用Pod列表。

可选的，该业务处理方法还包括：

控制所述自定义控制器监听各所述Pod的运行状态信息；

控制所述自定义控制器根据所述运行状态信息将最新信息更新至所述Nginx中。

可选的，根据预设负载均衡策略从所述可用Pod列表中选定目标Pod，包括：

获取所述可用Pod列表中每个所述可用Pod的当前负载；

比较各所述当前负载，将对应最小当前负载的可用Pod选定为所述目标Pod。

可选的，为实现上述目的，本申请还提供了一种业务处理***，应用于Kubernetes中的Ingress层，该***包括：

待处理业务接收单元，用于接收传入的待处理业务；

可用Pod列表获取单元，用于根据所述待处理业务，通过自定义控制器获取可用Pod列表；所述自定义控制器预置在所述Ingress层中，所述自定义控制器与各Pod建立有数据连接，可通过主动式的健康检查机制确定各Pod中的可用Pod，所述可用Pod列表中记录有各所述可用Pod的身份信息；

目标Pod选定单元，用于根据预设负载均衡策略从所述可用Pod列表中选定目标Pod；

待处理业务下发单元，用于将所述待处理业务下发给所述目标Pod。

可选的，所述可用Pod列表获取单元包括：

目标资源类型确定子单元，用于确定所述待处理业务的目标资源类型；其中，预先为每种待处理业务设置有相应的资源类型；

初始Pod列表确定子单元，用于确定与所述目标资源类型对应的初始Pod列表；其中，所述初始Pod列表中包括所有被分配处理资源类型为所述目标资源类型的Pod的身份信息；

信息刷新至Nginx子单元，用于控制所述自定义控制器将所述初始Pod列表中的身份信息全部刷新到Nginx中；

主动式健康检查操作执行子单元，用于控制所述Nginx对每个Pod执行健康检查操作，得到各所述可用Pod；

可用Pod列表生成子单元，用于根据各所述可用Pod的身份信息生成所述可用Pod列表。

可选的，该业务处理***还包括：

运行状态信息被动监听单元，用于控制所述自定义控制器监听各所述Pod的运行状态信息；

信息更新单元，用于控制所述自定义控制器根据所述运行状态信息将最新信息更新至所述Nginx中。

可选的，所述目标Pod选定单元包括：

当前负载获取子单元，用于获取所述可用Pod列表中每个所述可用Pod的当前负载；

负载比较及选取子单元，用于比较各所述当前负载，将对应最小当前负载的可用Pod选定为所述目标Pod。

为实现上述目的，本申请还提供了一种电子设备，该电子设备包括：

存储器，用于存储计算机程序；

处理器，用于在执行所述计算机程序时实现如上述内容所描述的应用于Kubernetes中Ingress层的业务处理方法的各步骤。

为实现上述目的，本申请还提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器调用并执行时可实现如上述内容所描述的应用于Kubernetes中Ingress层的业务处理方法的各步骤。

本申请提供了一种应用于Kubernetes中的Ingress层的业务处理方法，包括：接收传入的待处理业务；根据所述待处理业务，通过自定义控制器获取可用Pod列表；所述自定义控制器预置在所述Ingress层中，所述自定义控制器与各Pod建立有数据连接，可通过主动式的健康检查机制确定各Pod中的可用Pod，所述可用Pod列表中记录有各所述可用Pod的身份信息；根据预设负载均衡策略从所述可用Pod列表中选定目标Pod；将所述待处理业务下发给所述目标Pod。

根据本申请所提供的业务处理方法可知，区别于现有技术Ingress+Service+Pod的架构，本申请提供了一种新Ingress+Pod的新架构，新Ingress中通过额外增设自定义控制器，不仅可实现对下层Pod运行状态的被动监听，通过合适的处理还能够实现主动式的健康检查，使得在新Ingress层在接收到传入的待处理业务时，可以及时的确定当前的可用Pod，并将其下发给可用Pod，不会再出现由于传统方案Service层存在的弊端导致的不及时问题。换句话说，由于通过不必要层次的精简和整合，克服了传统方案中Service层的弊端，提升了服务注册发现的效率，有效防止了由于Pod状态更新不及时导致的业务中断现象的再次出现。

本申请同时还提供了一种业务处理***、电子设备及可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为现有技术使用的Kubernetes服务注册发现方案的结构示意图；

图2为本申请实施例提供的一种业务处理方法的流程图；

图3为本申请实施例提供的一种对应于图2所示方案的Kubernetes新型服务注册发现方案的结构示意图；

图4为本实施例提供的一种基于Nginx的获取可用Pod列表的方法的流程图；

图5为本实施例提供的一种实际代码运行图；

图6为本申请实施例提供的一种自定义控制器被动监听方案的流程图；

图7为本申请实施例提供的一种对应于图4方案的具体时序图；

图8为本申请实施例提供的一种对应于图6方案的具体时序图；

图9为本申请实施例提供的一种Nginx运行原理和效果的示意图；

图10为本申请实施例提供的另一种Nginx运行原理和效果的示意图；

图11为本申请实施例提供的一种基于最小负载选取目标Pod的方法的流程图；

图12为本申请实施例提供的一种业务处理***的结构框图。

具体实施方式

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

请参见图2，图2为本申请实施例所提供的一种业务处理方法的流程图，需要说明的是，图2中的各步骤的执行主体均为Kubernetes中的Ingress层，即下述步骤将通过描述本申请中的Ingress层将如何对待处理业务进行处理的角度，区别传统方案中的Ingress层，其包括以下步骤：

S101：接收传入的待处理业务；

其中，该待处理业务来自于集群上层，该待处理业务中至少包含有描述该待处理业务相关参数的信息，可以包括待处理业务的类型、处理要求、待处理业务的大小，以及其它根据实际应用场景中要求的特殊信息，此处不做具体限定。

S102：根据待处理业务，通过自定义控制器获取可用Pod列表；

其中，该自定义控制器预置在该Ingress层中，该自定义控制器与各Pod建立有数据连接，可通过主动式的健康检查机制确定各Pod中的可用Pod，该可用Pod列表中记录有各该可用Pod的身份信息。其中，主动式的健康检查机制通常可交由Nginx、apache、traffic以及其它可实现类似效果的负载工具完成。

其中，自定义控制器是本申请在Ingress层中区别于常规方案中的Ingress所新设置的，该自定义控制器通过与上述负载工具联动可实现在去除Service层的基础上更好的完成Pod状态确认、负载均衡的工作，同时，也由于去除了传统方案中的显得多余的Service层，使得步骤得到了精简，提升了效率。

在S101的基础上，本步骤旨在由新Ingress层通过层内新增设的自定义控制器与诸如Nginx等负载工具的联动，在去除原Service层、直接由新Ingress层与各Pod直接建立数据连接的情况下(参见如图3所示的新型架构示意图)，不仅没有丢失原Service层的原有功能，甚至还能够在Pod状态确认、负载均衡策略方面做得更好(由诸如Nginx等负载工具的可拓展性带来)，即获取到负责处理该待处理业务的可用Pod列表。由于通过自定义控制器和诸如Nginx等负载工具的作用，使得形成的可用Pod列表中记录的都是当前可用的Pod，因此不会出现向存在异常、不可用的Pod下发负载任务的情况。

为便于理解本步骤的具体执行过程，本申请还以Nginx负载工具为例，提供了一种如图4流程图所示的具体实现方案，包括如下步骤：

S201：确定待处理业务的目标资源类型；

S202：控制自定义控制器确定与目标资源类型对应的初始Pod列表；

由于集群的复杂性，本具体方案中还预先为不同的待处理业务设置为不同的资源类型，并为不同资源类型分配了相应的Pod组(包括多个Pod)，使得不同的Pod仅需负责其处理对应资源类型的待处理业务。

自定义资源类型可以为PIngress，对应关系可以通过Selecter的方式指定相应的代理Pod来实现。

初始Pod列表中包括所有被分配处理资源类型为目标资源类型的Pod的身份信息。

自定义控制器(controller)根据PIngress提供的资源类型标签指导与该标签中描述的资源类型对应的Pod列表(即该初始Pod列表)。可参见如图5所示的实际代码运行图。

S203：控制自定义控制器将初始Pod列表中的身份信息全部刷新到Nginx中；

在S202的基础上，自定义控制器自动将该初始Pod列表中的各Pod舒心到Nginx中，以供Nginx对刷新至其中的各Pod进行主动式的运行状态确认。

S204：控制Nginx对每个Pod执行健康检查操作，得到各可用Pod；

在S203的基础上，Nginx将会对刷新至其中的各Pod进行主动式的健康检查操作，从而根据健康检查操作的结果确定出哪些Pod是当前的可用Pod。

其中，该健康检查操作可通过多种方式实现，例如像Pod发送握手包、测试包或者发送一条自定义、可识别命名等等，目的在于能够让Pod响应于Nginx发出的询问信号，以便让Nginx确定其是否处于可用状态。

S205：根据各可用Pod的身份信息生成可用Pod列表。

在S204的基础上，本步骤旨在根据各可用Pod的身份信息生成可用Pod列表。

进一步的，该自定义控制器还可以监控来自上层的Pod增删、调整事件，从而对初始Pod列表中的信息进行调整，同时，还可以保留原Service层的被动监听功能，被动接收来自各Pod的反馈信息，从而根据该反馈信息自行先对初始Pod列表中的信息进行调整，从而尽可能的减轻主动健康机制所需执行的操作量。

一种包括但不限于的实现方式可以参见如图6所示的流程图：

S301：控制自定义控制器监听各Pod的运行状态信息；

S302：控制自定义控制器根据运行状态信息将最新信息更新至Nginx中。

包括图4和图6所示方案的更具体实现过程，可参见如图7和图8所示的时序图，该时序图对各部分如何交互实现这一过程进行了详细说明，针对Nginx这个负载工具，本申请也提供了图9和图10对其工作原理和效果进行了描述。

S103：根据预设负载均衡策略从可用Pod列表中选定目标Pod；

在S102的基础上，本步骤旨在根据预设的负载均衡策略从可用Pod列表中选取出合适的可用Pod作为目标Pod。其中，区别于传统由Service层带来的唯一的轮询的负载均衡策略，Nginx等负载工具由于其可拓展性和多样性，其能够支持更多样的负载均衡策略，例如负载最小策略(总选择多个Pod中当前负载最小)、分组策略、数据大小策略、请求响应时间策略、重要性策略等等。

为便于理解，此处以负载最小策略为例，给出一种具体的实现方式，请参见如图11所示的流程图，包括如下步骤：

S401：获取可用Pod列表中每个可用Pod的当前负载；

S402：比较各当前负载，将对应最小当前负载的可用Pod选定为目标Pod。

S104：将待处理业务下发给目标Pod。

在S103确定出目标Pod的基础上，本步骤旨在由新Ingress层将待处理业务下发给该目标Pod。

基于本实施例提供的一种业务处理方法可知，区别于现有技术Ingress+Service+Pod的架构，本申请提供了一种新Ingress+Pod的新架构，新Ingress中通过额外增设自定义控制器，不仅可实现对下层Pod运行状态的被动监听，通过合适的处理还能够实现主动式的健康检查，使得在新Ingress层在接收到传入的待处理业务时，可以及时的确定当前的可用Pod，并将其下发给可用Pod，不会再出现由于传统方案Service层存在的弊端导致的不及时问题。换句话说，由于通过不必要层次的精简和整合，克服了传统方案中Service层的弊端，提升了服务注册发现的效率，有效防止了也Pod状态更新不及时导致的业务中断现象的再次出现。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

下面请参见图12，图12为本申请实施例所提供的一种业务处理***的结构框图，该***可以包括：

待处理业务接收单元100，用于接收传入的待处理业务；

可用Pod列表获取单元200，用于根据待处理业务，通过自定义控制器获取可用Pod列表；自定义控制器预置在Ingress层中，自定义控制器与各Pod建立有数据连接，可通过主动式的健康检查机制确定各Pod中的可用Pod，可用Pod列表中记录有各可用Pod的身份信息；

目标Pod选定单元300，用于根据预设负载均衡策略从可用Pod列表中选定目标Pod；

待处理业务下发单元400，用于将待处理业务下发给目标Pod。

其中，该可用Pod列表获取单元200可以包括：

目标资源类型确定子单元，用于确定待处理业务的目标资源类型；其中，预先为每种待处理业务设置有相应的资源类型；

初始Pod列表确定子单元，用于确定与目标资源类型对应的初始Pod列表；其中，初始Pod列表中包括所有被分配处理资源类型为目标资源类型的Pod的身份信息；

信息刷新至Nginx子单元，用于控制自定义控制器将初始Pod列表中的身份信息全部刷新到Nginx中；

主动式健康检查操作执行子单元，用于控制Nginx对每个Pod执行健康检查操作，得到各可用Pod；

可用Pod列表生成子单元，用于根据各可用Pod的身份信息生成可用Pod列表。

进一步的，该业务处理***还可以包括：

运行状态信息被动监听单元，用于控制自定义控制器监听各Pod的运行状态信息；

信息更新单元，用于控制自定义控制器根据运行状态信息将最新信息更新至Nginx中。

其中，该目标Pod选定单元300可以包括：

当前负载获取子单元，用于获取可用Pod列表中每个可用Pod的当前负载；

负载比较及选取子单元，用于比较各当前负载，将对应最小当前负载的可用Pod选定为目标Pod。

本实施例作为对应于上述方法实施例的***实施例存在，具有方法实施例的全部有益效果，在此不再赘述。

基于上述实施例，本申请还提供了一种电子设备，该电子设备可以包括存储器和处理器，其中，该存储器中存有计算机程序，该处理器在调用该存储器中的计算机程序时，可以实现上述实施例所提供的各步骤。当然，该电子设备还可以包括各种必要的网络接口、电源以及其它零部件等。

本申请还提供了一种可读存储介质，其上存有计算机程序，该计算机程序被执行终端或处理器执行时可以实现上述实施例所提供的各步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims

1.一种业务处理方法，其特征在于，应用于Kubernetes中的Ingress层，包括：

接收传入的待处理业务；

根据预设负载均衡策略从所述可用Pod列表中选定目标Pod；

将所述待处理业务下发给所述目标Pod。

2.根据权利要求1所述的业务处理方法，其特征在于，根据所述待处理业务，通过自定义控制器获取可用Pod列表，包括：

根据各所述可用Pod的身份信息生成所述可用Pod列表。

3.根据权利要求2所述的业务处理方法，其特征在于，还包括：

控制所述自定义控制器监听各所述Pod的运行状态信息；

4.根据权利要求1至3任一项所述的业务处理方法，其特征在于，根据预设负载均衡策略从所述可用Pod列表中选定目标Pod，包括：

获取所述可用Pod列表中每个所述可用Pod的当前负载；

5.一种业务处理***，其特征在于，应用于Kubernetes中的Ingress层，包括：

待处理业务接收单元，用于接收传入的待处理业务；

6.根据权利要求5所述的业务处理***，其特征在于，所述可用Pod列表获取单元包括：

7.根据权利要求6所述的业务处理***，其特征在于，还包括：

8.根据权利要求5至7任一项所述的业务处理***，其特征在于，所述目标Pod选定单元包括：

9.一种电子设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于在执行所述计算机程序时，可实现如权利要求1至4任一项所述的业务处理方法的各步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质存储有计算机程序，所述计算机程序在被处理器调用并执行时，可实现如权利要求1至4任一项所述的业务处理方法的各步骤。