故障场景下的流量调度方法及装置与流程

1.本技术涉及大数据领域，可以用于金融领域，具体是一种故障场景下的流量调度方法及装置。


背景技术：

2.随着分布式技术的不断发展，分布式应用系统(简称应用系统)的部署架构日趋复杂，各应用系统可能部署在多个城市的多个区域，且各应用系统之间往往涉及跨区域的交叉访问与调用。
3.在现有的应用系统构架下，各应用系统之间的流量控制与访问调度均缺少统一的全局管理方法，无法快速灵活地进行流量调整与调度。在某一应用系统发生故障时，无法快速按照最小分区策略进行流量的动态实时切换。换而言之，若某个区域内的应用系统发生故障，很可能会影响到其他区域内应用系统的运行稳定，故障爆炸半径较大。


技术实现要素：

4.针对现有技术中的问题，本技术提供一种故障场景下的流量调度方法及装置，能够在业务处理节点故障的情况下，有序调度分区内或分区外的业务处理节点完成业务处理，有效降低了故障爆炸半径。
5.为解决上述技术问题，本技术提供以下技术方案：
6.第一方面，本技术提供一种故障场景下的流量调度方法，包括：
7.根据客户端发送的业务处理请求确定对应的业务处理分片；
8.根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点；其中，所述业务处理分区包括多个业务处理节点；
9.若检测到被调度所述业务处理请求的业务处理节点发生故障，根据该业务处理分区中业务处理节点发生故障的比例与预设阈值之间的关系，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点或调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理。
10.进一步地，所述根据客户端发送的业务处理请求确定对应的业务处理分片，包括：
11.将所述业务处理请求中的客户编号输入非加密散列函数，得到对应的哈希余数；
12.将所述哈希余数映射到预设值域的哈希环上，得到所述业务处理分片。
13.进一步地，所述根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点，包括：
14.根据预设的分片与分区之间的片区映射关系确定所述业务处理分片对应的所述业务处理分区；
15.在所述业务处理分区中，利用随机算法选取一空闲的业务处理节点，并将所述业务处理请求调度至该空闲的业务处理节点。
16.进一步地，若该业务处理分区中业务处理节点发生故障的比例不高于预设阈值，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点，包括：
17.对该业务处理分区中的业务处理节点进行健康检查，以确定该业务处理分区中无故障的业务处理节点；
18.选取该业务处理分区中各无故障的业务处理节点中连接数最少的业务处理节点，并调度所述业务处理请求至该连接数最少的业务处理节点。
19.进一步地，若该业务处理分区中的业务处理节点的当前故障比例高于阈值，调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点，包括：
20.根据预设的接管映射关系变更所述业务处理请求对应的路由地址至所述业务接管分区所在的路由地址；
21.将所述业务处理请求发送至所述业务接管分区所在的路由地址。
22.进一步地，所述对该业务处理分区中的业务处理节点进行健康检查，包括：
23.响应于客户端发送的健康检查请求，并根据预设的健康检查策略对所述业务处理节点进行健康检查。
24.进一步地，所述对该业务处理分区中的业务处理节点进行健康检查，包括：
25.按照轮询周期，根据预设的健康检查策略对所述业务处理节点进行健康检查。
26.进一步地，所述根据预设的健康检查策略对所述业务处理节点进行健康检查，包括：
27.对所述业务处理节点进行探活测试，并比较探活测试的测试返回值与设定的预期返回值是否相同；其中，若相同，所述业务处理节点为所述无故障的业务处理节点；
28.若不同，重新进行探活测试，并统计所述测试返回值与所述预期返回值不同的次数，直至所述次数达到预设允许值后确定所述业务处理节点存在故障或所述测试返回值与所述预期返回值相同时确定所述业务处理节点为所述无故障的业务处理节点。
29.第二方面，本技术提供一种故障场景下的流量调度装置，包括：
30.分片确定单元，用于根据客户端发送的业务处理请求确定对应的业务处理分片；
31.分区调度单元，用于根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点；其中，所述业务处理分区包括多个业务处理节点；
32.故障调度单元，用于若检测到被调度所述业务处理请求的业务处理节点发生故障，根据该业务处理分区中业务处理节点发生故障的比例与预设阈值之间的关系，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点或调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理。
33.进一步地，所述分片确定单元，包括：
34.哈希余数计算模块，用于将所述业务处理请求中的客户编号输入非加密散列函数，得到对应的哈希余数；
35.业务分片确定模块，用于将所述哈希余数映射到预设值域的哈希环上，得到所述业务处理分片。
36.进一步地，所述分区调度单元，包括：
37.片区映射模块，用于根据预设的分片与分区之间的片区映射关系确定所述业务处理分片对应的所述业务处理分区；
38.区内节点调度模块，用于在所述业务处理分区中，利用随机算法选取一空闲的业务处理节点，并将所述业务处理请求调度至该空闲的业务处理节点。
39.进一步地，若该业务处理分区中业务处理节点发生故障的比例不高于预设阈值，所述故障调度单元，包括：
40.区内无障节点确定模块，用于对该业务处理分区中的业务处理节点进行健康检查，以确定该业务处理分区中无故障的业务处理节点；
41.最少连接节点调度模块，用于选取该业务处理分区中各无故障的业务处理节点中连接数最少的业务处理节点，并调度所述业务处理请求至该连接数最少的业务处理节点。
42.进一步地，若该业务处理分区中的业务处理节点的当前故障比例高于阈值，所述故障调度单元，包括：
43.路由地址变更模块，用于根据预设的接管映射关系变更所述业务处理请求对应的路由地址至所述业务接管分区所在的路由地址；
44.接管分区调度模块，用于将所述业务处理请求发送至所述业务接管分区所在的路由地址。
45.进一步地，所述区内无障节点确定模块，具体用于响应于客户端发送的健康检查请求，并根据预设的健康检查策略对所述业务处理节点进行健康检查。
46.进一步地，所述区内无障节点确定模块，具体用于按照轮询周期，根据预设的健康检查策略对所述业务处理节点进行健康检查。
47.进一步地，所述区内无障节点确定模块，包括：
48.探活测试模块，用于对所述业务处理节点进行探活测试，并比较探活测试的测试返回值与设定的预期返回值是否相同；其中，若相同，所述业务处理节点为所述无故障的业务处理节点；
49.探活统计模块，用于若不同，重新进行探活测试，并统计所述测试返回值与所述预期返回值不同的次数，直至所述次数达到预设允许值后确定所述业务处理节点存在故障或所述测试返回值与所述预期返回值相同时确定所述业务处理节点为所述无故障的业务处理节点。
50.第三方面，本技术提供一种电子设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述故障场景下的流量调度方法的步骤。
51.第四方面，本技术提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述故障场景下的流量调度方法的步骤。
52.第五方面，本技术提供一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现所述故障场景下的流量调度方法的步骤。
53.针对现有技术中的问题，本技术提供的故障场景下的流量调度方法及装置，能够基于分布式负载均衡策略实现多分区架构下的流量调度，使得分布式系统构架下的各业务处理请求可以通过流量调度的方式优先在一个分区内实现闭环，从而避免在某一业务处理节点发生故障时，跨分区无序调度所导致的故障爆炸半径扩大，并能够利用健康检查策略
与分区接管策略实现跨分区调度的有序自动切换，提升了分布式系统运行的可靠性及应急响应效率。
附图说明
54.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
55.图1为本技术实施例中故障场景下的流量调度方法的流程图；
56.图2为本技术实施例中确定对应的业务处理分片的流程图；
57.图3为本技术实施例中调度至业务处理分区中业务处理节点的流程图；
58.图4为本技术实施例中调度至业务处理分区中无故障的业务处理节点的流程图；
59.图5为本技术实施例中调度至业务接管分区中无故障的业务处理节点的流程图；
60.图6为本技术实施例中进行健康检查的流程图；
61.图7为本技术实施例中故障场景下的流量调度装置的结构图；
62.图8为本技术实施例中分片确定单元的结构图；
63.图9为本技术实施例中分区调度单元的结构图；
64.图10为本技术实施例中故障调度单元的结构图之一；
65.图11为本技术实施例中故障调度单元的结构图之二；
66.图12为本技术实施例中区内无障节点确定模块的结构图；
67.图13为本技术实施例中的电子设备的结构示意图；
68.图14为本技术实施例中故障场景下的流量调度系统的示意图；
69.图15为本技术实施例中故障场景下的流量调度方法的步骤示意图；
70.图16为本技术实施例中分布式系统中各应用的示意图；
71.图17为本技术实施例中分片与分区的关系示意图；
72.图18为本技术实施例中分区的示意图。
具体实施方式
73.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
74.需要说明的是，本技术提供的故障场景下的流量调度方法及装置，可用于金融领域，也可用于除金融领域之外的任意领域，本技术提供的故障场景下的流量调度方法及装置的应用领域不做限定。
75.本技术技术方案中对数据的获取、存储、使用及处理等均符合国家法律法规的相关规定。
76.一实施例中，参见图1，为了能够在业务处理节点故障的情况下，有序调度分区内或分区外的业务处理节点完成业务处理，有效降低了故障爆炸半径，本技术提供一种故障
场景下的流量调度方法，包括：
77.s101：根据客户端发送的业务处理请求确定对应的业务处理分片；
78.s102：根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点；其中，所述业务处理分区包括多个业务处理节点；
79.s103：若检测到被调度所述业务处理请求的业务处理节点发生故障，根据该业务处理分区中业务处理节点发生故障的比例与预设阈值之间的关系，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点或调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理。
80.可以理解的是，本技术提供的故障场景下的流量调度方法在多分区架构下基于负载均衡策略实现，其执行主体是负载均衡流量调度系统，系统构架参见图14所示。通过该方法，图16中的渠道应用、产品应用、基础应用及数据分片(实体为数据库)能够实现分区部署，即：针对客户端发起的业务处理请求优先在分区内完成调度处理，当分区内原本负载处理该业务处理请求的业务处理节点(可以为任一渠道应用、产品应用、基础应用或数据分片)发生故障时，可以优先调度该业务处理请求至该业务处理分区中无故障的业务处理节点或根据预设的故障分区接管策略调度该业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理，从而实现了多个应用之间的业务流量统一有序调度。其中，所谓业务接管分区是指预先设定的在业务处理分区发生故障的情况下，接替该业务处理分区来处理业务处理请求的分区。换而言之，为处理业务处理请求，各应用之间均优先在其所在的分区内相互调度，只有在该业务处理分区出现故障时，才会进行跨区域的调度，由此当某一业务处理节点或某一分区发生故障时，利用本技术提供的方法能够最大限度地降低故障爆炸半径，尽量减少因无序跨分区调度而引发的故障爆炸半径扩大的情况发生。
81.需要说明的是，在本技术实施例中，分区的基础是分片，分片基于客户编号实现(具体实现方法参见下述步骤s201至步骤s202)。
82.以一个金融机构中的业务办理为例：
83.客户端发起交易请求(也称业务处理请求)，由于在进行与该客户的首笔交易时，客户编号尚未建立，因此金融机构暂不知晓，于是该交易请求由负载均衡流量调度系统。随机分发至任一分区中的渠道应用(其实体为一台后台服务器)进行处理。其中，渠道应用中的客户识别服务通过完成登录或其他非登录校验，获取到唯一的客户编号。
84.客户端获取到该客户编号后，后续的所有的交易请求中都带有该客户编号，并且所有的交易流量都经过负载均衡流量调度系统进行调控。负载均衡系统根据交易流量标签中的客户编号计算对应的哈希值(也称哈希余数)及分片信息，并根据分片信息与分区信息的对应关系，将该客户的交易请求调度到对应分区中的产品应用(其实体为一台后台服务器)进行处理，后续在该分区不出现故障的情况下，该客户所有操作均在此分区中进行。
85.产品应用调用其他基础应用或数据库分片时，所有流量也都先经过负载均衡流量调度系统，此过程中也均携带有客户编号。对于同一客户，均调用本分区中的各应用服务，按统一的分区内流量调度机制进行，使交易链路在本分区内形成闭环。
86.本分区应用运行正常情况下由负载均衡流量调度系统实现应用流量优先在本分
区内闭环，当通过健康检查机制，检查到某个分区的链路出现故障时，负载均衡流量调度系统可以实现自动切流。并且通过配置中心实现负载均衡的全局管控，通过提前预设的流量调度分区策略、故障分区接管策略及健康检查策略实现全局流量调度，进而实现分布式系统的整体高可用性。
87.下面阐述负载均衡流量调度系统的构架。
88.图14示出负载均衡(多分区)流量调度系统200，用于实现基于负载均衡应用系统的多分区流量闭环以及不同分区全局流量的快速切换，能够提升应用系统故障隔离能力及故障切换能力。负载均衡运行节点210包含分区规则配置组件211、负载策略配置组件212、健康检查配置组件213、请求处理组件214、分区采集组件215、负载调度处理组件216、健康检查处理组件217、流量调度组件218。负载均衡配置中心220包括分区规则全局配置组件221、负载策略全局配置组件222、健康检查全局配置组件223。应用服务集群230包含应用a分区集群231、应用b分区集群232、应用c分区集群233、应用d分区集群234。
89.各个组件的功能介绍：
90.1、分布式负载均衡运行节点210
91.(1)分区规则配置组件211:用于配置多分区基础配置信息，如分区个数n个、数据分片n片、分区规则(如1-32片对应a分区、33-64对应b分区、65-96对应c分区、97-128对应d分区，可支持连续或离散配置)和分区接管策略(ac分区互相接管、bd分区互相接管)。
92.(2)负载策略配置组件212：通过获取分区处理组件211中的信息，结合应用的基于域名/上下文根等负载策略，生成所有多分区应用的负载策略，例如：
93.a应用：根据域名a.icbc负载调度流量，并且客户id分片为1-32时优先调度到a分区，当a分区故障时，自动调度到c分区。其他负载调度策略...
94.b应用：根据域名b.icbc负载调度流量，并且客户id分片为33-64时优先调度到b分区，当b分区故障时，自动调度到d分区。其他负载调度策略...
95.c应用...
96.d应用...
97.(3)健康检查配置组件213：用于配置针对后端各个分区的健康检查策略，可配置健康检查路径、预期返回值、检查频率、分区切换标准(分区内存活服务器最小阈值)等信息。
98.(4)请求处理组件214：该组件针对流量请求进行拦截过处理获取到请求中的分区标志信息(该信息可以为全局系统多个应用间共享的客户信息或机构信息)。
99.(5)分区处理组件215：根据分区规则配置组件211，单元化数据分片规则，明确了按客编一致性哈希进行统一的分片。
100.(6)负载调度处理组件216：根据负载策略配置组件212配置的负载策略，结合分区处理组件215计算的分片结果(以128片为例)，将请求负载调度到特定的分区。
101.(7)健康检查处理组件217：根据健康检查配置组件213配置的健康检查策略，定期针对后端各个分区的节点进行检查，并将健康检查结果返回给负载调度处理组件216进行负载调度处理。
102.(8)流量调度组件218：根据负载调度处理组件216和健康检查处理组件217的处理结果，最终将请求转发到特定分区下的某台节点上，完成交易请求。
103.2、负载均衡配置中心220
104.(1)分区规则全局配置组件221：针对所有分布式负载均衡节点的分区规则配置组件进行配置管理，全局性实现快速调整分区规则。
105.(2)负载策略全局配置组件222：针对所有分布式负载均衡节点的负载策略组件进行配置管理，全局性实现快速调整负载策略。
106.(3)健康检查全局配置223：针对所有分布式负载均衡节点的健康检查策略，全局性实现快速调整健康检查策略。
107.3、应用服务集群230
108.(1)应用a分区集群231：a分区的应用服务器集群，用于处理负载到a分区的交易请求。
109.(2)应用b分区集群232：b分区的应用服务器集群，用于处理负载到b分区的交易请求。
110.(3)应用c分区集群233：c分区的应用服务器集群，用于处理负载到c分区的交易请求。
111.(4)应用d分区集群234:d分区的应用服务器集群，用于处理负载到d分区的交易请求。
112.其中，应用发起交易请求时，经过负载均衡流量处理节点请求处理组件211，该组件针对流量请求进行拦截过处理获取到请求中的分区标志信息(该信息可以为全局系统多个应用间共享的客户信息)。
113.从上述描述可知，本技术提供的故障场景下的流量调度方法，能够基于分布式负载均衡策略实现多分区架构下的流量调度，使得分布式系统构架下的各业务处理请求可以通过流量调度的方式优先在一个分区内实现闭环，从而避免在某一业务处理节点发生故障时，跨分区无序调度所导致的故障爆炸半径扩大，并能够利用健康检查策略与分区接管策略实现跨分区调度的有序自动切换，提升了分布式系统运行的可靠性及应急响应效率。
114.一实施例中，参见图2，所述业务处理请求包括客户编号；所述根据客户端发送的业务处理请求确定对应的业务处理分片，包括：
115.s201：将所述业务处理请求中的客户编号输入非加密散列函数，得到对应的哈希余数；
116.s202：将所述哈希余数映射到预设值域的哈希环上，得到所述业务处理分片。
117.可以理解的是，参见图17，可自定义分片的规则，比如分为16片，分别对应区间为a1-a16，或者分为8片，分别对应区间为b1-b8。步骤s201至步骤s202可以参照如下实现：
118.1、采用非加密散列算法murmurhash哈希算法为标准，输入客编得到一个0～(2^63-1)的数字，即表示2的63次方。
119.2、使用哈希环方式将哈希值空间[0～(2^63-1)]分为n段，上述得到的哈希值落在哪个分段。
[0120]
3、hash值的范围为[0,2^63-1]，h＝hash(客户信息编号)/2^63，得到[0,1)范围内的一个数值。假设a应用分16片，则((x-1)/16,x/16]之间的h值，路由到ax分片。
[0121]
4、通过分片和单元的对照关系，同时得到归属的单元。
[0122]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够根据客户端发
送的业务处理请求确定对应的业务处理分片。
[0123]
一实施例中，参见图3，所述流量调度分区策略包括分片与分区之间的片区映射关系；所述根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点，包括：
[0124]
s301：根据预设的分片与分区之间的片区映射关系确定所述业务处理分片对应的所述业务处理分区；
[0125]
s302：在所述业务处理分区中，利用随机算法选取一空闲的业务处理节点，并将所述业务处理请求调度至该空闲的业务处理节点。
[0126]
可以理解的是，参见图18，根据负载策略配置组件212配置的负载策略，结合分区处理组件215计算的分片结果(以128片为例)，将请求负载调度到特定的分区。
[0127]
hash分片对应分区关系可以按需定义、调整hash分片值范对应的分区关系，支持精细粒度离散的流量分片调拨控制，提升管控的灵活性。
[0128]
举例而言，参见下表所示。
[0129][0130]
任一分区发生故障时，利用负载均衡系统流量调拨能力，通过分区切换开关控制，可以由其他任一分区接管故障分区流量。
[0131]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点。
[0132]
一实施例中，参见图4，若该业务处理分区中业务处理节点发生故障的比例不高于预设阈值，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点，包括：
[0133]
s401：对该业务处理分区中的业务处理节点进行健康检查，以确定该业务处理分区中无故障的业务处理节点；
[0134]
s402：选取该业务处理分区中各无故障的业务处理节点中连接数最少的业务处理
节点，并调度所述业务处理请求至该连接数最少的业务处理节点。
[0135]
可以理解的是，有时该业务处理分区中的业务处理节点可能发生故障，此时需要对该业务处理分区中的其他业务处理节点进行健康检查，以确定该业务处理分区中无故障的业务处理节点，以便将该业务处理请求调度到同一分区内无故障的业务处理节点上进行处理。以此实现优先在区域内实现闭环，缩小故障爆炸半径的技术效果。
[0136]
需要说明的是，在所有无故障的业务处理节点中，本技术实施例中的负载均衡流量调度系统会优先选择连接数最少的(较为空闲的)业务处理节点进行分配，从而实现区域内部的负载均衡。
[0137]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够调度所述业务处理请求至该业务处理分区中无故障的业务处理节点。
[0138]
一实施例中，参见图5，若该业务处理分区中的业务处理节点的当前故障比例高于阈值，所述根据预设的故障分区接管策略调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点，包括：
[0139]
s501：根据预设的接管映射关系变更所述业务处理请求对应的路由地址至所述业务接管分区所在的路由地址；其中，接管映射关系体现了业务处理分区与其对应的业务接管分区之间的关系；
[0140]
s502：将所述业务处理请求发送至所述业务接管分区所在的路由地址。
[0141]
可以理解的是，步骤s501至步骤s502所描述的应用场景是当某一分区出现故障时，负载均衡流量调度系统需要进行跨区域调度。需要说明的是，这种跨区域调度是基于预先设定的接管映射关系实现的，也就是说，对于每个业务处理分区都有其所对应的业务接管分区，用于承担当业务处理分区发生故障后的业务请求处理工作。
[0142]
具体实施时，首先需要判断该业务处理分区中的业务处理节点的当前故障比例是否高于阈值。此阈值可以为一百分数，例如80％，在此种情况下，该业务处理分区中的业务处理节点中如果有80％及以上发生故障，则认为该分区发生了故障，那么负载均衡流量调度系统就不再将业务处理请求发送至该业务处理分区进行处理了，转而发送至该业务处理分区所对应的业务接管分区进行处理。具体的调度是通过变更路由地址实现的。
[0143]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够根据预设的故障分区接管策略调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点。
[0144]
一实施例中，所述对该业务处理分区中的业务处理节点进行健康检查，包括：
[0145]
响应于客户端发送的健康检查请求，并根据预设的健康检查策略对所述业务处理节点进行健康检查。
[0146]
一实施例中，所述对该业务处理分区中的业务处理节点进行健康检查，包括：
[0147]
按照轮询周期，根据预设的健康检查策略对所述业务处理节点进行健康检查。
[0148]
上述两个实施例表明，进行健康检查的触发要件可以是响应客户端发送的健康检查请求，在此场景下，客户端因接收到来自于负载均衡流量调度系统的“业务处理节点失能”的信息，主动发起健康检查请求，请求负载均衡流量调度系统检查该分区内是否有无故障的业务处理节点帮助其处理业务请求。此外，进行健康检查的触发要件还可以是按照轮询周期进行。例如，负载均衡流量调度系统每隔一天(可以根据实际情况进行设定)自动触
发一次健康检查。
[0149]
一实施例中，参见图6，所述根据预设的健康检查策略对所述业务处理节点进行健康检查，包括：
[0150]
s601：对所述业务处理节点进行探活测试，并比较探活测试的测试返回值与设定的预期返回值是否相同；其中，若相同，所述业务处理节点为所述无故障的业务处理节点；
[0151]
s602：若不同，重新进行探活测试，并统计所述测试返回值与所述预期返回值不同的次数，直至所述次数达到预设允许值后确定所述业务处理节点存在故障或所述测试返回值与所述预期返回值相同时确定所述业务处理节点为所述无故障的业务处理节点。
[0152]
可以理解的是，具体进行健康检查的方法如下：
[0153]
如前所述，健康检查配置组件213可以配置针对后端各个分区的健康检查策略，可配置健康检查路径、预期返回值、检查频率、分区切换标准(分区内存活的业务处理节点的最小阈值)等信息。
[0154]
其中，检查频率是设定了探活测试的允许失败次数(即预设允许值)。
[0155]
本技术实施例提供一个深度健康检查功能(详见下文(1)健康检查请求接口设计)，其触发针对服务器进程状态、磁盘空间、依赖服务等深度健康检查，并返回健康检查是否正常的结果。通过配置深度健康检查路径，如/icbc/healthcheck；预期健康检查返回值，如@the@health@is@good；检查频率，如连续3次成功或失败；分区切换标准(应用节点存活数量阈值)，比5个。负载节点根据健康检查结果和预设置的情况，判断是否需要进行分区切换(详见(2)针对接口返回结果的综合判断说明)。
[0156]
(1)健康检查请求接口设计：
[0157][0158][0159]
举例而言，一次健康检查探活请求是对负载均衡流量调度系统的一个节点探活，负载均衡流量调度系统根据负载策略规则区分探活请求路由的节点，探活请求需满足节点的负载均衡流量调度系统负载负载路由策略，如某节点是基于域名负载，则探活请求需要host字段带上域名，如果节点是使用特殊负载策略，探活请求也需要满足特殊负载策略规则。
[0160]
(2)针对接口返回结果的综合判断说明：
[0161]
应用需根据健康检查结果及请求header返回值综合判断得出最终探活结果。
[0162]
1)、访问健康检查路径通过且header值为true，则探活通过，说明单元节点正常。
[0163]
2)、访问健康检查路径通过而header值为false，说明单元异常，需要实施切流。
[0164]
3)、访问健康检查路径通过而header值为-1，说明slb进程处于重启状态，需要重新发起健康检查获取探活结果。
[0165]
4)、访问健康检查路径出现网络不通、返回4xx、5xx状态码、健康检查返回超时或返回值不匹配等异常情况，slb可能无法返回unit-health值，此时说明单元故障，需要实施切流。
[0166]
为避免因网络波动等情况引起的切流，应用应根据最近三次探活结果综合判断实施切流。
[0167][0168]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够根据预设的健康检查策略对所述业务处理节点进行健康检查。
[0169]
如图15所示，为本发明的实施方法流程图。具体处理过程如下：
[0170]
步骤301：所有多分区改造的应用全部接入到分布式负载均衡节点，由负载均衡节点进行负载。并且应用的访问请求都带有客户编号id信息或机构编号信息等可用于分区计算的标志信息。
[0171]
步骤302：通过负载均衡配置中心220的分区规则全局配置组件221、负载策略全局配置组件222、健康检查全局配置组件223，提前配置好全局性的分区规则、负载策略、健康检查策略、分区接管规则等信息。
[0172]
步骤303：负载均衡配置中心与系统内所有分布式负载均衡节点210建立通讯关系，并与节点内分区规模配置组件211、负载策略配置组件212、健康检查配置组件213实现动态联动，当配置中心相应的组件配置发生变化时，自动将配置同步到负载均衡节点。
[0173]
步骤304：当一个客户/机构发起一笔交易请求时，请求处理组件读取请求包中客户/机构的id信息。
[0174]
步骤305：将该客户/机构的id信息通过与分片数量进行求余计算得出该用户/机构的分片信息。
[0175]
步骤306：通过计算所得的分片信息与预先配置的负载策略进行匹配比对，将该用户的所有交易请求流量转发到特定分区内闭环访问。
[0176]
步骤307：健康检查处理组件定期针对后端各个分区的节点进行检查。当单某个分区全部故障或分区内某个应用故障时，可根据预设的分区接管规则和健康检查结果实现自动分区接管。
[0177]
步骤308：同时在运行过程中也可通过全局配置中心调整分区规则、分片规则、负载策略、健康检查策略，实现所有应用的交易请求快速切换分区。从而满足分区间不同颗粒度的分区接管需求，实现应用故障的快速恢复。
[0178]
基于同一发明构思，本技术实施例还提供了一种故障场景下的流量调度装置，可以用于实现上述实施例所描述的方法，如下面的实施例所述。由于故障场景下的流量调度装置解决问题的原理与故障场景下的流量调度方法相似，因此故障场景下的流量调度装置的实施可以参见基于软件性能基准确定方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
[0179]
一实施例中，参见图7，为了能够在业务处理节点故障的情况下，有序调度分区内或分区外的业务处理节点完成业务处理，有效降低了故障爆炸半径，本技术提供一种故障场景下的流量调度装置，包括：分片确定单元701、分区调度单元702及故障调度单元703。
[0180]
分片确定单元701，用于根据客户端发送的业务处理请求确定对应的业务处理分片；
[0181]
分区调度单元702，用于根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点；其中，所述业务处理分区包括多个业务处理节点；
[0182]
故障调度单元703，用于若检测到被调度所述业务处理请求的业务处理节点发生故障，根据该业务处理分区中业务处理节点发生故障的比例与预设阈值之间的关系，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点或调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理。
[0183]
一实施例中，参见图8，所述分片确定单元701，包括：哈希余数计算模块801及业务分片确定模块802。
[0184]
哈希余数计算模块801，将所述业务处理请求中的客户编号输入非加密散列函数，得到对应的哈希余数；
[0185]
业务分片确定模块802，将所述哈希余数映射到预设值域的哈希环上，得到所述业务处理分片。
[0186]
一实施例中，参见图9，所述分区调度单元702，包括：
[0187]
片区映射模块901，用于根据预设的分片与分区之间的片区映射关系确定所述业务处理分片对应的所述业务处理分区；
[0188]
区内节点调度模块902，用于在所述业务处理分区中，利用随机算法选取一空闲的业务处理节点，并将所述业务处理请求调度至该空闲的业务处理节点。
[0189]
一实施例中，参见图10，若该业务处理分区中业务处理节点发生故障的比例不高于预设阈值，所述故障调度单元703，包括：区内无障节点确定模块1001及最少连接节点调度模块1002。
[0190]
区内无障节点确定模块1001，用于对该业务处理分区中的业务处理节点进行健康检查，以确定该业务处理分区中无故障的业务处理节点；
[0191]
最少连接节点调度模块1002，用于选取该业务处理分区中各无故障的业务处理节点中连接数最少的业务处理节点，并调度所述业务处理请求至该连接数最少的业务处理节点。
[0192]
一实施例中，参见图11，若该业务处理分区中的业务处理节点的当前故障比例高
于阈值，所述故障调度单元703，包括：
[0193]
路由地址变更模块1101，用于根据预设的接管映射关系变更所述业务处理请求对应的路由地址至所述业务接管分区所在的路由地址；
[0194]
接管分区调度模块1102，用于将所述业务处理请求发送至所述业务接管分区所在的路由地址。
[0195]
一实施例中，所述区内无障节点确定模块1001，具体用于响应于客户端发送的健康检查请求，并根据预设的健康检查策略对所述业务处理节点进行健康检查。
[0196]
一实施例中，所述区内无障节点确定模块1001，具体用于按照轮询周期，根据预设的健康检查策略对所述业务处理节点进行健康检查。
[0197]
一实施例中，参见图12，所述区内无障节点确定模块1001，包括：
[0198]
探活测试模块1201，用于对所述业务处理节点进行探活测试，并比较探活测试的测试返回值与设定的预期返回值是否相同；其中，若相同，所述业务处理节点为所述无故障的业务处理节点；
[0199]
探活统计模块1202，用于若不同，重新进行探活测试，并统计所述测试返回值与所述预期返回值不同的次数，直至所述次数达到预设允许值后确定所述业务处理节点存在故障或所述测试返回值与所述预期返回值相同时确定所述业务处理节点为所述无故障的业务处理节点。
[0200]
从硬件层面来说，为了能够在业务处理节点故障的情况下，有序调度分区内或分区外的业务处理节点完成业务处理，有效降低了故障爆炸半径，本技术提供一种用于实现所述故障场景下的流量调度方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：
[0201]
处理器(processor)、存储器(memory)、通讯接口(communications interface)和总线；其中，所述处理器、存储器、通讯接口通过所述总线完成相互间的通讯；所述通讯接口用于实现所述故障场景下的流量调度装置与核心业务系统、用户终端以及相关数据库等相关设备之间的信息传输；该逻辑控制器可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该逻辑控制器可以参照实施例中的故障场景下的流量调度方法的实施例，以及故障场景下的流量调度装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。
[0202]
可以理解的是，所述用户终端可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(pda)、车载设备、智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表、智能手环等。
[0203]
在实际应用中，故障场景下的流量调度方法的部分可以在如上述内容所述的电子设备侧执行，也可以所有的操作都在所述客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本技术对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器。
[0204]
上述的客户端设备可以具有通讯模块(即通讯单元)，可以与远程的服务器进行通讯连接，实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间平台的服务器，例如与任务调度中心服务器有通讯链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个
服务器组成的服务器集群，或者分布式装置的服务器结构。
[0205]
图13为本技术实施例的电子设备9600的系统构成的示意框图。如图13所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图13是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。
[0206]
一实施例中，故障场景下的流量调度方法功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：
[0207]
s101：根据客户端发送的业务处理请求确定对应的业务处理分片；
[0208]
s102：根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点；其中，所述业务处理分区包括多个业务处理节点；
[0209]
s103：若检测到被调度所述业务处理请求的业务处理节点发生故障，根据该业务处理分区中业务处理节点发生故障的比例与预设阈值之间的关系，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点或调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理。
[0210]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够基于分布式负载均衡策略实现多分区架构下的流量调度，使得分布式系统构架下的各业务处理请求可以通过流量调度的方式优先在一个分区内实现闭环，从而避免在某一业务处理节点发生故障时，跨分区无序调度所导致的故障爆炸半径扩大，并能够利用健康检查策略与分区接管策略实现跨分区调度的有序自动切换，提升了分布式系统运行的可靠性及应急响应效率。
[0211]
在另一个实施方式中，故障场景下的流量调度装置可以与中央处理器9100分开配置，例如可以将数据复合传输装置故障场景下的流量调度装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现故障场景下的流量调度方法的功能。
[0212]
如图13所示，该电子设备9600还可以包括：通讯模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图13中所示的所有部件；此外，电子设备9600还可以包括图13中没有示出的部件，可以参考现有技术。
[0213]
如图13所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。
[0214]
其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。
[0215]
输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为lcd显示器，但并不限于此。
[0216]
该存储器9140可以是固态存储器，例如，只读存储器(rom)、随机存取存储器(ram)、sim卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除
且设有更多数据，该存储器的示例有时被称为eprom等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。
[0217]
存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通讯功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。
[0218]
通讯模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通讯模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通讯终端的情况相同。
[0219]
基于不同的通讯技术，在同一电子设备中，可以设置有多个通讯模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通讯模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。
[0220]
本技术的实施例还提供能够实现上述实施例中的执行主体为服务器或客户端的故障场景下的流量调度方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的故障场景下的流量调度方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
[0221]
s101：根据客户端发送的业务处理请求确定对应的业务处理分片；
[0222]
s102：根据预设的流量调度分区策略及所述业务处理分片将所述业务处理请求调度至对应的业务处理分区中的任一业务处理节点；其中，所述业务处理分区包括多个业务处理节点；
[0223]
s103：若检测到被调度所述业务处理请求的业务处理节点发生故障，根据该业务处理分区中业务处理节点发生故障的比例与预设阈值之间的关系，调度所述业务处理请求至该业务处理分区中无故障的业务处理节点或调度所述业务处理请求至该业务处理分区对应的业务接管分区中无故障的业务处理节点进行处理。
[0224]
从上述描述可知，本技术提供的故障场景下的流量调度方法，能够基于分布式负载均衡策略实现多分区架构下的流量调度，使得分布式系统构架下的各业务处理请求可以通过流量调度的方式优先在一个分区内实现闭环，从而避免在某一业务处理节点发生故障时，跨分区无序调度所导致的故障爆炸半径扩大，并能够利用健康检查策略与分区接管策略实现跨分区调度的有序自动切换，提升了分布式系统运行的可靠性及应急响应效率。
[0225]
本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机
可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0226]
本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0227]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0228]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0229]
本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。