在今天，基于SOA的架构已经大行其道。伴随着架构的SOA化，相关联的服务熔断、降级、限流等思想，也在各种技术讲座中频繁出现。本文将结合Netflix开源的Hystrix框架，对这些思想做一个梳理。

背景

伴随着业务复杂性的提高，系统的不断拆分，一个面向用户端的API，其内部的RPC调用层层嵌套，调用链条可能会非常长。这会造成以下几个问题：

API接口可用性降低

引用Hystrix官方的一个例子，假设tomcat对外提供的一个application，其内部依赖了30个服务，每个服务的可用性都很高，为99.99%。那整个applicatiion的可用性就是：99.99%的30次方 ＝ 99.7%，即0.3%的失败率。

这也就意味着，每1亿个请求，有30万个失败；按时间来算，就是每个月的故障时间超过2小时。

系统被block

假设一个请求的调用链上面有10个服务，只要这10个服务中有1个超时，就会导致这个请求超时。
更严重的，如果该请求的并发数很高，所有该请求在短时间内都被block（等待超时），tomcat的所有线程都block在此请求上，导致其他请求没办法及时响应。

服务熔断

为了解决上述问题，服务熔断的思想被提出来。类似现实世界中的“保险丝“，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。
熔断的触发条件可以依据不同的场景有所不同，比如统计一个时间窗口内失败的调用次数。

实现原理

实现原理讲起来很简单，其实就是不让客户端“裸调“服务器的rpc接口，而是在客户端包装一层。就在这个包装层里面，实现熔断逻辑。
拿Hystrix的helloword举例：

隔离策略: 线程 vs 信号量

缺省的，上面的HystrixCommand是被扔到一个线程中执行的，也就是说，缺省是线程隔离策略。
还有一种策略就是不搞线程池，直接在调用者线程中执行，也就是信号量的隔离策略。
关于这2者的详细区别，可以去参见官网。

熔断的参数配置

Hystrix提供了如下的几个关键参数，来对一个熔断器进行配置：

circuitBreaker.requestVolumeThreshold //滑动窗口的大小，默认为20
circuitBreaker.sleepWindowInMilliseconds //过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.errorThresholdPercentage //错误率，默认50%

3个参数放在一起，所表达的意思就是：
每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

服务降级

有了熔断，就得有降级。所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。
这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。

关于Hystrix中fallback的使用，此处不详述，参见官网。

服务限流

限流在日常生活中也很常见，比如节假日你去一个旅游景点，为了不把景点撑爆，管理部门通常会在外面设置拦截，限制景点的进入人数（等有人出来之后，再放新的人进去）。

对应到计算机中，比如要搞活动，秒杀等，通常都会限流。

说到限流，有个关键问题就是：你根据什么策略进行限制？？

比如在Hystrix中，如果是线程隔离，可以通过线程数 + 队列大小限制；如果是信号量隔离，可以设置最大并发请求数。

另外一个常见的策略就是根据QPS限制，比如我知道我调用的一个db服务，qps是3000，那如果不限制，超过3000，db就可能被打爆。这个时候，我可用在服务端做这个限流逻辑，也可以在客户端做。

现在一般成熟的RPC框架，都有参数直接设置这个。