以下内容全文转自 apache 官方 dubbo文档：http://dubbo.apache.org/en-us/docs/dev/design.html
框架设计
图片描述：
- 浅蓝色背景的左侧区域显示服务用户界面，浅绿色背景的右侧区域显示服务提供者界面，中心区域显示两个侧面界面。
- 图像从底部到顶部分为10层，这些层是单向依赖的。右侧的黑色箭头表示层之间的依赖关系，每层可以从上层剥离以重复使用，Service和Config层是API，其他层是SPI。
- 绿框是扩展接口，蓝框是实现类，图像仅显示关联层的实现类。
- 蓝色虚线是初始化过程，启动时为装配链，方法调用过程为红线，运行时调用链，继承紫色三角箭头，可将子类视为父类的同一节点，文本为lines是方法调用。
图层描述
- config层：外部配置界面，
ServiceConfig并且ReferenceConfig是图层的中心，可以直接初始化配置类，也可以通过spring生成配置类。 - 代理层：服务接口的透明代理，生成客户端Stub服务和服务器Skeletion of service，
ServiceProxy是中心，扩展接口是ProxyFactory。 - 注册表层：服务注册表和发现的封装，服务URL是中心，扩展接口是
RegistryFactory，Registry和RegistryService。 - 簇层：muliple提供商和负载平衡，和桥接登记中心的簇的封装，
Invoker是中心，扩展接口是Cluster，Directory，Router，LoadBalance。 - 监控层：的RPC调用倍显示器和呼叫执行时间，
Statistics是中心，扩展接口是MonitorFactory，Monitor，MonitorService - 协议层：RPC的封装，
Invocation并且Result是中心，扩展接口是Protocol，Invoker，Exporter - 交换层：的请求和响应，同步传输异步封装，
Request并且Response是中心，扩展接口是Exchanger，ExchangeChannel，ExchangeClient，ExchangeServer - 传输层：米娜和网状的抽象，
Message是中心，扩展接口是Channel，Transporter，Client，Server，Codec - 序列化层：可重复使用的工具，扩展接口
Serialization，ObjectInput，ObjectOutput，ThreadPool
关系描述
- 在RPC中，Protocol是核心层，它意味着您可以通过Protocol + Invoker + Exporter完成RPC调用，然后在Invoker的主进程中进行过滤。
- Consumer和Provider是抽象概念，只是希望您能更直观地了解哪些类属于客户端和服务器端，不使用Client和Server的原因是Dubbo使用Provider，Consumer，Registry，Monitor划分逻辑拓扑节点。场景，保持团结的概念。
- Cluster是外部概念，Cluster的目的是让各种Invoker伪装成一个Invoker，这样我们只关注Invoker in Protocol层，添加Cluster或删除Cluster不会影响其他层，因为我们不需要Cluster什么时候只有一个提供者。
- Proxy层封装了所有接口的透明代理，在Invoker作为中心的其他层中，将Invoker转换为接口，或者仅在暴露给用户时将接口实现转换为Invoker by Proxy。RPC仍然可以工作，甚至删除代理层，但不是那么透明，使得远程服务调用看起来不像本地服务调用。
- 远程处理是Dubbo协议的实现，如果选择RMI，您可以删除远程处理。Remoting分为Transport层和Exchange层，Transport层负责单向消息传输，它是Mina，Netty，Grizzly的抽象，它还可以扩展UDP传输。Exchange层在传输层上封装了Request-Response语义。
- 实际上Registry和Monitor不在同一层，它们是独立的节点，只是为了全局视图而一层一层地绘制它们。
模块包装
模块说明：
- dubbo-common模块：包括Util类和通用模块。
- dubbo-remoting模块：是Dubbo协议实现，如果使用RMI for RPC则无需使用此模块。
- dubbo-rpc模块：各种协议的抽象，和动态代理，只有一对一的调用，不关心集群的管理。
- dubbo-cluster模块：将许多服务提供者伪装成一个提供者，包括负载平衡，容错，路由等。群集的地址列表可以是静态的，也可以是注册表发送的。
- dubbo-registry模块：基于注册表发送地址的集群和各种注册中心的抽象。
- dubbo-monitor模块：服务呼叫时间统计，呼叫时间，呼叫链跟踪服务。
- dubbo-config模块：是Dubbo外部API，用户使用Dubbo by Config，隐藏Dubbo的详细信息。
- dubbo-container模块：是一个Standlone容器，只需使用Main方法加载Spring，因为通常服务不需要Tomcat / JBoss功能。
包层根据层结构划分，与层划分的区别：
- 容器是服务容器，用于服务运行部署，未在映像中显示。
- 协议层和代理层都放在RPC模块中，它们是RPC模块的核心，当只有1个提供者时，可以使用这2层完整的RPC调用。
- 传输层和交换层放置在远程模块中，用于RPC呼叫基础通信。
- 序列化层放在通用模块中，以便重用。
依赖关系
图片描述：
- 图像，协议，群集，代理，服务，容器，注册表，监视器中的框表示层或模块，蓝调表示与业务交互，绿色表示仅与Dubbo的内部交互。
- 图像，消费者，提供者，注册表，监视器中的背景框表示部署逻辑拓扑节点。
- 调用图像中的蓝色虚线进行初始化，为运行时异步调用红色虚线，并为运行时同步调用红线。
- 图像仅包含RPC层，不包括Remoting层，整个Remoting隐藏在Protocol层中。
调用链
展开整个设计地图的红色调用链：
公开服务顺序
展开服务提供者公开服务的初始化链，在整个设计图的左侧，序列图如下所示：
参考服务序列
展开服务使用者参考服务的初始化链，在整个设计图的右侧，序列图如下所示：
领域模型
达博的核心领域模型：
- 协议是服务域，它是Invoker暴露和参考的主要功能入口，它负责Invoker的生命周期管理。
- Invoker是实体域，它是Dubbo的核心模型，所有其他模型都受到干扰，或转换为它，它代表一个可执行文件，你可以通过调用invoke来调用它，它可以是一个本地实现，一个远程实现，或者集群实现。
- 调用是会话域，它在调用进程中保存变量，例如方法名称，参数等。
基本设计原则
- 使用Microkernel + Plugin设计模式，Microkernel只负责组装插件，Dubbo的功能是通过扩展点实现的，这意味着Dubbo的所有功能都可以被用户自定义扩展替换。
- 使用URL作为配置信息的startdard格式，所有扩展点都通过URL传输配置信息。
