dubbo——高可用性
一、zookeeper宕机
zookeeper注册中心宕机,还可以消费dubbo暴露的服务
健壮性:
- 监控中心宕掉不影响使用,只是丢失部分采样数据
- 数据库宕掉后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务
- 注册中心对等集群,任意一台宕掉后,将自动切换到另一台
- 注册中心全部宕掉后,服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者无状态,任意一台宕掉后,不影响使用
- 服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复
二、dubbo直连
在开发和测试环境中,通常需要绕过注册中心,只测试指定的服务提供者。在这种情况下,可能需要点对点直接连接,而服务提供者将忽略提供商注册提供程序的列表。接口A配置点对点,不影响B接口从注册表获取列表.
2.1 用xml配置
<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />
2.2 配置 -d
将-D参数映射服务地址添加到JVM启动参数:
java -Dcom.alibaba.xxx.XxxService=dubbo://localhost:20890
2.3 配置.properties档案(详情请参考官网)
三、集群下的dubbo负载均衡配置
dubo提供了许多用于集群负载平衡的平衡策略,这些策略默认为random
.
3.1 Random LoadBalance 随机负载均衡
- 乱七八糟,按权重设定随机概率。
- 在一个区段上发生碰撞的概率很高,但呼叫量越大,分布就越均匀。当使用基于概率的权重时,分布是一致的,这也有助于动态地调整提供者的权重。
3.2 RoundRobin LoadBalance 轮询负载均衡
- 圆木桶,使用重量的共同顾问确定循环知更率。
- 流向速度较慢的提供者的流量可能会导致请求堆积,例如,如果有一个提供者以非常慢的速度处理请求,但它仍然有效,这意味着它可以正常地接收请求。根据Roundrobin策略,用户将继续以预定的速度向该提供商发送请求,不知道供应商的不良状态。最后,我们将在这个不健康的提供者上得到许多请求。
3.3 LeastActive LoadBalance 最少活动负载均衡
- 最不活跃一种基于活动的随机机制,
actives
意味着消费者已发送但尚未返回的请求的数字。 - 较慢的提供者将收到较少的请求,因为较慢的提供程序有更高
actives
.
3.4 ConsistentHash LoadBalance 连续散列负载均衡
- 一致性 Hash,相同参数的请求总是发到同一提供者。
- 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
- 缺省只对第一个参数 Hash,如果要修改,请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
- 缺省用 160 份虚拟节点,如果要修改,请配置 <dubbo:parameter key="hash.nodes" value="320" />
3.5 配置
3.5.1 服务器服务级别
<dubbo:service interface="..." loadbalance="roundrobin" />
3.5.2 客户服务级别
<dubbo:reference interface="..." loadbalance="roundrobin" />
3.5.3 服务器方法级
<dubbo:service interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:service>
3.5.4 客户端方法级
<dubbo:reference interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:reference>
四、服务降级
4.1 什么是服务降级
当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。
可以通过服务降级临时屏蔽非关键服务,并为其定义返回策略
将动态配置规则发布到注册表:
RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension(); Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181")); registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
-
配置
mock=force:return+null
这意味着该服务的所有调用都将直接返回NULL值,而不进行远程调用。通常用于减少某些缓慢的非关键服务的影响。 -
此外,您还可以将该配置更改为
mock=fail:return+null
在调用失败后,您将获得空值。使用者将尝试进行远程调用,如果调用成功,将获得真实的结果;如果调用失败,则将获得空值。通常用于容忍某些非关键服务。
五、集群容错
在集群调用失败时,dubo提供了各种容错方案,默认的Failover Cluster(故障转移重试)。
5.1集群容错模式
1.Failover Cluster
失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
重试次数配置如下:
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference> <dubbo:method name="findFoo" retries="2" /> </dubbo:reference>
2.Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
3.Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
4.Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
5.Forking Cluster
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
6.Broadcast Cluster
广播调用所有提供者,逐个调用,任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。
5.2 集群模式配置
按照以下示例在服务提供方和消费方配置集群模式
<dubbo:service cluster="failsafe" />
或
<dubbo:reference cluster="failsafe" />