[发明专利]分布式网络业务调度方法、装置、计算设备和存储介质

说明书

本申请公开了一种分布式网络业务调度方法、装置、计算设备和存储介质。基于下游节点返回的业务处理结果，判断是否处理成功。分别统计上游节点的各个下游节点的业务处理失败率。将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于第一阈值的下游节点标记为正常节点。响应于上游节点存在要向下游节点下发的业务处理请求，构建候选队列，其中，将非正常节点放入候选队列的概率低于将正常节点放入候选队列。从候选队列中选择下游节点以用于执行业务处理请求。向所选择的下游节点发送业务处理请求。以及从所选择的下游节点接收业务处理结果。由此，能够识别逻辑坏点，逻辑坏点恢复正常后也能及时发现，保障了业务处理请求的顺利执行。

技术领域

本公开涉及分布式网络，特别涉及分布式网络中节点的健康状态监控及相应的业务调度。

背景技术

分布式网络是由分布在不同地点且具有多个终端的节点机互连而成的。在分布式网络中，基于系统吞吐量和容错等因素的考虑，通常情况下上游节点会同时与多个下游节点进行链接。在上游节点处，单个请求会以一定策略(例如轮询或随机等)发送到某个下游节点上。

图1示意性地示出了分布式网络中上下游节点的链接关系。上游节点与下游节点1、下游节点2、下游节点3分别链接。

当如图1所示，当下游某个节点(例如下游节点1)出现损坏(如机器宕机)时，系统需要及时自动发现该节点损坏，并切走发送至该节点上的全部(或绝大部分)请求，以保证系统的健壮性。

一般而言，当出现下游节点损坏时，上游节点需要自动发现该坏点(损坏的节点)，并将原计划发送至该节点的流量切换至其它下游节点，以保证线上流量的正常处理。

应对可能存在的坏点，当前分布式网络一般采用请求出错重试和心跳(Heartbeat)检测两种方案来应对。请求出错重试方案和心跳检测方案从不同的角度来应对坏点，两种方案可以单独使用，也可以结合使用。

图2示意性地示出了请求出错重试方案的简易流程。

在请求出错重试方案中，上游节点在尝试请求下游节点获得失败结果(例如超时等)之后，上游节点判断剩余时间是否充足，即剩余时间是否足够重新请求其它下游节点进行处理。若时间足够，则上游节点尝试请求其它下游节点，以期完成此次请求的业务处理。

请求出错重试方案的大致处理流程如下：

1.业务处理请求到达上游节点。

2.上游节点进行处理。

3.上游节点尝试发送至下游节点1。

4.下游节点1返回处理结果，在下游节点1损坏的情况下，处理结果表明处理失败。

5.上游节点判断剩余时间是否充足。

6.在剩余时间充足的情况下，尝试发送到下游节点2进行处理。

7.下游节点运行正常没有损坏，对业务处理请求进行正常处理后，返回处理结果。

在这种方案中，在下发业务处理请求时，并没有将下游节点区分为正常节点和损坏的节点。在业务处理请求被下发到损坏的节点时，通过及时发现处理失败并转发给其它下游节点来尽力保障该业务处理请求的顺利执行。而当损坏的下游节点恢复工作时，上游节点发送至该下游节点的业务处理请求将会得到正常处理，此时下游节点自然地恢复正常工作。

然而，采用请求出错重试的方式带来的风险是在整个请求链路中，若上游节点与下游坏点连接和处理过程中产生了较大的耗时，此时上游节点将没有更多的时间去选择其它下游节点，进而导致此次请求无法得到正常处理。该种情况下，将不可避免地产生流量的丢失。

图3示意性地示出了请求出错重试方案导致流量丢失的情形。

1.业务处理请求到达上游节点。