服务熔断、降级、限流、异步RPC -- HyStrix

我会带着你远行 2021-09-15 10:28 381阅读 0赞

[https://blog.csdn.net/chunlongyu/article/details/53259014][https_blog.csdn.net_chunlongyu_article_details_53259014]

在今天，基于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举例：

public class CommandHelloWorld extends HystrixCommand<String> { 
    
        private final String name;
    
        public CommandHelloWorld(String name) {
            super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
            this.name = name;
        }
    
        @Override
        protected String run() {
            //关键点：把一个RPC调用，封装在一个HystrixCommand里面
            return "Hello " + name + "!";
        }
    }
    
    //客户端调用：以前是直接调用远端RPC接口，现在是把RPC接口封装到HystrixCommand里面，它内部完成熔断逻辑
    String s = new CommandHelloWorld("World").execute();

*  1
 *  2
 *  3
 *  4
 *  5
 *  6
 *  7
 *  8
 *  9
 *  10
 *  11
 *  12
 *  13
 *  14
 *  15
 *  16
 *  17
 *  18

## 隔离策略: 线程 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框架，都有参数直接设置这个。

还有一些场景下，可用限制总数：比如连接数，业务层面限制“库存“总量等等。。