一种负载均衡的方法及装置

技术领域

本发明涉及数据处理技术领域，尤其涉及一种负载均衡的方法及装置。

背景技术

随着金融科技，尤其是互联网科技金融的不断发展，越来越多的技术(如分布式、区块链(Blockchain)、人工智能等)应用在金融领域，但金融业也对技术提出了更高的要求，如对金融业的各服务器的负载均衡的处理也有更高的要求。

目前主流互联网企业或金融企业采用廉价的软硬件通过分布式多活+灾备架构方式部署，确保系统的可靠性和稳定性。以银行等金融系统为例，应用服务器部署普遍采用同城多活，异地灾备的两地三中心架构，以确保应用服务的可靠性。

而分布式的应用多活架构下，首先需要解决的是，如何实现联机交易和批量交易在应用层面的负载均衡，而现有主流厂商均采用如下算法：轮询算法、加权轮询算法、最少连接数算法、固定权重算法、加权最少连接数、源IP哈希算法等。

现有的负载均衡方案中，多为简单的任务数量的均衡，并没有考虑应用实例本身的处理能力，当有计算密集型的交易请求下发到资源空闲不足的应用实例处理时，会导致出现应用实例处理交易请求的资源紧张的问题，降低了应用实例的处理效率。

发明内容

本发明实施例提供一种负载均衡的方法及装置，用以实现合理安排不同交易类型的交易请求，提高应用实例的处理效率。

第一方面，本发明实施例提供一种负载均衡的方法，包括：

获取前置交易系统发送的交易请求，所述交易请求包括交易类型；

从应用实例负载加权得分表中确定出当前时刻处理所述交易类型的应用实例；其中，所述应用实例负载加权得分表中各应用实例负载加权得分是由当前时刻各应用实例的资源状态包和各资源的权重因子确定的；所述各资源的权重因子是由各应用实例的历史单次资源消耗情况和各资源的总值确定的；

将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统，以使所述前置交易系统将所述交易请求下发给所述当前时刻处理所述交易类型的应用实例进行处理。

上述技术方案中，在选取处理交易请求的应用实例时，依据通过历史单次资源消耗情况确定的各资源的权重因子和当前时刻的资源状态包得到的负载加权得分，可以确定出资源空闲且处理高效的应用实例，提高了负载均衡的准确度，并提高了应用实例的处理效率。

可选的，所述由各应用实例的历史单次资源消耗情况和各资源的总值确定所述各资源的权重因子，包括：

周期性的获取各应用实例的处理各交易类型的交易请求的历史单次资源消耗情况；

以交易类型为维度，计算各应用实例的历史单次资源消耗情况的正态分布，将概率最高的资源消耗值确定为当前时刻各应用实例的各资源的预估消耗值；

依据所述当前时刻各应用实例的各资源的预估消耗值和各资源的总值，计算所述各资源的消耗占比；

依据所述各资源的消耗占比计算各资源的权重因子。

上述技术方案中，由于计算各资源的权重因子时，充分考虑了各应用实例的历史单次资源消耗情况，使得预估的当前时刻处理相同交易类型的交易请求的消耗值更为准确，从而能够提高应用实例的处理效率。

可选的，所述由当前时刻各应用实例的资源状态包和各资源的权重因子确定所述各应用实例负载加权得分，包括：

获取当前时刻各应用实例的资源状态包和所述资源状态包中各资源对应的权重因子；

对所述资源状态包中各资源的值和各资源对应的权重因子进行加权计算，得到所述各应用实例负载加权得分。

可选的，所述当前时刻各应用实例的资源状态包是由各应用实例通过心跳报文上报的或在预设时间内未收到心跳报文时向未收到心跳报文的应用实例发送心跳探测报文后得到的或各应用实例处理交易请求时实时上报的。

可选的，所述方法还包括：

在向所述未收到心跳报文的应用实例发送心跳探测报文后未收到心跳探测结果，则将所述未收到心跳报文的应用实例从待分配应用实例列表中删除。

可选的，所述将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统之后，还包括：

接收所述当前时刻处理所述交易类型的应用实例实时上报的处理所述交易请求时的资源状态包；

依据所述处理所述交易请求时的资源状态包和接收到所述交易请求时的资源状态包，计算所述当前时刻处理所述交易类型的应用实例处理所述交易类型的交易请求的单次资源消耗情况；

将所述处理所述交易类型的交易请求的单次资源消耗情况存储到所述当前时刻处理所述交易类型的应用实例的历史单次资源消耗情况库中。

可选的，所述从应用实例负载加权得分表中确定出当前时刻处理所述交易类型的应用实例，包括：

将所述应用实例负责加权得分表中交易类型相同且负载加权得分最高的应用实例确定为当前时刻处理所述交易类型的应用实例。

第二方面，本发明实施例提供一种负载均衡的装置，包括：

收发单元，用于获取前置交易系统发送的交易请求，所述交易请求包括交易类型；

处理单元，用于从应用实例负载加权得分表中确定出当前时刻处理所述交易类型的应用实例；其中，所述应用实例负载加权得分表中各应用实例负载加权得分是由当前时刻各应用实例的资源状态包和各资源的权重因子确定的；所述各资源的权重因子是由各应用实例的历史单次资源消耗情况和各资源的总值确定的；

所述收发单元，还用于将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统，以使所述前置交易系统将所述交易请求下发给所述当前时刻处理所述交易类型的应用实例进行处理。

可选的，所述处理单元具体用于：

周期性的获取各应用实例的处理各交易类型的交易请求的历史单次资源消耗情况；

以交易类型为维度，计算各应用实例的历史单次资源消耗情况的正态分布，将概率最高的资源消耗值确定为当前时刻各应用实例的各资源的预估消耗值；

依据所述当前时刻各应用实例的各资源的预估消耗值和各资源的总值，计算所述各资源的消耗占比；

依据所述各资源的消耗占比计算各资源的权重因子。

可选的，所述处理单元具体用于：

获取当前时刻各应用实例的资源状态包和所述资源状态包中各资源对应的权重因子；

对所述资源状态包中各资源的值和各资源对应的权重因子进行加权计算，得到所述各应用实例负载加权得分。

可选的，所述当前时刻各应用实例的资源状态包是由各应用实例通过心跳报文上报的或在预设时间内未收到心跳报文时向未收到心跳报文的应用实例发送心跳探测报文后得到的或各应用实例处理交易请求时实时上报的。

可选的，所述处理单元还用于：

在向所述未收到心跳报文的应用实例发送心跳探测报文后未收到心跳探测结果，则将所述未收到心跳报文的应用实例从待分配应用实例列表中删除。

可选的，所述处理单元还用于：

所述将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统之后，接收所述当前时刻处理所述交易类型的应用实例实时上报的处理所述交易请求时的资源状态包；

依据所述处理所述交易请求时的资源状态包和接收到所述交易请求时的资源状态包，计算所述当前时刻处理所述交易类型的应用实例处理所述交易类型的交易请求的单次资源消耗情况；

将所述处理所述交易类型的交易请求的单次资源消耗情况存储到所述当前时刻处理所述交易类型的应用实例的历史单次资源消耗情况库中。

可选的，所述处理单元具体用于：

将所述应用实例负责加权得分表中交易类型相同且负载加权得分最高的应用实例确定为当前时刻处理所述交易类型的应用实例。

第三方面，本发明实施例还提供一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述负载均衡的方法。

第四方面，本发明实施例还提供一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行所述计算机可读指令时，使得计算机执行上述负载均衡的方法。

附图说明

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

图1为本发明实施例提供的一种系统架构的示意图；

图2为本发明实施例提供的一种负载均衡的方法的流程示意图；

图3为本发明实施例提供的一种资源状态包报文的示意图；

图4为本发明实施例提供的一种主动探测心跳的示意图；

图5为本发明实施例提供的一种负载均衡的示意图；

图6为本发明实施例提供的一种负载均衡的装置的结构示意图。

具体实施方式

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

图1为本发明实施例提供的一种系统架构。如图1所示，该系统架构可以包括前置交易系统100、负载均衡配置中心200和业务处理系统300。

其中，前置交易系统100用于发送交易请求或任务的系统，其在向业务处理系统300下发交易请求或任务之前，需要向负载均衡配置中心200发送交易请求，以获取处理与该交易请求的交易类型相同的应用实例。

负载均衡配置中心200用于获取各应用实例上报的资源状态包，运行负载均衡算法，并依据前置交易系统100的请求，确定出处理高效的应用实例。

该业务处理系统300部署有多个应用实例，每个应用实例相当于一个服务器，用以处理前置交易系统100下发的交易请求或任务。

需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。

基于上述描述，图2详细的示出了本发明实施例提供的一种负载均衡的方法的流程，该流程可以由负载均衡的装置执行。

如图2所示，该流程具体包括：

步骤201，获取前置交易系统发送的交易请求。

在本发明实施例中，该交易请求中包括了交易类型，以通过交易类型来选取能够处理该交易类型的交易请求的应用实例。

步骤202，从应用实例负载加权得分表中确定出当前时刻处理所述交易类型的应用实例。

主要是将应用实例负责加权得分表中交易类型相同且负载加权得分最高的应用实例确定为当前时刻处理交易类型的应用实例。

其中，该应用实例负载加权得分表中各应用实例负载加权得分是由当前时刻各应用实例的资源状态包和各资源的权重因子确定的，具体的需要先当前时刻各应用实例的资源状态包和资源状态包中各资源对应的权重因子，再对资源状态包中各资源的值和各资源对应的权重因子进行加权计算，得到各应用实例负载加权得分。

在本发明实施例中，该资源状态包中的各资源可以包括但不限于CPU(CentralProcessing Unit，中央处理器)资源使用率、IO(Input/Output，输入/输出)使用率、内存剩余空间、应用实例与DB(Data Base，数据库)是否同IDC(Internet Data Center，互联网数据中心)、进程并发线程数、应用实例与DB跨IDC网络带宽延迟等资源信息。

其中，CPU利用率可以通过linux下top命令，获取应用实例的当前CPU利用率及空闲率。IO利用率可以通过linux下iostat命令，获取应用实例磁盘IO利用率及空闲率。内存剩余空间可以通过linux下free命令，获取应用实例当前剩余内存，通过top命令获取业务处理系统的进程内存占用量。应用与DB是否同IDC可以在部署交易系统B在不同IDC的应用实例时，通过环境变量参数获取应用实例所在IDC。进程并发线程数可以通过linux下的ps命令，获取业务处理系统的进程当前运行线程数。

资源状态包的报文可以采用json格式协议，其报文内容的格式可以如图3所示。

上述资源状态包中的各资源对应的权重因子可以从权重因子库中读取，当前接收到某应用实例上报的资源状态包后，可以触发系统资源加权的负载均衡计算逻辑，从而从权重因子库中读取该应用实例上报的资源状态包中各资源对应的权重因子。

权重因子的存储方式可以通过关系型数据库来实现，表结构可以如表1所示。

表1

当读取到权重因子后，就可以和当前时刻的资源状态包进行加权计算得到负载加权得分。其计算公式可以如下所示：

score＝W

其中，score为负载加权得分。W

上述负载加权得分可以存储在数据库的应用实例负载加权得分表中，表结构可以如表2所示，该表主键为应用实例ID和业务处理系统标识ID，应用实例ID通常为实例分配IP，业务处理系统标识ID通常为统一分配的系统标识ID或名称。

表2

此外，上应用实例负载加权得分表和应用实例上报的资源状态包可以存储到应用实例资源上报记录表中，其表结构可以如表3所示。

表3

上述各资源的权重因子是由各应用实例的历史单次资源消耗情况和各资源的总值确定的。具体的，可以周期性的获取各应用实例的处理各交易类型的交易请求的历史单次资源消耗情况。并以交易类型为维度，计算各应用实例的历史单次资源消耗情况的正态分布，将概率最高的资源消耗值确定为当前时刻各应用实例的各资源的预估消耗值。然后依据当前时刻各应用实例的各资源的预估消耗值和各资源的总值，计算各资源的消耗占比。最后依据各资源的消耗占比计算各资源的权重因子。

此处需要先预估应用实例的各资源的预估消耗值，其可以读取历史单次资源消耗情况库中的历史单次资源消耗情况，通过资源消耗计算模型来进行预估各个交易类型的资源消耗。例如，在预估交易类型typeA的资源消耗情况时，会将该应用实例n的处理该交易类型typeA时的历史单次资源消耗情况按照正态分布曲线进行排列，计算出该正态分布的均值m和标准差n，并取该正态分布下概率最高的资源消耗值作为各资源的预估消耗值X。

然后结合该应用实例各资源的全部值Y(如内存1024MB，计算资源的消耗占比，如Z＝X/Y。

例如，CPU资源的消耗占比：Z

内存资源的消耗占比：Z

IO资源的消耗占比：Z

从而可以得到CPU资源的权重因子W

内存资源的权重因子Wvm＝Z

同理可以得到该应用实例的其它资源的权重因子。

上述各资源的权重因子是需要周期性更新的，以便得到各应用实例的最优最准确的负载加权得分。从而可以在前置交易系统请求确定应用实例时可以根据负载加权得分的大小，取最大值作为最优的应用实例返回，用于处理交易请求。

上述资源状态包可以是由各应用实例通过心跳报文上报的或在预设时间内未收到心跳报文时向未收到心跳报文的应用实例发送心跳探测报文后得到的或各应用实例处理交易请求时实时上报的。该预设时间可以依据经验设置。

此外，在向未收到心跳报文的应用实例发送心跳探测报文后未收到心跳探测结果，则将未收到心跳报文的应用实例从待分配应用实例列表中删除。

也可以说，资源状态包可以分为定时上报和实时上报。

其中，定时上报时，业务处理系统的各个应用实例分别间隔指定时间t1，以既定的报文协议，向负载均衡配置中心上报其资源状态，包括不限于CPU资源使用率、IO使用率、内存剩余空间、应用实例与DB是否跨IDC等。负载均衡配置中心收到心跳上报的资源状态包后，更新应用实例的资源状态记录，并执行负载均衡算法，计算出负载加权得分。

当负载均衡配置中心在指定时间周期t2(预设时间)内，未收到来自业务处理系统的某应用实例P1的心跳上报的资源状态包时，负载均衡配置中心会向该应用实例P1主动发起心跳探测报文，处理流程可以如图4所示。若收到心跳探测响应报文，证明应用实例仍存活，则解析心跳探测响应报文，加权计算营业实例P1的负载加权得分，并更新负载加权得分至应用实例负载加权得分表中。若未收到心跳探测应答报文，说明应用实例P1可能宕机，视为应用实例P1当前服务不可用，则将该应用实例P1从负载均衡配置中心的业务处理系统的待分配应用实例列表中删除，后续来自前置交易系统的请求任务将不再分发至应用实例P1。

实时上报的情况是指：应用实例在处理交易请求过程中，实时主动上报应用实例的资源集合信息，以便负载均衡配置中心自主优化各资源的权重因子。

例如，在前置交易系统请求负载均衡配置中心，根据负载均衡算法获取当前处理最高效的应用实例后，记录下当前处理交易类型typeA，请求序列号serialnoA的交易请求的应用实例的系资源状态信息setA，作为应用实例在t1时刻的初始资源状态信息。

该应用实例在接收到前置交易系统的下发的交易类型typeA的交易请求后，在处理交易请求的同时，开启异步线程不断上报该交易类型typeA当前应用实例的资源状态包，直到收到交易请求处理完成信号后终止上报。该过程能帮助负载均衡配置中心实时计算交易类型typeA的资源消耗情况，并更新权重因子，不断优化交易类型typeA的各资源的预估消耗值。

步骤203，将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统。

将当前时刻处理交易类型的应用实例发送给前置交易系统，可以使得前置交易系统将该交易请求下发给该当前时刻处理该交易类型的应用实例进行处理。并还可以接收当前时刻处理交易类型的应用实例实时上报的处理交易请求时的资源状态包，然后依据处理交易请求时的资源状态包和接收到交易请求时的资源状态包，计算当前时刻处理交易类型的应用实例处理交易类型的交易请求的单次资源消耗情况。将处理交易类型的交易请求的单次资源消耗情况存储到当前时刻处理交易类型的应用实例的历史单次资源消耗情况库中。

其中，处理交易请求时的资源状态包是处于同一请求序列中的。

具体的，应用实例实时心跳上报资源状态包给负载均衡配置中心，负载均衡配置中心根据该应用实例的资源状态的变动情况，可分析得出该应用实例在处理请求序列serialnoA，请求类型typeA的交易请求的资源消耗情况，并记录在数据库中。

例如，如表4所示的资源状态包信息，可以依据该表4内容来计算单次某资源消耗情况，计算请求序列serialnoA，请求类型typeA的交易请求的cpu资源消耗值为(C

表4

在通过上述方式计算得到本次资源消耗情况后，可以存储到该应用实例的历史单次资源消耗情况库中，以用于更新该应用实例的各资源的预估消耗值。

为了更好的解释本发明实施例，下面将在具体的实施场景下来描述上述负载均衡的流程。

如图5所示，具体包括：

步骤501，接收应用实例的资源状态包。

负载均衡配置中心收到某应用实例定时上报的资源状态包后，触发负载均衡计算任务。

步骤502，获取资源的权重因子信息。

从资源权重因子库中，将该应用实例的各资源的权重因子读取到内存中。

步骤503，计算应用实例负载加权得分。

依据读取的该应用实例的各资源的权重因子和该应用实例上报的资源状态包中各资源的状态数值，加权计算应用实例负载加权得分，具体计算方式已在上述实施例描述，不再赘述。

步骤504，更新应用实例负载加权得分。

将计算得到的负载加权得分，更新到应用实例负载加权得分表中。

步骤505，保存应用实例的资源状态包。

把应用实例上报的资源状态包，保存到上报记录表中。

在本发明实施例中，通过获取前置交易系统发送的交易请求，交易请求包括交易类型，从应用实例负载加权得分表中确定出当前时刻处理交易类型的应用实例，各应用实例负载加权得分是由当前时刻各应用实例的资源状态包和各资源的权重因子确定的，各资源的权重因子是由各应用实例的历史单次资源消耗情况和各资源的总值确定的，将当前时刻处理所述交易类型的应用实例发送给前置交易系统。在选取处理交易请求的应用实例时，依据通过历史单次资源消耗情况确定的各资源的权重因子和当前时刻的资源状态包得到的负载加权得分，可以确定出资源空闲且处理高效的应用实例，提高了负载均衡的准确度，并提高了应用实例的处理效率。

基于相同的技术构思，图6示例性的示出了本发明实施例提供的一种负载均衡的装置的结构，该装置可以执行负载均衡的流程。

如图6所示，该装置具体包括：

收发单元601，用于获取前置交易系统发送的交易请求，所述交易请求包括交易类型；

处理单元602，用于从应用实例负载加权得分表中确定出当前时刻处理所述交易类型的应用实例；其中，所述应用实例负载加权得分表中各应用实例负载加权得分是由当前时刻各应用实例的资源状态包和各资源的权重因子确定的；所述各资源的权重因子是由各应用实例的历史单次资源消耗情况和各资源的总值确定的；

所述收发单元601，还用于将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统，以使所述前置交易系统将所述交易请求下发给所述当前时刻处理所述交易类型的应用实例进行处理。

可选的，所述处理单元602具体用于：

周期性的获取各应用实例的处理各交易类型的交易请求的历史单次资源消耗情况；

以交易类型为维度，计算各应用实例的历史单次资源消耗情况的正态分布，将概率最高的资源消耗值确定为当前时刻各应用实例的各资源的预估消耗值；

依据所述当前时刻各应用实例的各资源的预估消耗值和各资源的总值，计算所述各资源的消耗占比；

依据所述各资源的消耗占比计算各资源的权重因子。

可选的，所述处理单元602具体用于：

获取当前时刻各应用实例的资源状态包和所述资源状态包中各资源对应的权重因子；

对所述资源状态包中各资源的值和各资源对应的权重因子进行加权计算，得到所述各应用实例负载加权得分。

可选的，所述当前时刻各应用实例的资源状态包是由各应用实例通过心跳报文上报的或在预设时间内未收到心跳报文时向未收到心跳报文的应用实例发送心跳探测报文后得到的或各应用实例处理交易请求时实时上报的。

可选的，所述处理单元602还用于：

在向所述未收到心跳报文的应用实例发送心跳探测报文后未收到心跳探测结果，则将所述未收到心跳报文的应用实例从待分配应用实例列表中删除。

可选的，所述处理单元602还用于：

所述将所述当前时刻处理所述交易类型的应用实例发送给所述前置交易系统之后，接收所述当前时刻处理所述交易类型的应用实例实时上报的处理所述交易请求时的资源状态包；

依据所述处理所述交易请求时的资源状态包和接收到所述交易请求时的资源状态包，计算所述当前时刻处理所述交易类型的应用实例处理所述交易类型的交易请求的单次资源消耗情况；

将所述处理所述交易类型的交易请求的单次资源消耗情况存储到所述当前时刻处理所述交易类型的应用实例的历史单次资源消耗情况库中。

可选的，所述处理单元602具体用于：

将所述应用实例负责加权得分表中交易类型相同且负载加权得分最高的应用实例确定为当前时刻处理所述交易类型的应用实例。

基于相同的技术构思，本发明实施例还提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用存储器中存储的程序指令，按照获得的程序执行上述负载均衡的方法。

基于相同的技术构思，本发明实施例还提供了一种计算机可读非易失性存储介质，包括计算机可读指令，当计算机读取并执行计算机可读指令时，使得计算机执行上述负载均衡的方法。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。