Dubbo服务降级
1. 为什么需要服务降级
RPC 是解决分布式系统通信问题的一大利器，而分布式系统的一大特点就是高并发，所以说 RPC 也会面临高并发的场景。在这样的情况下，我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，我们要保证服务的稳定性和高可用性，这时我们就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。
2. 服务端的自我保护
先说个结论，服务端自我保护的方式就是限流,包括服务端的限流和客户端的限流。
也就是说，如果某个服务节点的负载压力高，那么就让该服务节点不再接收太多的服务请求就好。等接收和处理的请求数量下来后，这个节点的负载压力自然就下来了。
简单来说，就是让刚启动的服务提供方应用不承担全部的流量，而是让它被调用的次数随着时间的移动慢慢增加，最终让流量缓和地增加到跟已经运行一段时间后的水平一样。
如下:
Dubbo限流的方式
Dubbo 中的并发控制
样例 1
限制 com.foo.BarService 的每个方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
<dubbo:service interface="com.foo.BarService" executes="10" />
样例 2
限制 com.foo.BarService 的 sayHello 方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
<dubbo:service interface="com.foo.BarService">
<dubbo:method name="sayHello" executes="10" />
</dubbo:service>
样例 3
限制 com.foo.BarService 的每个方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
<dubbo:service interface="com.foo.BarService" actives="10" />
连接控制
样例1 服务端连接控制
限制服务器端接受的连接不能超过 10 个：
<dubbo:provider protocol="dubbo" accepts="10" />
样例2 客户端连接控制
限制客户端服务使用连接不能超过 10 个 2：
<dubbo:reference interface="com.foo.BarService" connections="10" />
Dubbo限流源码分析
通过以上的分析，我们知道在Dubbo可以通过多种的方式进行服务端的限流。实际上，上面的每一种限流的逻辑都是
一个个Filter，所有的Filter会连接成一个过滤器链，每次请求都会经过整个链路中的每一个Filter。后面会出一篇文章详细介绍Dubbo Filter了，这里就不再展开了。
3. 调用端的自我保护
熔断
以上分析了服务端的自我保护，那么调用端是否也需要进行自我保护呢？答案是肯定的。
举个例子。
有服务A, 服务B, 服务C 三个服务方。它们之间存在如下的调用链关系:
服务A -> 服务B -> 服务C。
也就是服务A 依赖于服务B，服务B依赖于服务C。当一个服务 A 来调用服务 B 时，服务 B 的业务逻辑调用服务 C，而这时服务 C 响应超时了，由于服务 B 依赖服务 C，C 超时直接导致 B 的业务逻辑一直等待，而这个时候服务 A 在频繁地调用服务 B，服务 B 就可能会因为堆积大量的请求而导致服务宕机。
如下图所示:
所以说，在一个服务作为调用端调用另外一个服务时，为了防止被调用的服务出现问题而影响到作为调用端的这个服务，这个服务也需要进行自我保护。而最有效的自我保护方式就是熔断。
关于熔断，可以看下面的这篇文章:
熔断
但是Dubbo中主要是通过Dubbo Mock来实现的，不能说是真正的熔断。
Dubbo Mock配置
- 服务消费者注册url的mock属性
可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。
向注册中心写入动态配置覆盖规则：
RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
其中：
-
mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
-
还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
- @DubboReference注解或者dubbo:reference标签的mock属性
这个标签的作用主要是用于本地伪装。比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过 Mock 数据返回授权失败。
例子：
mock=“return null”，即当服务提供者出现异常（宕机或者业务异常），则返回null给服务消费者。
public class HelloController{
@DubboReference(check = false,lazy = true,retries = 1,mock = "return null")
private DubboServiceOne dubboServiceOne;
//.....
}
MockClusterInvoker源码分析
com.alibaba.dubbo.rpc.cluster.support.wrapper.MockClusterInvoker ，实现 Invoker 接口，MockClusterWrapper 对应的 Invoker 实现类。
- 构造方法
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rcj4NxkQ-1673527805154)(https://tva1.sinaimg.cn/large/008i3skNgy1gqs6y28rt4j31p60nodkd.jpg)]](https://img-blog.csdnimg.cn/818d15d50a554730b0568d0b9248e0c7.jpeg)
- invoke
从上面的源码分析可知：
-
在 MockClusterInvoker#invoke 方法里面，如果是业务异常是不会做 mock 做处理的。而其他关于 RPC 的异常，是会做 mock 处理的，例如我们这里拿来测试的服务提供者超时异常和服务提供者不存在；
-
在 doMockInvoke 方法中，首先会调用 selectMockInvoker 方法会尝试获取 MockInvoker，而默认情况下，都是没有的，所以最后会使用 Dubbo 提供的 MockInvoker。
4. 总结
通过以上的分析，我们可以知道，服务端主要是通过限流来进行自我保护。而调用端主要是通过熔断来进行自我保护。
5. 鸣谢
RPC核心实战与原理
Dubbo服务熔断与降级的深入讲解&代码实战
