- 一、Dubbo的两大设计原则
- 二、三大领域模型
- 三、四大组件
- 二、十层架构
- 1.Business 层
- 2.PRC层
- 3.Remotting 层
- 二、框架架构
第一章Dubbo概述 https://blog.csdn.net/gqs2019/article/details/115366306
第二章 Dubbo系统框架搭建 https://blog.csdn.net/gqs2019/article/details/115370178
第三章 Dubbo高级配置 https://blog.csdn.net/gqs2019/article/details/115403364
第四章 Dubbo的系统架构解析 https://blog.csdn.net/gqs2019/article/details/115456656
第五章Dubbo 的内核解析 https://blog.csdn.net/gqs2019/article/details/115457046
第六章 Dubbo的源码解析 https://blog.csdn.net/gqs2019/article/details/115460065
Double 框架在设计时遵循了两大设计原则：
- Dubbo 使用“微内核+插件”的设计模式。内核只负责组装插件（扩展点），Dubbo 的功能
都是由插件实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展类所替换。 - 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。
为了对 Dubbo 整体架构叙述的方便，Dubbo 抽象出了三大领域模型。
- Protocol 服务域：是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管
理。 - Invoker 实体域：是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表
一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个
远程的实现，也可能一个集群实现。 - Invocation 会话域：它持有调用过程中的变量，比如方法名，参数等。
Dubbo 中存在四大组件：
- Provider：暴露服务方，亦称为服务提供者。
- Consumer：调用远程服务方，亦称为服务消费者。
- Registry：服务注册与发现的中心，提供目录服务，亦称为服务注册中心
- Monitor：统计服务的调用次数、调用时间等信息的日志服务，亦称为服务监控中心
Dubbo 的架构设计划分为了 10 层。图中左边淡蓝色背景为服务 Consumer 使用的接口，
右边淡绿色背景为服务 Provider 使用的接口，位于中轴线的为双方都要用到的接口。对于这
10 层，根据其总体功能划分，可以划分为三大层：
该层仅包含一个 service 服务层，该层与实际业务逻辑有关，根据服务消费方和服务提
供方的业务设计，实现对应的接口。
该层主要负责整个分布式系统中各个主机间的通讯。该层包含了以下 6 层。
（1） config 配置层
以 ServiceConfig 和 ReferenceConfig 为中心，用于加载并解析 Spring 配置文件中的 Dubbo标签。
（2） proxy 服务代理层
服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为
中心，扩展接口为 ProxyFactory。
Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴
露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去
掉 Proxy 层 RPC 是可以运行的，只是不那么透明，不那么看起来像调本地服务一样调远程
服务。
（3） registry 注册中心层
封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、
RegistryService，可能没有服务注册中心，此时服务提供方直接暴露服务。
（4） cluster 路由层
封装多个提供者的路由和负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为
Cluster、Directory、Router 和 LoadBalance，将多个服务提供方组合为一个服务提供方，实现
对服务消费通明。只需要与一个服务提供方进行交互。
Dubbo 官方指出，在 Dubbo 的整体架构中，Cluster 只是一个外围概念。Cluster 的目的
是将多个 Invoker 伪装成一个 Invoker，这样用户只需关注 Protocol 层 Invoker 即可，加上
Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要
Cluster 的。
（5） monitor 监控层
RPC 调用时间和次数监控，以 Statistics 为中心，扩展接口 MonitorFactory、Monitor 和
MonitorService。
（6） protocol 远程调用层
封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocol、Invoker 和 Exporter。
Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
Invoker 是实体域，它是 Dubbo 的核心模型，其他模型都是向它靠拢，或转换成它，它代表
一个可执行体，可向它发起 Invoker 调用，它有可能是一个本地实现，也有可能是一个远程
实现，也有可能是一个集群实现。
在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完
成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
Remoting 实现是 Dubbo 协议的实现，如果我们选择 RMI 协议，整个 Remoting 都不
会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只
负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange
层是在传输层之上封装了 Request-Response 语义。
具体包含以下三层：
（1） exchange 信息交换层
封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger
和 ExchangeChannel,ExchangeClient 和 ExchangeServer。
（2） transport 网络传输层
抽象和 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、
Client、Server 和 Codec。
（3） serialize 数据序列化层
可复用的一些工具，扩展接口为 Serialization、ObjectInput、ObejctOutput 和 ThreadPool。
将 Dubbo 源码工程导入 Idea
本例以 Dubbo2.7.3 为例进行源码解析。从官网下载到源码的 zip 包后解压后就可以直接
导入到 Idea 中。
Dubbo2.7 版本与 2.6 版本
Dubbo2.7 版本需要 Java 8 及以上版本。
2.7.0 版本在改造的过程中遵循了一个原则，即保持与低版本的兼容性，因此从功能层
面来说它是与 2.6.x 及更低版本完全兼容的。2.7 与 2.6 版本相比，改动最大的就是包名，由
原来的 com.alibaba.dubbo 改为了 org.apache.dubbo。
以下内容均来自,开课吧老雷,感谢老雷
第一章Dubbo概述 https://blog.csdn.net/gqs2019/article/details/115366306
第二章 Dubbo系统框架搭建 https://blog.csdn.net/gqs2019/article/details/115370178
第三章 Dubbo高级配置 https://blog.csdn.net/gqs2019/article/details/115403364
第四章 Dubbo的系统架构解析 https://blog.csdn.net/gqs2019/article/details/115456656
第五章Dubbo 的内核解析 https://blog.csdn.net/gqs2019/article/details/115457046
第六章 Dubbo的源码解析 https://blog.csdn.net/gqs2019/article/details/115460065
