dubbo——高可用性

一、zookeeper宕机

　　zookeeper注册中心宕机，还可以消费dubbo暴露的服务

　　健壮性：

1. 监控中心宕掉不影响使用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

二、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" />