dubbo学习

1.Dubbo集群容错

 

当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试

 

Failover Cluster:

· 失败自动切换，当出现失败，重试其它服务器。(缺省)

· 通常用于读操作，但重试会带来更长延迟。

· 可通过retries="2"来设置重试次数(不含第一次)。

例如：

某个服务部署在A,B两台服务器，当Consumer通过zookeeper访问这个服务时，如果没有设置集群模式，缺省会随机选一台服务器，比如A，如果此时A当机或者由于A性能原因，导致业务处理时间超过了服务设置Timeout时间，dubbo则会自动切换到B服务器

配置：

<dubbo:service interface="com.provider.DemoService" ref="demoService" cluster="failover"/>

 

可通过retries="2"来设置重试次数(不含第一次)

<dubbo:service interface="com.provider.DemoService" ref="demoService" retries="2" cluster="failover"/>

 

注）消费端需要捕获服务端抛出的异常

 

Failfast Cluster：

· 快速失败，只发起一次调用，失败立即报错。

· 通常用于非幂等性的写操作，比如新增记录。

注）消费端需要捕获服务端抛出的异常

 

例如：有A,B两台服务器，当消费调用A而且A当机，则直接返回异常而不会轮询到B服务器访问

配置：

<dubbo:service interface="com.provider.DemoService" ref="demoService" cluster="failfast"/>

 

 

Failsafe Cluster

· 失败安全，出现异常时，直接忽略。

· 通常用于写入审计日志等操作。

注）消费端不需要捕获服务端抛出的异常

配置：

<dubbo:service interface="com.provider.DemoService" ref="demoService" cluster="failsafe"/>

 

Failback Cluster

· 失败自动恢复，后台记录失败请求，定时重发。

· 通常用于消息通知操作。

 

当A服务器访问失败后，服务器会定时自动再发一次请求

注）消费端不需要捕获服务端抛出的异常

配置：

<dubbo:service interface="com.provider.DemoService" ref="demoService" cluster="failback"/>

 

Broadcast Cluster

· 广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)

· 通常用于通知所有提供者更新缓存或日志等本地资源信息。

注）消费端需要捕获服务端抛出的异常

 

例如，有A,B,C三台服务器，当消费者调用服务时，A,B,C三台服务器依次被调用

配置：

<dubbo:service interface="com.provider.DemoService" ref="demoService" cluster="broadcast"/>

 

 

 

2.Dubbo负载均衡

Random LoadBalance(默认配置)

· 随机，按权重设置随机概率。

· 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

 

配置如下：

 

<dubbo:service interface="..." loadbalance="random"/>

 

RoundRobin LoadBalance

· 轮循，按公约后的权重设置轮循比率。

· 存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

 

配置如下：

 

<dubbo:service interface="..." loadbalance="roundrobin" />

 

 

<dubbo:service>

weight

weight

int

可选

 

性能调优

服务权重

 

 

3.Dubbo推荐用法

因为服务端和消费端都可以配置一些属性，如：timeout, loadbalance,cluster等，建议配置放到服务端：

原因如下：

1. 作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

2. 在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。
否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。
PS: 配置的覆盖规则：1)方法级配置别优于接口级别，即小Scope优先2) Consumer端配置 优于Provider配置 优于 全局配置，最后是Dubbo Hard Code的配置值（见配置文档）
配置的覆盖规则详见： Dubbo配置参考手册

在Provider可以配置的Consumer端属性有：

1. timeout，方法调用超时

2. retries，失败重试次数，缺省是2（表示加上第一次调用，会调用3次）

3. loadbalance，负载均衡算法（有多个Provider时，如何挑选Provider调用），缺省是随机（random）。
还可以有轮训(roundrobin)、最不活跃优先（leastactive，指从Consumer端并发调用最好的Provider，可以减少的反应慢的Provider的调用，因为反应更容易累积并发的调用）

4. actives，消费者端，最大并发调用限制，即当Consumer对一个服务的并发调用到上限后，新调用会Wait直到超时。
在方法上配置（dubbo:method ）则并发限制针对方法，在接口上配置（dubbo:service），则并发限制针对服务。

 

4.Dubbo后台管理和监控

服务端配置：<dubbo:monitor> 监控中心协议，如果为protocol="registry"，表示从注册中心发现监控中心地址，否则直连监控中心