DUBBO服务启动过程

Dubbo的启动主要是发布服务的过程,起到核心作用的就是ServiceConfig(ServiceConfig就是我们在Dubbo的配置文件中配置的dubbo:service这些配置项对应的实体类)。服务的启动初始位置也基本是在这里,下面我们来看看具体的实现内容。

讲基本内容前首先理清楚几个名词概念:

Invoker:Invoker的概念我们在动态代理的时候就接触过,中文的意思大概是执行者,这里其实可以理解为具体方法的执行者。其核心内容大致如下:

Class<T> getInterface();
Result invoke(Invocation invocation) throws RpcException;
URL getUrl();

通过以上的三个方法们就可以执行到具体的方法并且获得方法的执行结果。通过getUrl获得需要执行的方法具体实现细节,主要是获得具体的ref;其次就是组装方法的参数信息等等,这些信息在invocation里面都有封装;最后通过执行invoke方法触发具体的方法并返回结果。从这里可以看出Invoker是具体方法执行的最后一个守关者,获得了Invoker,就获得了具体接口的代码,然后执行代理就可以。

Invoker仅仅是作为一个代理的门面,其不仅可以代表本地执行Duubo调用的代理,还可以充当RPC时候的代理,更是可以将自己包装成一个多个Invoker聚合而成的代理(主要是处理集群的一些策略,包括负载均衡和路由等)。

Exporter:服务暴露的过程中会将Invoker转换成Exporter(暴露者),及Exporter其实包含了Invoker,主要是用于不同层面的服务发布。
其实Dubbo 还有一些比较重要的对象,像Protocol,Exchanger等等。我认为在这里直接说明不太合适,所以等到我们用到之后再开始说明。

  1. 核心的属性信息

一些基本的属性:group,version,interfaceName,interfaceClass,timeout等等。我们凡是可以在dubbo:service上配置的属性都在ServiceConfig中可以找得到对应的属性;

//dubbo对应的服务发布协议,这里可以清楚地看到Dubbo在这里使用的自己的spi机制,来保证灵活性。(至于SPI机制的具体实现,之后有机会的话会讲到,简单理解就是通过getExtensionLoader获得对应类的扩展类实现类)

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

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

private final List<URL> urls = new ArrayList<URL>();
private final List<Exporter<?>> exporters = new ArrayList<Exporter<?>>();

2.服务暴露过程

对于服务暴露来说,在ServiceConfig里面的初始方法就是export()方法了,下面我们从export方法开始来看看:

public synchronized void export() {
        if (provider != null) {
            //默认取provider的配置
            if (export == null) {
                export = provider.getExport();
            }
            if (delay == null) {
                delay = provider.getDelay();
            }
        }
        //如果export设置为false的话就直接返回
        if (export != null && ! export.booleanValue()) {
            return;
        }
        //如果设置延迟时间的话就延迟指定时间然后进行暴露
        if (delay != null && delay > 0) {
            Thread thread = new Thread(new Runnable() {
                public void run() {
                    try {
                        Thread.sleep(delay);
                    } catch (Throwable e) {
                    }
                    doExport();
                }
            });
            thread.setDaemon(true);//将暴露接口的线程设置为守护线程
            thread.setName("DelayExportServiceThread");
            thread.start();
        } else {
            doExport(); //一切暴露的核心还都是要看doExport方法。
        }
    }

    protected synchronized void doExport() {
        // 防止服务多次暴露

        // 设置默认的基本属性

        // 针对泛化接口做单独处理
        if (ref instanceof GenericService) {
            interfaceClass = GenericService.class;
            if (StringUtils.isEmpty(generic)) {
                generic = Boolean.TRUE.toString();
            }
        } else {
            try {//通过反射初始化接口(interfaceName是实现类的全称)
                interfaceClass = Class.forName(interfaceName, true, Thread.currentThread()
                        .getContextClassLoader());
            } catch (ClassNotFoundException e) {
                throw new IllegalStateException(e.getMessage(), e);
            }
            //检查定义的方法是否为接口中的方法
            checkInterfaceAndMethods(interfaceClass, methods);
            //检查引用不为空,并且引用必需实现接口
            checkRef();
            //如果到这一步的话说明类实现是自己定义的,所以设置generic为false
            generic = Boolean.FALSE.toString();
        }

        // 处理Local和Stub代理处理

        // 检查Application,Registry,Protocol的配置情况

        //将配置的属性绑定到当前对象
        appendProperties(this);

        //针对Local,Stub和Mock进行校验

        //上面的操作主要是做一些检验和初始化的操作,没有涉及到具体的暴露服务逻辑

        doExportUrls();
    }

    private void doExportUrls() {
        //取到注册中心的URL
        List<URL> registryURLs = loadRegistries(true);
        for (ProtocolConfig protocolConfig : protocols) {
            //根据配置的通信协议将服务暴露到注册中心
            doExportUrlsFor1Protocol(protocolConfig, registryURLs);
        }
    }

    private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {

        //  默认采用Dubbo协议

        //之后的部分逻辑就是想尽一切办法取到host

        //取到端口号(之后的部分关于端口的逻辑就是想尽一切办法取端口号)

        // 这个map十分重要,它的意义在于所有存储所有最终使用到的属性,我们知道一个属性例如timeout,可能在Application,provider,service中都有配置,具体以哪个为准,都是这个map处理的事情。
        Map<String, String> map = new HashMap<String, String>();
        if (anyhost) { //如果此时anyhost为true的话
            map.put(Constants.ANYHOST_KEY, "true");
        }
        // 存储简单的服务信息

        //将application,module,provider,protocol和service的信息设置到map里面
        //将应用配置的树勇按照层级存入map中。注意这里的层级关系,是一层层覆盖的 即关系为:ServiceConfig->PrtocolConfig->ProviderConfig->ModuleConfig->ApplicaionConfig

        //单独处理好method层级的参数关系

        //判断有没有配置通配协议
        if (ProtocolUtils.isGeneric(generic)) {
            map.put("generic", generic);
            map.put("methods", Constants.ANY_VALUE);
        } else {
            String revision = Version.getVersion(interfaceClass, version);
            if (revision != null && revision.length() > 0) {
                map.put("revision", revision);
            }
            //通过包装类将interfaceClass进行包装然后取得方法名字,对于wapper包装器就是将不同的类统一化
            //参考http://blog.csdn.net/quhongwei_zhanqiu/article/details/41597261理解Wapper
            String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames();
            if(methods.length == 0) {
                logger.warn("NO method found in service interface " + interfaceClass.getName());
                map.put("methods", Constants.ANY_VALUE);
            }
            else {
                //将所有的方法拼接成以逗号为分隔符的字符串
                map.put("methods", StringUtils.join(new HashSet<String>(Arrays.asList(methods)), ","));
            }
        }
        //处理token属性

        //如果配置的injvm的话就代表本地调用(本地调用还用Dubbo的话实在有点蛋疼)

        //所有的核心属性最后都成了URL的拼接属性,如果我们还记得map里面拼装了多少属性的话就知道这个URL内容有多丰富
        URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);

        // 下面是核心暴露过程,将不会省略源码
        String scope = url.getParameter(Constants.SCOPE_KEY);
        //配置为none不暴露
        if (! Constants.SCOPE_NONE.toString().equalsIgnoreCase(scope)) {

            //配置不是remote的情况下做本地暴露 (配置为remote,则表示只暴露远程服务)
            if (!Constants.SCOPE_REMOTE.toString().equalsIgnoreCase(scope)) {
                exportLocal(url);
            }
            //如果配置不是local则暴露为远程服务.(配置为local,则表示只暴露远程服务)
            if (! Constants.SCOPE_LOCAL.toString().equalsIgnoreCase(scope) ){
                if (logger.isInfoEnabled()) {
                    logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
                }
                if (registryURLs != null && registryURLs.size() > 0
                        && url.getParameter("register", true)) {
                    for (URL registryURL : registryURLs) {
                        //dynamic表示是否需要人工管理服务的上线下线(动态管理模式)
                        url = url.addParameterIfAbsent("dynamic", registryURL.getParameter("dynamic"));
                        URL monitorUrl = loadMonitor(registryURL);
                        if (monitorUrl != null) {
                            url = url.addParameterAndEncoded(Constants.MONITOR_KEY, monitorUrl.toFullString());
                        }
                        if (logger.isInfoEnabled()) {
                            logger.info("Register dubbo service " + interfaceClass.getName() + " url " + url + " to registry " + registryURL);
                        }
                       ====================================================
                       //取到invoker对象(ref为接口实现类的引用)
                        Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
                        //将invoker转化为exporter对象
                        Exporter<?> exporter = protocol.export(invoker);
                        exporters.add(exporter); //将exporter添加到需要暴露的列表中取
                    }
                    ================================================================
                } else {
                    //如果找不到注册中心的话就自己充当自己的注册中心吧
                    Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);

                    Exporter<?> exporter = protocol.export(invoker);
                    exporters.add(exporter);
                }
            }
        }
        //多个协议就有多个url与其对应,所以要一一存储。
        this.urls.add(url);
    }

通过ServicConfig中的内容分解,我们看出来里面主要做的内容如下:
检验所需参数的合法性
将多层的参数(可能重复配置)最终整理出最终的结果(map),然后根据参数拼接成暴露服务需用到的url。
处理generic,Stub,injvm等其他需要支持的内容,补充dubbo的功能多样性,但是都不涉及核心流程。
根据对应的协议将服务进行暴露(将提供的服务推送到注册中心供服务调用者发现),默认使用Dubbo协议。

原文地址:http://blog.51cto.com/13833251/2153917

时间: 2024-11-05 22:54:26

DUBBO服务启动过程的相关文章

Windows平台下Oracle监听服务启动过程中日志输出

Windows平台下Oracle监听服务启动过程中日志输出记录. 日志目录:D:\app\Administrator\diag\tnslsnr\WIN-RU03CB21QGA\listener\trace\listener.log 日志输出内容: Sat Aug 06 20:38:44 2016 系统参数文件为D:\app\Administrator\product\11.2.0\dbhome_1\network\admin\listener.ora 写入d:\app\administrator

Android 输入管理服务启动过程的流程

接上一篇"Android窗口管理服务相关对象的创建流程",这两天分析了一下Android 输入管理服务启动过程的流程,流程图如下所示. 版权声明:本文为博主原创文章,未经博主允许不得转载.

What?一个 Dubbo 服务启动要两个小时!

前言 前几天在测试环境碰到一个非常奇怪的与 dubbo 相关的问题,事后我在网上搜索了一圈并没有发现类似的帖子或文章,于是便有了这篇. 希望对还未碰到或正在碰到的朋友有所帮助. 现象 现象是这样的,有一天测试在测试环境重新部署一个 dubbo 应用的时候发现应用"启动不起来". 但过几个小时候之后又能自己慢慢恢复,并能够对外提供 dubbo 服务. 但其实经过我后续排查发现刚开始其实并不是启动不起来,而是启动速度非常缓慢,所以当应用长时间启动后才会对外提供服务. 而这个速度慢到居然要花

Android AudioPolicyService服务启动过程

AudioPolicyService是策略的制定者,比如什么时候打开音频接口设备.某种Stream类型的音频对应什么设备等等.而AudioFlinger则是策略的执行者,例如具体如何与音频设备通信,如何维护现有系统中的音频设备,以及多个音频流的混音如何处理等等都得由它来完成.AudioPolicyService根据用户配置来指导AudioFlinger加载设备接口,起到路由功能. AudioPolicyService启动过程 AudioPolicyService服务运行在mediaserver进

Docker Registry服务启动过程浅析

当我们pull一个registry镜像或者自己制作一个镜像之后,使用命令docker run -d -p 5000:5000 registry,就可以启动一个私有容器服务,那么究竟是怎么做到的呢? 首先docker ps显示cmd是 "docker-registry",但是启动的时候并没有输入. [email protected]:/home/opuser# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

dubbo服务启动正常,但是访问不到服务,在监测中心也找不服务的原因之一

配置文件没有加全. 之前加载spring配置文件是指定的文件,后面发现自己的配置文件不止一个,导致项目出错,虽然启动没有报错,在zookeeper也能找到对应的服务节点,但是在这个接口明显是访问不到的,所以在监控中心是不存在对应的服务接口. 原文地址:https://www.cnblogs.com/hirampeng/p/10236705.html

Openstack liberty中nova-compute服务的启动过程

前段时间撰文分析了"云主机的启动过程"源码,读者应该注意到了nova-scheduler,nova-compute等组件是通过发起rpc.cast, rpc.call调用完成交互的.那今天我打算介绍下nova-compute服务的启动过程,并重点分析下其与AMQP(rabbitmq)链接的建立过程. 在CentOS 7中启动nova-compute服务,执行路径是这样的: systemctl start openstack-nova-compute.service -> /usr

shell脚本生成服务演示服务启动、停止过程。

1.编写服务脚本/root/bin/testsrv.sh,完成如下要求 1.编写服务脚本/root/bin/testsrv.sh,完成如下要求 (1) 脚本可接受参数: start, stop, restart, status(2) 如果参数非此四者之一,提示使用格式后报错退出(3) 如是start:则创建/var/lock/subsys/SCRIPT_NAME, 并显示"启动成功"考虑:如果事先已经启动过一次,该如何处理?(4) 如是stop:则删除/var/lock/subsys/

你所不知道的SQL Server数据库启动过程(用户数据库加载过程的疑难杂症)

前言 本篇主要是上一篇文章的补充篇,上一篇我们介绍了SQL Server服务启动过程所遇到的一些问题和解决方法,可点击查看,我们此篇主要介绍的是SQL Server启动过程中关于用户数据库加载的流程,并且根据加载过程中所遇到的一系列问题提供解决方案. 其实SQL Server作为微软的一款优秀RDBMS,它启动的过程中,本身所带的那些系统库发生问题的情况相对还是很少的,我们在平常使用中,出问题的大部分集中于我们自己建立的用户数据库. 而且,相对于侧重面而言,其实我们更关注的是我们自己建立的用户数