阅读说明

为了更好的阅读体验，将一些特殊符号约定特作说明：

类型 说明
// ...... 常用于代码片段，表示此处有省略部分代码。
使用此标记的出发点是，防止大批量复制非关键代码，影响阅读效率

整个分析流程基于 Dubbo 官方源码 3.0 分支，使用示例项目为 dubbo-demo/dubbo-demo-triple，采用源码编译的方式运行。
由于 Dubbo 3.0 使用到了 IDL 语言（例如 Protobuf）来生成接口类和 POJO 定义，所以在运行之前需要先在根目录手动执行 mvn compile， 以便生成相应的定义文件。

RPC 演进

记得刚开始接触编程那会，主流还是单体应用，服务 A 想要调用服务 B，直接就是函数间的调用。
image.png
后来应用慢慢变大，一些单体应用开始按照功能进行拆分，例如拆分成了订单和用户，通过 HTTP 接口进行交互，此时会在应用 A 配置文件里，提前放置应用 B 的访问地址。
image.png
再后来，应用越来越大，越拆越多，FunctionA 想要知道 FunctionB 在哪里需要繁杂的配置，交叉的网络给运维和伸缩拓展带来巨大挑战，于是乎架构师们引入了“服务注册中心”，作为应用间的引路人。
image.png
阶段三也是目前主流服务治理框架，例如 Dubbo 的原始模型结构。当然，真到了工业实践层面，会有大量细节需要处理，差不得毫厘。

Dubbo 核心流程

这是网上流传最广 Dubbo 架构图，出自官网，从 Dubbo 2.0 到 3.0，这个基础架构一直是稳定不变的。
想要深入了解 Dubbo，第一步得先了解他最核心的流程：服务暴露-服务调用 流程（即下图的上半三角）
image.png

我们以模块为粒度，对服务暴露-调用流程做初步细化，便看到如下架构，接下来我们将顺藤摸瓜，一步步解构 Dubbo 3.0。
image.png

  • 其中：启动流程管理 = DubboBootstrap 单例类，拓展管理 = ExtensionLoader 单例类，配置管理 = ApplicationModel 单例类

参考资料