知道了这些内容，闭着眼面试Dubbo！(2)

doExportUrls 方法

doExportUrlsFor1Protocol 方法-1

doExportUrlsFor1Protocol 方法-2

上面截取了服务提供者暴露服务的代码片段，从注释上看整个暴露过程分为七个步骤：

读取其他配置信息到 map 中，用来后面构造 URL。

读取全局配置信息。

配置不是 remote，也就是暴露本地服务。

如果配置了监控地址，则服务调用信息会上报。

通过 Proxy 转化成 Invoker，RegistryURL 存放的是注册中心的地址。

暴露服务以后，向注册中心注册服务信息。

没有注册中心直接暴露服务。

一旦服务注册到注册中心以后，注册中心会通过 RegistryProtocol 中的 Export 方法将服务暴露出去，并依次做以下操作：

委托具体协议进行服务暴露，创建 NettyServer 监听端口，并保持服务实例。

创建注册中心对象，创建对应的 TCP 连接。

注册元数据到注册中心。

订阅 Configurators 节点。

如果需要销毁服务，需要关闭端口，注销服务信息。

说完了服务提供者的暴露再来看看服务消费者。

服务消费者消费服务机制

服务消费者首先持有远程服务实例生成的 Invoker，然后把 Invoker 转换成用户接口的动态代理引用。

框架进行服务引用的入口点在 ReferenceBean 中的 getObject 方法，会将实体转换成 ReferenceBean，它是集成与 ReferenceConfig 类的。

这里一起来看看 createProxy 的源代码：

getProxy 代码片段 1

getProxy 代码片段 2

从上面代码片段可以看出，消费者服务在调用服务提供者时，做了以下动作：

检查是否是同一个 JVM 内部引用。

如果是同一个 JVM 的引用，直接使用 injvm 协议从内存中获取实例。

注册中心地址后，添加 refer 存储服务消费元数据信息。

单注册中心消费。

依次获取注册中心的服务，并且添加到 Invokers 列表中。

通过 Cluster 将多个 Invoker 转换成一个 Invoker。

把 Invoker 转换成接口代理。

注册中心

说完服务暴露，再回头来看看注册中心。Dubbo 通过注册中心实现了分布式环境中服务的注册和发现。

配置中心

其主要作用如下：

动态载入服务。服务提供者通过注册中心，把自己暴露给消费者，无须消费者逐个更新配置文件。

动态发现服务。消费者动态感知新的配置，路由规则和新的服务提供者。

参数动态调整。支持参数的动态调整，新参数自动更新到所有服务节点。

服务统一配置。统一连接到注册中心的服务配置。

配置中心工作流

注册调用流程图

先看看注册中心调用的流程图：

提供者(Provider)启动时，会向注册中心写入自己的元数据信息(调用方式)。

消费者(Consumer)启动时，也会在注册中心写入自己的元数据信息，并且订阅服务提供者，路由和配置元数据的信息。

服务治理中心(duubo-admin)启动时，会同时订阅所有消费者，提供者，路由和配置元数据的信息。

当提供者离开或者新提供者加入时，注册中心发现变化会通知消费者和服务治理中心。

注册中心工作原理

Dubbo 有四种注册中心的实现，分别是 ZooKeeper，Redis，Simple 和 Multicast。

这里着重介绍一下 ZooKeeper 的实现。ZooKeeper 是负责协调服务式应用的。

它通过树形文件存储的 ZNode 在 /dubbo/Service 目录下面建立了四个目录，分别是：

Providers 目录下面，存放服务提供者 URL 和元数据。

Consumers 目录下面，存放消费者的 URL 和元数据。

Routers 目录下面，存放消费者的路由策略。

Configurators 目录下面，存放多个用于服务提供者动态配置 URL 元数据信息。

客户端第一次连接注册中心的时候，会获取全量的服务元数据，包括服务提供者和服务消费者以及路由和配置的信息。

根据 ZooKeeper 客户端的特性，会在对应 ZNode 的目录上注册一个 Watcher，同时让客户端和注册中心保持 TCP 长连接。

如果服务的元数据信息发生变化，客户端会接受到变更通知，然后去注册中心更新元数据信息。变更时根据 ZNode 节点中版本变化进行。

Dubbo 集群容错

（编辑：ASP站长网）