1.服务导出过程 本篇文章，我们来研究一下 Dubbo 导出服务的过程。Dubbo 服务导出过程始于 Spring 容器发布刷新事件，Dubbo 在接收到事件后，会立即执行服务导出逻辑。整个逻辑大致可分为三个部分，第一是前置工作，主要用于检查参数，组装 URL。第二是导出服务，包含导出服务到本地 (JVM)，和导出服务到远程两个过程。第三是向注册中心注册服务，用于服务发现。本篇文章将会对这三个部分代码进行详细的分析，在分析之前，我们先来了解一下服务的导出过程。 Dubbo 支持两种服务导出方式，分别延迟导出和立即导出。延迟导出的入口是 ServiceBean 的 afterPropertiesSet 方法，立即导出的入口是 ServiceBean 的 onApplicationEvent 方法。本文打算分析服务延迟导出过程，因此不会分析 afterPropertiesSet 方法。下面从 onApplicationEvent 方法说起，该方法收到 Spring 容器的刷新事件后，会调用 export 方法执行服务导出操作。服务导出之前，要进行对一系列的配置进行检查，以及生成 URL。准备工作做完，随后开始导出服务。首先导出到本地，然后再导出到远程。导出到本地就是将服务导出到 JVM 中，此过程比较简单。导出到远程的过程则要复杂的多，以 dubbo 协议为例，DubboProtocol 类的 export 方法将会被调用。该方法主要用于创建 Exporter 和 ExchangeServer。ExchangeServer 本身并不具备通信能力，需要借助更底层的 Server 实现通信功能。因此，在创建 ExchangeServer 实例时，需要先创建 NettyServer 或者 MinaServer 实例，并将实例作为参数传给 ExchangeServer 实现类的构造方法。ExchangeServer 实例创建完成后，导出服务到远程的过程也就接近尾声了。服务导出结束后，服务消费者即可通过直联的方式消费服务。当然，一般我们不会使用直联的方式消费服务。所以，在服务导出结束后，紧接着要做的事情是向注册中心注册服务。此时，客户端即可从注册中心发现服务。 以上就是 Dubbo 服务导出的过程，比较复杂。下面开始分析源码，从源码的角度展现整个过程。 2.源码分析 一场 Dubbo 源码分析的马拉松比赛即将开始，现在我们站在赛道的起点进行热身准备。本次比赛的起点位置位于 ServiceBean 的 onApplicationEvent 方法处。好了，发令枪响了，我将和一些朋友从 onApplicationEvent 方法处出发，探索 Dubbo 服务导出的全过程。下面我们来看一下 onApplicationEvent 方法的源码。 public void onApplicationEvent(ContextRefreshedEvent event) { // 是否有延迟导出 && 是否已导出 && 是不是已被取消导出 if (isDelay() && !isExported() && !isUnexported()) { // 导出服务 export(); } } onApplicationEvent 是一个事件响应方法，该方法会在收到 Spring 上下文刷新事件后执行。这个方法首先会根据条件决定是否导出服务，比如有些服务设置了延时导出，那么此时就不应该在此处导出。还有一些服务已经被导出了，或者当前服务被取消导出了，此时也不能再次导出相关服务。注意这里的 isDelay 方法，这个方法字面意思是“是否延迟导出服务”，返回 true 表示延迟导出，false 表示不延迟导出。但是该方法真实意思却并非如此，当方法返回 true 时，表示无需延迟导出。返回 false 时，表示需要延迟导出。与字面意思恰恰相反，让人觉得很奇怪。下面我们来看一下这个方法的逻辑。 // -☆- ServiceBean private boolean isDelay() { // 获取 delay Integer delay = getDelay(); ProviderConfig provider = getProvider(); if (delay == null && provider != null) { // 如果前面获取的 delay 为空，这里继续获取 delay = provider.getDelay(); } // 判断 delay 是否为空，或者等于 -1 return supportedApplicationListener && (delay == null || delay == -1); } 暂时忽略 supportedApplicationListener 这个条件，当 delay 为空，或者等于-1时，该方法返回 true，而不是 false。这个方法的返回值让人有点困惑，因此我重构了该方法的代码，并给 Dubbo 提了一个 Pull Request，最终这个 PR 被合到了 Dubbo 主分支中。详细请参见 Dubbo #2686。 现在解释一下 supportedApplicationListener 变量含义，该变量用于表示当前的 Spring 容器是否支持 ApplicationListener，这个值初始为 false。在 Spring 容器将自己设置到 ServiceBean 中时，ServiceBean 的 setApplicationContext 方法会检测 Spring 容器是否支持 ApplicationListener。若支持，则将 supportedApplicationListener 置为 true。代码就不分析了，大家自行查阅了解。 ServiceBean 是 Dubbo 与 Spring 框架进行整合的关键，可以看做是两个框架之间的桥梁。具有同样作用的类还有 ReferenceBean。ServiceBean 实现了 Spring 的一些拓展接口，有 FactoryBean、ApplicationContextAware、ApplicationListener、DisposableBean 和 BeanNameAware。这些接口我在 Spring 源码分析系列文章中介绍过，大家可以参考一下，这里就不赘述了。 现在我们知道了 Dubbo 服务导出过程的起点。那么接下来，我们快马加鞭，继续进行比赛。赛程预告，下一站是“服务导出的前置工作”。 2.1 前置工作 前置工作主要包含两个部分，分别是配置检查，以及 URL 装配。在导出服务之前，Dubbo 需要检查用户的配置是否合理，或者为用户补充缺省配置。配置检查完成后，接下来需要根据这些配置组装 URL。在 Dubbo 中，URL 的作用十分重要。Dubbo 使用 URL 作为配置载体，所有的拓展点都是通过 URL 获取配置。这一点，官方文档中有所说明。 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息。 接下来，我们先来分析配置检查部分的源码，随后再来分析 URL 组装部分的源码。 2.1.1 检查配置 本节我们接着前面的源码向下分析，前面说过 onApplicationEvent 方法在经过一些判断后，会决定是否调用 export 方法导出服务。那么下面我们从 export 方法开始进行分析，如下： public synchronized void export() { if (provider != null) { // 获取 export 和 delay 配置 if (export == null) { export = provider.getExport(); } if (delay == null) { delay = provider.getDelay(); } } // 如果 export 为 false，则不导出服务 if (export != null && !export) { return; } if (delay != null && delay > 0) { // delay > 0，延时导出服务 delayExportExecutor.schedule(new Runnable() { @Override public void run() { doExport(); } }, delay, TimeUnit.MILLISECONDS); } else { // 立即导出服务 doExport(); } } export 对两个配置进行了检查，并配置执行相应的动作。首先是 export，这个配置决定了是否导出服务。有时候我们只是想本地启动服务进行一些调试工作，这个时候我们并不希望把本地启动的服务暴露出去给别人调用。此时，我们就可以通过配置 export 禁止服务导出，比如： delay 见名知意了，用于延迟导出服务。下面，我们继续分析源码，这次要分析的是 doExport 方法。 protected synchronized void doExport() { if (unexported) { throw new IllegalStateException("Already unexported!"); } if (exported) { return; } exported = true; // 检测 interfaceName 是否合法 if (interfaceName == null || interfaceName.length() == 0) { throw new IllegalStateException("interface not allow null!"); } // 检测 provider 是否为空，为空则新建一个，并通过系统变量为其初始化 checkDefault(); // 下面几个 if 语句用于检测 provider、application 等核心配置类对象是否为空， // 若为空，则尝试从其他配置类对象中获取相应的实例。 if (provider != null) { if (application == null) { application = provider.getApplication(); } if (module == null) { module = provider.getModule(); } if (registries == null) {...} if (monitor == null) {...} if (protocols == null) {...} } if (module != null) { if (registries == null) { registries = module.getRegistries(); } if (monitor == null) {...} } if (application != null) { if (registries == null) { registries = application.getRegistries(); } if (monitor == null) {...} } // 检测 ref 是否泛化服务类型 if (ref instanceof GenericService) { // 设置 interfaceClass 为 GenericService.class interfaceClass = GenericService.class; if (StringUtils.isEmpty(generic)) { // 设置 generic = "true" generic = Boolean.TRUE.toString(); } } else { // ref 非 GenericService 类型 try { interfaceClass = Class.forName(interfaceName, true, Thread.currentThread() .getContextClassLoader()); } catch (ClassNotFoundException e) { throw new IllegalStateException(e.getMessage(), e); } // 对 interfaceClass，以及 必要字段进行检查 checkInterfaceAndMethods(interfaceClass, methods); // 对 ref 合法性进行检测 checkRef(); // 设置 generic = "false" generic = Boolean.FALSE.toString(); } // local 属性 Dubbo 官方文档中没有说明，不过 local 和 stub 在功能应该是一致的，用于配置本地存根 if (local != null) { if ("true".equals(local)) { local = interfaceName + "Local"; } Class localClass; try { // 获取本地存根类 localClass = ClassHelper.forNameWithThreadContextClassLoader(local); } catch (ClassNotFoundException e) { throw new IllegalStateException(e.getMessage(), e); } // 检测本地存根类是否可赋值给接口类，若不可赋值则会抛出异常，提醒使用者本地存根类类型不合法 if (!interfaceClass.isAssignableFrom(localClass)) { throw new IllegalStateException("The local implementation class " + localClass.getName() + " not implement interface " + interfaceName); } } // stub 和 local 均用于配置本地存根 if (stub != null) { // 此处的代码和上一个 if 分支的代码基本一致，这里省略了 } // 检测各种对象是否为空，为空则新建，或者抛出异常 checkApplication(); checkRegistry(); checkProtocol(); appendProperties(this); checkStubAndMock(interfaceClass); if (path == null || path.length() == 0) { path = interfaceName; } // 导出服务 doExportUrls(); // ProviderModel 表示服务提供者模型，此对象中存储了和服务提供者相关的信息。 // 比如服务的配置信息，服务实例等。每个被导出的服务对应一个 ProviderModel。 // ApplicationModel 持有所有的 ProviderModel。 ProviderModel providerModel = new ProviderModel(getUniqueServiceName(), this, ref); ApplicationModel.initProviderModel(getUniqueServiceName(), providerModel); } 以上就是配置检查的相关分析，代码比较多，需要大家耐心看一下。下面对配置检查的逻辑进行简单的总结，如下： 检测 标签的 interface 属性合法性，不合法则抛出异常 检测 ProviderConfig、ApplicationConfig 等核心配置类对象是否为空，若为空，则尝试从其他配置类对象中获取相应的实例。 检测并处理泛化服务和普通服务类 检测本地存根配置，并进行相应的处理 对 ApplicationConfig、RegistryConfig 等配置类进行检测，为空则尝试创建，若无法创建则抛出异常 配置检查并非本文重点，因此我不打算对 doExport 方法所调用的方法进行分析（doExportUrls 方法除外）。在这些方法中，除了 appendProperties 方法稍微复杂一些，其他方法都还好。因此，大家可自行进行分析。好了，其他的就不多说了，继续向下分析。 2.1.2 多协议多注册中心导出服务 Dubbo 允许我们使用不同的协议导出服务，也允许我们向多个注册中心注册服务。Dubbo 在 doExportUrls 方法中对多协议，多注册中心进行了支持。相关代码如下： private void doExportUrls() { // 加载注册中心链接 List registryURLs = loadRegistries(true); // 遍历 protocols，导出每个服务 for (ProtocolConfig protocolConfig : protocols) { doExportUrlsFor1Protocol(protocolConfig, registryURLs); } } 上面代码比较简单，首先是通过 loadRegistries 加载注册中心链接，然后再遍历 ProtocolConfig 集合导出每个服务。并在导出服务的过程中，将服务注册到注册中心处。下面，我们先来看一下 loadRegistries 方法的逻辑。 protected List loadRegistries(boolean provider) { // 检测是否存在注册中心配置类，不存在则抛出异常 checkRegistry(); List registryList = new ArrayList(); if (registries != null && !registries.isEmpty()) { for (RegistryConfig config : registries) { String address = config.getAddress(); if (address == null || address.length() == 0) { // 若 address 为空，则将其设为 0.0.0.0 address = Constants.ANYHOST_VALUE; } // 从系统属性中加载注册中心地址 String sysaddress = System.getProperty("dubbo.registry.address"); if (sysaddress != null && sysaddress.length() > 0) { address = sysaddress; } // 判断 address 是否合法 if (address.length() > 0 && !RegistryConfig.NO_AVAILABLE.equalsIgnoreCase(address)) { Map map = new HashMap(); // 添加 ApplicationConfig 中的字段信息到 map 中 appendParameters(map, application); // 添加 RegistryConfig 字段信息到 map 中 appendParameters(map, config); map.put("path", RegistryService.class.getName()); map.put("dubbo", Version.getProtocolVersion()); map.put(Constants.TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis())); if (ConfigUtils.getPid() > 0) { map.put(Constants.PID_KEY, String.valueOf(ConfigUtils.getPid())); } if (!map.containsKey("protocol")) { if (ExtensionLoader.getExtensionLoader(RegistryFactory.class).hasExtension("remote")) { map.put("protocol", "remote"); } else { map.put("protocol", "dubbo"); } } // 解析得到 URL 列表，address 可能包含多个注册中心 ip， // 因此解析得到的是一个 URL 列表 List urls = UrlUtils.parseURLs(address, map); for (URL url : urls) { url = url.addParameter(Constants.REGISTRY_KEY, url.getProtocol()); // 将 URL 协议头设置为 registry url = url.setProtocol(Constants.REGISTRY_PROTOCOL); // 通过判断条件，决定是否添加 url 到 registryList 中，条件如下： // (服务提供者 && register = true 或 null) // || (非服务提供者 && subscribe = true 或 null) if ((provider && url.getParameter(Constants.REGISTER_KEY, true)) || (!provider && url.getParameter(Constants.SUBSCRIBE_KEY, true))) { registryList.add(url); } } } } } return registryList; } 上面代码不是很复杂，包含如下逻辑： 检测是否存在注册中心配置类，不存在则抛出异常 构建参数映射集合，也就是 map 构建注册中心链接列表 遍历链接列表，并根据条件决定是否将其添加到 registryList 中 关于多协议多注册中心导出服务就先分析到这，代码不是很多，就不过多叙述了。接下来分析 URL 组装过程。 2.1.3 组装 URL 配置检查完毕后，紧接着要做的事情是根据配置，以及其他一些信息组装 URL。前面说过，URL 是 Dubbo 配置的载体，通过 URL 可让 Dubbo 的各种配置在各个模块之间传递。URL 之于 Dubbo，犹如水之于鱼，非常重要。大家在阅读 Dubbo 服务导出相关源码的过程中，要注意 URL 内容的变化。既然 URL 如此重要，那么下面我们来了解一下 URL 组装的过程。 private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List registryURLs) { String name = protocolConfig.getName(); // 如果协议名为空，或空串，则将协议名变量设置为 dubbo if (name == null || name.length() == 0) { name = "dubbo"; } Map map = new HashMap(); // 添加 side、版本、时间戳以及进程号等信息到 map 中 map.put(Constants.SIDE_KEY, Constants.PROVIDER_SIDE); map.put(Constants.DUBBO_VERSION_KEY, Version.getProtocolVersion()); map.put(Constants.TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis())); if (ConfigUtils.getPid() > 0) { map.put(Constants.PID_KEY, String.valueOf(ConfigUtils.getPid())); } // 通过反射将对象的字段信息到 map 中 appendParameters(map, application); appendParameters(map, module); appendParameters(map, provider, Constants.DEFAULT_KEY); appendParameters(map, protocolConfig); appendParameters(map, this); // methods 为 MethodConfig 集合，MethodConfig 中存储了 标签的配置信息 if (methods != null && !methods.isEmpty()) { // 这段代码用于添加 Callback 配置到 map 中，代码太长，待会单独分析 } // 检测 generic 是否为 "true"，并根据检测结果向 map 中添加不同的信息 if (ProtocolUtils.isGeneric(generic)) { map.put(Constants.GENERIC_KEY, generic); map.put(Constants.METHODS_KEY, Constants.ANY_VALUE); } else { String revision = Version.getVersion(interfaceClass, version); if (revision != null && revision.length() > 0) { map.put("revision", revision); } // 为接口生成包裹类 Wrapper，Wrapper 中包含了接口的详细信息，比如接口方法名数组，字段信息等 String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames(); // 添加方法名到 map 中，如果包含多个方法名，则用逗号隔开，比如 method = init,destroy if (methods.length == 0) { logger.warn("NO method found in service interface ..."); map.put(Constants.METHODS_KEY, Constants.ANY_VALUE); } else { // 将逗号作为分隔符连接方法名，并将连接后的字符串放入 map 中 map.put(Constants.METHODS_KEY, StringUtils.join(new HashSet(Arrays.asList(m