13-1-13 D eveloper G uide-zh - D ubbo - Alibaba O pen S esam e
1/44code.alibabatech.com /w iki/display/dubbo/D eveloper+G uide-zh
Added by 梁 飞, last edited by 李 鼎 on 十一月 27, 2012
首页 || 下载 || 用户指南 || 开发者指南 || 管理员指南 || 培训文档 || 常见问题解答 || 发布记录 || 发展路线 || 社区
English | 中文
开发者指南
参与
流程
任务
版本开发模式
2个版本并行开发
优势
用户要配合的职责
框架设计
整体设计
模块分包
依赖关系
调用链
暴露服务时序
引用服务时序
领域模型
基本原则
扩展点加载
扩展点配置
扩展点自动包装
扩展点自动装配
扩展点自适应
扩展点自动激活
实现细节
初始化过程细节
远程调用细节
远程通讯细节
SPI参考手册
协议扩展
调用拦截扩展
引用监听扩展
暴露监听扩展
集群扩展
路由扩展
负载均衡扩展
合并结果扩展
注册中心扩展
监控中心扩展
扩展点加载扩展
动态代理扩展
编译器扩展
消息派发扩展
线程池扩展
序列化扩展
网络传输扩展
信息交换扩展
组网扩展
Telnet命令扩展
状态检查扩展
容器扩展
页面扩展
缓存扩展
验证扩展
日志适配扩展
技术兼容性测试
Protocol TCK
Registry TCK
公共契约
URL
日志
坏味道
URL转换
调用参数
扩展点的加载
Callback功能
Lazy连接
共享连接
sticky 策略
服务提供者选择逻辑
源码构建
编码约定
检查列表
设计原则
13-1-13 D eveloper G uide-zh - D ubbo - Alibaba O pen S esam e
2/44code.alibabatech.com /w iki/display/dubbo/D eveloper+G uide-zh
参与
(+) (#)
流程
(#)
1. 如果是扩展功能，直接新增工程，黑盒依赖Dubbo进行扩展。
2. 如果是改BUG，或修改框架本身，可以从Dubb的GitHub上Fork工程。
3. 修改后通过Push Request反馈修改。
任务
(#)
功能 分类 优先级 状态 认领者 计划完成时间 进度
《用户指南》翻译 文档 高 未认领 待定 待定 0%
《开发指南》翻译 文档 高 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
扩展点兼容性测试 测试 高 已认领 罗立树 待定 0%
性能基准测试 测试 高 未认领 待定 待定 0%
功能单元测试 测试 高 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
JTA/XA分布式事务 拦截扩展 高 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
Thrift 协议扩展 高 开发完成 闾刚 2012-04-27 90%
ICE 协议扩展 高 未认领 待定 待定 0%
ACE 协议扩展 低 未认领 待定 待定 0%
JSON-RPC 协议扩展 低 未认领 待定 待定 0%
XML-RPC 协议扩展 低 未认领 待定 待定 0%
JSR181&CXF(WebService) 协议扩展 高 开发完成 白文志 2012-04-27 90%
JSR311&JSR339(RestfulWebService) 协议扩展 高 未认领 待定 待定 0%
JMS&ActiveMQ 协议扩展 高 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
Protobuf 序列化扩展 高 调研 朱启恒 2012-02-30 20%
Avro 序列化扩展 低 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
XSocket 传输扩展 低 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
CGLib 动态代理扩展 低 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
JNDI 注册中心扩展 高 未认领 待定 待定 0%
LDAP 注册中心扩展 低 未认领 待定 待定 0%
JSR140&SLP 注册中心扩展 高 未认领 待定 待定 0%
UDDI 注册中心扩展 高 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
JMX 监控中心扩展 高 未认领 待定 待定 0%
SNMP 监控中心扩展 高 未认领 待定 待定 0%
Cacti 监控中心扩展 高 未认领 待定 待定 0%
Nagios 监控中心扩展 高 未认领 待定 待定 0%
Logstash 监控中心扩展 高 未认领 待定 待定 0%
JRobin 监控中心扩展 高 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
Maven 服务安装包仓库 低 未认领 待定 待定 0%
Subversion 服务安装包仓库 低 未认领 待定 待定 0%
JCR/JSR283 服务安装包仓库 低 未认领 待定 待定 0%
功能 分类 优先级 状态 认领者 计划完成时间 进度
13-1-13 D eveloper G uide-zh - D ubbo - Alibaba O pen S esam e
3/44code.alibabatech.com /w iki/display/dubbo/D eveloper+G uide-zh
SimpleDeployer 本地部署代理 低 未认领 待定 待定 0%
SimpleScheduler 资源调度器 低 未认领 待定 待定 0%
版本开发模式
(+) (#)
新功能的开发 和 稳定性的提高 对产品都很重要。
但是添加新功能对影响稳定性，Dubbo使用如下的版本开发模式来保障两者。
2个版本并行开发
BugFix版本，低版本，比如2.4.x。是GA版本，线上使用的版本，只会BugFix，升级第三位版本号。
# 这个版本可放在SVN的Fix分支上。
新功能版本，高版本，比如2.5.x。加新功能的版本，会给对新功能有需求的应用试用。
# 这个版本可放在SVN的Trunk上。
2.5.x的新功能基本稳定后，进入2.5.x试用阶段。找足够多的应用试用2.5.x版本。
在2.5.x够稳定后：
1. 2.5.x成为GA版本，只BugFix，推广使用此版本。
# 如何可行，可以推进应用在期望的时间点内升级到GA版本。
2. 2.4.x不再开发，应用碰到Bug让直接升级。（这个称为“夕阳条款”）
3. 从2.5.x拉成分支2.6.0，作为新功能开发版本。
优势
保持GA版本是稳定的！因为：
只会作BugFix
成为GA版本前有试用阶段
新功能可以高版本中快速响应，并让应用能试用新功能。
不会版本过多，导致开发和维护成本剧增
用户要配合的职责
由于开发只会BugFix GA版本，所以用户需要积极跟进升级到GA版本，以Fix发现的问题。
定期升级版本用户带来了不安。这是一个伪命题，说明如下：
GA经过一个试用阶段保持稳定。
GA版本有Bug会火速Fix
相对出问题才升级到GA版本（可以跨了多个版本）定期升级平摊风险（类似小步快跑）。
经历过周期长的大项目的同学会有这样的经历，三方库版本不时间不升级，结果出了问题不得不升级到新版本（跨了多个版本）风险巨大。
框架设计
(+) (#)
整体设计
13-1-13 D eveloper G uide-zh - D ubbo - Alibaba O pen S esam e
4/44code.alibabatech.com /w iki/display/dubbo/D eveloper+G uide-zh
如果你觉得图过于复杂，请查看：>>框架图绘制步骤动画
图例说明：
图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。
图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service和Config层为API，其它各层均为
SPI。
图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为
调用的方法。
各层说明：
config，配置层，对外配置接口，以ServiceConfig, ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类
proxy，服务代理层，服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory
registry，注册中心层，封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService
cluster，路由层，封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster, Directory, Router, LoadBalance
monitor，监控层，RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService
protocol，远程调用层，封将RPC调用，以Invocation, Result为中心，扩展接口为Protocol, Invoker, Exporter
exchange，信息交换层，封装请求响应模式，同步转异步，以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel, ExchangeClient,
ExchangeServer
transport，网络传输层，抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec
serialize，数据序列化层，可复用的一些工具，扩展接口为Serialization, ObjectInput, ObjectOutput, ThreadPool
关系说明：
在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用
Provider, Consumer, Registry, Monitor划分逻辑拓普节点，保持统一概念。
而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会
造成影响，因为只有一个提供者时，是不需要Cluster的。
Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是
去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只
负责单向消息传输，是对Mina,Netty,Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
模块分包
13-1-13 D eveloper G uide-zh - D ubbo - Alibaba O pen S esam e
5/44code.alibabatech.com /w iki/display/dubbo/D eveloper+G uide-zh
模块说明：
dubbo-common 公共逻辑模块，包括Util类和通用模型。
dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
dubbo-container 容器模块，是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载
服务。
整体上按照分层结构进行分包，与分层的不同点在于：
container为服务容器，用于部署运行服务，没有在层中画出。
protocol层和proxy层都放在rpc模块中，这两层是rpc的核心，在不需要集群时(只有一个提供者)，可以只使用这两层完成rpc调用。
transport层和exchange层都放在remoting模块中，为rpc调用的通讯基础。
serialize层放在common模块中，以便更大程度复用。
依赖关系
图例说明：
图中小方块Protocol, Cluster, Proxy, Service, Container, Registry, Monitor代表层或模块，蓝色的表示与业务有交互，绿色的表示只对Dubbo内部交互。
图中背景方块Consumer, Provider, Registry, Monitor代表部署逻辑拓普节点。
图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。
图中只包含RPC的层，不包含Remoting的层，Remoting整体都隐含在Protocol中。
调用链
展开总设计图的红色调用链，如下：
