系列文章目录

面试Dubbo ，却问我和Springcloud有什么区别？
超简单，手把手教你搭建Dubbo工程（内附源码）
【收藏向】从用法到源码，一篇文章让你精通Dubbo的SPI机制
Dubbo最核心功能——服务暴露的配置、使用及原理
并不简单的代理，Dubbo是如何做服务引用的
不满足于RPC，详解Dubbo的服务调用链路
从理论到实践，必须了解的部分Dubbo配置

---

---

在当今互联网时代，随着用户量的不断增长和业务复杂性的提升，高并发成为了很多系统面临的挑战。Dubbo作为一种优秀的分布式服务框架，在大规模高并发场景下也面临着一系列的挑战，其中最突出的，就是大量调用带来的流量问题。这次我就和大家一起探讨下Dubbo在高并发情况下的问题，并针对性地介绍流量控制解决方案，帮助大家更好地应对高并发场景下的挑战

📕作者简介：战斧，多年开发及管理经验，爱好广泛，致力于创作更多高质量内容
📗本文收录于 Dubbo专栏，有需要者，可直接订阅专栏实时获取更新
📘高质量专栏 RabbitMQ、Spring全家桶 等仍在更新，欢迎指导
📙Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待

---

一、与Dubbo有相关的高并发问题

1. 资源耗尽

高并发情况下，Dubbo所占用的资源会大幅上升，包括线程池、内存、CPU等。当资源耗尽时，系统性能会急剧下降，甚至导致系统崩溃。并且因为Dubbo使用的长连接通信，高并发下会导致连接状态过多，可能会导致网络堵塞、连接耗尽等问题

2. 服务雪崩

服务雪崩是指当某个服务出现故障或响应过慢时，请求会在服务之间传递，导致所有相关服务都不可用的现象。在高并发情况下，一旦出现服务雪崩，整个系统的可用性将受到严重影响。

如图，故障应用的影响范围，会逆着调用方向进行扩散，导致更大面积的故障。

二、控制思路

其实我们分析Dubbo在高并发情况下的问题，随着并发数的增多，前者(资源占用)其实是不可避免的，解决策略无非是硬件升级或性能优化来进行缓解。我们真正关注的，其实是：

1. 如何控制单台机器或单个服务的流量，避免负载过重，过长响应时间甚至宕机？
2. 如果真的出现响应缓慢甚至宕机，如何避免故障扩大化，防止服务雪崩？

单机流量控制 ，思路主要就是分流、限流和错峰，其中限流也可以分为入口请求限流，和服务自身的保护式限流。同时也要注意，流量不仅来源于入口，也应该避免架构体系自身产生过多内部请求。
避免服务雪崩，主要考虑单机与架构层面，单机层面针对某些服务拆分不够细的工程，一个服务过饱和，不应该影响该机器的其他服务。架构层面：一台机器的宕机，主要依赖于故障转移，及时的熔断降级进行处理，尽量不影响其他机器

三、控制方案

1. 限流策略

限流是最常见也是最有效的流量控制手段之一。通过限制每个服务的最大并发请求量，可以有效防止系统被过多的请求压垮。在Dubbo中，其实对于服务提供者有着现成的限流保护：TpsLimitFilter

@Activate(group = CommonConstants.PROVIDER, value = TPS_LIMIT_RATE_KEY)
public class TpsLimitFilter implements Filter {
    private final TPSLimiter tpsLimiter = new DefaultTPSLimiter();
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        if (!tpsLimiter.isAllowable(invoker.getUrl(), invocation)) {
            throw new RpcException(
                    "Failed to invoke service " +
                            invoker.getInterface().getName() +
                            "." +
                            invocation.getMethodName() +
                            " because exceed max service tps.");
        }
        return invoker.invoke(invocation);
    }
}

但官方可能觉得这种程度的限流并不够理想，因此没有使用它，使得想真正启用该拦截器还要开发者手动做不少处理。因此我们也并不推荐这种做法。
与之对比的是，官方目前大力推广的都是借助第三方组件如Sentinel实现限流策略。Sentinel 提供了与 Dubbo 适配的模块 – Sentinel Dubbo Adapter，包括针对服务提供方的过滤器和服务消费方的过滤器（Filter）。使用时我们只需引入以下模块（dubbo3.0.5以上）

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-apache-dubbo3-adapter</artifactId>
    <version>x1.8.6</version>
</dependency>

引入此依赖后，Dubbo 的服务接口和方法（包括调用端和服务端）就会成为 Sentinel 中的资源，在配置了规则后就可以自动享受到 Sentinel 的防护能力。

2. 服务降级

服务降级是在系统遇到高并发或资源耗尽的情况下，暂时屏蔽一些非核心或可选功能，保证系统的核心功能依然可用。Dubbo支持在服务提供方进行服务降级，可以通过设置降级策略来应对高并发时的情况。在Dubbo里，我们可以使用Mock功能来实现降级，即通过配置消费端的mock参数，设定服务降级策略
我们还以以前的Demo为例子，写一个Mock:

public class DemoServiceMock implements DemoService {
    @Override
    public String sayHello(String name) {
        return "出现故障，mock上任";
    }
}

然后在引用的位置加上 mock 参数为 true，当然mock的用法有很多种，你也可以直接写实现类名。

然后将服务提供者进行线程睡眠处理

此时，将触发Mock的执行

3. 超时重试

对于一些耗时较长的服务调用，设置合理的超时时间是必要的。超时控制可以防止请求在服务提供方占用过多资源，从而保护系统的稳定性。在Dubbo中，我们可以通过配置超时时间来控制服务的调用时间。

有记忆好的朋友，应该还记得 【问题处理】—— 一次内存溢出（OutOfMemoryError）实战排查 这个问题，其中很大原因就是调用下游系统，下游系统卡死，但超时设置时间过长，导致资源占用太多。所以保持较小的超时时间可以避免故障扩大。
而重试则是指消费端在调用失败后的重试次数，在高并发下，这个值可以设置的小一些，甚至可以不进行重试

4. 故障转移

在高并发情况下，服务之间的调用可能会因网络波动或服务不可用而失败。Dubbo提供了多种集群容错策略，如快速失败、失败重试、失败安全等，可以根据具体情况选择合适的策略，保障服务的稳定性。

关于集群容错，现在内置的几种方案，我们此处并不细说，主要是根据应用场景来进行选择。

5. 负载均衡

配合着限流的，还应当有分流，而负载均衡就起到了分流的作用，我们在Dubbo中可以设置多种负载均衡模式：

我们可以进行全局配置，比如

<!-- 全局负载均衡策略 -->
<dubbo:consumer loadbalance="random" />

也可以进行服务接口级别的配置，比如

@Service(interfaceClass = XxxService.class, loadbalance = "leastactive")
public class XxxServiceImpl implements XxxService {
    //...
}

其多种均衡策略，leastactive - “最少活跃调用数负载均衡” 是比较适合在高并发场景下选用的,，即当前活跃数（active，即指某个服务提供者正在处理请求的数量）最小的那个服务提供者，如果活跃数相同，则随机选择一个。比如，当前有3个服务提供者，其活跃数分别为：2、3、4，那么就会选择活跃数为2的服务提供者。当第一个服务提供者的活跃数增加到3时，那么最少活跃调用数的服务提供者就变成了第一个服务提供者

6. 线程池隔离

当某一块业务访问量大增，往往会伴随着资源占用的急剧增加，但是我们并不希望应用整个宕机，此时就要用到线程池隔离，线程池隔离是一种将请求任务与线程池分离的技术，我们在Dubbo里可以这么使用executes来为指定服务建立定长的线程池

@Service
@DubboService(interfaceClass = XxxService.class, executes = 10)
public class XxxServiceImpl implements XxxService {
    // 服务实现代码
}

这将为该服务创建一个固定大小为10的线程池，供服务消费者调用该服务时使用。这样当同时有11个请求到来时，第11个请求只能等到或被拒，事实上形成了限流，具有类似效果的参数还有 actives

7. 异步削峰

我们其实在讲rabbitMQ的时候，就提到过异步的好处，其中之一就是可以削峰。同样的Dubbo也能使用 async 进行异步调用，来避免瞬时的大流量造成的服务故障。更具体的讲，这种场景下有三个好处：

1. 减少响应时间：在高并发场景下，同步调用会阻塞线程，导致响应时间变长。而异步调用可以让线程立即返回，不用等待响应，从而缩短响应时间。
2. 提高容错能力：在同步调用中，如果某个调用出现异常，那么整个调用链都会被打断，从而影响到其他调用的正常执行。而异步调用会把调用拆分成多个独立的任务，每个任务独立执行，如果其中某个任务出现异常，不会影响其他任务的执行，从而提高了容错能力。
3. 提高吞吐量：在高并发场景下，同步调用可能会因为线程阻塞导致线程池资源耗尽，从而影响系统的吞吐量。异步调用可以将请求提交到异步线程池中执行，从而释放主线程，提高了系统的吞吐量。

而我们的设置也是可以分为全局设置，和服务接口级别。其中全局配置如下(不建议):

<dubbo:consumer async="true" />
<dubbo:provider async="true" />

单个服务配置如下

@DubboReference(async = true)
private DemoService demoService;

四、结论

高并发是Dubbo应用需要面对的一个持续挑战。通过合理配置流量控制方案，包括限流策略、服务降级、超时控制和集群容错等操作，我们可以有效地保护系统免受高并发压力带来的影响。同时，需要注意不同业务场景可能需要不同的流量控制策略，因此我们需要根据实际情况进行调优和监控。