示例

(+) (#)

启动时检查

(+) (#)

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

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

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

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

也可以用dubbo.properties配置：

也可以用-D参数：

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

集群容错

(+) (#)

各节点关系：

• 这里的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集群模式生效)

或：

或：

集群模式配置如：

或：

负载均衡

(+) (#)

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

Random LoadBalance

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

RoundRobin LoadBalance

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

LeastActive LoadBalance

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

ConsistentHash LoadBalance

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

配置如：

或：

或：

或：

线程模型

(+) (#)

• 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在中文站和国际站均有部署，接口及版本号都一样，但连的数据库不一样。

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

服务分组

(+) (#)

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

多版本

(+) (#)

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

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

分组聚合

(+) (#)

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

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

或：(合并指定分组)

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

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

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

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

参数验证

(+) (#)

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

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

参数标注示例：

分组验证示例：

关联验证示例：

参数验证示例：

在客户端验证参数：

在服务器端验证参数：

验证异常信息：

需要加入依赖：

结果缓存

(+) (#)

示例代码：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扩展点

配置如：

或：

泛化引用

(+) (#)

假设存在POJO如：

则POJO数据：

可用下面Map表示：

泛化实现

(+) (#)

回声测试

(+) (#)

上下文信息

(+) (#)

(1) 服务消费方

(2) 服务提供方

隐式传参

(+) (#)

(1) 服务消费方

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

(2) 服务提供方

异步调用

(+) (#)

配置声明：

调用代码：

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

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

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

本地调用

(+) (#)

Define injvm protocol:

Set default protocol:

Set service protocol:

Use injvm first:

或

自动暴露、引用本地服务

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

参数回调

(+) (#)

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

(1) 共享服务接口：

服务接口示例：

(2) 服务提供者：

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

服务提供者配置示例：

(2) 服务消费者：

服务消费者配置示例：

服务消费者调用示例：

事件通知

(+) (#)

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

(2) 服务提供者实现：

(3) 服务提供者配置：

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

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

(6) TEST CASE：

本地存根

(+) (#)

Or:

api.jar:

本地伪装

(+) (#)

Or:

api.jar:

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

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

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

延迟暴露

(+) (#)

延迟5秒暴露服务：

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

并发控制

(+) (#)

限制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>优先，参见：配置的覆盖策略。

延迟连接

(+) (#)

粘滞连接

(+) (#)

令牌验证

(+) (#)

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

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

也可在服务级别设置：

还可在协议级别设置：

路由规则

(+) (#)

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

其中：

• 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. 提供者与消费者部署在同集群内，本机只访问本机的服务：

脚本路由规则

(#)

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

配置规则

(+) (#)

向注册中心写入动态配置覆盖规则：(通常由监控中心或治理中心的页面完成)

其中：

• override://
  • 表示数据采用覆盖方式，支持override和absent，可扩展，必填。
• 0.0.0.0
  • 表示对所有IP地址生效，如果只想覆盖某个IP的数据，请填入具体IP，必填。
• com.foo.BarService
  • 表示只对指定服务生效，必填。
• category=configurators
  • 表示该数据为动态配置类型，必填。
• dynamic=false
  • 表示该数据为持久数据，当注册方退出时，数据依然保存在注册中心，必填。
• enabled=true
  • 覆盖规则是否生效，可不填，缺省生效。
• application=foo
  • 表示只对指定应用生效，可不填，表示对所有应用生效。
• timeout=1000
  • 表示将满足以上条件的timeout参数的值覆盖为1000。
  • 如果想覆盖其它参数，直接加在override的URL参数上。

示例：

1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)

2. 调整权重：(通常用于容量评估，缺省权重为100)

3. 调整负载均衡策略：(缺省负载均衡策略为random)

4. 服务降级：(通常用于临时屏蔽某个出错的非关键服务)

服务降级

(+) (#)

向注册中心写入动态配置覆盖规则：(通过由监控中心或治理中心的页面完成)

其中：

• 表示消费方对该服务的方法调用都直接返回null值，不发起远程调用。
• 屏蔽不重要服务不可用时对调用方的影响。

还可以改为：

• 表示消费方对该服务的方法调用在失败后，再返回null值，不抛异常。
• 容忍不重要服务不稳定时对调用方的影响。

优雅停机

(+) (#)

原理：

• 服务提供方
  • 停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
  • 然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。
• 服务消费方
  • 停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
  • 然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。

设置优雅停机超时时间，缺省超时时间是10秒：(超时则强制关闭)

如果ShutdownHook不能生效，可以自行调用：

主机绑定

(+) (#)

缺省主机IP查找顺序：

• 通过LocalHost.getLocalHost()获取本机地址。
• 如果是127.*等loopback地址，则扫描各网卡，获取网卡IP。

注册的地址如果获取不正确，比如需要注册公网地址，可以：
1. 可以在/etc/hosts中加入：机器名 公网IP，比如：

2. 在dubbo.xml中加入主机地址的配置：

3. 或在dubbo.properties中加入主机地址的配置：

缺省主机端口与协议相关：

• dubbo: 20880
• rmi: 1099
• http: 80
• hessian: 80
• webservice: 80
• memcached: 11211
• redis: 6379

主机端口配置：

1. 在dubbo.xml中加入主机地址的配置：

3. 或在dubbo.properties中加入主机地址的配置：

日志适配

(+) (#)

缺省自动查找：

• log4j
• slf4j
• jcl
• jdk

可以通过以下方式配置日志输出策略：

访问日志

(+) (#)

将访问日志输出到当前应用的log4j日志：

将访问日志输出到指定文件：

服务容器

(+) (#)

Spring Container

• 自动加载META-INF/spring目录下的所有Spring配置。
• 配置：(配在java命令-D参数或者dubbo.properties中)
  • dubbo.spring.config=classpath*:META-INF/spring/*.xml ----配置spring配置加载位置

Jetty Container

• 启动一个内嵌Jetty，用于汇报状态。
• 配置：(配在java命令-D参数或者dubbo.properties中)
  • dubbo.jetty.port=8080 ----配置jetty启动端口
  • dubbo.jetty.directory=/foo/bar ----配置可通过jetty直接访问的目录，用于存放静态文件
  • dubbo.jetty.page=log,status,system ----配置显示的页面，缺省加载所有页面

Log4j Container

• 自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录。
• 配置：(配在java命令-D参数或者dubbo.properties中)
  • dubbo.log4j.file=/foo/bar.log ----配置日志文件路径
  • dubbo.log4j.level=WARN ----配置日志级别
  • dubbo.log4j.subdirectory=20880 ----配置日志子目录，用于多进程启动，避免冲突

容器启动

如：(缺省只加载spring)

或：(通过main函数参数传入要加载的容器)

或：(通过JVM启动参数传入要加载的容器)

或：(通过classpath下的dubbo.properties配置传入要加载的容器)

Reference Config缓存

(+) (#)

ReferenceConfig实例很重，封装了与注册中心的连接以及与提供者的连接，需要缓存，否则重复生成ReferenceConfig可能造成性能问题并且会有内存和连接泄漏。API方式编程时，容易忽略此问题。

Dubbo 2.4.0+版本，提供了简单的工具类ReferenceConfigCache用于缓存ReferenceConfig实例。

使用方式如下：

消除Cache中的ReferenceConfig，销毁ReferenceConfig并释放对应的资源。

缺省ReferenceConfigCache把相同服务Group、接口、版本的ReferenceConfig认为是相同，缓存一份。即以服务Group、接口、版本为缓存的Key。

可以修改这个策略，在ReferenceConfigCache.getCache时，传一个KeyGenerator。详见ReferenceConfigCache类的方法。

分布式事务

(+) (#)

两阶段提交：