42 加餐：服务引用流程全解析 Dubbo 作为一个 RPC 框架，暴露给用户最基本的功能就是服务发布和服务引用。在上一课时，我们已经分析了服务发布的核心流程。那么在本课时，我们就接着深入分析服务引用的核心流程。
Dubbo 支持两种方式引用远程的服务：
- 服务直连的方式，仅适合在调试服务的时候使用；
- 基于注册中心引用服务，这是生产环境中使用的服务引用方式。
DubboBootstrap 入口
在上一课时介绍服务发布的时候，我们介绍了 DubboBootstrap.start() 方法的核心流程，其中除了会调用 exportServices() 方法完成服务发布之外，还会调用 referServices() 方法完成服务引用，这里就不再贴出 DubboBootstrap.start() 方法的具体代码，你若感兴趣的话可以参考源码进行学习。
在 DubboBootstrap.referServices() 方法中，会从 ConfigManager 中获取所有 ReferenceConfig 列表，并根据 ReferenceConfig 获取对应的代理对象，入口逻辑如下： private void referServices() { if (cache == null) { // 初始ReferenceConfigCache cache = ReferenceConfigCache.getCache(); } configManager.getReferences().forEach(rc -> { // 遍历ReferenceConfig列表 ReferenceConfig referenceConfig = (ReferenceConfig) rc; referenceConfig.setBootstrap(this); if (rc.shouldInit()) { // 检测ReferenceConfig是否已经初始化 if (referAsync) { // 异步 CompletableFuture
这里的 ReferenceConfig 是哪里来的呢？在[第 01 课时]dubbo-demo-api-consumer 示例中，我们可以看到构造 ReferenceConfig 对象的逻辑，这些新建的 ReferenceConfig 对象会通过 DubboBootstrap.reference() 方法添加到 ConfigManager 中进行管理，如下所示：
public DubboBootstrap reference(ReferenceConfig<?> referenceConfig) { configManager.addReference(referenceConfig); return this; }
ReferenceConfigCache
服务引用的核心实现在 ReferenceConfig 之中，一个 ReferenceConfig 对象对应一个服务接口，每个 ReferenceConfig 对象中都封装了与注册中心的网络连接，以及与 Provider 的网络连接，这是一个非常重要的对象。
为了避免底层连接泄漏造成性能问题，从 Dubbo 2.4.0 版本开始，Dubbo 提供了 ReferenceConfigCache 用于缓存 ReferenceConfig 实例。
在 dubbo-demo-api-consumer 示例中，我们可以看到 ReferenceConfigCache 的基本使用方式：
ReferenceConfig
在 ReferenceConfigCache 中维护了一个静态的 Map（CACHE_HOLDER）字段，其中 Key 是由 Group、服务接口和 version 构成，Value 是一个 ReferenceConfigCache 对象。在 ReferenceConfigCache 中可以传入一个 KeyGenerator 用来修改缓存 Key 的生成逻辑，KeyGenerator 接口的定义如下：
public interface KeyGenerator { String generateKey(ReferenceConfigBase<?> referenceConfig); }
默认的 KeyGenerator 实现是 ReferenceConfigCache 中的匿名内部类，其对象由 DEFAULT_KEY_GENERATOR 这个静态字段引用，具体实现如下：
public static final KeyGenerator DEFAULT_KEY_GENERATOR = referenceConfig -> { String iName = referenceConfig.getInterface(); if (StringUtils.isBlank(iName)) { // 获取服务接口名称 Class<?> clazz = referenceConfig.getInterfaceClass(); iName = clazz.getName(); } if (StringUtils.isBlank(iName)) { throw new IllegalArgumentException(“No interface info in ReferenceConfig” + referenceConfig); } // Key的格式是group/interface:version StringBuilder ret = new StringBuilder(); if (!StringUtils.isBlank(referenceConfig.getGroup())) { ret.append(referenceConfig.getGroup()).append(“/”); } ret.append(iName); if (!StringUtils.isBlank(referenceConfig.getVersion())) { ret.append(“:”).append(referenceConfig.getVersion()); } return ret.toString(); };
在 ReferenceConfigCache 实例对象中，会维护下面两个 Map 集合。
- proxies（ConcurrentMap, ConcurrentMap>类型）：该集合用来存储服务接口的全部代理对象，其中第一层 Key 是服务接口的类型，第二层 Key 是上面介绍的 KeyGenerator 为不同服务提供方生成的 Key，Value 是服务的代理对象。
- referredReferences（ConcurrentMap> 类型）：该集合用来存储已经被处理的 ReferenceConfig 对象。
我们回到 DubboBootstrap.referServices() 方法中，看一下其中与 ReferenceConfigCache 相关的逻辑。
首先是 ReferenceConfigCache.getCache() 这个静态方法，会在 CACHE_HOLDER 集合中添加一个 Key 为“/DEFAULT/”的 ReferenceConfigCache 对象（使用默认的 KeyGenerator 实现），它将作为默认的 ReferenceConfigCache 对象。
接下来，无论是同步服务引用还是异步服务引用，都会调用 ReferenceConfigCache.get() 方法，创建并缓存代理对象。下面就是 ReferenceConfigCache.get() 方法的核心实现：
public
ReferenceConfig
通过前面的介绍我们知道，ReferenceConfig 是服务引用的真正入口，其中会创建相关的代理对象。下面先来看 ReferenceConfig.get() 方法： public synchronized T get() { if (destroyed) { // 检测当前ReferenceConfig状态 throw new IllegalStateException(“…”); } if (ref == null) {// ref指向了服务的代理对象 init(); // 初始化ref字段 } return ref; }
在 ReferenceConfig.init() 方法中，首先会对服务引用的配置进行处理，以保证配置的正确性。这里的具体实现其实本身并不复杂，但由于涉及很多的配置解析和处理逻辑，代码就显得非常长，我们就不再一一展示，你若感兴趣的话可以参考源码进行学习。
ReferenceConfig.init() 方法的核心逻辑是调用 createProxy() 方法，调用之前会从配置中获取 createProxy() 方法需要的参数： public synchronized void init() { if (initialized) { // 检测ReferenceConfig的初始化状态 return; } if (bootstrap == null) { // 检测DubboBootstrap的初始化状态 bootstrap = DubboBootstrap.getInstance(); bootstrap.init(); } … // 省略其他配置的检查 Map<String, String> map = new HashMap<String, String>(); map.put(SIDE_KEY, CONSUMER_SIDE); // 添加side参数 // 添加Dubbo版本、release参数、timestamp参数、pid参数 ReferenceConfigBase.appendRuntimeParameters(map); // 添加interface参数 map.put(INTERFACE_KEY, interfaceName); … // 省略其他参数的处理 String hostToRegistry = ConfigUtils.getSystemProperty(DUBBO_IP_TO_REGISTRY); if (StringUtils.isEmpty(hostToRegistry)) { hostToRegistry = NetUtils.getLocalHost(); } else if (isInvalidLocalHost(hostToRegistry)) { throw new IllegalArgumentException(“…”); } // 添加ip参数 map.put(REGISTER_IP_KEY, hostToRegistry); // 调用createProxy()方法 ref = createProxy(map); …// 省略其他代码 initialized = true; // 触发ReferenceConfigInitializedEvent事件 dispatch(new ReferenceConfigInitializedEvent(this, invoker)); }
ReferenceConfig.createProxy() 方法中处理了多种服务引用的场景，例如，直连单个/多个Provider、单个/多个注册中心。下面是 createProxy() 方法的核心流程，大致可以梳理出这么 5 个步骤。
- 根据传入的参数集合判断协议是否为 injvm 协议，如果是，直接通过 InjvmProtocol 引用服务。
- 构造 urls 集合。Dubbo 支持直连 Provider和依赖注册中心两种服务引用方式。如果是直连服务的模式，我们可以通过 url 参数指定一个或者多个 Provider 地址，会被解析并填充到 urls 集合；如果通过注册中心的方式进行服务引用，则会调用 AbstractInterfaceConfig.loadRegistries() 方法加载所有注册中心。
- 如果 urls 集合中只记录了一个 URL，通过 Protocol 适配器选择合适的 Protocol 扩展实现创建 Invoker 对象。如果是直连 Provider 的场景，则 URL 为 dubbo 协议，这里就会使用 DubboProtocol 这个实现；如果依赖注册中心，则使用 RegistryProtocol 这个实现。
- 如果 urls 集合中有多个注册中心，则使用 ZoneAwareCluster 作为 Cluster 的默认实现，生成对应的 Invoker 对象；如果 urls 集合中记录的是多个直连服务的地址，则使用 Cluster 适配器选择合适的扩展实现生成 Invoker 对象。
- 通过 ProxyFactory 适配器选择合适的 ProxyFactory 扩展实现，将 Invoker 包装成服务接口的代理对象。
通过上面的流程我们可以看出createProxy() 方法中有两个核心：一是通过 Protocol 适配器选择合适的 Protocol 扩展实现创建 Invoker 对象；二是通过 ProxyFactory 适配器选择合适的 ProxyFactory 创建代理对象。
下面我们来看 createProxy() 方法的具体实现：
private T createProxy(Map<String, String> map) { if (shouldJvmRefer(map)) { // 根据url的协议、scope以及injvm等参数检测是否需要本地引用 // 创建injvm协议的URL URL url = new URL(LOCAL_PROTOCOL, LOCALHOST_VALUE, 0, interfaceClass.getName()).addParameters(map); // 通过Protocol的适配器选择对应的Protocol实现创建Invoker对象 invoker = REF_PROTOCOL.refer(interfaceClass, url); if (logger.isInfoEnabled()) { logger.info(“Using injvm service “ + interfaceClass.getName()); } } else { urls.clear(); if (url != null && url.length() > 0) { String[] us = SEMICOLON_SPLIT_PATTERN.split(url); // 配置多个URL的时候，会用分号进行切分 if (us != null && us.length > 0) { // url不为空，表明用户可能想进行点对点调用 for (String u : us) { URL url = URL.valueOf(u); if (StringUtils.isEmpty(url.getPath())) { url = url.setPath(interfaceName); // 设置接口完全限定名为URL Path } if (UrlUtils.isRegistry(url)) { // 检测URL协议是否为registry，若是，说明用户想使用指定的注册中心 // 这里会将map中的参数整理成一个参数添加到refer参数中 urls.add(url.addParameterAndEncoded(REFER_KEY, StringUtils.toQueryString(map))); } else { // 将map中的参数添加到url中 urls.add(ClusterUtils.mergeUrl(url, map)); } } } } else { if (!LOCAL_PROTOCOL.equalsIgnoreCase(getProtocol())) { checkRegistry(); // 加载注册中心的地址RegistryURL List
RegistryProtocol
在直连 Provider 的场景中，会使用 DubboProtocol.refer() 方法完成服务引用，DubboProtocol.refer() 方法的具体实现在前面[第 25 课时]中已经详细介绍过了，这里我们重点来看存在注册中心的场景中，Dubbo Consumer 是如何通过 RegistryProtocol 完成服务引用的。
在 RegistryProtocol.refer() 方法中，会先根据 URL 获取注册中心的 URL，再调用 doRefer 方法生成 Invoker，在 refer() 方法中会使用 MergeableCluster 处理多 group 引用的场景。
public
在 doRefer() 方法中，首先会根据 URL 初始化 RegistryDirectory 实例，然后生成 Subscribe URL 并进行注册，之后会通过 Registry 订阅服务，最后通过 Cluster 将多个 Invoker 合并成一个 Invoker 返回给上层，具体实现如下：
private
这里涉及的 RegistryDirectory、Router 接口、Cluster 接口及其相关的扩展实现，我们都已经在前面的课时详细分析过了，这里不再重复。
总结
本课时，我们重点介绍了 Dubbo 服务引用的整个流程。
- 首先，我们介绍了 DubboBootStrap 这个入口门面类与服务引用相关的方法，其中涉及 referServices()、reference() 等核心方法。
- 接下来，我们分析了 ReferenceConfigCache 这个 ReferenceConfig 对象缓存，以及 ReferenceConfig 实现服务引用的核心流程。
- 最后，我们还讲解了 RegistryProtocol 从注册中心引用服务的核心实现。
参考资料
https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/Dubbo%e6%ba%90%e7%a0%81%e8%a7%a3%e8%af%bb%e4%b8%8e%e5%ae%9e%e6%88%98-%e5%ae%8c/42%20%20%e5%8a%a0%e9%a4%90%ef%bc%9a%e6%9c%8d%e5%8a%a1%e5%bc%95%e7%94%a8%e6%b5%81%e7%a8%8b%e5%85%a8%e8%a7%a3%e6%9e%90.md
更多学习
更多实时资讯，前沿技术，生活趣事。尽在【老马啸西风】
交流社群：[交流群信息](https://mp.weixin.qq.com/s/rkSvXxiiLGjl3S-ZOZCr0Q)
