当Dubbo遇到高并发:探究流量控制解决方案

举报
战斧 发表于 2023/09/21 19:21:05 2023/09/21
【摘要】 在当今互联网时代,随着用户量的不断增长和业务复杂性的提升,高并发成为了很多系统面临的挑战。Dubbo作为一种优秀的分布式服务框架,在大规模高并发场景下也面临着一系列的挑战,其中最突出的,就是大量调用带来的流量问题。这次我就和大家一起探讨下Dubbo在高并发情况下的问题,并针对性地介绍流量控制解决方案,帮助大家更好地应对高并发场景下的挑战一、与Dubbo有相关的高并发问题1. 资源耗尽高并发情...


在这里插入图片描述

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


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

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。