Dubbo服务高可用机制
Dubbo 容错机制
容错机制值得是服务容忍错误的能力,当系统出现网络延迟、网络中断、服务异常等原因,造成当前服务暂时不可用,Dubbo
提供了容错机制来优雅地帮助服务调用者处理这类错误。
Dubbo默认提供了6种容错模式
- Failover Cluster(默认):失败自动切换。当服务调用失败后,会切换到集群中的其他机器进行重试,默认重试次数为2,通过属性
retries=2
可以修改次数,但是重试次数增加会带来更长的响应延迟。(这种容错模式通常用于读操作) - Failfast Cluster:快速失败。当服务调用失败后,立即报错,也就是指发起一次调用。(这种模式通常用于写操作,这种模式可以防止网络等问题导致数据重复新增,它等同于
Failover Cluster retries=0
) - Failsafe Cluster:失败安全,出现异常时,直接忽略异常。(这种模式处理的数据相对而言不太重要)
- Failback Cluster:失败后自动回复。服务调用出现异常时,在后台记录这条失败的请求定时重发。(这种模式适合用于消息通知操作,保证这个请求一定发送成功,可以解决短期网络拥塞导致请求的丢失)
- Forking Cluster:并行调用集群中的多个服务,只要其中一个成功就返回。可以通过
forks=2
来设置最大并行数。(这种模式要保证请求的幂等性) - Broadcast Cluster:广播调用所有的服务提供者,任意一个服务报错则表示服务调用失败。(这种模式需要所有节点都是正常的才能被调用)
服务调用者容错机制的配置方式
容错机制既可以在服务调用者中配置或在服务提供者中配置
- 在服务调用者中配置只对该调用者起作用(其他调用节点采用默认的)
- 在服务服务者中配置对所有调用者起作用
- 调用者的配置优先级高于服务者
方式一:使用@Service注解
@Service(cluster = "failfast")
public class DubboComsumerService {
}
方式二:xml 标签
//服务端
<dubbo:service cluster="failfast">
//客户端
<dubbo:reference cluster="failfast">
容错机制的控制粒度是class
级别的,而最常用的两个模式为Failover Cluster
和Failfast Cluster
,而Failfast Cluster
可以被Failover Cluster + retries=0
取代,所以我们在真实使用场景可以这样设置
<dubbo:reference interface="com.luo.api.service.IUserService">
<dubbo:method name="findXxx" timeout="3000" retries="2" />
<dubbo:method name="addXxx" timeout="3000" retries="0" />
</dubbo:reference>
Dubbo 负载均衡机制
在Dubbo
提供了4种负载均衡策略,分别是:
Random LoadBalance
随机算法(默认):可以针对性能较好的服务器设置较大的权重值,权重值越大,随机的概率越大。RoundRobin LoadBalance
轮询:安装公约后的权重设置轮询比例。LeastActive LoadBalance
最少活跃调用数:处理较慢的节点将会收到更少的请求。ConsistentHash LoadBalance
一致性Hash
:相同参数的请求总是发送到同一个服务提供者。
Dubbo负载均衡地配置方式
方式一:使用@Service注解
@Service(cluster = "failfast",loadbalance = "random")
public class DubboComsumerService {
}
方式二:xml标签
-
负载均衡配置可以是类级别也可以方法级别
-
优先级:客户端方法级别配置 > 客户端类级别配置 > 服务端方法级别配置 >服务器类级别配置
//服务端
<dubbo:service interface="…">
<dubbo:method name="…" loadbalance=“roundrobin”/>
</dubbo:service>//客户端
<dubbo:reference interface="…">
<dubbo:method name="…" loadbalance=“roundrobin”/>
</dubbo:reference>
Dubbo服务降级机制
服务降级是一种系统保护策略,当服务器访问压力较大时,可以根据当前业务情况对不重要的服务降级,以保证核心服务的正常进行。
服务降级可以分为两类:
- 人工降级:具有一定的前置性,比如在电商大促之前,关闭某些非核心服务,比如评价等
- 自动降级:当系统出现某些异常时自动触发“补偿性响应”
Dubbo 提供了Mock
配置来实现服务降级,它会在一下情况触发:
Dubbo
服务者不提供服务Dubbo
服务超时
Dubbo 服务降级配置方式
创建IMockHelloService
接口(要与正常业务的service
实现同样的接口,正常Method
与降级Method
一一对应)
public class MockUserService implements IUserService {
@Override
public String ceshi(String input) {
return "服务暂时不可用,请重试";
}
}
在服务提供端中绑定mock
接口
<!-- dubbo管理平台接口 -->
<bean id="UserService" class="com.luo.producer.rpcservice.UserServiceImpl" />
<dubbo:service interface="com.luo.api.service.IUserService" ref="UserService" mock="com.luo.api.service.mockimpl.MockUserService" />
在服务消费端配置mock
级别
-
dubbo
服务调用者check=“false”
能保证服务提供者不存在的情况,依旧可以正常启动项目,否则会报错<dubbo:reference id=“user” interface=“com.luo.api.service.IUserService” retries=“0” timeout=“50000” check=“false” mock=“true” />
服务降级mock
的级别:
false
,不调用mock
服务true
,当服务调用失败时,使用mock
服务。default
,当服务调用失败时,使用mock
服务。force
,强制使用mock
服务(不管服务能否调用成功)。
开启服务调用者,关闭服务提供者,验证: