本小节,我们将 《精尽 Dubbo 源码解析》 和 《Dubbo 用户指南》 做一次映射,方便大家直接找到感兴趣的功能的具体源码实现。当然,如果有整理不到位的地方,欢迎大家给我留言斧正。
Dubbo 采用全 Spring 配置方式,透明化接入应用,对应用没有任何 API 侵入,只需用 Spring 加载 Dubbo 的配置即可,Dubbo 基于 Spring 的 Schema 扩展进行加载。 如果不想使用 Spring 配置,可以通过 API 的方式 进行调用。
对应源码解析文章:
有关 XML 的详细配置项,请参见:配置参考手册。如果不想使用 Spring 配置,而希望通过 API 的方式进行调用,请参见:API配置。想知道如何使用配置,请参见:快速启动。
对应源码解析文章:
如果公共配置很简单,没有多注册中心,多协议等情况,或者想多个 Spring 容器想共享配置,可以使用 dubbo.properties 作为缺省配置。 Dubbo 将自动加载 classpath 根目录下的 dubbo.properties,可以通过JVM启动参数
-Ddubbo.properties.file=xxx.properties
改变缺省配置位置。1
对应源码解析文章:
API 属性与配置项一对一,各属性含义,请参见:配置参考手册,比如:
ApplicationConfig.setName("xxx")
对应<dubbo:application name="xxx" />
1
对应源码解析文章:
需要
2.5.7
及以上版本支持
对应源码解析文章:
《精尽 Dubbo 源码解析 —— 注解配置》
Dubbo 缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring 初始化完成,以便上线时,能及早发现问题,默认
check="true"
。 可以通过check="false"
关闭检查,比如,测试时,有些服务不关心,或者出现了循环依赖,必须有一方先启动。 另外,如果你的 Spring 容器是懒加载的,或者通过 API 编程延迟引用服务,请关闭 check,否则服务临时不可用时,会抛出异常,拿到 null 引用,如果check="false"
,总是会返回引用,当服务恢复时,能自动连上。
对应源码解析文章:
在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。
cluster
对应源码解析文章:
在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为
random
随机调用。 可以自行扩展负载均衡策略,参见:负载均衡扩展
对应源码解析文章:
如果事件处理的逻辑能迅速完成,并且不会发起新的 IO 请求,比如只是在内存中记个标识,则直接在 IO 线程上处理更快,因为减少了线程池调度。 但如果事件处理逻辑较慢,或者需要发起新的 IO 请求,比如需要查询数据库,则必须派发到线程池,否则 IO 线程阻塞,将导致不能接收其它请求。 如果用 IO 线程处理事件,又在事件处理过程中发起新的 IO 请求,比如在连接事件中发起登录请求,会报“可能引发死锁”异常,但不会真死锁。
dubbo-protocol
对应源码解析文章:
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,点对点直联方式,将以服务接口为单位,忽略注册中心的提供者列表,A 接口配置点对点,不影响 B 接口从注册中心获取列表。
/user-guide/images/dubbo-directly.jpg
对应源码解析文章:
为方便开发测试,经常会在线下共用一个所有服务可用的注册中心,这时,如果一个正在开发中的服务提供者注册,可能会影响消费者不能正常运行。 可以让服务提供者开发方,只订阅服务(开发的服务可能依赖其它服务),而不注册正在开发的服务,通过直连测试正在开发的服务。
/user-guide/images/subscribe-only.jpg
对应源码解析文章:
如果有两个镜像环境,两个注册中心,有一个服务只在其中一个注册中心有部署,另一个注册中心还没来得及部署,而两个注册中心的其它应用都需要依赖此服务。这个时候,可以让服务提供者方只注册服务到另一注册中心,而不从另一注册中心订阅服务。
对应源码解析文章:
有时候希望人工管理服务提供者的上线和下线,此时需将注册中心标识为非动态管理模式。
对应源码解析文章:
Dubbo 允许配置多协议,在不同服务上支持不同协议或者同一服务上同时支持多种协议。
对应源码解析文章:
Dubbo 支持同一服务向多注册中心同时注册,或者不同服务分别注册到不同的注册中心上去,甚至可以同时引用注册在不同注册中心上的同名服务。另外,注册中心是支持自定义扩展的。
对应源码解析文章:
当一个接口有多种实现时,可以用 group 区分。
当一个接口实现,出现不兼容升级时,可以用版本号过渡,版本号不同的服务相互间不引用。 可以按照以下的步骤进行版本迁移:
对应源码解析文章:
按组合并返回结果 1,比如菜单服务,接口一样,但有多种实现,用group区分,现在消费方需从每种group中调用一次返回结果,合并结果返回,这样就可以实现聚合菜单项。
对应源码解析文章:
参数验证功能 1 是基于 JSR303 实现的,用户只需标识 JSR303 标准的验证 annotation,并通过声明 filter 来实现验证 2。
对应源码解析文章:
结果缓存 1,用于加速热门数据的访问速度,Dubbo 提供声明式缓存,以减少用户加缓存的工作量 2。
对应源码解析文章:
泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况,参数及返回值中的所有 POJO 均用
Map
表示,通常用于框架集成,比如:实现一个通用的服务测试框架,可通过GenericService
调用所有服务实现。
对应源码解析文章:
泛接口实现方式主要用于服务器端没有API接口及模型类元的情况,参数及返回值中的所有POJO均用Map表示,通常用于框架集成,比如:实现一个通用的远程服务Mock框架,可通过实现GenericService接口处理所有服务请求。
对应源码解析文章:
回声测试用于检测服务是否可用,回声测试按照正常请求流程执行,能够测试整个调用是否通畅,可用于监控。 所有服务自动实现
EchoService
接口,只需将任意服务引用强制转型为EchoService
,即可使用。
对应源码解析文章:
上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为 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
在服务消费方和提供方之间进行参数的隐式传递。 1
/user-guide/images/context.png
对应源码解析文章:
基于 NIO 的非阻塞实现并行调用,客户端不需要启动多线程即可完成并行调用多个远程服务,相对多线程开销较小。 1
/user-guide/images/future.jpg
对应源码解析文章:
本地调用使用了 injvm 协议,是一个伪协议,它不开启端口,不发起远程调用,只在 JVM 内直接关联,但执行 Dubbo 的 Filter 链。
对应源码解析文章:
参数回调方式与调用本地 callback 或 listener 相同,只需要在 Spring 的配置文件中声明哪个参数是 callback 类型即可。Dubbo 将基于长连接生成反向代理,这样就可以从服务器端调用客户端逻辑 1。可以参考 dubbo 项目中的示例代码。
对应源码解析文章:
在调用之前、调用之后、出现异常时,会触发
oninvoke
、onreturn
、onthrow
三个事件,可以配置当事件发生时,通知哪个类的哪个方法 1。
对应源码解析文章:
远程服务后,客户端通常只剩下接口,而实现全在服务器端,但提供方有些时候想在客户端也执行部分逻辑,比如:做 ThreadLocal 缓存,提前验证参数,调用失败后伪造容错数据等等,此时就需要在 API 中带上 Stub,客户端生成 Proxy 实例,会把 Proxy 通过构造函数传给 Stub 1,然后把 Stub 暴露给用户,Stub 可以决定要不要去调 Proxy。
/user-guide/images/stub.jpg
对应源码解析文章:
本地伪装 1 通常用于服务降级,比如某验权服务,当服务提供方全部挂掉后,客户端不抛出异常,而是通过 Mock 数据返回授权失败。
对应源码解析文章:
如果你的服务需要预热时间,比如初始化缓存,等待相关资源就位等,可以使用 delay 进行延迟暴露。
对应源码解析文章:
限制
com.foo.BarService
的每个方法,服务器端并发执行(或占用线程池线程数)不能超过 10 个 限制com.foo.BarService
的sayHello
方法,服务器端并发执行(或占用线程池线程数)不能超过 10 个 限制com.foo.BarService
的每个方法,每客户端并发执行(或占用连接的请求数)不能超过 10 个 限制com.foo.BarService
的sayHello
方法,每客户端并发执行(或占用连接的请求数)不能超过 10 个
对应源码解析文章:
限制服务器端接受的连接不能超过 10 个 1: 限制客户端服务使用连接不能超过 10 个 2:
对应源码解析文章:
延迟连接用于减少长连接数。当有调用发起时,再创建长连接。1
对应源码解析文章:
粘滞连接用于有状态服务,尽可能让客户端总是向同一提供者发起调用,除非该提供者挂了,再连另一台。 粘滞连接将自动开启延迟连接,以减少长连接数。
对应源码解析文章:
通过令牌验证在注册中心控制权限,以决定要不要下发令牌给消费者,可以防止消费者绕过注册中心访问提供者,另外通过注册中心可灵活改变授权方式,而不需修改或升级提供者
/user-guide/images/dubbo-token.jpg
对应源码解析文章:
路由规则 1 决定一次 dubbo 服务调用的目标服务器,分为条件路由规则和脚本路由规则,并且支持可扩展 2。
对应源码解析文章:
向注册中心写入动态配置覆盖规则 1。该功能通常由监控中心或治理中心的页面完成。
对应源码解析文章:
可以通过服务降级功能 1 临时屏蔽某个出错的非关键服务,并定义降级后的返回策略。
对应源码解析文章:
Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的,所以如果用户使用
kill -9 PID
等强制关闭指令,是不会执行优雅停机的,只有通过kill PID
时,才会执行。
对应源码解析文章:
缺省主机 IP 查找顺序:
LocalHost.getLocalHost()
获取本机地址。127.*
等 loopback 地址,则扫描各网卡,获取网卡 IP。对应源码解析文章:
自
2.2.1
开始,dubbo 开始内置 log4j、slf4j、jcl、jdk 这些日志框架的适配 1,也可以通过以下方式显示配置日志输出策略:
dubbo.properties
中指定dubbo.xml
中配置对应源码解析文章:
如果你想记录每一次请求信息,可开启访问日志,类似于apache的访问日志。注意:此日志量比较大,请注意磁盘容量。
对应源码解析文章:
服务容器是一个 standalone 的启动程序,因为后台服务不需要 Tomcat 或 JBoss 等 Web 容器的功能,如果硬要用 Web 容器去加载服务提供方,增加复杂性,也浪费资源。 服务容器只是一个简单的 Main 方法,并加载一个简单的 Spring 容器,用于暴露服务。 服务容器的加载内容可以扩展,内置了 spring, jetty, log4j 等加载,可通过容器扩展点进行扩展。配置配在 java 命令的 -D 参数或者
dubbo.properties
中。
对应源码解析文章:
ReferenceConfig
实例很重,封装了与注册中心的连接以及与提供者的连接,需要缓存。否则重复生成ReferenceConfig
可能造成性能问题并且会有内存和连接泄漏。在 API 方式编程时,容易忽略此问题。 因此,自2.4.0
版本开始, dubbo 提供了简单的工具类ReferenceConfigCache
用于缓存ReferenceConfig
实例。
对应源码解析文章:
分布式事务基于 JTA/XA 规范实现 1。 两阶段提交:
/user-guide/images/jta-xa.jpg
目前该功能暂未实现,如下是推荐阅读的内容:
当业务线程池满时,我们需要知道线程都在等待哪些资源、条件,以找到系统的瓶颈点或异常点。dubbo通过Jstack自动导出线程堆栈来保留现场,方便排查问题 默认策略:
对应源码解析文章:
dubbo 2.5.6版本新增了对netty4通信模块的支持
对应源码解析文章:
这里以 XML Config 1 为准,列举所有配置项 2。其它配置方式,请参见相应转换关系:属性配置,注解配置,API 配置。
对应源码解析文章:
Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。 反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。
dubbo-protocol.jpg
对应源码解析文章:
RMI 协议采用 JDK 标准的
java.rmi.*
实现,采用阻塞式短连接和 JDK 标准序列化方式。 注意:如果正在使用 RMI 提供服务给外部访问 1,同时应用里依赖了老的 common-collections 包 2 的情况下,存在反序列化安全风险 3。
对应源码解析文章:
Hessian 1 协议用于集成 Hessian 的服务,Hessian 底层采用 Http 通讯,采用 Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现。 Dubbo 的 Hessian 协议可以和原生 Hessian 服务互操作,即:
对应源码解析文章:
基于 HTTP 表单的远程调用协议,采用 Spring 的 HttpInvoker 实现 1
对应源码解析文章:
基于 WebService 的远程调用协议,基于 Apache CXF 1 的
frontend-simple
和transports-http
实现 2。 可以和原生 WebService 服务互操作,即:
对应源码解析文章:
当前 dubbo 支持 1的 thrift 协议是对 thrift 原生协议 2 的扩展,在原生协议的基础上添加了一些额外的头信息,比如 service name,magic number 等。 使用 dubbo thrift 协议同样需要使用 thrift 的 idl compiler 编译生成相应的 java 代码,后续版本中会在这方面做一些增强。
对应源码解析文章:
基于 memcached 1 实现的 RPC 协议 2。
对应源码解析文章:
基于 Redis 1 实现的 RPC 协议 2。
对应源码解析文章:
对应文档为
对应源码解析文章:
Multicast 注册中心不需要启动任何中心节点,只要广播地址一样,就可以互相发现。
/user-guide/images/multicast.jpg
unicast=false
,则广播给订阅者组播受网络结构限制,只适合小规模应用或开发阶段使用。组播地址段: 224.0.0.0 - 239.255.255.255
对应源码解析文章:
Zookeeper 是 Apacahe Hadoop 的子项目,是一个树型的目录服务,支持变更推送,适合作为 Dubbo 服务的注册中心,工业强度较高,可用于生产环境,并推荐使用 1。
/user-guide/images/zookeeper.jpg
对应源码解析文章:
基于 Redis 1 实现的注册中心 2。
/user-guide/images/dubbo-redis-registry.jpg
对应源码解析文章:
Simple 注册中心本身就是一个普通的 Dubbo 服务,可以减少第三方依赖,使整体通讯方式一致。
对应源码解析文章:
从
2.0.5
版本开始,dubbo 开始支持通过 telnet 命令来镜像服务治理。
对应源码解析文章:
dubbo 2.5.8 新版本重构了 telnet 模块,提供了新的 telnet 命令支持。
对应源码解析文章:
TODO
dubbo-ops
本小节,我们将 《精尽 Dubbo 源码解析》 和 《Dubbo 开发指南》 做一次映射,方便大家直接找到感兴趣的功能的具体源码实现。当然,如果有整理不到位的地方,欢迎大家给我留言斧正。
代码签出 分支 构建 构建源代码 jar 包 IDE 支持
对应源码解析文章:
/dev-guide/images/dubbo-framework.jpg
对应源码解析文章:
Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。 Dubbo 改进了 JDK 标准的 SPI 的以下问题:
getName()
获取脚本类型的名称,但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在,导致 RubyScriptEngine 类加载失败,这个失败原因被吃掉了,和 ruby 对应不起来,当用户执行 ruby 脚本时,会报不支持 ruby,而不是真正失败的原因。对应源码解析文章:
RPC 协议扩展,封装远程调用细节。 契约:
refer()
所返回的 Invoker
对象的 invoke()
方法时,协议需相应执行同 URL 远端 export()
传入的 Invoker
对象的 invoke()
方法。refer()
返回的 Invoker
由协议实现,协议通常需要在此 Invoker
中发送远程请求,export()
传入的 Invoker
由框架实现并传入,协议不需要关心。注意:
Invoker
为中心,由外层将 Invoker
转换为业务接口。对应源码解析文章:
服务提供方和服务消费方调用过程拦截,Dubbo 本身的大多功能均基于此扩展点实现,每次远程方法执行,该拦截都会被执行,请注意对性能的影响。 约定:
default
,表示缺省扩展点插入的位置。比如:filter="xxx,default,yyy"
,表示 xxx
在缺省 filter 之前,yyy
在缺省 filter 之后。-
,表示剔除。比如:filter="-foo1"
,剔除添加缺省扩展点 foo1
。比如:filter="-default"
,剔除添加所有缺省扩展点。xxx
,yyy
,aaa
,bbb
均会生效。如果要覆盖,需配置:对应源码解析文章:
当有服务引用时,触发该事件。
对应源码解析文章:
当有服务暴露时,触发该事件。
对应源码解析文章:
当有多个服务提供方时,将多个服务提供方组织成一个集群,并伪装成一个提供方。
对应源码解析文章:
从多个服务提者方中选择一个进行调用。
对应源码解析文章:
从多个服务提者方中选择一个进行调用
对应源码解析文章:
合并返回结果,用于分组聚合。
对应源码解析文章:
负责服务的注册与发现。
对应源码解析文章:
负责服务调用次和调用时间的监控。
对应源码解析文章:
TODO
扩展点本身的加载容器,可从不同容器加载扩展点。
对应源码解析文章:
将
Invoker
接口转换成业务接口。
对应源码解析文章:
Java 代码编译器,用于动态生成字节码,加速调用。
对应源码解析文章:
通道信息派发器,用于指定线程池模型。
对应源码解析文章:
服务提供方线程程实现策略,当服务器收到一个请求时,需要在线程池中创建一个线程去执行服务提供方业务逻辑。
对应源码解析文章:
将对象转成字节流,用于网络传输,以及将字节流转为对象,用于在收到字节流数据后还原成对象。
对应源码解析文章:
远程通讯的服务器及客户端传输实现。
对应源码解析文章:
基于传输层之上,实现 Request-Response 信息交换语义。
对应源码解析文章:
对等网络节点组网器。
对应源码解析文章:
所有服务器均支持 telnet 访问,用于人工干预。
对应源码解析文章:
检查服务依赖各种资源的状态,此状态检查可同时用于 telnet 的 status 命令和 hosting 的 status 页面。
对应源码解析文章:
TODO
服务容器扩展,用于自定义加载内容。
对应源码解析文章:
对等网络节点组网器。
对应源码解析文章:
TODO
用请求参数作为 key,缓存返回结果。
对应源码解析文章:
参数验证扩展点。
对应源码解析文章:
日志输出适配扩展点。
对应源码解析文章:
《Dubbo 运维指南》 ,暂时无映射的需要。