Dubbo文档

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

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

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

配置

三种配置方式

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

集群容错模式

集群模式配置

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

使用

如果你的服务需要预热时间，比如初始化缓存，等待相关资源就位等，可以使用 delay 进行延迟暴露。我们在 Dubbo 2.6.5 版本中对服务延迟暴露逻辑进行了细微的调整，将需要延迟暴露（delay > 0）服务的倒计时动作推迟到了 Spring 初始化完成后进行。你在使用 Dubbo 的过程中，并不会感知到此变化，因此请放心使用。

使用

配置样例

使用

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

配置

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

安全

使用

路由规则在发起一次RPC调用前起到过滤目标服务器地址的作用，过滤后的地址列表，将作为消费端最终发起RPC调用的备选地址。

条件路由。支持以服务或Consumer应用为粒度配置路由规则。

标签路由。以Provider应用为粒度配置路由规则。

覆盖规则是Dubbo设计的在无需重启应用的情况下，动态调整RPC调用行为的一种能力。2.7.0版本开始，支持从服务和应用两个粒度来调整动态配置。

概览

规则详解

使用

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果用户使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

使用

当业务线程池满时，我们需要知道线程都在等待哪些资源、条件，以找到系统的瓶颈点或异常点。dubbo通过Jstack自动导出线程堆栈来保留现场，方便排查问题

默认策略:

导出路径，user.home标识的用户主目录
导出间隔，最短间隔允许每隔10分钟导出一次
指定导出路径：

# dubbo.properties
dubbo.application.dump.directory=/tmp
<dubbo:application ...>
<dubbo:parameter key="dump.directory" value="/tmp" />
</dubbo:application>

使用

类似支付之类的对安全性敏感的业务可能会有限制匿名调用的需求。在加固安全性方面，2.7.5 引入了基于AK/SK机制的认证鉴权机制，并且引入了鉴权服务中心，主要原理是消费端在请求需要鉴权的服务时，会通过SK、请求元数据、时间戳、参数等信息来生成对应的请求签名，通过Dubbo的Attahcment机制携带到对端进行验签，验签通过才进行业务逻辑处理。如下图所示：



具体的接入方式也并不复杂：

使用者需要在微服务站点上填写自己的应用信息，并为该应用生成唯一的证书凭证。

之后在管理站点上提交工单，申请某个敏感业务服务的使用权限，并由对应业务管理者进行审批，审批通过之后，会生成对应的AK/SK到鉴权服务中心。

导入该证书到对应的应用下，并且进行配置。配置方式也十分简单，以注解方式为例：

服务提供端，只需要设置service.auth为true，表示该服务的调用需要鉴权认证通过。param.sign为true表示需要对参数也进行校验。

@Service(parameters = {"service.auth","true","param.sign","true"})
public class AuthDemoServiceImpl implements AuthService {
}

服务消费端，只需要配置好对应的证书等信息即可，之后会自动地在对这些需要认证的接口发起调用前进行签名操作，通过与鉴权服务的交互，用户无需在代码中配置AK/SK这些敏感信息，并且在不重启应用的情况下刷新AK/SK，达到权限动态下发的目的。

该方案目前已经提交给Dubbo开源社区，并且完成了基本框架的合并，除了AK/SK的鉴权方式之外，通过SPI机制支持用户可定制化的鉴权认证以及适配公司内部基础设施的密钥存储。

使用

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

可以自行扩展负载均衡策略

负载均衡策略

是否需要在netty/mina的网络io线程外开启另外个线程池去完成其它的任务。如果其它的任务比较重，建议开启。

配置

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

缓存类型

缓存类型可扩展

耗时的请求可以使用异步

Consumer异步调用

Provider异步执行

参数回调

事件通知

使用

provider端：

<dubbo:protocol server="netty4" />
或

<dubbo:provider server="netty4" />
consumer端：

<dubbo:consumer client="netty4" />

注意

provider端如需不同的协议使用不同的通信层框架，请配置多个protocol分别设置
consumer端请使用如下形式：
<dubbo:consumer client="netty">
<dubbo:reference />
</dubbo:consumer>
<dubbo:consumer client="netty4">
<dubbo:reference />
</dubbo:consumer>
接下来我们会继续完善：

性能测试指标及与netty3版本的性能测试对比，我们会提供一份参考数据

使用

直连

只注册

静态服务

多协议

多注册中心

服务分组

多版本

分组聚合

参数验证

上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为 URL 的参数，参见 schema 配置参考手册 中的对应URL参数一列。

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

使用

可以通过 RpcContext 上的 setAttachment 和 getAttachment 在服务消费方和提供方之间进行参数的隐式传递。注意：path, group, version, dubbo, token, timeout 几个 key 是保留字段，请使用其它值。

使用

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

使用

使用

使用

配置

使用

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

通过 Spring 使用泛化调用

通过 API 方式使用泛化调用

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

配置

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

使用

使用

服务容器是一个 standalone 的启动程序，因为后台服务不需要 Tomcat 或 JBoss 等 Web 容器的功能，如果硬要用 Web 容器去加载服务提供方，增加复杂性，也浪费资源。

服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。

服务容器的加载内容可以扩展，内置了 spring, jetty, log4j 等加载，可通过容器扩展点进行扩展。配置配在 java 命令的 -D 参数或者 dubbo.properties 中。

容器类型

容器启动

dubbo:service

dubbo:provider

dubbo:method

dubbo:reference

dubbo:consumer

dubbo:method

dubbo:protocol

dubbo:registry

dubbo:monitor

dubbo:application

dubbo:module

dubbo:config-center

JVM -D参数，当你部署或者启动应用时，它可以轻易地重写配置，比如，改变dubbo协议端口；

XML, XML中的当前配置会重写dubbo.properties中的；

Properties，默认配置，仅仅作用于以上两者没有配置时

如果 id没有在protocol中配置，将使用name作为默认属性。

org.apache.dubbo.common.URL
org.apache.dubbo.rpc.RpcException

org.apache.dubbo.rpc.RpcContext

上下文信息

隐式参数

异步调用

org.apache.dubbo.rpc.service.GenericService
org.apache.dubbo.rpc.service.GenericException

泛化调用

泛化实现

回声测试

1. 外部化配置。启动配置的集中式存储 （简单理解为dubbo.properties的外部化存储）。

2. 服务治理。服务治理规则的存储与通知。

指定一些列配置到URL中的键值对，通常通过JVM -D或系统环境变量指定。

增加以下配置：

# JVM
-Ddubbo.labels = "tag1=value1; tag2=value2"

# 环境变量
DUBBO_LABELS = "tag1=value1; tag2=value2"
最终生成的URL会包含 tag1、tag2 两个 key: dubbo://xxx?tag1=value1&tag2=value2

指定环境变量key值，Dubbo会尝试从环境变量加载每个 key

# JVM
-Ddubbo.env.keys = "DUBBO_TAG1, DUBBO_TAG2"

# 环境变量
DUBBO_ENV_KEYS = "DUBBO_TAG1, DUBBO_TAG2"
最终生成的URL会包含 DUBBO_TAG1、DUBBO_TAG2 两个 key: dubbo://xxx?DUBBO_TAG1=value1&DUBBO_TAG2=value2