dubbo开发者指南：http://dubbo.io/Developer+Guide-zh.htm

dubbo用户指南：http://dubbo.io/User+Guide-zh.htm

转自：http://121.42.47.99/yuenshome/wordpress/?p=3424#ltdubbo:referencegt

给出几个不错的推荐阅读，以及复制了下Dubbo官方文档的部分内容（背景、需求、架构、推荐用法），作为入门介绍，最后给出一些推荐阅读，建议可以读下推荐阅读部分的例子，写得很好、通俗易懂。

1. 背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

• 单一应用架构
  • 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
  • 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
• 垂直应用架构
  • 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
  • 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
• 分布式服务架构
  • 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
  • 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
• 流动计算架构
  • 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
  • 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

2. 需求

在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。

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

此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

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

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

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

为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。

其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

以上是Dubbo最基本的几个需求，更多服务治理问题参见：

http://code.alibabatech.com/blog/experience_1402/service-governance-process.html

3. 架构

节点角色说明：

• Provider: 暴露服务的服务提供方。
• Consumer: 调用远程服务的服务消费方。
• Registry: 服务注册与发现的注册中心。
• Monitor: 统计服务的调用次调和调用时间的监控中心。
• Container: 服务运行容器。

调用关系说明：

• 0. 服务容器负责启动，加载，运行服务提供者。
• 1. 服务提供者在启动时，向注册中心注册自己提供的服务。
• 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

(1) 连通性：

• 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
• 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
• 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
• 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
• 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
• 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

(2) 健状性：

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

(3) 伸缩性：

• 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
• 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

(4) 升级性：

• 当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力：

4. 配置参考手册

这里以Xml配置为准，列举所有配置项，其它配置方式，请参见相应转换关系：属性配置，注解配置，API配置

注意：只有group，interface，version是服务的匹配条件，三者决定是不是同一个服务，其它配置项均为调优和治理参数。

所有配置项分为三大类，参见下表中的”作用”一列。

• 服务发现：表示该配置项用于服务的注册与发现，目的是让消费方找到提供方。
• 服务治理：表示该配置项用于治理服务间的关系，或为开发测试提供便利条件。
• 性能调优：表示该配置项用于调优性能，不同的选项对性能会产生影响。

所有配置最终都将转换为URL表示，并由服务提供方生成，经注册中心传递给消费方，各属性对应URL的参数，参见配置项一览表中的”对应URL参数”列。
URL格式：

Schema: http://code.alibabatech.com/schema/dubbo/dubbo.xsd

4.1 <dubbo:service/>

(+) (#)

服务提供者暴露服务配置：
配置类：com.alibaba.dubbo.config.ServiceConfig

4.2 <dubbo:reference/>

服务消费者引用服务配置：
配置类：com.alibaba.dubbo.config.ReferenceConfig

4.3 <dubbo:protocol/>

服务提供者协议配置：
配置类：com.alibaba.dubbo.config.ProtocolConfig
说明：如果需要支持多协议，可以声明多个<dubbo:protocol>标签，并在<dubbo:service>中通过protocol属性指定使用的协议。

4.4 <dubbo:registry/>

注册中心配置：
配置类：com.alibaba.dubbo.config.RegistryConfig
说明：如果有多个不同的注册中心，可以声明多个<dubbo:registry>标签，并在<dubbo:service>或<dubbo:reference>的registry属性指定使用的注册中心。

4.5 <dubbo:monitor/>

监控中心配置：
配置类：com.alibaba.dubbo.config.MonitorConfig

4.6 <dubbo:application/>

应用信息配置：
配置类：com.alibaba.dubbo.config.ApplicationConfig

4.7 <dubbo:module/>

模块信息配置：
配置类：com.alibaba.dubbo.config.ModuleConfig

4.8 <dubbo:provider/>

服务提供者缺省值配置：
配置类：com.alibaba.dubbo.config.ProviderConfig
说明：该标签为<dubbo:service>和<dubbo:protocol>标签的缺省值设置。

4.9 <dubbo:consumer/>

服务消费者缺省值配置：
配置类：com.alibaba.dubbo.config.ConsumerConfig
说明：该标签为<dubbo:reference>标签的缺省值设置。

4.10 <dubbo:method/>

方法级配置：
配置类：com.alibaba.dubbo.config.MethodConfig
说明：该标签为<dubbo:service>或<dubbo:reference>的子标签，用于控制到方法级，

比如：

4.11 <dubbo:argument/>

方法参数配置：
配置类：com.alibaba.dubbo.config.ArgumentConfig
说明：该标签为<dubbo:method>的子标签，用于方法参数的特征描述，比如：

4.12 <dubbo:parameter/>

选项参数配置：
配置类：java.util.Map
说明：该标签为<dubbo:protocol>或<dubbo:service>或<dubbo:provider>或<dubbo:reference>或<dubbo:consumer>的子标签，用于配置自定义参数，该配置项将作为扩展点设置自定义参数使用。

比如：

也可以：

详细参见：自定义参数

5. 推荐用法

5.1 在Provider上尽量多配置Consumer端属性

原因如下：

1. 作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
2. 在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。
   否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。
   PS: 配置的覆盖规则：1) 方法级配置别优于接口级别，即小Scope优先 2) Consumer端配置 优于 Provider配置 优于 全局配置，最后是Dubbo Hard Code的配置值（见配置文档）
   配置的覆盖规则详见： Dubbo配置参考手册

Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题。

示例：

在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），则并发限制针对服务。

详细配置说明参见：Dubbo配置参考手册

5.2 Provider上配置合理的Provider端属性

Provider上可以配置的Provider端属性有：

1. threads，服务线程池大小
2. executes，一个服务提供者并行执行请求上限，即当Provider对一个服务的并发调用到上限后，新调用会Wait（Consumer可能到超时）。在方法上配置（dubbo:method ）则并发限制针对方法，在接口上配置（dubbo:service），则并发限制针对服务。

5.3 配置上管理信息

目前有负责人信息和组织信息（用于区分站点）。

有问题时便于的找到服务的负责人，至少写两个人以便备份。

负责人和组织的信息可以在注册中心的上看到。

示例：

dubbo:service、dubbo:reference没有配置负责人，则使用dubbo:application设置的负责人。

5.4 配置上Dubbo缓存文件

配置方法如下：

注意：

1. 文件的路径，应用可以根据需要调整，保证这个文件不会在发布过程中被清除。
2. 如果有多个应用进程注意不要使用同一个文件，避免内容被覆盖。

这个文件会缓存：

1. 注册中心的列表
2. 服务提供者列表

有了这项配置后，当应用重启过程中，Dubbo注册中心不可用时则应用会从这个缓存文件读取服务提供者列表的信息，进一步保证应用可靠性。

5.5 监控配置

1. 使用固定端口暴露服务，而不要使用随机端口

这样在注册中心推送有延迟的情况下，消费者通过缓存列表也能调用到原地址，保证调用成功。

3. 使用Dragoon的http监控项监控注册中心上服务提供方

Dragoon监控服务在注册中心上的状态：http://dubbo-reg1.hst.xyi.cn.alidc.net:8080/status/com.alibaba.morgan.member.MemberService:1.0.5，确保注册中心上有该服务的存在。

4. 服务提供方，使用Dragoon的telnet或shell监控项

监控服务提供者端口状态：echo status | nc –i 1 20880 | grep OK | wc –l，其中的20880为服务端口

5. 服务消费方，通过将服务强制转型为EchoService，并调用$echo()测试该服务的提供者是可用

如 assertEqauls(“OK”, ((EchoService)memberService).$echo(“OK”));

5.6 不要使用dubbo.properties文件配置，推荐使用对应XML配置

Dubbo2中所有的配置项都可以Spring配置中，并且可以针对单个服务配置。

# 如完全不配置使用Dubbo缺省值，参见Dubbo配置参考手册中的说明。

在Dubbo1中需要在dubbo.properties文件中的配置项，Dubbo2中配置示例如下：

1. 应用名

对应dubbo.properties中的Key名dubbo.application.name

2. 注册中心地址

对应dubbo.properties中的Key名dubbo.registry.address

3. 调用超时

可以在多个配置项设置超时，由上至下覆盖（即上面的优先），示例如下：

# 其它的参数（retries、loadbalance、actives等）的覆盖策略也一样。

提供者端特定方法的配置

提供者端特定接口的配置

# timeout可以在多处设置，配置项及覆盖规则详见： Dubbo配置参考手册

全局配置项值，对应dubbo.properties中的Key名dubbo.service.invoke.timeout

5. 服务提供者协议、服务的监听端口

对应dubbo.properties中的Key名dubbo.service.protocol、dubbo.service.server.port

4. 服务线程池大小

对应dubbo.properties中的Key名dubbo.service.max.thread.threads.size

6. 消费者启动时，没有提供者是否抛异常Fast-Fail

对应dubbo.properties中的Key名alibaba.intl.commons.dubbo.service.allow.no.provider

6. 推荐阅读列表

看了这篇，简单了解了下：

• 阿里巴巴分布式服务框架 Dubbo 团队成员梁飞专访 – 名家访谈 – ITeye精华 http://www.iteye.com/magazines/103?page=2#comments
• 最近项目用到Dubbo框架，临时抱佛脚分享一下共探讨。 – 一十一. – 博客园 http://www.cnblogs.com/Javame/p/3632473.html

继而看文档：

• User Guide-zh – Dubbo – Alibaba Open Sesame
  http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF