（一）Dubbo基础

本文参考Dubbo官方文档：http://dubbo.apache.org/#!/docs/user/quick-start.md?lang=zh-cn

1.Doobule的由来

当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。 

此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 

这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 

为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

2.架构图：

节点角色说明

 

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

3.应用

 用 Spring 配置声明暴露服务

 provider.xml：

 

通过 Spring 配置引用远程服务

consumer.xml：

4.Dubbo常用的策略：

4.1启动时检查：

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。

可以通过 check="false" 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check="false"，总是会返回引用，当服务恢复时，能自动连上。

示例

通过 spring 配置文件

关闭某个服务的启动时检查 (没有提供者时报错)：

关闭所有服务的启动时检查 (没有提供者时报错)：

关闭注册中心启动时检查 (注册订阅失败时报错)：

4.2.集群容错：

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试

Dubbo提供了6种容错机制，分别如下

1.     failsafe 失败安全，可以认为是把错误吞掉（记录日志）

2.     failover(默认)   重试其他服务器； retries（2）

3.     failfast 快速失败， 失败以后立马报错

4.     failback  失败后自动恢复。

5.     forking  forks. 设置并行数

6.     broadcast  广播，任意一台报错，则执行的方法报错

配置方式如下，通过cluster方式，配置指定的容错方案

或

4.3负载均衡策略

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。

Random LoadBalance

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

RoundRobin LoadBalance

• 轮循，按公约后的权重设置轮循比率。
• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
• 缺省只对第一个参数 Hash，如果要修改，请配置 
• 缺省用 160 份虚拟节点，如果要修改，请配置 

服务端服务级别

客户端服务级别

服务端方法级别

客户端方法级别

4.4多协议

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

不同服务不同协议

不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议

4.5配置优先级别

 以timeout为例，显示了配置的查找顺序，其它retries, loadbalance等类似。

1.    方法级优先，接口级次之，全局配置再次之。

2.    如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过URL经由注册中心传递给消费方。

建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。