服务如何做熔断，降级，限流？

基础概念

降级（自身服务出现问题，降级）

降级也就是服务降级，当服务器压力剧增为了保证核心功能的可用性 ，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

一般而言都会建立一个独立的降级系统，可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的，例如接口超时降级、失败重试多次降级等。具体失败几次，超时设置多久，由你们的业务等其他因素决定。开个小会，定个值，扔线上去看看情况。根据情况再调优。

熔断（依赖的外部接口出现故障的情况时，断绝和外部接口的关系）

那什么时候熔断合适呢？也就是到达哪个阈值进行熔断，5分钟内50%的请求都超过1秒？还是啥？参考降级。

限流

即限制流量。

我们是如何做的？

降级

• 标记，灰度规则不执行
• 指定规则，场景不执行/严格限制执行时间
• 缓存不刷新
• 不发日志 / 不记录 info 日志
• 不重要业务方流量直接返回

熔断

• 从用户层面来看，实现路径是：由用户针对 场景-规则 配置熔断规则，比如：最近10分钟命中量 >= 1000时，将规则由生效状态转为标记状态等等

后端服务是通过 Hystrix 做的熔断与降级

降级函数

• fail fast ：快速失败，直接在run方法中抛异常。
• fail silent：安静失败，返回 null,空列表等等操作。
  
• static fallback ：返回缺省值，或者是默认值。

资源隔离:线程隔离，信号量隔离

● 线程隔离: Hystrix 会给每一 个 Command 分配一个单独的线程池， 这样在进行单个服务调用的时候，就可以在独立的线程池里面进行，而不会对其他线程池造成影响。
● 信号量隔离:客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时,后续的请求都会直接拒绝，进入falback流程。信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞,从而达到限流和防止雪崩的目的。

限流

通过内部平台 Rhino 做的限流。

Hystrix替代品之 Alibaba Sentinel 简介