基于3.0.5版本
整体架构
- Provider：服务提供方；
- Consumer：服务消费方；
- Registry：服务注册与发现的注册中心；
- Container：服务运行容器；
- Monitor：统计服务的调用次数、调用时间 的监控中心。
SPI机制
jdk：SPI，即 Service Provider Interface。在面向对象的设计里面，模块之间推荐基于接口编程，而不是对实现类进行硬编码，这样做也是为了模块设计的可插拔原则。比较典型的应用，如 JDBC，Java 定义了一套 JDBC 的接口，但是 Java 本身并不提供对 JDBC 的实现类，而是开发者根据项目实际使用的数据库来选择驱动程序 jar 包，比如 mysql，你就将 mysql-jdbc-connector.jar 引入进来；oracle，你就将 oracle-jdbc-connector.jar 引入进来。在系统跑的时候，碰到你使用 jdbc 的接口，他会在底层使用你引入的那个 jar 中提供的实现类。
dubbo 自己实现了一套 SPI 机制，并对 JDK 的 SPI 进行了改进。
- JDK 标准的 SPI 只能通过遍历来查找扩展点和实例化，有可能导致一次性加载所有的扩展点，如果不是所有的扩展点都被用到，就会导致资源的浪费。dubbo 每个扩展点都有多种实现，例如：com.alibaba.dubbo.rpc.Protocol 接口有 InjvmProtocol、DubboProtocol、RmiProtocol、HttpProtocol、HessianProtocol 等实现，如果只是用到其中一个实现，可是加载了全部的实现，会导致资源的浪费。
- 对配置文件中扩展实现的格式的修改，例如，META-INF/dubbo/com.xxx.Protocol 里的 com.foo.XxxProtocol 格式 改为了 xxx = com.foo.XxxProtocol 这种以键值对的形式，这样做的目的是为了让我们更容易的定位到问题。比如，由于第三方库不存在，无法初始化，导致无法加载扩展点（“A”），当用户配置使用 A 时，dubbo 就会报无法加载扩展点的错误，而不是报哪些扩展点的实现加载失败以及错误原因，这是因为原来的配置格式没有记录扩展名的 id，导致 dubbo 无法抛出较为精准的异常，这会加大排查问题的难度。所以改成 key-value 的形式来进行配置。
- dubbo 的 SPI 机制增加了对 IOC、AOP 的支持，一个扩展点可以直接通过 setter 注入到其他扩展点
首先看一下 SPI 注解。在某个接口上加上 @SPI 注解后，表明该接口为可扩展接口。比如，协议扩展接口 Protocol，如果使用者在 <dubbo:protocol />、<dubbo:service />、<dubbo:reference /> 都没有指定 protocol 属性 的话，那么就默认使用 DubboProtocol 作为接口 Protocol 的实现，因为在 Protocol 上有 @SPI("dubbo")注解。而这个 protocol 属性值 或者默认值会被当作该接口的实现类中的一个 key，dubbo 会去 META-INF.dubbo.internal 下的 com.alibaba.dubbo.rpc.Protocol 文件中找该 key 对应的 value，源码如下。
负责均衡实现及解析
dubbo作为分布式远程调用框架，要保证的点很多，如：服务注册与发现，故障转移，高性能通讯，负载均衡等等。
Dubbo内置了负载均衡策略:
RandomLoadBalance:随机负载均衡。随机的选择一个。是Dubbo的默认负载均衡策略。
RoundRobinLoadBalance：轮询负载均衡。轮询选择一个
LeastActiveLoadBalance:最少活跃调用数，相同活跃数的随机。活跃数指调用前后计数差。使慢的 Provider 收到更少请求，因为越慢的 Provider 的调用前后计数差会越大。
ConsistentHashLoadBalance:一致性哈希负载均衡。相同参数的请求总是落在同一台机器上。
ShortestResponseLoadBalance：根据相应时间策略注册中心
dubbo注册中心在dubbo-registry工程下，实现了dns，kubernetes,multicast,multiple,nacos,xds,zookeeper，公共的dubbo-registry-api包下
RegistryService 接口：
RegistryService 是注册中心模块的服务接口，定义了注册、取消注册、订阅、取消订阅以及查询符合条件的已注册数据 等方法。这里统一说明一下 URL，dubbo 是以总线模式来时刻传递和保存配置信息的，配置信息都被放在 URL 上进行传递，随时可以取得相关配置信息，而这里提到了 URL 有别的作用，就是作为类似于节点的作用，首先服务提供者（Provider）启动时需要提供服务，就会向注册中心写下自己的 URL 地址。然后消费者启动时需要去订阅该服务，则会订阅 Provider 注册的地址，并且消费者也会写下自己的 URL。
dubbo://10.20.153.10/com.alibaba.foo.BarService?version=1.0.0&application=kylin
AbstractRegistry接口:
实现了 Registry 接口的抽象类。为了减轻注册中心的压力，该抽象类把本地 URL 缓存到了 property 文件中，并且实现了注册中心的注册、订阅等方法。
// 已注册 URL 集合。
private final Set<URL> registered = new ConcurrentHashSet<>();
//订阅 URL 的监听器集合
private final ConcurrentMap<URL, Set<NotifyListener>> subscribed = new ConcurrentHashMap<>();
//被通知的 URL 集合
private final ConcurrentMap<URL, Map<String, List<URL>>> notified = new ConcurrentHashMap<>();FailbackRegistry 抽象类 继承了上面的 AbstractRegistry，AbstractRegistry 中的注册、订阅等方法，实际上就是一些内存缓存的变化，而真正的注册订阅的实现逻辑在 FailbackRegistry 实现，并且 FailbackRegistry 提供了失败重试的机制。
RegistryFactory 接口 是 Registry 的工厂接口，用来返回 Registry 实例。该接口是一个可扩展接口，可以看到该接口上有个@SPI 注解，并且默认值为 dubbo，也就是默认扩展的是 DubboRegistryFactory。AbstractRegistryFactory 则是实现了 RegistryFactory 接口 的抽象类。
ZookeeperRegistry ，ZookeeperRegistryFactory
下图展示了 dubbo 在 zookeeper 中存储的形式以及节点层级。dubbo 的 Root 层是根目录，通过<dubbo:registry group="dubbo" />的“group”来设置 zookeeper 的根节点，缺省值是“dubbo”。Service 层是服务接口的全名。Type 层是分类，一共有四种分类，分别是 providers 服务提供者列表、consumers 服务消费者列表、routes 路由规则列表、configurations 配置规则列表。URL 层 根据不同的 Type 目录：可以有服务提供者 URL 、服务消费者 URL 、路由规则 URL 、配置规则 URL 。不同的 Type 关注的 URL 不同。