dubbo暴露服务有两种情况，一种是设置了延迟暴露（比如delay=”5000”），另外一种是没有设置延迟暴露或者延迟设置为-1（delay=”-1”）：
设置了延迟暴露，dubbo在Spring实例化bean（initializeBean）的时候会对实现了InitializingBean的类进行回调，回调方法是afterPropertySet()，如果设置了延迟暴露，dubbo在这个方法中进行服务的发布。
没有设置延迟或者延迟为-1，dubbo会在Spring实例化完bean之后，在刷新容器最后一步发布ContextRefreshEvent事件的时候，通知实现了ApplicationListener的类进行回调onApplicationEvent，dubbo会在这个方法中发布服务。 但是不管延迟与否，都是使用ServiceConfig的export()方法进行服务的暴露。使用export初始化的时候会将Bean对象转换成URL格式，所有Bean属性转换成URL的参数。
过程
以没有设置延迟暴露熟属性的过程为例。
简易的暴露流程
首先将服务的实现封装成一个Invoker，Invoker中封装了服务的实现类。
将Invoker封装成Exporter，并缓存起来，缓存里使用Invoker的url作为key。
服务端Server启动，监听端口。（请求来到时，根据请求信息生成key，到缓存查找Exporter，就找到了Invoker，就可以完成调用。） Spring容器初始化调用
当Spring容器实例化bean完成，走到最后一步发布ContextRefreshEvent事件的时候，ServiceBean会执行onApplicationEvent方法，该方法调用ServiceConfig的export方法。
ServiceConfig初始化的时候，会先初始化静态变量protocol和proxyFactory，这两个变量初始化的结果是通过dubbo的spi扩展机制得到的。
生成的protocol实例是：
1
package com.alibaba.dubbo.rpc;
生成的proxyFactory实例：
1
package com.alibaba.dubbo.rpc;
生成的代码中可以看到，默认的Protocol实现是dubbo，默认的proxy是javassist。
ServiceConfig的export
export的步骤简介
首先会检查各种配置信息，填充各种属性，总之就是保证我在开始暴露服务之前，所有的东西都准备好了，并且是正确的。
加载所有的注册中心，因为我们暴露服务需要注册到注册中心中去。
根据配置的所有协议和注册中心url分别进行导出。
进行导出的时候，又是一波属性的获取设置检查等操作。
如果配置的不是remote，则做本地导出。
如果配置的不是local，则暴露为远程服务。
不管是本地还是远程服务暴露，首先都会获取Invoker。
获取完Invoker之后，转换成对外的Exporter，缓存起来。 export方法先判断是否需要延迟暴露（这里我们使用的是不延迟暴露），然后执行doExport方法。
doExport方法先执行一系列的检查方法，然后调用doExportUrls方法。检查方法会检测dubbo的配置是否在Spring配置文件中声明，没有的话读取properties文件初始化。
doExportUrls方法先调用loadRegistries获取所有的注册中心url，然后遍历调用doExportUrlsFor1Protocol方法。对于在标签中指定了registry属性的Bean，会在加载BeanDefinition的时候就加载了注册中心。
获取注册中心url，会把注册的信息都放在一个URL对象中，一个URL内容如下：
1
registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=dubbo-provider&application.version=1.0&dubbo=2.5.3&environment=product&organization=china&owner=cheng.xi&pid=2939®istry=zookeeper×tamp=1488898049284
doExportUrlsFor1Protocol根据不同的协议将服务以URL形式暴露。如果scope配置为none则不暴露，如果服务未配置成remote，则本地暴露exportLocal，如果未配置成local，则注册服务registryProcotol。
这里的URL是：
1
dubbo://192.168.1.100:20880/dubbo.common.hello.service.HelloService?anyhost=true&application=dubbo-provider&application.version=1.0&delay=5000&dubbo=2.5.3&environment=product&interface=dubbo.common.hello.service.HelloService&methods=sayHello&organization=china&owner=cheng.xi&pid=2939&side=provider×tamp=1488898464953
这时候会先做本地暴露，exportLocal(url);：
1
private void exportLocal(URL url) {
接下来是暴露为远程服务，跟本地暴露的流程一样还是先获取Invoker，然后导出成Exporter：
1
//根据服务具体实现，实现接口，以及registryUrl通过ProxyFactory将HelloServiceImpl封装成一个本地执行的Invoker
关于Invoker，Exporter等的解释参见最下面的内容。
暴露远程服务时的获取Invoker过程
服务实现类转换成Invoker，大概的步骤是：
根据上面生成的proxyFactory方法调用具体的ProxyFactory实现类的getInvoker方法获取Invoker。
getInvoker的过程是，首先对实现类做一个包装，生成一个包装后的类。
然后新创建一个Invoker实例，这个Invoker中包含着生成的Wrapper类，Wrapper类中有具体的实现类。
1
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
这行代码中包含服务实现类转换成Invoker的过程，其中proxyFactory是上面列出的动态生成的代码，其中getInvoker的代码为（做了精简，把包都去掉了）：
1
public Invoker getInvoker(Object arg0, Class arg1, URL arg2) throws Object {
JavassistProxyFactory的getInvoker方法：
1
public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
生成wrapper类的过程，首先看getWrapper方法：
1
public static Wrapper getWrapper(Class<?> c){
makeWrapper方法代码不在列出，太长了。就是生成一个继承自Wrapper的类，最后的结果大概是：
1
public class Wrapper1 extends Wrapper {
生成完Wrapper以后，返回一个AbstractProxyInvoker实例。至此生成Invoker的步骤就完成了。可以看到Invoker执行方法的时候，会调用Wrapper的invokeMethod，这个方法中会有真实的实现类调用真实方法的代码。
暴露远程服务时导出Invoker为Exporter
Invoker导出为Exporter分为两种情况，第一种是Registry类型的Invoker，第二种是其他协议类型的Invoker，分开解析。
代码入口：
1
Exporter<?> exporter = protocol.export(invoker);
Registry类型的Invoker处理过程
大概的步骤是：
经过两个不用做任何处理的Wrapper类，然后到达RegistryProtocol中。
通过具体的协议导出Invoker为Exporter。
注册服务到注册中心。
订阅注册中心的服务。
生成一个新的Exporter实例，将上面的Exporter进行引入，然后返回。 protocol是上面列出的动态生成的代码，会先调用ProtocolListenerWrapper，这个Wrapper负责初始化暴露和引用服务的监听器。对于Registry类型的不做处理，代码如下：
1
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
接着调用ProtocolFilterWrapper中的export方法，ProtocolFilterWrapper负责初始化invoker所有的Filter。代码如下：
1
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
这里我们先解析的是Registry类型的Invoker，接着就会调用RegistryProtocol的export方法，RegistryProtocol负责注册服务到注册中心和向注册中心订阅服务。代码如下：
1
public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
交给具体的协议去暴露服务
先不解析，留在后面，可以先去后面看下导出过程，然后再回来接着看注册到注册中心的过程。具体协议暴露服务主要是打开服务器和端口，进行监听。
注册到注册中心
具体的协议进行暴露并且返回了一个ExporterChangeableWrapper之后，接下来看下一步连接注册中心并注册到注册中心，代码是在RegistryProtocol的export方法：
1
//此步已经分析完
getRegistry(originInvoker)方法：
1
//根据invoker的地址获取registry实例
这里的registryFactory是动态生成的代码，如下：
1
import com.alibaba.dubbo.common.extension.ExtensionLoader;
所以这里registryFactory.getRegistry(registryUrl)用的是ZookeeperRegistryFactory。
先看下getRegistry方法，会发现该方法会在AbstractRegistryFactory中实现：
1
public Registry getRegistry(URL url) {
createRegistry(url);是在子类中实现的，这里是ZookeeperRegistry，首先需要经过AbstractRegistry的构造：
1
public AbstractRegistry(URL url) {
notify()方法：
1
protected void notify(List<URL> urls) {
notify(url, listener, filterEmpty(url, urls));代码：
1
protected void notify(URL url, NotifyListener listener, List<URL> urls) {
AbstractRegistry构造器初始化完，接着调用FailbackRegistry构造器初始化：
1
public FailbackRegistry(URL url) {
最后回到ZookeeperRegistry的构造初始化：
1
public ZookeeperRegistry(URL url, ZookeeperTransporter zookeeperTransporter) {
获取到了Registry，Registry实例中保存着连接到了zookeeper的zkClient实例之后，下一步获取要注册到注册中心的url（在RegistryProtocol中）。
1
final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
然后调用registry.register(registedProviderUrl)注册到注册中心（在RegistryProtocol中）。register方法的实现在FailbackRegistry中：
1
public void register(URL url) {
doRegister(url);在这里是ZookeeperRegistry中具体实现的，这里将会注册到注册中心：
1
protected void doRegister(URL url) {
经过这一步之后，Zookeeper中就有节点存在了，具体节点为：
1
/dubbo
订阅注册中心的服务
在注册到注册中心之后，registry会去订阅覆盖配置的服务，这一步之后就会在/dubbo/dubbo.common.hello.service/HelloService节点下多一个configurators节点。（具体过程暂先不解析）。
返回新Exporter实例
最后返回Exporter新实例，返回到ServiceConfig中。服务的发布就算完成了。
交给具体的协议进行服务暴露
这里也就是非Registry类型的Invoker的导出过程。主要的步骤是将本地ip和20880端口打开，进行监听。最后包装成exporter返回。
doLocalExport(invoker)：
1
private <T> ExporterChangeableWrapper<T> doLocalExport(final Invoker<T> originInvoker){
这里protocol.export(invokerDelegete)就要去具体的DubboProtocol中执行了，DubboProtocol的外面包裹着ProtocolFilterWrapper，再外面还包裹着ProtocolListenerWrapper。会先经过ProtocolListenerWrapper：
1
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
再经过ProtocolFilterWrapper：
1
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
查看下构建Invoker链的方法：
1
private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) {
接着就到了DubboProtocol的export方法，这里进行暴露服务：
1
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
上面得到的Exporter会被放到缓存中去，key就是上面生成的，客户端就可以发请求根据key找到Exporter，然后找到invoker进行调用了。接下来是创建服务器并监听端口。
接着调用openServer方法创建NIO Server进行监听：
1
private void openServer(URL url) {
继续看createServer方法：
1
//url为：
Exchangers.bind方法：
1
public static ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
HeaderExchanger的bind方法：
1
public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
这里会先创建一个HeaderExchangerHandler，包含着ExchangeHandlerAdapter，接着创建一个DecodeHandler，会包含前面的handler，接下来调用Transporters的bind方法，返回一个Server，接着用HeaderExchangeServer包装一下，就返回给Protocol层了。
在HeaderExchangerServer包装的时候会启动心跳定时器startHeatbeatTimer();，暂不解析。
Transports的bind方法：
1
public static Server bind(URL url, ChannelHandler... handlers) throws RemotingException {
getTransporter()生成的Transporter的代码如下：
1
import com.alibaba.dubbo.common.extension.ExtensionLoader;
NettyTransporter的bind方法：
1
public Server bind(URL url, ChannelHandler listener) throws RemotingException {
1
public NettyServer(URL url, ChannelHandler handler) throws RemotingException{
ChannelHandlers.wrap方法中会根据SPI扩展机制动态生成Dispatcher的自适应类，生成的代码不在列出，默认使用AllDispatcher处理，会返回一个AllChannelHandler，会把线程池和DataStore都初始化了。然后经过HeartbeatHandler封装，再经过MultiMessageHandler封装后返回。
NettyServer构造，会依次经过AbstractPeer，AbstractEndpoint，AbstractServer，NettyServer的初始化。重点看下AbstractServer的构造方法：
1
public AbstractServer(URL url, ChannelHandler handler) throws RemotingException {
然后调用doOpen方法：
1
protected void doOpen() throws Throwable {
doOpen方法创建Netty的Server端并打开，具体的事情就交给Netty去处理了，Netty的过程，原理，代码有时间再另行研究。
NIO框架接受到消息后，先由NettyCodecAdapter解码，再由NettyHandler处理具体的业务逻辑，再由NettyCodecAdapter编码后发送。
NettyServer既是Server又是Handler。
HeaderExchangerServer只是Server。
MultiMessageHandler是多消息处理Handler。
HeartbeatHandler是处理心跳事件的Handler。
AllChannelHandler是消息派发器，负责将请求放入线程池，并执行请求。
DecodeHandler是编解码Handler。
HeaderExchangerHandler是信息交换Handler，将请求转化成请求响应模式与同步转异步模式。
RequestHandler是最后执行的Handler，会在协议层选择Exporter后选择Invoker，进而执行Filter与Invoker，最终执行请求服务实现类方法。
Channel直接触发事件并执行Handler，Channel在有客户端连接Server的时候触发创建并封装成NettyChannel，再由HeaderExchangerHandler创建HeaderExchangerChannel，负责请求响应模式的处理。
NettyChannel其实是个Handler，HeaderExchangerChannel是个Channel，
消息的序列化与反序列化工作在NettyCodecAdapter中发起完成。 当有客户端连接Server时的连接过程：
NettyHandler.connected()
NettyServer.connected()
MultiMessageHandler.connected()
HeartbeatHandler.connected()
AllChannelHandler.connected()
DecodeHandler.connected()
HeaderExchangerHandler.connected()
requestHandler.connected()
执行服务的onconnect事件的监听方法 名词解释
Invoker
可执行的对象，执行具体的远程调用，能够根据方法名称，参数得到相应的执行结果。
Invocation，包含了需要执行的方法，参数等信息。目前实现类只有RpcInvocation。
有三种类型的Invoker：
本地执行类的Invoker。
远程通信执行类的Invoker。
多个远程通信执行类的Invoker聚合成集群版的Invoker。 以HelloService为例：
本地执行类的Invoker：在Server端有HelloServiceImpl实现，要执行该接口，只需要通过反射执行对应的实现类即可。
远程通信执行类的Invoker：在Client端要想执行该接口的实现方法，需要先进行远程通信，发送要执行的参数信息给Server端，Server端利用本地执行Invoker的方式执行，最后将结果发送给Client。
集群版的Invoker：Client端使用的时候，通过集群版的Invoker操作，Invoker会挑选一个远程通信类型的Invoker来执行。 提供者端的Invoker封装了服务实现类，URL，Type，状态都是只读并且线程安全。通过发起invoke来具体调用服务类。
ProxyFactory
在服务提供者端，ProxyFactory主要服务的实现统一包装成一个Invoker，Invoker通过反射来执行具体的Service实现对象的方法。默认的实现是JavassistProxyFactory，代码如下：
1
public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
Protocol
服务地址的发布和订阅。
Protocol是dubbo中的服务域，只在服务启用时加载，无状态，线程安全，是实体域Invoker暴露和引用的主功能入口，负责Invoker的生命周期管理，是Dubbo中远程服务调用层。
Protocol根据指定协议对外公布服务，当客户端根据协议调用这个服务时，Protocol会将客户端传递过来的Invocation参数交给Invoker去执行。
Protocol加入了远程通信协议，会根据客户端的请求来获取参数Invocation。
1
@Extension("dubbo")
关于RegistryProtocol和DubboProtocol的疑惑
以下是官方文档说明：
暴露服务:
(1) 只暴露服务端口：
在没有注册中心，直接暴露提供者的情况下，即：<dubbo:service regisrty="N/A" /> or <dubbo:registry address="N/A" />
ServiceConfig解析出的URL的格式为：dubbo://service-host/com.foo.FooService?version=1.0.0
基于扩展点的Adaptive机制，通过URL的”dubbo://“协议头识别，直接调用DubboProtocol的export()方法，打开服务端口。
(2) 向注册中心暴露服务：
在有注册中心，需要注册提供者地址的情况下，即：<dubbo:registry address="zookeeper://10.20.153.10:2181" />
ServiceConfig解析出的URL的格式为：registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/com.foo.FooService?version=1.0.0")
基于扩展点的Adaptive机制，通过URL的”registry://“协议头识别，就会调用RegistryProtocol的export()方法，将export参数中的提供者URL，先注册到注册中心，再重新传给Protocol扩展点进行暴露：dubbo://service-host/com.foo.FooService?version=1.0.0
基于扩展点的Adaptive机制，通过提供者URL的”dubbo://“协议头识别，就会调用DubboProtocol的export()方法，打开服务端口。
RegistryProtocol，注册中心协议集成，装饰真正暴露引用服务的协议，增强注册发布功能。
ServiceConfig中的protocol是被多层装饰的Protocol，是DubboProtocol+RegistryProtocol+ProtocolListenerWrapper+ProtocolFilterWrapper。
ProtocolFilterWrapper负责初始化invoker所有的Filter。
ProtocolListenerWrapper负责初始化暴露或引用服务的监听器。
RegistryProtocol负责注册服务到注册中心和向注册中心订阅服务。
DubboProtocol负责服务的具体暴露与引用，也负责网络传输层，信息交换层的初始化，以及底层NIO框架的初始化。 Exporter
负责invoker的生命周期，包含一个Invoker对象，可以撤销服务。
Exchanger
负责数据交换和网络通信的组件。每个Invoker都维护了一个ExchangeClient的 引用，并通过它和远端server进行通信。
