dubbo学习
1.Dubbo 集群容错
当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试
Failover Cluster:
· 失败自动切换，当出现失败，重试其它服务器。(缺省)
· 通常用于读操作，但重试会带来更长延迟。
· 可通过retries="2"来设置重试次数(不含第一次)。
例如：
某个服务部署在A,B两台服务器，当Consumer通过zookeeper访问这个服务时，如果没有设置集群模式，缺省会随机选一台服务器，比如A，如果此时A当机或者由于A性能原因，导致业务处理时间超过了服务设置Timeout时间，dubbo则会自动切换到B服务器
配置：
可通过retries="2"来设置重试次数(不含第一次)
注）消费端需要捕获服务端抛出的异常
Failfast Cluster：
· 快速失败，只发起一次调用，失败立即报错。
· 通常用于非幂等性的写操作，比如新增记录。
注）消费端需要捕获服务端抛出的异常
例如：有A,B两台服务器，当消费调用A而且A当机，则直接返回异常而不会轮询到B服务器访问
配置：
Failsafe Cluster
· 失败安全，出现异常时，直接忽略。
· 通常用于写入审计日志等操作。
注）消费端不需要捕获服务端抛出的异常
配置：
Failback Cluster
· 失败自动恢复，后台记录失败请求，定时重发。
· 通常用于消息通知操作。
当A服务器访问失败后，服务器会定时自动再发一次请求
注）消费端不需要捕获服务端抛出的异常
配置：
Broadcast Cluster
· 广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
· 通常用于通知所有提供者更新缓存或日志等本地资源信息。
注）消费端需要捕获服务端抛出的异常
例如，有A,B,C三台服务器，当消费者调用服务时，A,B,C三台服务器依次被调用
配置：
2.Dubbo 负载均衡
Random LoadBalance(默认配置)
· 随机，按权重设置随机概率。
· 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
配置如下：
| <dubbo:service interface="..." loadbalance="random"/> |
RoundRobin LoadBalance
· 轮循，按公约后的权重设置轮循比率。
· 存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
配置如下：
|
| |
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 后台管理和监控
服务端配置：