Dubbo2.7.6之服务暴露流程

最新推荐文章于 2022-03-14 16:51:16 发布
最新推荐文章于 2022-03-14 16:51:16 发布
阅读量1k 收藏 1
点赞数 2
分类专栏： Spring源码解读 文章标签： java spring zookeeper
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhaodongchao1992/article/details/106011794
版权

在上一篇文章Dubbo2.7.6启动原理之Provider中我已经探讨了dubbo服务启动的大致流程。可以看到，暴露服务逻辑在DubboBootstrap#exportServices()方法中。今天就来详细来探索一下暴露服务的实现细节。

如下为服务暴露过程中的涉及到的主要组件：
在这里插入图片描述
注意：

  1. 一个服务可以同时以多种协议暴露
  2. 一个服务可以同时注册在多个不同的注册中心
  3. 每一个服务接口都会转换为对应的ServiceConfig实例

如下是dubbo官方给出的服务暴露时序图：
在这里插入图片描述

如下就是服务接口暴露过程中的转换逻辑：
在这里插入图片描述
说明：

  1. 每一个接口根据一个协议暴露到一个注册中心时，最终会装换为Exporter实例！

上面整理了一下服务暴露的整体流程图，
下面就开始继续撸源码DubboBootstrap#exportServices()

//暴露所有的服务
private void exportServices() {
    //从ConfigManager中获取所有的ServiceConfig实例，然后遍历，一个一个的暴露
    configManager.getServices().forEach(sc -> {
        // 服务export的核心逻辑方法是ServiceConfig#export()
        ServiceConfig serviceConfig = (ServiceConfig) sc;
        //将DubboBootstrap实例赋值给ServiceConfig
        serviceConfig.setBootstrap(this);
        //是否异步Export
        if (exportAsync) {
            //如果是异步，就获取一个线程池，来异步执行export逻辑
            ExecutorService executor = executorRepository.getServiceExporterExecutor();
            Future<?> future = executor.submit(() -> {
                sc.export();
            });
            asyncExportingFutures.add(future);
        } else {
            //同步export
            sc.export();
            exportedServices.add(sc);
        }
    });
}

再来看ServiceConfig#export()

private DubboBootstrap bootstrap;
protected ServiceMetadata serviceMetadata;

public synchronized void export() {
    //如果服务已经export就返回
    if (!shouldExport()) {
        return;
    }
    //如果DubboBootstrap为空，也就没有初始化，就初始化一下DubboBootstrap
    if (bootstrap == null) {
        //这里使用了单例模式，DubboBootstrap不会重复创建
        bootstrap = DubboBootstrap.getInstance();
        bootstrap.init();
    }

    checkAndUpdateSubConfigs();

    //init serviceMetadata 初始化服务的原数据信息
    serviceMetadata.setVersion(version);
    serviceMetadata.setGroup(group);
    serviceMetadata.setDefaultGroup(group);
    serviceMetadata.setServiceType(getInterfaceClass());
    //设置服务接口
    serviceMetadata.setServiceInterfaceName(getInterface());
    //设置服务的实现类
    serviceMetadata.setTarget(getRef());
    //export服务，判断是否延时export
    if (shouldDelay()) {
        //如果是延时export，就使用时间调度器延时执行服务export逻辑
        DELAY_EXPORT_EXECUTOR.schedule(this::doExport, getDelay(), TimeUnit.MILLISECONDS);
    } else {
        //直接export服务
        doExport();
    }
    //发布ServiceConfigExportedEvent事件
    exported();
}
public void exported() {
    // dispatch a ServiceConfigExportedEvent since 2.7.4
    dispatch(new ServiceConfigExportedEvent(this));
}

可以看到，在最后使用事件模型，dubbo事件模型以后再研究，由于篇幅原因，这里不做介绍。

然后在看ServiceConfig#doExport()

/**
 * The flag whether a service has unexported ,if the method unexported is invoked, the value is true
 */
private transient volatile boolean unexported;
/**
 * The service name
 */
protected String path;

protected synchronized void doExport() {
    //如果service已经被unexported,就抛出异常
    if (unexported) {
        throw new IllegalStateException("The service " + interfaceClass.getName() + " has already unexported!");
    }
    //如果服务已经被暴露，就返回
    if (exported) {
        return;
    }
    exported = true;
    //设置path值，只为接口的全限定名
    if (StringUtils.isEmpty(path)) {
        path = interfaceName;
    }
    //执行服务暴露逻辑
    doExportUrls();
}

继续看ServiceConfig#doExportUrls() ，这里才是export核心逻辑的开始

/**
 * The protocol list the service will export with
 * Also see {@link #protocolIds}, only one of them will work.
 * 
 * 一个服务ServiceConfig可能同时以多个协议export
 */
protected List<ProtocolConfig> protocols;
private void doExportUrls() {
    //从ApplicationModel容器中获取服务仓库ServiceRepository(也是一个容器)
    ServiceRepository repository = ApplicationModel.getServiceRepository();
    //生产一个服务描述实例ServiceDescriptor
    ServiceDescriptor serviceDescriptor = repository.registerService(getInterfaceClass());
    //将服务提供者的信息存放到ServiceRepository中
    repository.registerProvider(
            getUniqueServiceName(),
            ref,
            serviceDescriptor,
            this,
            serviceMetadata
    );
    //获取服务注册中心的URL地址信息，一个服务可以同事在多个注册中心注册。所以此处是List
    List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);
    //遍历服务要暴露的协议集合。一个服务可能同时以dubbo协议，rest协议等export。一般默认是dubbo协议，也推荐是用dubbo协议
    for (ProtocolConfig protocolConfig : protocols) {
        //构建服务的path的key
        String pathKey = URL.buildKey(getContextPath(protocolConfig)
                .map(p -> p + "/" + path)
                .orElse(path), group, version);
        // In case user specified path, register service one more time to map it to path.
        repository.registerService(pathKey, interfaceClass);
        // TODO, uncomment this line once service key is unified
        serviceMetadata.setServiceKey(pathKey);
        //真对一个协议，在一个或多个注册中心来export这个服务
        doExportUrlsFor1Protocol(protocolConfig, registryURLs);
    }
}

可以看到，ServiceConfig#doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List registryURLs)是真对一个协议，在一个或多个注册中心来export服务。

/**
 * The exported services
 */
private final List<Exporter<?>> exporters = new ArrayList<Exporter<?>>();
private static final Protocol PROTOCOL = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
private static final ProxyFactory PROXY_FACTORY = ExtensionLoader.getExtensionLoader(ProxyFactory.class).getAdaptiveExtension();

private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
    //获取协议名称，没有则默认使用dubbo
    String name = protocolConfig.getName();
    if (StringUtils.isEmpty(name)) {
        name = DUBBO;
    }
    //组装参数
    Map<String, String> map = new HashMap<String, String>();
    map.put(SIDE_KEY, PROVIDER_SIDE);
    ... 
  
    //init serviceMetadata attachments, ServiceMetadata中的attachments will be transferred to remote side
    serviceMetadata.getAttachments().putAll(map);

    // export service , 构建URL实例
    String host = findConfigedHosts(protocolConfig, registryURLs, map);
    Integer port = findConfigedPorts(protocolConfig, name, map);
    URL url = new URL(name, host, port, getContextPath(protocolConfig).map(p -> p + "/" + path).orElse(path), map);
    
    // You can customize Configurator to append extra parameters
    if (ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
            .hasExtension(url.getProtocol())) {
        url = ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
                .getExtension(url.getProtocol()).getConfigurator(url).configure(url);
    }
    //获取scope ，如果没有配置服务的scope时就不暴露服务
    String scope = url.getParameter(SCOPE_KEY);
    // don't export when none is configured
    if (!SCOPE_NONE.equalsIgnoreCase(scope)) {

        // export to local if the config is not remote (export to remote only when config is remote)
        //如果scope != remote , 就以本地方式export
        if (!SCOPE_REMOTE.equalsIgnoreCase(scope)) {
            exportLocal(url);
        }
        // export to remote if the config is not local (export to local only when config is local)
        //如果scope不是local,就默认以remote方式export
        if (!SCOPE_LOCAL.equalsIgnoreCase(scope)) {
            if (CollectionUtils.isNotEmpty(registryURLs)) {
                //遍历注册中心的地址。来一个一个的export
                for (URL registryURL : registryURLs) {
                    //if protocol is only injvm ,not register
                    //如果协议为injvm， 就不需要暴露，在同一个jvm内的服务
                    if (LOCAL_PROTOCOL.equalsIgnoreCase(url.getProtocol())) {
                        continue;
                    }
                    //添加dynamic参数配置
                    url = url.addParameterIfAbsent(DYNAMIC_KEY, registryURL.getParameter(DYNAMIC_KEY));
                    //添加监控中心url配置， 可选
                    URL monitorUrl = ConfigValidationUtils.loadMonitor(this, registryURL);
                    if (monitorUrl != null) {
                        url = url.addParameterAndEncoded(MONITOR_KEY, monitorUrl.toFullString());
                    }
                   ...

                    // For providers, this is used to enable custom proxy to generate invoker
                    String proxy = url.getParameter(PROXY_KEY);
                    if (StringUtils.isNotEmpty(proxy)) {
                        registryURL = registryURL.addParameter(PROXY_KEY, proxy);
                    }
                    // 使用ProxyFactory来生成接口的代理
                    Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(EXPORT_KEY, url.toFullString()));
                    //生成Invoker的包装类，实现了Invoker接口，其本身也是一个Invoker，只是在invoker的基础上扩展了ServiceConfig 
                    DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);
                    //使用Protocol来暴露服务接口到对应的注册中心
                    Exporter<?> exporter = PROTOCOL.export(wrapperInvoker);
                    //将这个Exporter实例存入ServiceConfig中的exporters属性中
                    exporters.add(exporter);
                }
            } else {
                if (logger.isInfoEnabled()) {
                    logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
                }
                Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, url);
                DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);

                Exporter<?> exporter = PROTOCOL.export(wrapperInvoker);
                exporters.add(exporter);
            }
            /**
             * @since 2.7.0
             * ServiceData Store
             * 处理服务的元数据信息
             */
            WritableMetadataService metadataService = WritableMetadataService.getExtension(url.getParameter(METADATA_KEY, DEFAULT_METADATA_STORAGE_TYPE));
            if (metadataService != null) {
                metadataService.publishServiceDefinition(url);
            }
        }
    }
    this.urls.add(url);
}

至此大致的服务暴露流程就整理完毕。再来看实现细节。

  • Protocol 协议
    可以看到：这里的协议实现是通过ExtensionLoader.getAdaptiveExtension()去加载的
Protocol PROTOCOL = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

那么这样得到的是一个什么样的结果呢？先看一下Protocol的相关实现结构图：
在这里插入图片描述
Protocol源码如下：

@SPI("dubbo")
public interface Protocol {

    int getDefaultPort();
    
    //provider端暴露接口
    @Adaptive
    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;
    
    //consumer端引用接口
    @Adaptive
    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;

    void destroy();

    default List<ProtocolServer> getServers() {
        return Collections.emptyList();
    }

}

在@SPI中指定了默认实现的名称为dubbo ,那么就要去找SPI的配置文件啦，如下：
在这里插入图片描述
可以看到dubbo对应的实现类为DubboProtocol ,因此Protocol接口的默认实现类是DubboProtocol 。

那么上文中PROTOCOL就是DubboProtocol吗？

ExtensionLoader#getAdaptiveExtension();返回的实际上是dubbo通过字节码技术重新生成的一个类，生产的类的代码如下：

package org.apache.dubbo.rpc;

import org.apache.dubbo.common.extension.ExtensionLoader;

public class Protocol$Adaptive implements org.apache.dubbo.rpc.Protocol {
    public org.apache.dubbo.rpc.Invoker refer(java.lang.Class arg0, org.apache.dubbo.common.URL arg1) throws org.apache.dubbo.rpc.RpcException {
        if (arg1 == null) throw new IllegalArgumentException("url == null");
        org.apache.dubbo.common.URL url = arg1;
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
        if (extName == null)
            throw new IllegalStateException("Failed to get extension (org.apache.dubbo.rpc.Protocol) name from url (" + url.toString() + ") use keys([protocol])");
        org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.refer(arg0, arg1);
    }

    public java.util.List getServers() {
        throw new UnsupportedOperationException("The method public default java.util.List org.apache.dubbo.rpc.Protocol.getServers() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
    }

    public void destroy() {
        throw new UnsupportedOperationException("The method public abstract void org.apache.dubbo.rpc.Protocol.destroy() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
    }

    public int getDefaultPort() {
        throw new UnsupportedOperationException("The method public abstract int org.apache.dubbo.rpc.Protocol.getDefaultPort() of interface org.apache.dubbo.rpc.Protocol is not adaptive method!");
    }

    public org.apache.dubbo.rpc.Exporter export(org.apache.dubbo.rpc.Invoker arg0) throws org.apache.dubbo.rpc.RpcException {
        if (arg0 == null) throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument == null");
        if (arg0.getUrl() == null)
            throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument getUrl() == null");
        org.apache.dubbo.common.URL url = arg0.getUrl();
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
        if (extName == null)
            throw new IllegalStateException("Failed to get extension (org.apache.dubbo.rpc.Protocol) name from url (" + url.toString() + ") use keys([protocol])");
        org.apache.dubbo.rpc.Protocol extension = (org.apache.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.export(arg0);
    }
}

可以看到，重新生成的类，对于接口中标注有@Adaptive注解的方法才给出了实现。
而实现的方式也就是通过ExtensionLoader#getExtension(extName)来获取对于的类的实例。然后代其执行对于的逻辑。

下面再来看一下ExtensionLoader#getExtension(extName)的返回接口，这里extName=dubbo 。

private T createExtension(String name) {
    //获取对于名称为dubbo的class ，这里值为org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol
    Class<?> clazz = getExtensionClasses().get(name);
    if (clazz == null) {
        throw findException(name);
    }
    try {
        //从缓存中加载class的实例，如果没有就新建一个
        T instance = (T) EXTENSION_INSTANCES.get(clazz);
        if (instance == null) {
            EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
            instance = (T) EXTENSION_INSTANCES.get(clazz);
        }
        //对类中的属性进行依赖注入
        injectExtension(instance);
        //处理包装类 ， cachedWrapperClasses存放的是Protocol所有的Wrapper类，也就是上图中的三个
        Set<Class<?>> wrapperClasses = cachedWrapperClasses;
        if (CollectionUtils.isNotEmpty(wrapperClasses)) {
            //循环wrapper类，将DubboProtocol一层一层包装起来
            for (Class<?> wrapperClass : wrapperClasses) {
                instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
            }
        }
        initExtension(instance);
        //然后再返回实例。这时候返回的就是包装了DubboProtocol的包装类的实例了
        return instance;
    } catch (Throwable t) {
        ...
    }
}

由于Protocol接口存在三个Wrapper类，因此这里返回的是一个包装了DubboProtocol的包装类。如下图所示：
在这里插入图片描述

ExtensionLoader的相关源码解读在以前章节已经有详细讨论，这里就不在赘述。
服务暴露的所有细节都在 PROTOCOL.export(wrapperInvoker);中。篇幅原因这个下篇文章中再详细讨论

  • ProxyFactory 代理工厂
ProxyFactory PROXY_FACTORY = ExtensionLoader.getExtensionLoader(ProxyFactory.class).getAdaptiveExtension();

ProxyFactory也是一个SPI接口，并指定了默认实现是javassist对应的是JavassistProxyFactory 。然后这里在方法的上也都标注了@Adaptive ，并指定了参数PROXY_KEY ，也就是说我们可以指定PROXY_KEY的值来指定默认的实现.

源码如下：

/**
 * ProxyFactory. (API/SPI, Singleton, ThreadSafe)
 */
@SPI("javassist")
public interface ProxyFactory {
    
    @Adaptive({PROXY_KEY})
    <T> T getProxy(Invoker<T> invoker) throws RpcException;

    @Adaptive({PROXY_KEY})
    <T> T getProxy(Invoker<T> invoker, boolean generic) throws RpcException;

    @Adaptive({PROXY_KEY})
    <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) throws RpcException;

}

可以看到，它也有一个Wrapper类。结构的原理如Protocol 。最终PROXY_FACTORY的值为一个包装了JavassistProxyFactory的StubProxyFactoryWrapper类
在这里插入图片描述

PROXY_FACTORY值为：
在这里插入图片描述
到此dubbo中暴露服务的流程整理完毕！

峡谷程序猿
关注
  • 2
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
专栏目录
dubbo知识点以及源码流程
04-22
dubbo知识点以及源码流程
dubbo——标签解析、服务暴露、服务引用、服务调用1
08-04
一、标签处理 二、服务暴露过程 三、服务引用过程 四、服务调用过程
记dubbo consumer服务因订阅其他有异常的服务导致超时的问题
mikelv01的博客
03-14 2550
provider端怎么处理dubbo.cloud.subscribed-services springCloudAlibaba+dubbo+nacos环境下，重启服务提供者或先启动服务消费者后启动服务提供者的情况下，消费者有时候会出现找不到服务的问题及解决方案（In the spring cloud Alibaba + Dubbo + Nacos environment, when the service provider is restarted or the service consumer is st
Dubbo2.7.6之服务暴露详细过程解析
zhaodongchao的博客
07-08 1241
请问
dubbo使用7----＞ dubbo spi源码分析
qq_34978129的博客
08-29 290
1、根据名称获取扩展点的源码分析 1.1、使用方式案例org.apache.dubbo.container.Container扩展点 默认的实现是spring @SPI("spring") public interface Container { /** * start method to load the container. */ void start(); /** * stop method to unload...
Dubbo源码阅读六：Dubbo动态生成的类
yang1060887552的专栏
02-11 3050
第1节 Dubbo动态生成的类 dubbo在调用exportServices()方法时，会使用代码生成技术动态地生成Protocol$Adaptive、ProxyFactory$Adaptive和Wrapper子类这些类。 Dubbo使用javassist动态生成类。Dubbo有两个场景使用动态类。 1）ExtensionLoader.getExtensionLoader().getAdaptiveExtension()使用JavassistCompiler生成每个类型的Adaptive类。Pro
dubbo解析-详解MetadataService
龚厂长的博客
05-19 9603
这篇文章介绍一个和元数据中心密切相关的接口MetadataService。可以这么说没有MetadataService，元数据中心就无法正常使用。 本文主要分析WritableMetadataService的实现类：InMemoryWritableMetadataService和RemoteWritableMetadataService、RemoteWritableMetadataServiceDelegate。详细分析其方法
java调试技能之dubbo调试
02-24
（比如我当初就误以为dubbo会做一个服务转发，好尴尬）下面是一个更完整架构图，可以更清晰的看到软件是如何工作的：（以下是官方说明，我觉得很有必要了解下，so）节点角色说明：Provider:暴露服务的服务提供方。...
dubbo2.7.x服务暴露流程总结
luzhensmart的专栏
09-02 428
这篇文章主要总结一下dubbo服务端启动的时候服务暴露过程，虽然官方网站和各种博客上已经有很多介绍服务暴露的帖子，但还是想把自己跟源码过程中遇到的问题和心得记录下来，算是个总结，并且本篇文章是基于dubbo最新的2.7.6版本，和官网介绍的2.6.5版本差别还是有点大的（重构了很多模块，代码逻辑比之前清晰多了，说实话这里要吐槽下之前版本的代码，常常看见一个上百行的代码，只有屈指可数的注释，真让人看的头大。。），本文也会提到某些有差异的地方： 2.7.5版本dubbo中加入了OneTimeExecution
dubbo注解暴露接口失败问题原因与解决
热门推荐
落日流年
02-12 1万+
1.@Service注解引包错误@Service正确的引包注解地址为import com.alibaba.dubbo.config.annotation.Service;2.在service层有事务注解@Transactionalspringmvc框架扫描包的时候当发现@Transactional注解时，会生成一个代理类，并对这个类进行了管理，当进行dubbo接口暴露的时候扫描的会是代理类，而不是...
（八）Dubbo常见的错误总结
HaC 的博客
12-29 4235
dubbo常见错误总结
dubbo的服务暴露过程
最新发布
05-27
Dubbo的服务暴露过程大致如下： 1. 首先，Dubbo会通过配置文件或者注解方式定义服务接口，包括接口名称、方法等信息。 2. 接着，Dubbo会将服务接口的实现注册到注册中心，包括服务名称、IP地址、端口号等信息。 3...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值