基于Hystrix的分布式系统集群熔断方法及分布式系统与流程

基于hystrix的分布式系统集群熔断方法及分布式系统
技术领域
1.本发明涉及计算机技术领域，特别涉及一种集群熔断的方法及分布式系统。


背景技术：

2.在分布式系统中，多级依赖形成的多级上下游级联比较常见。举例来说，如图1所示，服务a依赖于服务b和服务c，而服务b又依赖于服务d。如果服务d出现问题，导致大量来自服务b的请求超时，服务b请求服务d的大量的连接被耗尽，最终可能导致服务b无法向服务a提供服务，引发系统雪崩。实际上，服务d可能是一个并不重要的服务，这种情况下，我们希望服务b可以在没有获取服务d的数据的情况下，服务b可以继续为服务a提供服务。
3.如果一个应用不能对来自依赖的故障进行隔离，那该应用本身就处在被拖垮的风险中。因此，为了构建稳定、可靠的分布式系统，服务应当具有自我保护能力，当依赖服务不可用时，当前服务启动自我保护功能，从而避免发生雪崩效应。
4.仍以图1为例，能否在服务b请求服务d时有某种熔断机制，在统计得知服务d有问题的情况下，不再请求服务d，而立即返回降级数据，从而不会耗尽连接直到每个连接都超时。而后在某个时机尝试访问服务d，如果认为服务d已恢复则恢复请求服务d。
5.于是业界产生了hystrix，后来又有了sentinel。对于并不是所有请求都经过网关的php生态的自我保护，业界也有一些解决方案，如odesk phystrix，其使用了apcu作为存储媒介实现了单机版熔断能力。但每台机器的处理能力如果有差异，熔断参数配置会有多份，并且一旦负载均衡策略改变，每台机器的熔断参数配置就得调整。所以这种情况下集群版熔断方案更适合这个场景。
6.目前，业界已经开发了php生态的集群版熔断解决方案，其存储基于redis从而解决上述问题，但这种方案也存在一定的问题。举例而言，首先，如使用了redis的zset来存储成功(success)、失败(failure)、拒绝(reject)三种统计请求的个数，达到统计阈值判断的目的。但是，清除过期的点需要使用非常消耗redis性能的zremrangebyscore操作，在操作大量的元素时会拖垮redis；其次，redis没有开启长连接，每次操作均需要建立连接和结束连接；再次，每次访问时redis没有链路追踪，redis读写出问题时无法在第一时间感知，影响断路器状态的判断；最后，分布式的系统从本机获取时间可能存在差异，对于设置比较小的窗口(window)，对时间的差异比较敏感，如果没有一个统一的时间会直接降低计数的准确度。
7.需要说明的是，以上背景技术部分所公开的信息仅用于增强对本发明背景的理解，因此其可能包含不构成对本领域技术人员已知的现有技术的信息。


技术实现要素：

8.为了至少在一定程度上解决现有技术中存在的上述问题之一，本发明的第一个目的在于提供一种基于hystrix的分布式系统集群熔断的方法。本发明的第二个目的在于还提供一种分布式系统。本发明的其他目的在于提供一种计算机可读存储介质和计算机程序
产品。
9.为达到上述目的，根据本发明一实施例，本发明第一方面提供一种基于hystrix的分布式系统集群熔断方法，该方法利用滑动窗口进行统计，所述滑动窗口由多个桶组成，其中：所述桶使用redis存放为哈希结构，该哈希结构的键包括桶生成时间和桶当前值；所述桶当前值为二进制整数，该二进制整数的比特位包括成功比特位、失败比特位、拒绝比特位、未使用比特位以及设置在该四个比特位之间的防溢出比特位；所述成功比特位、失败比特位和拒绝比特位分别记录请求的成功操作、失败操作和被拒绝操作；所述防溢出比特位在统计时如果出现值，则终止统计流程。
10.上述桶当前值可以为64位整数。其中，所述成功比特位可以占22位，所述失败比特位可以占16位，所述拒绝比特位可以占18位，所述未使用比特位可以占2位，并且/或者所述防溢出比特位可以各占2位。
11.根据本发明一实施例的基于hystrix的分布式系统集群熔断方法，以从redis获取的时间为基准进行统计；可以对于redis开启长连接并且/或者设置链路追踪；可以利用lua脚本将信息写入lua命令，并发送给redis；还可以在断路器状态发生变化和/或redis出现异常时，发出通知信息。
12.为达到上述目的，根据本发明一实施例，本发明第二方面提供一种分布式系统，其包含集群熔断模块，该集群熔断模块基于hystrix利用滑动窗口进行统计，所述滑动窗口由多个桶组成，其中：所述桶使用redis存放为哈希结构，该哈希结构的键包括桶生成时间和桶当前值；所述桶当前值为二进制整数，该二进制整数的比特位包括成功比特位、失败比特位、拒绝比特位、未使用比特位以及设置在该四个比特位之间的防溢出比特位；所述成功比特位、失败比特位和拒绝比特位分别记录请求的成功操作、失败操作和被拒绝操作；所述防溢出比特位在统计时如果出现值，则终止统计流程。
13.根据本发明一实施例的分布式系统所包含的集群熔断模块以从redis获取的时间为基准进行统计；可以对于redis开启长连接并且/或者设置链路追踪；可以利用lua脚本将信息写入lua命令，并发送给redis；还可以在断路器状态发生变化和/或redis出现异常时，发出通知信息。
14.为达到上述目的，根据本发明一实施例，本发明第三方面提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现上述基于hystrix的分布式系统集群熔断方法的步骤。
15.为达到上述目的，根据本发明一实施例，本发明第四方面提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现上述基于hystrix的分布式系统集群熔断方法的步骤。
16.本发明所提供的基于hystrix的分布式系统集群熔断方法及其分布式系统，使用redis作为存储媒介，利用hystrix的滑动窗口和桶进行计数，可以降低redis cpu的开销，减少redis io操作(输入输出操作)，使得相同的redis可以针对更大的并发来计数。
附图说明
17.以下将详细参考附图示出的特定示例性实施例，对本发明的上述和其他特征进行说明，所述示例性实施例在下文中仅以说明的方式给出，因此并不限制本发明，其中：
18.图1示出常见分布式系统的简化架构示意图。
19.图2示出hystrix在请求发出前执行可用性判断的基本逻辑流程图。
20.图3示出图2所示流程图的具体操作流程图。
21.图4示出hystrix对请求结果进行判断的基本逻辑流程图。
22.图5示出hystrix经过图4所示逻辑流程图后断路器的相关操作流程图。
23.图6示出根据本发明一实施例的滑动窗口及其所包含的桶的示意图。
24.图7示出根据本发明一实施例滑动窗口与其所包含桶与时间的关系示意图。
25.图8示出根据本发明一实施例的桶当前值的比特位示意图。
具体实施方式
26.以下通过具体实施例对本发明进行详细描述，以使本领域普通技术人员能够容易地根据本说明书公开的内容实施本发明。以下所描述的实施例仅是本发明的一部分实施例，而非全部。基于本说明书所描述的实施例，本领域普通技术人员在不付出创造性劳动的前提下所获得的所有其它实施例，都属于本发明保护的范围。需要说明的是，在不发生冲突的情况下，本说明书中的实施例及实施例中的特征可以相互组合。
27.本文所使用的术语仅是为了说明特定实施例的目的，而非意在限制本发明。除非上下文另外特别指明，本文所使用的单数形式“一个”、“一种”和“该”也包括复数形式“多个”、“多种”和“该等”。本文所使用的“第一”、“第二”等词语仅用于区别不同特征、步骤、操作、元件和/或部件等，既不表示任何特定的技术含义，也不表示它们之间的必然逻辑顺序。本文所使用的词语“多个”可以指两个或两个以上，词语“至少一个”可以指一个、两个或两个以上。对于本文中提及的任何特征、步骤、操作、元件和/或部件，在上下文没有另外特别指明的情况下，一般可以理解为一个或多个。还应理解的是，本文使用的词语“包括”和/或“包含”指存在所述特征、步骤、操作、元件和/或部件，但不排除一个或多个其他特征、步骤、操作、元件、部件和/或其集合的存在或增加。本文所使用的词语“和/或”包括一个或多个相关列出项目的任何或全部组合。本文中的元件后缀“模块”和“单元”仅是用于便于描述，因此，其能够交替使用，并且不具有任何有区别的意义或功能。
28.当与本发明的说明有关的现有技术对于本领域的技术人员而言显而易见时，将省略其详细描述。还应理解的是，本说明书对各个实施例的描述着重于强调各实施例之间的不同之处，实施例间的相同或相似之处可以相互参考，本说明书为了简洁起见，不做一一赘述。
29.在互联网分布式系统，在php生态的后端服务中利用hystrix实现熔断通常有多种方式，如命令(command)方式和中间件(middleware)方式。这两种方式都可以分为两步：第一步，查看断路器(circuit，也称为“熔断器”)和计数器(metric，也称为“统计器”)判断是否发出请求；第二步，在请求发出后(或请求未发出后)完成计数(也称为“统计”)和计算断路器状态。由于php生态服务大量使用guzzle来完成rpc(remote procedure call，远程过程调用)请求，而guzzle提供了middleware的方式可以在请求前和请求后分别执行middleware中的代码，因此本技术具体实施方式部分以middleware方式实现熔断为例进行说明。根据本发明的一个具体实施例，利用php的composer包，以middleware方式植入某个基于guzzle的rpc的逻辑中，从而实现本发明的至少一个发明目的。可以很容易地理解，本
领域技术人员在本说明书的基础上，可以很容易地以其他方式实现本发明。
30.以下结合图2～图5对hystrix及其断路器的整体逻辑和流程进行简要说明。hystrix中的断路器的作用和基本工作机制是，hystrix在运行过程中向每个commandkey对应的断路器报告请求成功、失败和拒绝的状态，断路器维护并统计这些数据，并根据这些统计信息来决策熔断开关是否打开(open)。如果打开，则熔断后续请求，快速返回(fallback)。隔一段时间之后断路器尝试半开(half open)，放入一部分流量请求进来，相当于对依赖服务进行一次健康检查，如果请求成功，则断路器关闭(close)。
31.如图2所示，在步骤s201中，hystrix在请求发出前执行可用性(isavailable)判断，即判断请求是否可用(具体判断方式例如图3中方案所示)，如果请求可用，则在步骤s203继续处理请求，否则在步骤s202执行降级回退(fallback)。
32.图3示出了执行可用性判断的具体步骤，如图3所示，在步骤s301中，首先判断断路器状态是否为关闭状态。如果答案为肯定，即断路器处于关闭状态，则在步骤s303发出请求，相当于图2中确定请求可用、继续处理请求的步骤s203；如果答案为否定，即断路器未处于关闭状态，而是处于打开或半开状态，则在步骤s302判断最后一次失败的时刻(latest fail time)是否在滑动窗口(rolling window)观察范围内。如果答案为肯定，即最后一次失败的时刻仍在滑动窗口观察范围内，则在步骤s305中不允许发出请求(拒绝请求，reject)，直接记录拒绝，然后执行降级回退，即相当于图2中确定请求不可用、执行降级回退的步骤s202；如果答案为否定，即最后一次失败的时刻已经不在滑动窗口观察范围内，则在步骤s304发出请求，相当于图2中确定请求可用、继续处理请求的步骤s203。
33.图4示出请求发出后hystrix对请求结果进行判断的基本逻辑流程图。如果经过上述可用性判断后允许请求发出，则在请求发出后，会得到如图4中s401所示的请求结果，请求结果初步分为s402所示的成功(success)和s403所示的失败(fail)。如果请求结果为s402所示的成功，还需要经过有效性检查(valid check)，再次区分哪些请求结果被认定为是s404所示的成功和s405所示的失败。这里的有效性检查是用户对返回的请求结果做自定义的判定统计，以便于计数，因此s403和s405所示的失败结果在认定标准上存在一定的差异，但其在统计口径上都划分为失败，在此意义上二者实质上相同。
34.经过图4所示的逻辑判断后，如果请求结果被判断为成功，则记录成功，增加成功的计数，随后如图5所示进行断路器相关操作。如图5所示，在步骤s501中，查看断路器的状态，断路器状态分为s502所示的半开(half open)状态、s504所示的打开(open)状态和s510所示的关闭(close)状态。如果断路器为半开状态，则在步骤s503重置统计(metric)和断路器状态为关闭。
35.如果断路器为打开状态，则需要检查是否在当前窗口中关闭或保持打开断路器，具体而言，在步骤s505首先判断失败的总次数是否为零，如果为零则在步骤s507中关闭断路器；如果不为零，则在步骤s506中判断失败的次数是否小于特定的第一阈值，该第一阈值可以根据需要进行设定。如果失败次数小于该第一阈值，则在步骤s507中关闭断路器，否则在步骤s508中判断失败率是否小于特定的第二阈值，同样地，该第二阈值也可以根据需要进行设定。如果失败率小于该第二阈值，则在步骤s507中关闭断路器，否则在步骤s509中保持断路器为打开状态(无操作)，即断路器状态不发生变化。
36.如果需要对失败计数，则断路器当前状态是否为关闭，如果断路器状态为s510所
示的关闭，则需要检查是否在当前窗口中打开或保持关闭断路器，具体而言，在步骤s511中首先判断失败的总次数是否为零，如果为零则在步骤s512中保持断路器为关闭状态(无操作)，即断路器状态不发生变化；如果失败次数不为零，则在步骤s513中判断失败的次数是否小于上述特定的第一阈值，该第一阈值可以根据需要进行设定。如果失败次数小于特定阈值，则在步骤s515中保持断路器关闭，并增加失败计数(加一操作)，否则在步骤s514中判断失败率是否小于上述特定的第二阈值，同样地，该第二阈值也可以根据需要进行设定。如果失败率小于该第二阈值，则在步骤s515中保持断路器关闭，并增加失败计数(加一操作)，否则在步骤s516中打开断路器，即把断路器状态置为打开。
37.hystrix中实现计数器的方案可以有多种，本发明实施例采用滑动窗口(rolling window)来进行计数。以下结合图6～图7对hystrix的滑动窗口进行说明。滑动窗口记录循环数组，并且随着时间的推移不停的覆盖最后一个需要淘汰的桶(bucket)，桶是hystrix统计滑动窗口数据时的最小单位，桶的大小乘以桶的个数n即等于滑动窗口的大小，即桶相当于窗口n分之一的概念。桶的个数n可以根据系统配置进行设置，也可以是一个定值。但是桶的个数n原则上不应设置得过大或过小，过小会降低计数器的灵敏度，过大会带来性能的耗损。本说明书示例性实施例以滑动窗口包含5个桶为例进行说明，如图6所示，桶分别以a、b、c、d、e标记，这5个桶首尾相连形成一个圆环，表示滑动窗口被桶a、b、c、d、e占满。
38.桶的生成和过期分为以下几种情况：(1)滑动窗口中没有桶，此情况对应于首次运行计数或者所有桶已过期的情况，此时从桶a开始记录计数；(2)滑动窗口中有未过期的桶，此情况则依据最新的桶来计算目标桶的序列。以下将结合图7对如何计算目标桶的序列进行说明，图中阴影部分代表滑动窗口，横坐标表示时间线，竖向箭头代表当前时刻，为便于说明，图中仅示出了桶a、c、d及过期的桶c(图中表示为“前桶c”)。如图7所示，滑动窗口中距离当前时间最近一个未过期的桶为a，依据当前时间和桶a的起始时间计算比如有2.7 个桶时间的间隔，那么直接产生桶c，并在桶c中计数。举例来说，如果窗口大小为10秒(10s)，则每个桶的大小为2s。随着时间的推移，当之前的桶c过期的时候，同时生成新的桶c，之前的桶c中的数据全部失效，新的桶c开始计数。
39.本发明中桶的实现使用了redis中存放的数据格式为哈希(hash)结构，哈希结构中存放了10个键(key)，桶a、b、c、d、e各两个键，分别为各桶的生成时间及其当前值。以桶a为例，其两个键分别为桶a的成生成时间(定义为bucket_a_start_time)和桶a的当前值(定义为bucket_a_value)。桶b、c、d、e的两个键与上述桶a类似，不再赘述，这样哈希结构中共有10个键。仍以桶a为例(其他桶与桶a类似)，bucket_a_start_time记录桶a的创建时间，其单位为秒，精确到10的
‑
6次方，这个时间用于判断桶是否过期，如果过期则被销毁，创建新的桶；bucket_a_value记录了一个64位(bit)二进制整数，每个bit位的使用例如可以如图8所示，其详细说明列于下表1中。
40.表1桶a当前值比特位具体说明
[0041][0042]
这样，对应于上述成功计数的操作，只需加1(1
×
20)；对应于失败计数的操作，只需加(1
×224
)；对应于拒绝计数的操作，只需加(1
×242
)。每次对当前桶只做前述三种计数中的一种，可以使用redis的hincrby这种原子操作来完成。如果加到溢出，每次使用计数器的时候会判断溢出位是否有值，如果有值则抛出异常，终止计数流程。rpc请求中可以处理这种异常。
[0043]
通过以上方式，每次获取每个桶中计数的时候只对前述成功、失败、拒绝三种计数中的一种进行计数，而不像现有技术中对每个桶要进行三种计数，这样每个桶就可以省去读取两个键的操作，五个桶即可省去十次读取。并且在桶过期时，整个桶的计数和时间记录销毁即可，无需使用redis的zremrangebyscore操作(该操作的复杂度为o(lgn m)，n是集合中的元素个数zset需要找到跳跃表的这个范围的起始和终止位置，m是这个范围中的元素个数，一旦集合较大时，这个操作就会非常消耗redis的cpu和增加整体耗时)，大幅减少了对redis性能的消耗。
[0044]
需要说明的是，以上实施例中的桶当前值的比特位，包括总位数和各类型计数的比特位范围，均为示例性的而非任何限制，本领域技术人员可以在以上示例性实施例的基础上，很容易地根据实际需要改变桶当前值的比特位，例如改为32位或128位，同时根据需要改变各类型计数的比特位范围，同样可以实现本发明技术方案，并取得同样的技术效果，实现同样的发明目的。
[0045]
在分布式系统中，虽然通常服务器会定期校准时间，但仍然不可避免地会存在一定的时间差异。因此，本发明还可以进一步包括使用中心化的时间来提升准确度，消除分布式的时间差异。具体而言，如果使用服务器的时间作为记录上报的时间，可能在同一时刻上报的统计数据就会落入不同的桶中。举例来说，假设服务器x比基准时间快1s，服务器y比基准时间慢1s，若桶的大小为2s，服务器x计算当前桶为桶b，因而向桶b执行计数操作，而如果同时服务器y也有一个请求，其计算当前桶为桶a，因而向a中执行统计操作，这种场景势必会造成统计混乱，影响熔断器的工作。为了消除这种因时间差异而造成的混乱，根据本发明一实施例的技术方案在每次计算当前桶的时候，提前从redis获取当前时间，然后以这个时间来计算当前桶。虽然从redis中获取当前时间时，遇到网络延时也会造成差异，但相比较于从服务器本地获取时间的方案已有较大的改善。
[0046]
根据本发明一实施例的技术方案还针对redis开启了长连接和/或加入了链路追踪(trace)。在实际应用高并发场景下，开启长连接可以使得php
‑
fpm与redis之间建立tcp通道，省去较多的tcp建立和关闭的操作，减少浪费，节约时间。加入链路追踪可以方便在某次请求中查询请求和写入计数器的状态是否正确，从而可以感知计数器是否正常工作。链路追踪的操作可以包括如下表2中所列出的示例。
[0047]
表2链路追踪操作示例及使用场景说明
[0048]
操作使用场景get断路器状态获取set断路器状态设置获取eval获取多个值或一次多个操作hgetall获取所有桶的计数del重置断路器
[0049]
根据本发明一实施例的技术方案还使用redis运行lua脚本，将例如获取的桶、系统时间、最新失败时间和断路器状态等信息都写入到同一个lua命令中，然后发送给redis。这样既能全面地获取信息，又节省了网络的io的开销。
[0050]
根据本发明一实施例的技术方案还加入了监控与报警功能。监控报警可以分为两类：第一类监控报警为断路器状态的监控报警，当断路器状态有变化的时候会发出通知，告知开发人员断路器从关闭变为打开，一般为某种失败过多过于集中，熔断机制开始触发，当然也有断路器恢复的情况。第二类监控报警为链路追踪的上报，可以上报到已有的监控体系中，一旦redis出现异常则会触发此类报警，此时开发人员就可以得知断路器本身有问题，然后可以决定关闭这种机制也可以进行综合判断。
[0051]
本发明上述实施例对依赖的存储介质redis进行了优化，在对系统加入了熔断能力的同时，尽可能地降低对redis的开销，使得相同的redis可以针对更大的并发来计数。
[0052]
另一方面，本技术还提供了一种分布式系统，其除了常规分布式系统所包含的硬件之外，还包含集群熔断模块，该集群熔断模块基于hystrix利用滑动窗口进行统计，其能够实现本发明上述基于hystrix的分布式系统集群熔断方法。其中，所述滑动窗口由多个桶组成，所述桶使用redis存放为哈希结构，该哈希结构的键包括桶生成时间和桶当前值，桶当前值可以是二进制整数，该二进制整数的比特位包括成功比特位、失败比特位、拒绝比特位、未使用比特位以及设置在该四个比特位之间的防溢出比特位，所述成功比特位、失败比
特位和拒绝比特位分别记录请求的成功操作、失败操作和被拒绝操作，所述防溢出比特位在统计时如果出现值，则终止统计流程。
[0053]
根据本发明一实施例，所述集群熔断模块以从redis获取的时间为基准进行统计。另外，所述集群熔断模块还可以对于redis开启长连接并且/或者设置链路追踪。此外，所述集群熔断模块还可以利用lua脚本将信息写入lua命令，并发送给redis。最后，当断路器状态发生变化和/或redis出现异常时，所述集群熔断模块还可以发出通知信息。
[0054]
另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的系统中所包含的；也可以是单独存在而未装配入该系统中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该装置执行时，使得该装置可以实现本发明上述基于hystrix的分布式系统集群熔断方法的步骤。
[0055]
再一方面，本技术还提供了一种计算机程序产品，其包括计算机指令，该计算机指令被处理器执行时实现本发明上述基于hystrix的分布式系统集群熔断方法的步骤。
[0056]
特别地，以上参考附图中的流程图描述的实施例可以被实现为计算机软件程序。例如，本技术说明书公开的实施例包括一种计算机程序产品，该计算机程序产品包含用于执行附图中各流程图所示的本发明的hystrix的分布式系统集群熔断方法的程序指令或代码。在这样的实施例中，该计算机程序可以通过通信单元从网络上下载和安装，以及/或者从可拆卸介质安装。在该计算机程序被执行时，实现本发明的方法。
[0057]
需要说明的是，本技术所描述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是，但不限于，电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom)、闪存、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0058]
在本技术中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等，或者上述的任意合适的组合。
[0059]
可以通过一种或多种程序设计语言或其组合来编写用于执行本技术操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言，诸如java、smalltalk、c ，还包括常规的过程式程序设计语言，诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(lan)或广域网(wan)连接到用户计算机，或者，可以连接到外部计算机(例如利用互联网服务提供商来通过互联网连接)。
[0060]
附图中的流程图和框图，示例性示出了按照本技术各实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。应当注意，在有些可作为替换的实施方式中，方框中所标注的功能也可以以不同于附图中所示的顺序发生。例如，两个依次表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。还要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0061]
本技术实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。上述单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器，其包括集群熔断模块。这些单元或模块的名称在某些情况下并不构成对该单元或模块本身的限定。
[0062]
在本说明书中提及的所有文献都在本技术中引用作为参考，就如同每一篇文献被完整引用至本说明书作为参考。
[0063]
此外应理解，在阅读了本发明的上述说明内容之后，本领域技术人员可以对本发明做出各种改动或修改，这些等同形式同样落入本发明的保护范围。