欢迎大家关注 github.com/hsfxuebao ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈
1. Dubbo 的两大设计原则
Dubbo 框架在设计时遵循了两大设计原则：
-
Dubbo 使用
“微内核+插件”的设计模式。内核只负责组装插件（扩展点）， Dubbo 的功能都是由插件实现的。 Dubbo 作为一个优秀的 RPC 框架，一个 Apache 的顶级项目，其最大的亮点之一就是其优秀的无限开放性设计架构—“微内核+插件”的架构设计思想，使得其几乎所有组件均可方便的进行扩展、增强、替换。 -
采用 URL 作为配置信息的统一格式，
所有扩展点都通过传递 URL 携带配置信息。
2. Dubbo 的三大领域模型
为了对 Dubbo 整体架构叙述的方便， Dubbo 抽象出了三大领域模型。
-
Protocol 服务域： 是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。 -
Invoker 实体域： 是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。 -
Invocation 会话域： 它持有调用过程中的变量，比如方法名，参数等。
3. 四大组件
Provider： 暴露服务方，亦称为服务提供者。Consumer： 调用远程服务方，亦称为服务消费者。Registry： 服务注册与发现的中心，提供目录服务，亦称为服务注册中心Monitor： 统计服务的调用次数、调用时间等信息的日志服务，亦称为服务监控中心
4. 十层架构
注意，该 10 层架构图为 2.7 版本的， 3.0 版本官方没有给出类似架构图。 3.0 版本与 2.7 版本还是发生了不少变化的。
Dubbo 的架构设计划分为了 10 层。图中左边淡蓝色背景为服务 Consumer 使用的接口， 右边淡绿色背景为服务 Provider 使用的接口，位于中轴线的为双方都要用到的接口。 对于这10 层，根据其总体功能划分，可以划分为三大层。
4.1 Business 层
该层仅包含一个 service 服务层， 该层与实际业务逻辑有关，根据服务消费方和服务提供方的业务设计，实现对应的接口。
4.2 RPC 层
该层主要负责整个分布式系统中各个主机间的通讯。该层包含了以下 6 层。
config 配置层
以 ServiceConfig 和 ReferenceConfig 为中心， 用于加载并解析 Spring 配置文件中的 Dubbo 标签。
proxy 服务代理层
服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory。
Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker， 也就是去掉 Proxy 层 RPC 是可以运行的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
registry 注册中心层
封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、 Registry、 RegistryService，可能没有服务注册中心，此时服务提供方直接暴露服务。
cluster 路由层
封装多个提供者的路由和负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为Cluster、 Directory、 Router 和 LoadBalance，将多个服务提供方组合为一个服务提供方，实现 对服务消费通明。只需要与一个服务提供方进行交互。
Dubbo 官方指出，在 Dubbo 的整体架构中， Cluster 只是一个外围概念。 Cluster 的目的 是将多个 Invoker 伪装成一个 Invoker，这样用户只需关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster 的。
monitor 监控层
RPC 调用时间和次数监控，以 Statistics 为中心，扩展接口 MonitorFactory、 Monitor 和 MonitorService。
protocol 远程调用层
封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocol、Invoker 和 Exporter。Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
Invoker 是实体域，它是 Dubbo 的核心模型，其他模型都是向它靠拢，或转换成它，它代表一个可执行体，可向它发起 Invoker 调用，它有可能是一个本地实现，也有可能是一个远程实现，也有可能是一个集群实现。
在 RPC 中， Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完 成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
4.3 Remotting 层
Remoting 实现是 Dubbo 协议的实现，如果我们选择 RMI 协议，整个 Remoting 都不会用上， Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层， Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了 Request-Response 语义。具体包含以下三层：
exchange 信息交换层
封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger 和 ExchangeChannel,ExchangeClient 和 ExchangeServer。
transport 网络传输层
抽象和 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、 Client、 Server 和 Codec。
serialize 数据序列化层
可复用的一些工具，扩展接口为 Serialization、 ObjectInput、 ObejctOutput 和 ThreadPool。
5. 将 Dubbo 源码工程导入 Idea
github下载地址：github.com/apache/dubb…
本例以 Dubbo3.0.0 为例进行源码解析。从官网下载到源码的 zip 包后解压后就可以直接 导入到 Idea 中。
5.1 模块说明
模块说明：
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 容器去加载服务。dubbo-demo: demo例子模块，可以按照这个进行学习。