当Dubbo遇到高并发:探究流量控制解决方案
在当今互联网时代,随着用户量的不断增长和业务复杂性的提升,高并发成为了很多系统面临的挑战。Dubbo作为一种优秀的分布式服务框架,在大规模高并发场景下也面临着一系列的挑战,其中最突出的,就是大量调用带来的流量问题。这次我就和大家一起探讨下Dubbo在高并发情况下的问题,并针对性地介绍流量控制解决方案,帮助大家更好地应对高并发场景下的挑战
高并发情况下,Dubbo所占用的资源会大幅上升,包括线程池、内存、CPU等。当资源耗尽时,系统性能会急剧下降,甚至导致系统崩溃。并且因为Dubbo使用的长连接通信,高并发下会导致连接状态过多,可能会导致网络堵塞、连接耗尽等问题
服务雪崩是指当某个服务出现故障或响应过慢时,请求会在服务之间传递,导致所有相关服务都不可用的现象。在高并发情况下,一旦出现服务雪崩,整个系统的可用性将受到严重影响。
如图,故障应用的影响范围,会逆着调用方向进行扩散,导致更大面积的故障。
其实我们分析Dubbo在高并发情况下的问题,随着并发数的增多,前者(资源占用)其实是不可避免的,解决策略无非是硬件升级或性能优化来进行缓解。我们真正关注的,其实是:
- 如何控制单台机器或单个服务的流量,避免负载过重,过长响应时间甚至宕机?
- 如果真的出现响应缓慢甚至宕机,如何避免故障扩大化,防止服务雪崩?
单机流量控制 ,思路主要就是分流、限流和错峰,其中限流也可以分为入口请求限流,和服务自身的保护式限流。同时也要注意,流量不仅来源于入口,也应该避免架构体系自身产生过多内部请求。
避免服务雪崩,主要考虑单机与架构层面,单机层面针对某些服务拆分不够细的工程,一个服务过饱和,不应该影响该机器的其他服务。架构层面:一台机器的宕机,主要依赖于故障转移,及时的熔断降级进行处理,尽量不影响其他机器
限流是最常见也是最有效的流量控制手段之一。通过限制每个服务的最大并发请求量,可以有效防止系统被过多的请求压垮。在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 的防护能力。
服务降级是在系统遇到高并发或资源耗尽的情况下,暂时屏蔽一些非核心或可选功能,保证系统的核心功能依然可用。Dubbo支持在服务提供方进行服务降级,可以通过设置降级策略来应对高并发时的情况。在Dubbo里,我们可以使用Mock功能来实现降级,即通过配置消费端的mock参数,设定服务降级策略
我们还以以前的Demo为例子,写一个Mock:
public class DemoServiceMock implements DemoService {
@Override
public String sayHello(String name) {
return "出现故障,mock上任";
}
}
然后在引用的位置加上 mock
参数为 true
,当然mock的用法有很多种,你也可以直接写实现类名。
然后将服务提供者进行线程睡眠处理
此时,将触发Mock的执行
对于一些耗时较长的服务调用,设置合理的超时时间是必要的。超时控制可以防止请求在服务提供方占用过多资源,从而保护系统的稳定性。在Dubbo中,我们可以通过配置超时时间来控制服务的调用时间。
有记忆好的朋友,应该还记得 【问题处理】—— 一次内存溢出(OutOfMemoryError)实战排查 这个问题,其中很大原因就是调用下游系统,下游系统卡死,但超时设置时间过长,导致资源占用太多。所以保持较小的超时时间可以避免故障扩大。
而重试则是指消费端在调用失败后的重试次数,在高并发下,这个值可以设置的小一些,甚至可以不进行重试
在高并发情况下,服务之间的调用可能会因网络波动或服务不可用而失败。Dubbo提供了多种集群容错策略,如快速失败、失败重试、失败安全等,可以根据具体情况选择合适的策略,保障服务的稳定性。
关于集群容错,现在内置的几种方案,我们此处并不细说,主要是根据应用场景来进行选择。
配合着限流的,还应当有分流,而负载均衡就起到了分流的作用,我们在Dubbo中可以设置多种负载均衡模式:
我们可以进行全局配置,比如
<!-- 全局负载均衡策略 -->
<dubbo:consumer loadbalance="random" />
也可以进行服务接口级别的配置,比如
@Service(interfaceClass = XxxService.class, loadbalance = "leastactive")
public class XxxServiceImpl implements XxxService {
//...
}
其多种均衡策略,leastactive - “最少活跃调用数负载均衡”
是比较适合在高并发场景下选用的,,即当前活跃数(active,即指某个服务提供者正在处理请求的数量)最小的那个服务提供者,如果活跃数相同,则随机选择一个。比如,当前有3个服务提供者,其活跃数分别为:2、3、4,那么就会选择活跃数为2的服务提供者。当第一个服务提供者的活跃数增加到3时,那么最少活跃调用数的服务提供者就变成了第一个服务提供者
当某一块业务访问量大增,往往会伴随着资源占用的急剧增加,但是我们并不希望应用整个宕机,此时就要用到线程池隔离,线程池隔离是一种将请求任务与线程池分离的技术,我们在Dubbo里可以这么使用executes
来为指定服务建立定长的线程池
@Service
@DubboService(interfaceClass = XxxService.class, executes = 10)
public class XxxServiceImpl implements XxxService {
// 服务实现代码
}
这将为该服务创建一个固定大小为10的线程池,供服务消费者调用该服务时使用。这样当同时有11个请求到来时,第11个请求只能等到或被拒,事实上形成了限流,具有类似效果的参数还有 actives
我们其实在讲rabbitMQ的时候,就提到过异步的好处,其中之一就是可以削峰。同样的Dubbo也能使用 async
进行异步调用,来避免瞬时的大流量造成的服务故障。更具体的讲,这种场景下有三个好处:
- 减少响应时间:在高并发场景下,同步调用会阻塞线程,导致响应时间变长。而异步调用可以让线程立即返回,不用等待响应,从而缩短响应时间。
- 提高容错能力:在同步调用中,如果某个调用出现异常,那么整个调用链都会被打断,从而影响到其他调用的正常执行。而异步调用会把调用拆分成多个独立的任务,每个任务独立执行,如果其中某个任务出现异常,不会影响其他任务的执行,从而提高了容错能力。
- 提高吞吐量:在高并发场景下,同步调用可能会因为线程阻塞导致线程池资源耗尽,从而影响系统的吞吐量。异步调用可以将请求提交到异步线程池中执行,从而释放主线程,提高了系统的吞吐量。
而我们的设置也是可以分为全局设置,和服务接口级别。其中全局配置如下(不建议):
<dubbo:consumer async="true" />
<dubbo:provider async="true" />
单个服务配置如下
@DubboReference(async = true)
private DemoService demoService;
高并发是Dubbo应用需要面对的一个持续挑战。通过合理配置流量控制方案,包括限流策略、服务降级、超时控制和集群容错等操作,我们可以有效地保护系统免受高并发压力带来的影响。同时,需要注意不同业务场景可能需要不同的流量控制策略,因此我们需要根据实际情况进行调优和监控。
- 点赞
- 收藏
- 关注作者
评论(0)