dubbo源码分析-服务暴露流程

如下图：

doExportUrlsFor1Protocol(…)这个函数可以理解为通过具体协议进行服务暴露。
(4)最终调用的是InjvmProtocol的export(), 然后构建了一个InjvmExporter对象作为本地暴露对象，然后将构建的对象存入AbstractProtocol的exporterMap中，与此同时，构建的InjvmExporter中也持有一份exporterMap的引用。
我们知道服务暴露的核心组件是ServiceBean，我们也知道ServiceBean是在基于spring可扩展的XMLschema实例化来的，也就是说在spring容器启动的过程当中就完成了服务的暴露，接下来我们着重分析这个类就可以了。
很明显，如果我们不配置动态代理方式，那么缺省是javassist。

具体执行export的是ProtocolListenerWrapper，我们先看下执行的过程（接下来是一片连续代码截图~）

ServiceConfig#export()，这个方法首先会根据用户配置判断是否暴露，以及是否延迟暴露，不关注这块逻辑的话，最关键的部分是调用doExport()这个方法。如图：

从这个函数我们其实是可以看出dubbo默认支持dubbo协议，换个角度讲，读者如果看过官方文档的话，不难了解到dubbo是支持多协议的并且默认（缺省）协议是dubbo，官方截图如下：

8. proxyFactory.getInvoker(ref, (Class) interfaceClass, local)这段逻辑是具体服务转换为Invoker的过程，这个过程中用到了ProxyFactory这个概念，ProxyFactory的作用在开篇也讲过了，proxyFactory是根据spi动态获取到的，具体表现为一个动态代理类，如图：

从这个函数的逻辑不难发现这块逻辑的功能与我们探讨doExport()函数时引申出的dubbo是支持多协议注册想呼应。简言之，上图的逻辑实现了多协议注册，是多协议支持的根本。

至此，已经一口气完成了本地暴露，我结合代码大概的说一下暴露过程中需要注意的点：
9. 得到Invoker之后，接下来我们该马不停蹄的进行转换Exporter的过程了。protocol.export(Invoker），

我们可以猜想AbstractInterfaceConfig#loadRegistries()这个函数会将用户配置的协议转换为内部的URL对象（dubbo统一数据模型）加载到一个list当中。断点进入loadRegistries()这个方法去验证下我们的想法~ 如图：
服务暴露时序图