用户指南

入门

(+) (#)

背景

(#)

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

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

需求

(#)

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

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

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

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

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

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

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

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

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

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

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

架构

(#)

节点角色说明：

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

调用关系说明：

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

(1) 连通性：

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

(2) 健状性：

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

(3) 伸缩性：

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

(4) 升级性：

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

• Deployer: 自动部署服务的本地代理。
• Repository: 仓库用于存储服务应用发布包。
• Scheduler: 调度中心基于访问压力自动增减服务提供者。
• Admin: 统一管理控制台。

用法

(#)

本地服务：(Spring配置)

远程服务：(Spring配置)

在本地服务的基础上，只需做简单配置，即可完成远程化：

• 将上面的local.xml配置拆分成两份，将服务定义部分放在服务提供方remote-provider.xml，将服务引用部分放在服务消费方remote-consumer.xml。
• 并在提供方增加暴露服务配置<dubbo:service>，在消费方增加引用服务配置<dubbo:reference>。

如下：

快速启动

(+) (#)

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

如果不想使用Spring配置，而希望通过API的方式进行调用（不推荐），请参见：API配置 (+)

服务提供者

(#)

完整安装步骤，请参见：示例提供者安装 (+)

定义服务接口: (该接口需单独打包，在服务提供方和消费方共享)

在服务提供方实现接口：(对服务消费方隐藏实现)

用Spring配置声明暴露服务：

加载Spring配置：

服务消费者

(#)

完整安装步骤，请参见：示例消费者安装 (+)

通过Spring配置引用远程服务：

加载Spring配置，并调用远程服务：(也可以使用IoC注入)

依赖

(+) (#)

必需依赖

• JDK1.5+

理论上Dubbo可以只依赖JDK，不依赖于任何三方库运行，只需配置使用JDK相关实现策略。

缺省依赖

通过mvn dependency:tree > dep.log命令分析，Dubbo缺省依赖以下三方库：

这里所有依赖都是换照Dubbo缺省配置选的，这些缺省值是基于稳定性和性能考虑的。

• log4j.jar和commons-logging.jar日志输出包。
  • 可以直接去掉，dubbo本身的日志会自动切换为JDK的java.util.logging输出。
  • 但如果其它三方库比如spring.jar间接依赖commons-logging，则不能去掉。
• javassist.jar 字节码生成。
  • 如果<dubbo:provider proxy="jdk" />或<dubbo:consumer proxy="jdk" />，以及<dubbo:application compiler="jdk" />，则不需要。
• spring.jar 配置解析。
  • 如果用ServiceConfig和ReferenceConfig的API调用，则不需要。
• netty.jar 网络传输。
  • 如果<dubbo:protocol server="mina"/>或<dubbo:protocol server="grizzly"/>，则换成mina.jar或grizzly.jar。
  • 如果<protocol name="rmi"/>，则不需要。

可选依赖

以下依赖，在主动配置使用相应实现策略时用到，需自行加入依赖。

• mina: 1.1.7
• grizzly: 2.1.4
• httpclient: 4.1.2
• hessian_lite: 3.2.1-fixed
• xstream: 1.4.1
• fastjson: 1.1.8
• zookeeper: 3.3.3
• jedis: 2.0.0
• xmemcached: 1.3.6
• jfreechart: 1.0.13
• hessian: 4.0.7
• jetty: 6.1.26
• hibernate-validator: 4.2.0.Final
• zkclient: 0.1
• curator: 1.1.10
• cxf: 2.6.1
• thrift: 0.8.0

JEE:

• servlet: 2.5
• bsf: 3.1
• validation-api: 1.0.0.GA
• jcache: 0.4

成熟度

(+) (#)

功能成熟度

(#)

策略成熟度

(#)

配置

(+) (#)

Xml配置

(+) (#)

配置项说明 详细配置项，请参见：配置参考手册 (+)

API使用说明 如果不想使用Spring配置，而希望通过API的方式进行调用，请参见：API配置 (+)

配置使用说明 想知道如何使用配置，请参见：快速启动 (+)

示例：

所有标签者支持自定义参数，用于不同扩展点实现的特殊配置。

如：

或：(2.1.0开始支持)

注意声明：xmlns:p="http://www.springframework.org/schema/p"

Configuration Relation:

• <dubbo:service/> 服务配置，用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心。
• <dubbo:reference/> 引用配置，用于创建一个远程服务代理，一个引用可以指向多个注册中心。
• <dubbo:protocol/> 协议配置，用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受。
• <dubbo:application/> 应用配置，用于配置当前应用信息，不管该应用是提供者还是消费者。
• <dubbo:module/> 模块配置，用于配置当前模块信息，可选。
• <dubbo:registry/> 注册中心配置，用于配置连接注册中心相关信息。
• <dubbo:monitor/> 监控中心配置，用于配置连接监控中心相关信息，可选。
• <dubbo:provider/> 提供方的缺省值，当ProtocolConfig和ServiceConfig某属性没有配置时，采用此缺省值，可选。
• <dubbo:consumer/> 消费方缺省配置，当ReferenceConfig某属性没有配置时，采用此缺省值，可选。
• <dubbo:method/> 方法配置，用于ServiceConfig和ReferenceConfig指定方法级的配置信息。
• <dubbo:argument/> 用于指定方法参数配置。

Configuration Override:

• 上图中以timeout为例，显示了配置的查找顺序，其它retries, loadbalance, actives等类似。
  • 方法级优先，接口级次之，全局配置再次之。
  • 如果级别一样，则消费方优先，提供方次之。
• 其中，服务提供方配置，通过URL经由注册中心传递给消费方。
• 建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。
• 理论上ReferenceConfig的非服务标识配置，在ConsumerConfig，ServiceConfig, ProviderConfig均可以缺省配置。

属性配置

(+) (#)

如果公共配置很简单，没有多注册中心，多协议等情况，或者想多个Spring容器想共享配置，可以使用dubbo.properties作为缺省配置。

Dubbo将自动加载classpath根目录下的dubbo.properties，可以通过JVM启动参数：-Ddubbo.properties.file=xxx.properties 改变缺省配置位置。

如果classpath根目录下存在多个dubbo.properties，比如多个jar包中有dubbo.properties，Dubbo会任意加载，并打印Error日志，后续可能改为抛异常。

映射规则：

• 将XML配置的标签名，加属性名，用点分隔，多个属性拆成多行：
  • 比如：dubbo.application.name=foo等价于<dubbo:application name="foo" />
  • 比如：dubbo.registry.address=10.20.153.10:9090等价于<dubbo:registry address="10.20.153.10:9090" />
• 如果XML有多行同名标签配置，可用id号区分，如果没有id号将对所有同名标签生效：
  • 比如：dubbo.protocol.rmi.port=1234等价于<dubbo:protocol id="rmi" name="rmi" port="1099" /> (协议的id没配时，缺省使用协议名作为id)
  • 比如：dubbo.registry.china.address=10.20.153.10:9090等价于<dubbo:registry id="china" address="10.20.153.10:9090" />

典型配置如：

覆盖策略：

• JVM启动-D参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。
• XML次之，如果在XML中有配置，则dubbo.properties中的相应配置项无效。
• Properties最后，相当于缺省值，只有XML没有配置时，dubbo.properties的相应配置项才会生效，通常用于共享公共配置，比如应用名。

注解配置

(+) (#)

2.2.1以上版本支持

服务提供方注解：

服务提供方配置：

服务消费方注解：

服务消费方配置：

也可以使用：(等价于前面的：<dubbo:annotation package="com.foo.bar.service" />)

Spring2.5及以后版本支持component-scan，如果用的是Spring2.0及以前版本，需配置： <!-- Spring2.0支持@Service注解配置，但不支持package属性自动加载bean的实例，需人工定义bean的实例。--> <dubbo:annotation /> <bean id="barService" class="com.foo.BarServiceImpl" />

API配置

(+) (#)

API使用范围 API仅用于OpenAPI, ESB, Test, Mock等系统集成，普通服务提供方或消费方，请采用配置方式使用Dubbo，请参见：Xml配置 (+)

API属性含义参考 API属性与配置项一对一，各属性含义，请参见：配置参考手册 (+)， 比如：ApplicationConfig.setName("xxx") 对应 <dubbo:application name="xxx" />

(1) 服务提供者：

(2) 服务消费者：

(3) 特殊场景

注：下面只列出不同的地方，其它参见上面的写法

(3.1) 方法级设置：

(3.2) 点对点直连：

示例

(+) (#)

想完整的运行起来，请参见：快速启动 (+)，这里只列出各种场景的配置方式

以下示例全部使用基于Spring的Xml配置 (+)作为参考，如果不想使用Spring，而希望通过API的方式进行调用，请参见：API配置 (+)

启动时检查

(+) (#)

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

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

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

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

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

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

也可以用dubbo.properties配置：

也可以用-D参数：

注意区别 dubbo.reference.check=false，强制改变所有reference的check值，就算配置中有声明，也会被覆盖。 dubbo.consumer.check=false，是设置check的缺省值，如果配置中有显式的声明，如：<dubbo:reference check="true"/>，不会受影响。 dubbo.registry.check=false，前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。

引用缺省是延迟初始化的，只有引用被注入到其它Bean，或被getBean()获取，才会初始化。
如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：

集群容错

(+) (#)

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

各节点关系：

• 这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。
• Directory代表多个Invoker，可以把它看成List<Invoker>，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。
• Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。
• Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。
• LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。

集群容错模式：

可以自行扩展集群容错策略，参见：集群扩展

Failover Cluster

• 失败自动切换，当出现失败，重试其它服务器。(缺省)
• 通常用于读操作，但重试会带来更长延迟。
• 可通过retries="2"来设置重试次数(不含第一次)。

Failfast Cluster

• 快速失败，只发起一次调用，失败立即报错。
• 通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

• 失败安全，出现异常时，直接忽略。
• 通常用于写入审计日志等操作。

Failback Cluster

• 失败自动恢复，后台记录失败请求，定时重发。
• 通常用于消息通知操作。

Forking Cluster

• 并行调用多个服务器，只要一个成功即返回。
• 通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
• 可通过forks="2"来设置最大并行数。

Broadcast Cluster

• 广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
• 通常用于通知所有提供者更新缓存或日志等本地资源信息。

重试次数配置如：(failover集群模式生效)

或：

或：

集群模式配置如：

或：

负载均衡

(+) (#)

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

可以自行扩展负载均衡策略，参见：负载均衡扩展

Random LoadBalance

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

RoundRobin LoadBalance

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

LeastActive LoadBalance

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

ConsistentHash LoadBalance

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

配置如：

或：

或：

或：

线程模型

(+) (#)

事件处理线程说明 如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记个标识，则直接在IO线程上处理更快，因为减少了线程池调度。 但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。 如果用IO线程处理事件，又在事件处理过程中发起新的IO请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

• Dispatcher
  • all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
  • direct 所有消息都不派发到线程池，全部在IO线程上直接执行。
  • message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在IO线程上执行。
  • execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在IO线程上执行。
  • connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

• ThreadPool
  • fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
  • cached 缓存线程池，空闲一分钟自动删除，需要时重建。
  • limited 可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。

配置如：

直连提供者

(+) (#)

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，
点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，
A接口配置点对点，不影响B接口从注册中心获取列表。

(1) 如果是线上需求需要点对点，可在<dubbo:reference>中配置url指向提供者，将绕过注册中心，多个地址用分号隔开，配置如下：(1.0.6及以上版本支持)

(2) 在JVM启动参数中加入-D参数映射服务地址，如：
(key为服务名，value为服务提供者url，此配置优先级最高，1.0.15及以上版本支持)

注意 为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。

(3) 如果服务比较多，也可以用文件映射，如：
(用-Ddubbo.resolve.file指定映射文件路径，此配置优先级高于<dubbo:reference>中的配置，1.0.15及以上版本支持)
(2.0以上版本自动加载${user.home}/dubbo-resolve.properties文件，不需要配置)

然后在映射文件xxx.properties中加入：
(key为服务名，value为服务提供者url)

注意 为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。

只订阅

(+) (#)

问题 为方便开发测试，经常会在线下共用一个所有服务可用的注册中心，这时，如果一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。

解决方案 可以让服务提供者开发方，只订阅服务(开发的服务可能依赖其它服务)，而不注册正在开发的服务，通过直连测试正在开发的服务。

禁用注册配置：

或者：

只注册

(+) (#)

问题 如果有两个镜像环境，两个注册中心，有一个服务只在其中一个注册中心有部署，另一个注册中心还没来得及部署，而两个注册中心的其它应用都需要依赖此服务，所以需要将服务同时注册到两个注册中心，但却不能让此服务同时依赖两个注册中心的其它服务。

解决方案 可以让服务提供者方，只注册服务到另一注册中心，而不从另一注册中心订阅服务。

禁用订阅配置：

或者：

静态服务

(+) (#)

有时候希望人工管理服务提供者的上线和下线，此时需将注册中心标识为非动态管理模式。

或者：

服务提供者初次注册时为禁用状态，需人工启用，断线时，将不会被自动删除，需人工禁用。

如果是一个第三方独立提供者，比如memcached等，可以直接向注册中心写入提供者地址信息，消费者正常使用：
(通常由脚本监控中心页面等调用)

多协议

(+) (#)

可以自行扩展协议，参见：协议扩展

(1) 不同服务不同协议

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

(2) 多协议暴露服务

比如：需要与http客户端互操作

多注册中心

(+) (#)

可以自行扩展注册中心，参见：注册中心扩展

(1) 多注册中心注册

比如：中文站有些服务来不及在青岛部署，只在杭州部署，而青岛的其它应用需要引用此服务，就可以将服务同时注册到两个注册中心。

(2) 不同服务使用不同注册中心

比如：CRM有些服务是专门为国际站设计的，有些服务是专门为中文站设计的。

(3) 多注册中心引用

比如：CRM需同时调用中文站和国际站的PC2服务，PC2在中文站和国际站均有部署，接口及版本号都一样，但连的数据库不一样。

如果只是测试环境临时需要连接两个不同注册中心，使用竖号分隔多个不同注册中心地址：

服务分组

(+) (#)

当一个接口有多种实现时，可以用group区分。

任意组：(2.2.0以上版本支持，总是只调一个可用组的实现)

多版本

(+) (#)

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

• 在低压力时间段，先升级一半提供者为新版本
• 再将所有消费者升级为新版本
• 然后将剩下的一半提供者升级为新版本

不区分版本：(2.2.0以上版本支持)

分组聚合

(+) (#)

按组合并返回结果，比如菜单服务，接口一样，但有多种实现，用group区分，现在消费方需从每种group中调用一次返回结果，合并结果返回，这样就可以实现聚合菜单项。

从2.1.0版本开始支持

代码参见：https://github.com/alibaba/dubbo/tree/master/dubbo-test/dubbo-test-examples/src/main/java/com/alibaba/dubbo/examples/merge

配置如：(搜索所有分组)

或：(合并指定分组)

或：(指定方法合并结果，其它未指定的方法，将只调用一个Group)

或：(某个方法不合并结果，其它都合并结果)

或：(指定合并策略，缺省根据返回值类型自动匹配，如果同一类型有两个合并器时，需指定合并器的名称)
参见：[合并结果扩展]

或：(指定合并方法，将调用返回结果的指定方法进行合并，合并方法的参数类型必须是返回结果类型本身)

参数验证

(+) (#)

参数验证功能是基于JSR303实现的，用户只需标识JSR303标准的验证Annotation，并通过声明filter来实现验证。

2.1.0以上版本支持

完整示例代码参见：https://github.com/alibaba/dubbo/tree/master/dubbo-test/dubbo-test-examples/src/main/java/com/alibaba/dubbo/examples/validation

验证方式可扩展，参见：Validation扩展点

参数标注示例：

分组验证示例：

关联验证示例：

参数验证示例：

在客户端验证参数：

在服务器端验证参数：

验证异常信息：

需要加入依赖：

结果缓存

(+) (#)

结果缓存，用于加速热门数据的访问速度，Dubbo提供声明式缓存，以减少用户加缓存的工作量。

2.1.0以上版本支持

示例代码：https://github.com/alibaba/dubbo/tree/master/dubbo-test/dubbo-test-examples/src/main/java/com/alibaba/dubbo/examples/cache

• lru 基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。
• threadlocal 当前线程缓存，比如一个页面渲染，用到很多portal，每个portal都要去查用户信息，通过线程缓存，可以减少这种多余访问。
• jcache 与JSR107集成，可以桥接各种缓存实现。

缓存类型可扩展，参见：CacheFactory扩展点

配置如：

或：

泛化引用

(+) (#)

泛接口调用方式主要用于客户端没有API接口及模型类元的情况，参数及返回值中的所有POJO均用Map表示，通常用于框架集成，比如：实现一个通用的服务测试框架，可通过GenericService调用所有服务实现。

假设存在POJO如：

则POJO数据：

可用下面Map表示：

泛化实现

(+) (#)

泛接口实现方式主要用于服务器端没有API接口及模型类元的情况，参数及返回值中的所有POJO均用Map表示，通常用于框架集成，比如：实现一个通用的远程服务Mock框架，可通过实现GenericService接口处理所有服务请求。

回声测试

(+) (#)

回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。

所有服务自动实现EchoService接口，只需将任意服务引用强制转型为EchoService，即可使用。

上下文信息

(+) (#)

上下文中存放的是当前调用过程中所需的环境信息。

所有配置信息都将转换为URL的参数，参见《配置项一览表》中的“对应URL参数”一列。

注意 RpcContext是一个ThreadLocal的临时状态记录器，当接收到RPC请求，或发起RPC请求时，RpcContext的状态都会变化。 比如：A调B，B再调C，则B机器上，在B调C之前，RpcContext记录的是A调B的信息，在B调C之后，RpcContext记录的是B调C的信息。

(1) 服务消费方

(2) 服务提供方

隐式传参

(+) (#)

注：path,group,version,dubbo,token,timeout几个key有特殊处理，请使用其它key值。

(1) 服务消费方

【注】 setAttachment设置的KV，在完成下面一次远程调用会被清空。即多次远程调用要多次设置。

(2) 服务提供方

异步调用

(+) (#)

基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。

2.0.6及其以上版本支持

配置声明：

调用代码：

你也可以设置是否等待消息发出：(异步总是不等待返回)

• sent="true" 等待消息发出，消息发送失败将抛出异常。
• sent="false" 不等待消息发出，将消息放入IO队列，即刻返回。

  <dubbo:method name="findFoo" async="true" sent="true" />

如果你只是想异步，完全忽略返回值，可以配置return="false"，以减少Future对象的创建和管理成本：

本地调用

(+) (#)

本地调用，使用了Injvm协议，是一个伪协议，它不开启端口，不发起远程调用，只在JVM内直接关联，但执行Dubbo的Filter链。

Define injvm protocol:

Set default protocol:

Set service protocol:

Use injvm first:

或

注意：服务暴露与服务引用都需要声明injvm="true"

自动暴露、引用本地服务

从 dubbo 2.2.0 开始，每个服务默认都会在本地暴露；在引用服务的时候，默认优先引用本地服务；如果希望引用远程服务可以使用一下配置强制引用远程服务。

参数回调

(+) (#)

参数回调方式与调用本地callback或listener相同，只需要在Spring的配置文件中声明哪个参数是callback类型即可，Dubbo将基于长连接生成反向代理，这样就可以从服务器端调用客户端逻辑。

2.0.6及其以上版本支持

代码参见：https://github.com/alibaba/dubbo/tree/master/dubbo-test/dubbo-test-examples/src/main/java/com/alibaba/dubbo/examples/callback

(1) 共享服务接口：

服务接口示例：

(2) 服务提供者：

服务提供者接口实现示例：

服务提供者配置示例：

(2) 服务消费者：

服务消费者配置示例：

服务消费者调用示例：

事件通知

(+) (#)

在调用之前，调用之后，出现异常时，会触发oninvoke, onreturn, onthrow三个事件，可以配置当事件发生时，通知哪个类的哪个方法。

支持版本：2.0.7之后

(1) 服务提供者与消费者共享服务接口：

(2) 服务提供者实现：

(3) 服务提供者配置：

(4) 服务消费者Callback接口及实现：

(5) 服务消费者Callback接口及实现：

注： callback与async功能正交分解： async=true，表示结果是否马上返回. onreturn 表示是否需要回调. 组合情况：(async=false 默认) 异步回调模式：async=true onreturn="xxx" 同步回调模式：async=false onreturn="xxx" 异步无回调 ：async=true 同步无回调 ：async=false

(6) TEST CASE：

本地存根

(+) (#)

远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，比如：做ThreadLocal缓存，提前验证参数，调用失败后伪造容错数据等等，此时就需要在API中带上Stub，客户端生成Proxy实，会把Proxy通过构造函数传给Stub，然后把Stub暴露组给用户，Stub可以决定要不要去调Proxy。

Stub必须有可传入Proxy的构造函数。

Or:

api.jar:

本地伪装

(+) (#)

Mock通常用于服务降级，比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过Mock数据返回授权失败。

Mock是Stub的一个子集，便于服务提供方在客户端执行容错逻辑，因经常需要在出现RpcException(比如网络失败，超时等)时进行容错，而在出现业务异常(比如登录用户名密码错误)时不需要容错，如果用Stub，可能就需要捕获并依赖RpcException类，而用Mock就可以不依赖RpcException，因为它的约定就是只有出现RpcException时才执行。

Or:

api.jar:

如果服务的消费方经常需要try-catch捕获异常，如：

请考虑改为Mock实现，并在Mock中return null。

如果只是想简单的忽略异常，在2.0.11以上版本可用：

延迟暴露

(+) (#)

如果你的服务需要Warmup时间，比如初始化缓存，等待相关资源就位等，可以使用delay进行延迟暴露。

延迟5秒暴露服务：

延迟到Spring初始化完成后，再暴露服务：(基于Spring的ContextRefreshedEvent事件触发暴露)

Spring2.x初始化死锁问题 在Spring解析到<dubbo:service />时，就已经向外暴露了服务，而Spring还在接着初始化其它Bean。 如果这时有请求进来，并且服务的实现类里有调用applicationContext.getBean()的用法。 1. 请求线程的applicationContext.getBean()调用，先同步singletonObjects判断Bean是否存在，不存在就同步beanDefinitionMap进行初始化，并再次同步singletonObjects写入Bean实例缓存。 2. 而Spring初始化线程，因不需要判断Bean的存在，直接同步beanDefinitionMap进行初始化，并同步singletonObjects写入Bean实例缓存。 这样就导致getBean线程，先锁singletonObjects，再锁beanDefinitionMap，再次锁singletonObjects。 而Spring初始化线程，先锁beanDefinitionMap，再锁singletonObjects。 反向锁导致线程死锁，不能提供服务，启动不了。

规避办法 1. 强烈建议不要在服务的实现类中有applicationContext.getBean()的调用，全部采用IoC注入的方式使用Spring的Bean。 2. 如果实在要调getBean()，可以将Dubbo的配置放在Spring的最后加载。 3. 如果不想依赖配置顺序，可以使用<dubbo:provider deplay=”-1” />，使Dubbo在Spring容器初始化完后，再暴露服务。 4. 如果大量使用getBean()，相当于已经把Spring退化为工厂模式在用，可以将Dubbo的服务隔离单独的Spring容器。

并发控制

(+) (#)

限制com.foo.BarService的每个方法，服务器端并发执行（或占用线程池线程数）不能超过10个：

限制com.foo.BarService的sayHello方法，服务器端并发执行（或占用线程池线程数）不能超过10个：

限制com.foo.BarService的每个方法，每客户端并发执行（或占用连接的请求数）不能超过10个：

Or:

限制com.foo.BarService的sayHello方法，每客户端并发执行（或占用连接的请求数）不能超过10个：

Or:

如果<dubbo:service>和<dubbo:reference>都配了actives，<dubbo:reference>优先，参见：配置的覆盖策略。

Load Balance均衡：

配置服务的客户端的loadbalance属性为leastactive，此Loadbalance会调用并发数最小的Provider（Consumer端并发数）。

Or:

连接控制

(+) (#)

限制服务器端接受的连接不能超过10个：（以连接在Server上，所以配置在Provider上）

限制客户端服务使用连接连接数：(如果是长连接，比如Dubbo协议，connections表示该服务对每个提供者建立的长连接数)

Or:

如果<dubbo:service>和<dubbo:reference>都配了connections，<dubbo:reference>优先，参见：配置的覆盖策略。

延迟连接

(+) (#)

延迟连接，用于减少长连接数，当有调用发起时，再创建长连接。

只对使用长连接的dubbo协议生效。

粘滞连接

(+) (#)

粘滞连接用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非该提供者挂了，再连另一台。

粘滞连接将自动开启延迟连接，以减少长连接数，参见：延迟连接 (+)

令牌验证

(+) (#)

• 防止消费者绕过注册中心访问提供者
• 在注册中心控制权限，以决定要不要下发令牌给消费者
• 注册中心可灵活改变授权方式，而不需修改或升级提供者

可以全局设置开启令牌验证：

也可在服务级别设置：

还可在协议级别设置：

路由规则

(+) (#)

2.2.0以上版本支持

路由规则扩展点：路由扩展

向注册中心写入路由规则：(通常由监控中心或治理中心的页面完成)

其中：

• condition://
  • 表示路由规则的类型，支持条件路由规则和脚本路由规则，可扩展，必填。
• 0.0.0.0
  • 表示对所有IP地址生效，如果只想对某个IP的生效，请填入具体IP，必填。
• com.foo.BarService
  • 表示只对指定服务生效，必填。
• category=routers
  • 表示该数据为动态配置类型，必填。
• dynamic=false
  • 表示该数据为持久数据，当注册方退出时，数据依然保存在注册中心，必填。
• enabled=true
  • 覆盖规则是否生效，可不填，缺省生效。
• force=false
  • 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为flase。
• runtime=false
  • 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。
  • 如果用了参数路由，必须设为true，需要注意设置会影响调用的性能，可不填，缺省为flase。
• priority=1
  • 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为0。
• rule=URL.encode("host = 10.20.153.10 => host = 10.20.153.11")
  • 表示路由规则的内容，必填。

条件路由规则

(#)

基于条件表达式的路由规则，如：

规则：

• "=>"之前的为消费者匹配条件，所有参数和消费者的URL进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
• "=>"之后为提供者地址列表的过滤条件，所有参数和提供者的URL进行对比，消费者最终只拿到过滤后的地址列表。
• 如果匹配条件为空，表示对所有消费方应用，如：=> host != 10.20.153.11
• 如果过滤条件为空，表示禁止访问，如：host = 10.20.153.10 =>

表达式：

• 参数支持：
  • 服务调用信息，如：method, argument 等 (暂不支持参数路由)
  • URL本身的字段，如：protocol, host, port 等
  • 以及URL上的所有参数，如：application, organization 等
• 条件支持：
  • 等号"="表示"匹配"，如：host = 10.20.153.10
  • 不等号"!="表示"不匹配"，如：host != 10.20.153.10
• 值支持：
  • 以逗号","分隔多个值，如：host != 10.20.153.10,10.20.153.11
  • 以星号"*"结尾，表示通配，如：host != 10.20.*
  • 以美元符"$"开头，表示引用消费者参数，如：host = $host

示例：

1. 排除预发布机：

2. 白名单：(注意：一个服务只能有一条白名单规则，否则两条规则交叉，就都被筛选掉了)

3. 黑名单：

4. 服务寄宿在应用上，只暴露一部分的机器，防止整个集群挂掉：

5. 为重要应用提供额外的机器：

6. 读写分离：

7. 前后台分离：

8. 隔离不同机房网段：

9. 提供者与消费者部署在同集群内，本机只访问本机的服务：

脚本路由规则

(#)

支持JDK脚本引擎的所有脚本，比如：javascript,jruby,groovy等，通过type=javascript参数设置脚本类型，缺省为javascript。

脚本没有沙箱约束，可执行任意代码，存在后门风险

基于脚本引擎的路由规则，如：