首先我们通过一个时序图，直观看下Dubbo服务提供方启动的流程：

dubbo 用 getway 吗_java

  • 在《Dubbo整体框架分析》一文中我们提到，服务提供方需要使用ServiceConfig API发布服务，具体是调用代码（1）export()方法来激活发布服务。export的核心代码如下：
public synchronized void export(){
    ...
    // 这里是延迟发布
    if(delay != null && delay > 0){
        delayExportExecutor.schedule(new Runnable(){
            public void run(){
                doExport();
            }
        } , delay , TimeUnit.MILLISECONDS);
    }else{
        // 直接发布
        doExport();
    }
}



private static final ScheduledExecutorService delayExportExecutor = Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory("DubboServiceDelayExporter" , true));



如上代码，可知Dubbo的延迟发布通过使用ScheduledExecutorService来实现的，可以通过调用ServiceConfig的setDelay(Integer delay)来设置延迟发布时间。如果没有设置延迟时间则直接调用代码（2）doExport()方法发布服务，延迟发布最后也是调用的该方法。

  • 代码（2）主要是根据ServiceConfig里面的属性进行合法性检查，这里我们主要看其内部最后调用的doExportUrls方法。
  • 代码（3）内部首先通过调用loadRegistries方法加载所有的服务注册中心对象，Dubbo中一个服务可以被注册到多个服务注册中心。
  • 另外Dubbo支持本地调用，本地调用使用了injvm协议，是一个伪协议，它不开启端口，不发起远程调用，旨在jvm内直接关联，但执行Dubbo的Filter链，所以默认下Dubbo同时支持本地调用与远程调用协议，所以这里的循环用来暴露本地服务和远程服务。
  • 代码（5）的 doExportUrlsFor1Protocol 方法内部首先把参数封装在url，在Dubbo里面会把所有参数封装在一个url里面，然后具体执行服务到处，其核心代码如下：
Invoker<?> invoker = proxyFactory.getInvoker(ref , (Class)interfaceClass , url);
DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker , this);
Exporter<?> exporter = protocol.export(wrapperInvoker);
exporters.add(exporter);



其中proxyFactory和protocol的定义如下：



private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdativeExtension();
private static final ProxyFactory proxyFactory = ExtensionLoader.getExtensionLoader(ProxyFactory.class).getAdaptiveExtension();



可知它们是扩展接口的适配器类。

  • 执行代码 proxyFactory.getInvoker(ref , (Class)interfaceClass , url)时，我们发现实际是首先执行代码（6）调用了扩展接口 ProxyFactory的适配器类，然后适配器内部根据url里proxy的类型选择具体的代理工厂，这里默认proxy类型为javasist，所以又调用了代码（7）执行了JavassistProxyFactory的getInvoker方法获取了代理类。

JavassistProxyFactory的getInvoker代码如下：



public <T> Invoker<T> getInvoker(T proxy , Class<T> type , URL url){
    // 
    final Wrapper c = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
    return new AbstractProxyInvoker<T>(proxy , type , url){
        @Override
        protected Object doInvoke(T proxy , String methodName , Class<?>[] parameterTypes , Object[] arguments) throws Throwable {
            return wrapper.invokeMethod(proxy,methodName,parameterTypes,arguments);
        }
    };    
}



这里首先把服务实现类转换为Wrapper类，是为了减少反射的调用。代码（6）具体返回的是AbstractProxyInvoker对象，其内部重写doInvoke方法，具体委托给Wrapper实现具体功能。到这里完成了《Dubbo具体架构分析》一文中讲解的服务提供方实现类到Invoker的转换。

  • 然后执行代码（8），当执行protocol.export(wrapperInvoker)的时候，实际调用了Protocol的适配器类Protocol$Adaptive的export方法。其内部根据url中Protocol的类型为registry，会选择Protocol的实现类RegistryProtocol。但由于Dubbo SPI的扩展点使用wrapper自动增强的存在，这里使用了ProtocolFilterWrapper、ProtocolListenerWrapper、QosProtocolWrapper对其进行了增强，所以需要一层层调用才会具体调用到RegistryProtocol的export方法。
  • 代码（12）RegistryProtocol中的export方法通过代码（13）doLocalExport启动了NettyServer进行监听服务，代码（14）则将当前服务注册到具体的服务注册中心。到这里完成《Dubbo整体架构分析》一文中谈到的Invoker到Exporter的转换。

下面我们再来看doLocalExport是如何启动NettyServer的，doLocalExport内部主要调用DubboProtocol的export方法，下面看下时序图：

dubbo 用 getway 吗_java_02

由于DubboProtocol也被Wrapper类增强了，所以也是一层层调用后，执行代码（7）调用DubboProtocol的export方法，export代码如下：



public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException{
    URL url = invoker.getUrl();
    // invoker到exporter转换
    String key = serviceKey(url);
    DubboExporter<T> exporter = new DubboExporter<T>(invoker , key , exporterMap);
    exporterMap.put(key,exporter);
    ...
    openServer(url);
    return exporter;
}



这里将invoker转换到DubboExporter对象，然后执行代码（9），接着一步步最后会执行到代码（14）NettyTransporter的bind方法，其代码如下：



public Server bind(URL url,ChannelHandler listener) throws RemotingException{
    return new NettyServer(url,listener);    
}



有上面代码可知，其内部创建了NettyServer，而NettyServer的构造函数内部又调用了NettyServer的doOpen方法启动了服务监听。



public NettyServer(URL url,ChannelHandler handler) throws RemotingException{
    super(url,ChannelHandlers.wrap(handler,ExecutorUtil.setThreadName(url,SERVER_THREAD_POOL_NAME)));
}



这里我们主要看 ChannelHandlers.wrap(handler,ExecutorUtil.setThreadName(url,SERVER_THREAD_POOL_NAME))这个代码，改代码里面加载了具体的线程模型，通过ChannelHandlers的wrapInternal方法完成了加载：



protected ChannelHandler wrapInternal(ChannelHandler handler,URL url){
    return new MultiMessageHandler(new HeartbeatHandler(ExtensionLoader.getExtensionLoader(Dispatcher.class).getAdaptiveExtension().dispatch(handler,url)));
}



可知根据url里面的线程模型选择具体的Dispatcher实现类，这里再重新提下Dubbo提供的Dispatcher实现类如下，默认是all：



all=com.alibaba.dubbo.remoting.transport.dispatcher.all.AllDispatcher
direct=com.alibaba.dubbo.remoting.transport.dispatcher.direct.DirectDispatcher
message=com.alibaba.dubbo.remoting.transport.dispatcher.message.MessageOnlyDispatcher
execution=com.alibaba.dubbo.remoting.transport.dispatcher.execution.ExecutionDispatcher
connection=com.alibaba.dubbo.remoting.transport.dispatcher.connection.ConnectionOrderedDispatcher



到这里线程模型加载地方讲解完了，还有一个点就是线程模型中线程池SPI扩展什么时候加载的呢？这里以线程模型AllDispatcher为例，它对应的是AllChannelHandler，其构造函数如下：



public AllChannelHandler(ChannelHandler handler,URL url){
    super(handler , url);    // 父类WrappedChannelHandler构造方法      
}



public WrappedChannelHandler(ChannelHandler handler,URL url){
    ...
    executor = (ExecutorService)ExtensionLoader.getExtensionLoader(ThreadPool.class).getAdaptiveExtension().getExecutor(url);
    ...
}



可知WrapperChannelHandler的构造函数里根据url获取了具体的扩展接口ThreadPool的SPI实现类，这里再提下ThreadPool的扩展接口如下，默认是fixed：



fixed=com.alibaba.dubbo.common.threadpool.support.fixed.FixedThreadPool
cached=com.alibaba.dubbo.common.threadpool.support.cached.CachedThreadPool
limited=com.alibaba.dubbo.common.threadpool.support.limited.LimitedThreadPool