文章目录
- 1. ZooKeeper宕机
- 2. Dubbo直连
- 3. 负载均衡(防止单点故障)
- 3.1 负载均衡策略
- 3.2. 负载均衡策略配置
- 4. 服务容错(调用失败处理机制)
- 4.1 Failover Cluster(失败自动切换)
- 4.2 Failfast Cluster(快速失败)
- 4.3 Failsafe Cluster(失败安全)
- 4.4 Failback Cluster( 失败自动恢复)
- 4.5 Forking Cluster(并行调用多个服务器)
- 4.6 Broadcast Cluster
- 5. 服务降级(mock值,为其他重要服务让路)
- 5.1 代码中指定mock值
- 6. Dubbo整合Hystrix实现服务熔断
高可用:通过设计,减少系统不能提供服务的时间。
1. ZooKeeper宕机
现象:ZooKeeper注册中心宕机,还可以消费Dubbo暴露的服务。原因:
- 注册中心全部宕机后,服务提供者和服务消费者仍能通过本地缓存通信;
- 监控中心宕机不影响使用,只是丢失部分采样数据;
- 数据库宕机后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务;
- 注册中心对等集群,任意一台宕机后,将自动切换到另一台;
- 服务提供者无状态,任意一台宕机后,不影响使用;
- 服务提供者全部宕机后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复。
2. Dubbo直连
消费方不通过zookeeper注册中心去调用注册的服务,而是直接绕过zookeeper环节直接调用服务。
注解方式:
//通过url直接告诉调用者服务所在的地址
@Reference(url="127.0.0.1:20880")
IUserService userService;
xml配置方式:
<!-- 注意:dubbo直连不需要zookeeper做注册中心,但是还得配置否则报错 ,register="false"(只订阅,不注册) sbuscribe=false(只注册,不订阅) -->
<dubbo:registry address="zookeeper://192.168.22.128:2181" register="false" />
<!-- 用dubbo协议在20880端口暴露服务 -->
<dubbo:protocol name="dubbo" port="20882" />
<dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false" version="1.0.0" url="dubbo://127.0.0.1:20882"></dubbo:reference>
3. 负载均衡(防止单点故障)
在集群负载均衡时,Dubbo 提供了多种均衡策略,默认为 random
随机调用;
3.1 负载均衡策略
-
Random LoadBalance
:随机,按权重设置随机概率。 -
RoundRobin LoadBalance
:轮询,按公约后的权重设置轮询比率。 -
LeastActive LoadBalance
:最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大 -
ConsistentHash LoadBalance
:一致性哈希,相同参数的请求总是发到同一提供者。当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
- 缺省只对第一个参数 Hash,如果要修改,请配置 <dubbo:parameter key=“hash.arguments” value="0,1
- 缺省用 160 份虚拟节点,如果要修改,请配置 <dubbo:parameter key=“hash.nodes” value=“320” />
3.2. 负载均衡策略配置
(1)服务端服务级别
<dubbo:service interface="..." loadbalance="roundrobin" />
(2)客户端服务级别
<dubbo:reference interface="..." loadbalance="roundrobin" />
(3)服务端方法级别
<dubbo:service interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
(4)客户端方法级别
<dubbo:reference interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>
4. 服务容错(调用失败处理机制)
在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。
4.1 Failover Cluster(失败自动切换)
失败自动切换,当出现失败,重试其它服务器 [1]。通常用于读操作,但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。 重试次数配置如下:
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference>
<dubbo:method name="findFoo" retries="2" />
</dubbo:reference>
4.2 Failfast Cluster(快速失败)
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
4.3 Failsafe Cluster(失败安全)
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
4.4 Failback Cluster( 失败自动恢复)
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
4.5 Forking Cluster(并行调用多个服务器)
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
4.6 Broadcast Cluster
广播调用所有提供者,逐个调用,任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。
5. 服务降级(mock值,为其他重要服务让路)
当多个服务之间由于网络原因调不通或者服务请求过大,需要停止部分服务以保证核心服务正常运行时,可以使用Dubbo的的服务降级来解决。
服务降级:当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。
Dubbo提供了mock配置,可以很好的实现服务降级,mock主要有两种配置方式,一种是在代码中指定Mock值,另一种是在dubbo-admin管理界面中指定mock值。
5.1 代码中指定mock值
在远程调用异常时,服务端直接返回一个固定的字符串(也就是写死的字符串)
具体配置:在服务调用方配置mock参数:
<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="return 123456..." />
在远程调用异常时,服务端根据自定义mock业务处理类进行返回)
具体配置:
在服务调用方配置mock参数:
<dubbo:reference id=“xxxService” interface=“com.x…service.xxxxService” check=“false” mock=“true” />
说明:配置了mock参数之后,假设在调用服务的时候,远程服务没有启动,或者各种网络异常了,那远程服务会去寻找自定义的mock业务处理类进行业务处理。
因此还需配置一个自定义mock业务处理类
在接口服务xxxxService的目录下创建相应的mock业务处理类,同时实现业务接口xxxxService(),接口名要注意命名规范:接口名+Mock后缀,mock实现需要保证有无参的构造方法。
public class xxxxServiceMock implements xxxxService {
@Override
public String getXXXX(int id) {
return “this is exception 自定义…”;
}
}
配置完成后,此时如果调用失败会调用自定义的Mock业务实现。
注:除了以上两处之外,其它地方不用变。
说明:配置了mock参数之后,假设在调用服务的时候,远程服务没有启动,或者各种网络异常了,那远程服务会把这个mock配置的值返回,也就是会返回123456…
通过这种方式就可以避免了因为服务调用不了而出现异常错误而带来的程序不可用(起码是有值返回的,然后可以根据值进行业务逻辑处理判断等等)。
注:除了配置mock参数之外,其它地方不用变。
4.2 dubb-admin管理界面直接手动配置mock值
分别是屏蔽和容错:
屏蔽:force.mock (即:屏蔽请求,直接返回某个值,如上面的字符串,mock=“return 123456…”);
容错:fail.mock (即:允许请求,在请求失败的时候,再返回某个值,如:mock=“fail:return 123456…”);
6. Dubbo整合Hystrix实现服务熔断
微服务架构中,服务与服务之间通过RPC调用,为了保证高可用,如果单个服务不可用,调用这个服务就不可用,如果此时继续调用此服务将导致。
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.2.8.RELEASE</version>
</dependency>
在Application中增加@EnableHystrix
注解,开启Hystrix功。在Service中增加@HystrixCommand
注解,此时调用会经过Hystrix代理。
触发熔断:异常/服务中断。