Dubbo源码学习之-服务导出

前言

        忙的时候，会埋怨学习的时间太少，缺少个人的空间，于是会争分夺秒的工作、学习。而一旦繁忙的时候过去，有时间了之后，整个人又会不自觉的陷入一种懒散的状态中，时间也显得不那么重要了，随便就可以浪费掉几个小时。可见普通人的学习之路要主动地去克服掉很多阻碍，最主要的阻碍还是来自于自身，周期性的不想学习、不自觉的懒散、浅尝辄止的态度、好高骛远贪多的盲目...哎，学习之路，还是要时刻提醒自己，需勤勉致知。

        闲话少叙，今天的学习目标是要尽量的了解清楚Dubbo框架中的服务导出功能，先附上Dubbo官网上的一个框架图

本文要说的服务导出，指的就是上图中的动作1-register，即将配置文件/类中服务提供者的信息在注册中心完成注册，以便后续的消费者能发现服务，此外，开放NettyClient用于与消费者通讯。

 下面会从服务导出的触发时机、配置项准备、开放通讯client并注册三部分进行服务导出流程的了解。

一、服务导出的触发时机

        Dubbo是一个可以完全兼容Spring的服务治理框架，兼容性体现在何处？一是Dubbo的配置可以做到对Spring配置无侵入；二是Dubbo默认是随着Spring容器的启动而启动的，不需要人为的控制。帮助Dubbo实现第二项的类有两个：ReferenceBean和ServiceBean，这两个类在Dubbo中担任了连接Spring的桥梁的作用。与本文相关的类是ServiceBean，此类实现了ApplicationListener接口，这样Spring框架在执行refresh方法完成容器初始化的时候，就会发布容器刷新事件，调用ServiceBean的重写方法onApplicationEvent，触发服务导出。

public void onApplicationEvent(ContextRefreshedEvent event) {
// 判断是否已经导出 或者是否不应该导出
if (!isExported() && !isUnexported()) {
if (logger.isInfoEnabled()) {
logger.info("The service ready on spring started. service: " + getInterface());
}
export();
}
}

二、配置项准备

        既然有了入口，就顺着一路追溯下去。真正的export导出方法，在ServiceConfig类中。此时需要说明一下Dubbo中的配置类与实际配置项之间的对应关系。此处以Dubbo的xml配置文件为例。

<dubbo:service interface = "com.test.dubboservice.ITestService" ref = "testService" version="1.0"/>  对应 ServiceConfig类，

<dubbo:provider delay="-1" timeout="${DUBBO_TIMEOUT}" retries="0" token="test_demo"/>  对应 ProviderConfig类，此类与ServiceConfig同属于AbstractServiceConfig的实现类

<dubbo:application name = "dubbo_provider"/> 对应ApplicationConfig类，

<dubbo:registry address = "zookeeper://192/168.16.218:10110" check="false" subscribe="false" register=""/> 对应RegistryConfig类，

<dubbo:protocol name = "dubbo"/>  对应ProtocolConfig类，此外监控中心对应的类是 MonitorConfig

播放完插曲，继续往下追溯export方法 ServiceConfig中的 doExportUrls方法：

private void doExportUrls() {
// 1、Dubbo支持多协议多注册中心
List<URL> registryURLs = loadRegistries(true);
///2、多协议导出服务，向多注册中心注册服务
for (ProtocolConfig protocolConfig : protocols) {
String pathKey = URL.buildKey(getContextPath(protocolConfig).map(p -> p + "/" + path).orElse(path), group, version);
ProviderModel providerModel = new ProviderModel(pathKey, ref, interfaceClass);
ApplicationModel.initProviderModel(pathKey, providerModel);
doExportUrlsFor1Protocol(protocolConfig, registryURLs);
}
}

此方法分为两步，第一步是获取配置的注册中心生成的URL，第二步是通过不同协议进行注册。一步一步的看，先看loadRegistries方法。

1、loadRegistries(true)方法

protected List<URL> loadRegistries(boolean provider) {
// check && override if necessary
List<URL> registryList = new ArrayList<URL>();
// 此处registries类型为List<RegistryConfig>，是解析配置文件时完成的注入，类似于Spring对配置文件的解析
if (CollectionUtils.isNotEmpty(registries)) {
for (RegistryConfig config : registries) {
String address = config.getAddress();
if (StringUtils.isEmpty(address)) {
address = ANYHOST_VALUE;
}
// 判断当前注册中心的地址是否为可用地址，不可用地址格式为 N/A
if (!RegistryConfig.NO_AVAILABLE.equalsIgnoreCase(address)) {
Map<String, String> map = new HashMap<String, String>();
// ！！！此方法极为重要，在拼接URL时经常会看到，是重点需要理解的方法
appendParameters(map, application);
appendParameters(map, config);
map.put(PATH_KEY, RegistryService.class.getName());
appendRuntimeParameters(map);
// 如果注册中心配置中没有配置protocol，则默认用dubbo
if (!map.containsKey(PROTOCOL_KEY)) {
map.put(PROTOCOL_KEY, DUBBO_PROTOCOL);
}
List<URL> urls = UrlUtils.parseURLs(address, map);
// 重新构建URL
for (URL url : urls) {
url = URLBuilder.from(url)
.addParameter(REGISTRY_KEY, url.getProtocol())
.setProtocol(REGISTRY_PROTOCOL)
.build();
// 满足两个条件会往里添加：1、是提供者且有配置注册中心；2、不是提供者但是配置了订阅
if ((provider && url.getParameter(REGISTER_KEY, true))
|| (!provider && url.getParameter(SUBSCRIBE_KEY, true))) {
registryList.add(url);
}
}
}
}
}
return registryList;
}

 此方法逻辑不难理解，先是判断如果为空则设置address的默认值为127的本地地址，再是组装URL参数，最后重新build一下，判断是否添加，最终返回。只是有三个地方需要搞清楚，一个是appendParameters方法的原理及作用，一个是UrlUtils.parseURLs方法的原理，最后是26-29行代码的作用以及为什么还要重新创建（直接将23行的urls返回不行吗？）。下面一个个的来。

1.1 appendParameters方法

源码如下所示：

// 第二个参数就是前面传入的配置类 ApplicationConfig、RegistryConfig等
protected static void appendParameters(Map<String, String> parameters, Object config, String prefix) {
if (config == null) {
return;
}
// 通过反射得到所有的方法
Method[] methods = config.getClass().getMethods();
for (Method method : methods) {
try {
String name = method.getName();
// 是get方法或is方法才进行赋值
if (MethodUtils.isGetter(method)) {
Parameter parameter = method.getAnnotation(Parameter.class);
// 返回值是当前配置类，或者此方法有Parameter注解且excluded参数为true，此时不往map中赋值
if (method.getReturnType() == Object.class || parameter != null && parameter.excluded()) {
continue;
}
String key;
if (parameter != null && parameter.key().length() > 0) {
// 如果Parameter注解中的key不为空，则将它作为往map中put的key
key = parameter.key();
} else {
// 否则截取get/is后面的字符串,转成application.version格式的key
key = calculatePropertyFromGetter(name);
}
// 通过反射获取value
Object value = method.invoke(config);
String str = String.valueOf(value).trim();
if (value != null && str.length() > 0) {
if (parameter != null && parameter.escaped()) {
// 转成utf-8格式
str = URL.encode(str);
}
// 注解中有可拼接配置，则在value前面拼接默认值
if (parameter != null && parameter.append()) {
String pre = parameters.get(DEFAULT_KEY + "." + key);
if (pre != null && pre.length() > 0) {
str = pre + "," + str;
}
pre = parameters.get(key);
if (pre != null && pre.length() > 0) {
str = pre + "," + str;
}
}
// 如果有前缀则在key上加前缀
if (prefix != null && prefix.length() > 0) {
key = prefix + "." + key;
}
// 放入map中
parameters.put(key, str);
} else if (parameter != null && parameter.required()) {
throw new IllegalStateException(config.getClass().getSimpleName() + "." + key + " == null");
}
// 如果是getParameters方法
} else if ("getParameters".equals(name)
&& Modifier.isPublic(method.getModifiers())
&& method.getParameterTypes().length == 0
&& method.getReturnType() == Map.class) {
Map<String, String> map = (Map<String, String>) method.invoke(config, new Object[0]);
if (map != null && map.size() > 0) {
String pre = (prefix != null && prefix.length() > 0 ? prefix + "." : "");
// 重新放入parameters中
for (Map.Entry<String, String> entry : map.entrySet()) {
parameters.put(pre + entry.getKey().replace('-', '.'), entry.getValue());
}
}
}
} catch (Exception e) {
throw new IllegalStateException(e.getMessage(), e);
}
}
}

此方法的作用就是获取传入Object的get/is方法，将get/is后面的属性名跟返回的value值作为key-value放入map中，此外该方法还兼容了Dubbo本身的配置项功能。

 1.2 UrlUtils.parseURLs方法

此方法最终调用了org.apache.dubbo.common.utils.UrlUtils#parseURL方法，由于代码较长，就不贴出来了。

方法中做的事情为：拆分address，如果配置了多个注册中心地址，则每个地址对应一个URL，然后组装URL的七大基本参数 protocol, username, password, host, port, path, parameters，最后new一个URL并返回。

1.3 26-29行代码的作用

将registry、protocol的值作为key、value放入parameters中，将protocol设置为registry，然后用新七项信息创建一个新的URL，此时的URL就被标记为registry的URL了。

2、遍历协议配置，用每个协议配置往注册中心进行服务导出

其中pathkey字段，获取到的就是要导出的服务的接口全路径名，然后将ProviderModel放入map中缓存起来，最后再调用导出方法。

三、服务导出并注册

此部分代码较长，逻辑复杂，故只贴一下关键地方的代码，需结合代码一起看。

1、服务导出的触发

在ServiceConfig类的上述doExportUrlsFor1Protocol方法的后面，进行了导出的触发。分析如下：

String host = this.findConfigedHosts(protocolConfig, registryURLs, map);
Integer port = this.findConfigedPorts(protocolConfig, name, map);

上面2.1中获取到的注册中心URL用于提供host地址，在获取到String protocol, String host, int port, String path, Map<String, String> parameters这五项信息后，new一个URL。然后通过proxyFactory（通过SPI机制生成的代理类）来生成invoker对象，包装成一个包装类，然后调用通过SPI机制生成的protocol代理类的export方法进行导出。

if (CollectionUtils.isNotEmpty(registryURLs)) {
for (URL registryURL : registryURLs) {
// 若干无关代码
// 通过代理工厂生成invoker
Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(EXPORT_KEY, url.toFullString()));
// 用于持有invoker和ServiceConfig
DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);
// 进行服务导出
Exporter<?> exporter = protocol.export(wrapperInvoker);
exporters.add(exporter);
}
} else {
Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, url);
DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);

Exporter<?> exporter = protocol.export(wrapperInvoker);
exporters.add(exporter);
}

 Dubbo中一般都是这个套路，先将URL等准备好的对象转换成一个Invoker，再将Invoker对象传入目标方法完成特定功能。方便理解，可顾名思义，将Invoker看成一个调用体的抽象。

此处需要说明一点的是上述的if-else分支，if中的逻辑是当存在注册中心时的处理方式，即向注册中心注册，并暴露服务供调用；而else中的逻辑，是不存在注册中心时，只暴露服务。他们二者功能区别的实现，在于第5行跟第13行，getInvoker方法的第三个参数不同，一个是注册中心的URL中带有服务的URL，一个只是服务的URL。前者通过SPI的代理工厂类调用的是RegistryProtocol类，因为RegistryURL的protocol属性为registry；而后者通过代理工厂类调用的是DubboProtocol等具体的协议类，因为此URL的protocol属性是取得配置属性，默认dubbo协议。由此可见，以URL为媒介的配置类与SPI机制结合时的灵活性是很大的。

2、RegistryProtocol中的export方法

public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
URL registryUrl = getRegistryUrl(originInvoker);
// url to export locally
URL providerUrl = getProviderUrl(originInvoker);
//  subscription information to cover.
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(providerUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);

providerUrl = overrideUrlWithConfig(providerUrl, overrideSubscribeListener);
//export invoker
// *** 导出是指，创建可供客户端通讯的nettyClient，并启动
final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker, providerUrl);

// url to registry
final Registry registry = getRegistry(originInvoker);
final URL registeredProviderUrl = getRegisteredProviderUrl(providerUrl, registryUrl);
ProviderInvokerWrapper<T> providerInvokerWrapper = ProviderConsumerRegTable.registerProvider(originInvoker,
registryUrl, registeredProviderUrl);
//to judge if we need to delay publish
boolean register = registeredProviderUrl.getParameter("register", true);
if (register) {
// *** 将服务注册到注册中心
register(registryUrl, registeredProviderUrl);
providerInvokerWrapper.setReg(true);
}

// Deprecated! Subscribe to override rules in 2.6.x or before.
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);

exporter.setRegisterUrl(registeredProviderUrl);
exporter.setSubscribeUrl(overrideSubscribeUrl);
//Ensure that a new exporter instance is returned every time export
return new DestroyableExporter<>(exporter);
}

此方法中最重要的两个方法我用*号打了标记，其中前者最终执行的是DubboProtocol等类中的export方法，即启动服务端的通讯Client，以进行后续的通讯调用，此方法下面再看。后者register方法的作用，即将服务注册到注册中心。不同的注册中心，注册的实现是不一样的，比如如果用的是ZooKeeper注册，则此处是调用ZooKeeper的相关API，在对应路径上创建节点，一个节点对应一个服务。

3、DubboProtocol中的export方法

此处以默认协议DubboProtocol为例，看它的export方法。

public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
URL url = invoker.getUrl();

// export service.
String key = serviceKey(url);
DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap);
exporterMap.put(key, exporter);

//export an stub service for dispatching event
Boolean isStubSupportEvent = url.getParameter(STUB_EVENT_KEY, DEFAULT_STUB_EVENT);
Boolean isCallbackservice = url.getParameter(IS_CALLBACK_SERVICE, false);
if (isStubSupportEvent && !isCallbackservice) {
String stubServiceMethods = url.getParameter(STUB_EVENT_METHODS_KEY);
if (stubServiceMethods == null || stubServiceMethods.length() == 0) {
if (logger.isWarnEnabled()) {
logger.warn(new IllegalStateException("consumer [" + url.getParameter(INTERFACE_KEY) +
"], has set stubproxy support event ,but no stub methods founded."));
}

} else {
stubServiceMethodsMap.put(url.getServiceKey(), stubServiceMethods);
}
}
// 打开服务器，为什么是打开服务器？因为打开了服务端Client，消费者就可以与其进行通讯的交互了
openServer(url);
optimizeSerialization(url);//序列化的优化

return exporter;
}

此方法最主要的就是openServer方法，追踪下去你会发现，最终创建了某Client并启动（默认是NettyClient，此外还有MinaClient、GrizzlyClient），等待消息的传入。

总结

        Dubbo中服务导出的流程，基本如上所述。3.2和3.3中由于有多层类调用代码量较多，所以未详细跟进流程，不过相信以道友们扎实的源码阅读功底，应该不难追溯下去，追溯到最后面就是封装的与其他组件交互的api了，感觉繁琐且陌生。源码阅读，还是要找到一个比较好的框架慢慢研读下去，勿好高骛远，勿心急气躁。一时看不懂的地方，就多研究一下，实在不行则先放放，过两天重看的时候就会有不一样的灵感，一般都很容易就领悟了，如若还不行，上网看看大神们的解读也能豁然开朗。

        总之技术的提升没有什么捷径，需要多学习多积累多思考。与各位共勉！