服务降级的目的

为什么服务降级？

当对业务的请求超过业务系统预设的上限阈值时，为了保证基本和重要的业务模块正常运行，

1. 拒绝部分请求
   

2. 不重要的业务模块暂停服务或延迟提供服务。

例如天猫在双11的服务降级：

服务降级的实现手段

服务降级的手段有两大类：

第一类是关闭部分非核心服务。例如双12当天，京东暂时关闭退货服务。

第二类是拒绝部分请求。这里面又分成三个手段

（1）根据RPC队列方式，把旧的请求丢弃。我们还是想想双12买东西。在业务逻辑层pendding的旧的请求，或许客户端已经取消了，因此要舍弃请求，一定先舍弃最久的。但这种方式有个问题，旧的请求可能是核心请求，新的可能是非核心请求的。

（2）根据请求报文CMD的优先级。在CMD列表的请求保留，不在列表中的CMD舍弃。

实际应用中，需要前两种相结合，即（1）决定什么时候开启、关闭丢弃  （2）决定丢弃谁

（3）随机拒绝方式：这种不靠谱，实际环境没人用。

服务降级的设计

我们将服务降级设置在什么位置？网关还是全链路？

1. 在网关层做服务降级：

   这样做不靠谱的地方是，因为一个网关后面可能有多个业务逻辑层。

2.全链路降级。也就是使用上上个图中两种方法结合的方式。让网关、业务逻辑层、数据访问层都有降级的机制。每一层能处理多少请求自己说了算。

和方案1比，方案2更靠谱。

那么，有一个小疑问，在方案2中，DB层是否需要做降级？

在上图的模型中，读同步写异步。读的时候，DAO层已经做了限流，就不用在DB层限流。在写请求时，会先写到MQ，所以只要是MQ没有超限，DB就不会出现问题。

熔断的实现

熔断的实现有两种方式：组件级、平台级：

组件级解决方案

Neflix的Hystrix熔断组件是个jar包。Hystrix的熔断机制是API颗粒度的。如下图所示：

前面说过，Hystrix是组件级的熔断，好处是使用的时候，直接引入Jar包就可以。坏处是，任何要做熔断的微服务，它的上上游都需要引入jar，而且Hystrix限制哪个API，是需要硬编码的。

平台级解决方案

如果上下游调用是RPC。我们能否把熔断的功能写入到RPC Client。这样上游引入RPC Client客户端就可以，而不需要引入单独的jar包。此外，哪些API需要熔断，最好写在配置中心。

如下图所示，我们在dashboard写入要限制API的名称以及参数，然后通过服务管理平台将配置规则推送给网关。网关上的RPC Client（RPC Over TCP）可以解析这些配置，并其下游的业务逻辑层对应的API进行熔断。

服务管理平台的本质如下图所示，即服务数据平台是控制面板。

服务治理平台实现熔断的逻辑图，图示比较清楚，不再赘述：

在构建服务治理平台时，可以参照现在市面上新型的熔断器框架，例如Resilience4j，会有服务器模式和嵌入模式。前者会有一个独立的 Resilience4j server，后者还是引入jar包。前者性能会好不少。

具体可以参考https://xie.infoq.cn/article/14786e571c1a4143ad1ef8f19