Dubbo-发布服务执行的流程

我们以dubbo 的xml配置为例：

dubbo服务发布只需在springxml中如下配置即可：

<dubbo:service interface="comalibabadubbodemoDemoService" ref="demoService" />

通过dubbo于spring的融合可以了解到<dubbo:service>标签是通过ServiceBean解析封装。

ServiceBean这个类继承 了ServiceConfig实现了spring的5个接口

InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener, BeanNameAware 来融入到spring的启动过程。

ServiceBean实现了 ApplicationListener 接口，当spring容器触发了ContextRefreshedEvent事件时，

就会调用 ServiceConfig 中的export()方法发布申明的dubbo服务，

ServiceConfig 中的export()方法部分源码如下，如果申明了delay（延迟多少），那么延迟调用doExport()发布这个服务，如果没有设置则直接调用doExport()发布服务：

接下来看ServiceConfig的doExport()方法

1，检查中是否配置了interface, 如果为空，那么抛出异常：

if (interfaceName == null || interfaceNamelength() == 0) { throw new IllegalStateException("interface not allow null!");}

2，检查接口类型必需为接口

if(! interfaceClassisInterface()) {

throw new IllegalStateException("The interface class " + interfaceClass + " is not a interface!");

}

3，检查方法是否在接口中存在

4，检查引用不为空，并且引用必需实现接口 interface="comalibabadubbodemoDemoService" ref="demoService"

5，检查checkApplication(); checkRegistry(); checkProtocol();有效性。

6，调用ServiceConfigdoExportUrls()发布dubbo服务

ServiceConfigdoExportUrls()如下：

通过调用loadRegistries(true)得到所有registry的url地址，例如配置了

<dubbo:registry address="zookeeper://127001:2181">

配置结果为dubboregistryaddress=zookeeper://127001:2181；

protocols就是将要发布服务的协议集合(dubbo服务可以同时暴露多种协议)，例如配置了

<dubbo:protocol name="dubbo" port="20880">

dubboprotocolname=dubbo ,  dubboprotocolport=20880

ServiceConfigdoExportUrlsFor1Protocol()

先把application、module、provider、protocol、exporter、registries、monitor所有属性封装到Map中例如protocol=dubbo，host=10001，port=20880，path=comalibabadubbodemoTestService等，然后构造dubbo定义的统一数据模型URL:

URL url = new URL(name, host, port, (contextPath == null || contextPathlength() == 0 "" : contextPath + "/") + path, map);

这个url非常重要，贯穿整个dubbo服务的发布和调用过程，可以在服务发布后在dubbo-monitor中看到；

ServiceConfigdoExportUrlsFor1Protocol()中根据scope判断服务的发布范围：

如果配置scope = none， 那么不需要发布这个dubbo服务；

没有配置scope = none，且配置的scope != remote， 那么本地暴露 这个dubbo服务；

没有配置scope = none，且配置的scope != remote且配置的scope != local，那么远程暴露这个dubbo服务（例如远程暴露这个服务到zk上，默认情况下scope没有配置，就是在这里发布服务）；

以上如果执行成功，会把dubbo服务到zookeeper上，invokergetUrl()的值为

registry://1005387:2188/comalibabadubboregistryRegistryServiceapplication=dubbo-test&dubbo=200&export=dubbo%3A%2F%2F105216218%3A20886%2FcomalibabadubbodemoDemoService%3Fanyhost%3Dtrue%26application%3Ddubbo-test%26dubbo%3D200%26interface%3DcomalibabadubbodemoDemoService%26loadbalance%3Droundrobin%26methods%3DsayHello%26owner%3Dafei%26pid%3D2380%26side%3Dprovider%26timestamp%3D1509953019382&owner=afei&pid=2380®istry=zookeeper×tamp=150995301934：

接下来我们分析

Protocolexport()暴露服务接口：

然后调用RegistryProtocolexport()：

核心调用registryregister(registedProviderUrl)。

调用AbstractRegistryregister(URL)，把这次需要注册的URL加到Set registered中，即本地缓存新的注册URL；

在ZookeeperRegistrydoRegister(URL)调用AbstractZookeeperClientcreate()，toUrlPath将URL形式的地址转换成zookeeper路径，最终在AbstractZookeeperClient中把需要发布的服务的URL保存到zookeeper：

ZookeeperRegistrydoRegister(url)注册服务如果失败：

如果开启了启动检查check=true，那么直接抛出异常；

如果没有开启启动检查，那么将失败的注册请求记录到失败列表，定时重试;

核心调用registrysubscribe(overrideSubscribeUrl, overrideSubscribeListener):

对发布的dubbo服务的这个url进行监听， 当服务变化有时通知重新暴露服务， 以zookeeper为例，暴露服务会在zookeeper生成一个节点，当节点发生变化的时候会触发overrideSubscribeListener的notify方法重新暴露服务

注册服务失败的重试机制：

注册服务失败后，会将url加入重试url集合中，failedRegisteredadd(url);重试任务在FailbackRegistry中实现：

注册的监听机制：

订阅并设置监听registrysubscribe(overrideSubscribeUrl, overrideSubscribeListener);

--> FailbackRegistrysubscribe(URL url, NotifyListener listener)

--> ZookeeperRegistrydoSubscribe(final URL url, final NotifyListener listener)，部分实现源码如下：

当服务有变化的时候:

doNotify(url, listener, urls);

AbstractRegistrynotify(URL url, NotifyListener listener, List urls)

--> RegistryDirectorynotify(List urls)

--> RegistryDirectoryrefreshInvoker(List invokerUrls)，这里调用toMethodInvokers(Map> invokersMap)的实现比较重要，将invokers列表转成与方法的映射关系，且每个方法对应的List需要通过Collectionssort(methodInvokers, InvokerComparatorgetComparator());排序，然后，还要将其转为unmodifiable的map

其中 InvokerComparator 的定义如下，即直接根据url进行比较排序

dubbo协议发布服务会调用DubboProtocolexport()的过程：

从Invoker中获取URL： URL url = invokergetUrl();

根据URL得到key, 由暴露的服务接口+端口组成，例如comalibabadubbodemoDemoService:20886 ；  String key = serviceKey(url);

构造DubboExporter存到Map中local cache化：

DubboExporter exporter = new DubboExporter(invoker, key, exporterMap); exporterMapput(key, exporter);

调用DubboProtocolopenServer()开启netty(默认)服务保持通信，并设置requestHandler处理consumer对provider的调用请求；

DubboProtocolopenServer()：

key的值就是IP:Port，例如105217167:20886，根据key从serverMap中如果取不到ExchangeServer，表示还没绑定服务端口，需要调用createServer(url)-->Exchangersbind(url, requestHandler)-->TransportersgetTransporter()bind(url, handler)(dubbo支持mina，netty，grizzly，默认实现是netty) --> NettyTransporterbind(URL, ChannelHandler) --> NettyServeropen()；

dubbo默认调用的是netty

Netty服务几个重要的地方

构造 ChannelPipeline 时指定了编码&解码，其中编码为NettyCodecAdaptergetEncoder()，解码为NettyCodecAdaptergetDncoder()；

指定了handler为final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);处理请求；

解析dubbo-service标签

由此可以看出，服务暴露的过程，也就是ServiceBean的创建过程。

读取服务提供配置文件，初始化服务配置参数：protocol（dubbo 、hessian、>

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。而Dubbo则是SOA服务化治理方案的一个核心框架。

Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。

作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：

Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出 服务提供方（Provider） 和 服务消费方（Consumer） 两个角色。

Dubbo包含 远程通讯、服务集群和服务发现与注册 三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo服务组件调用关秕说明 ：

Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。

下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：

从上图可以看出， Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的） 。

根据官方提供的，对于上述各层之间关系的描述，如下所示：

dubbo实现了分布式远程调用框架，多运行节点既能提高可靠性，又能提升负载能力。dubbo配置主要有注册中心（推荐zookeeper或redis）、提供者provider、消费者consumer，注册中心是第三方实现，所以主要配置好服务提供者和消费者就可以了。实际上服务接口和实现都是需要我们自己设计和实现的，dubbo做的事情就是将服务实现发布到注册中心，然后消费者从注册中心订阅服务接口，之后对接口的调用就由dubbo调度提供者去执行并返回结果。以下配置都有源码，见右侧“免费资源”。

提供者provider的配置：提供者是独立运行的节点，可以多实例运行，将服务注册到注册中心

必须要有application name，注册中心配置zookeeper，协议dubbo，超时6秒失败不重试，提供者加载repository和service层bean，然后发布接口service。

<dubbo:application name="ite-provider" />

<dubbo:registry address="zookeeper://127001:2181"/>

<dubbo:protocol name="dubbo" port="20880" />

<dubbo:provider timeout="6000" retries="0"/>

<import resource="classpath:cachexml"/>

<import resource="classpath:ite-repositoryxml"/>

<import resource="classpath:ite-servicexml"/>

<import resource="classpath:ite-providerxml"/>

ite-providerxml，ref引用的bean是ite-servicexml已经定义好的接口实现，dubbo:service就是把接口实现发布到注册中心

<dubbo:service ref="codeListService" interface="comitecheastitedomainserviceCodeListService" />

<dubbo:service ref="idService" interface="comitecheastitedomainserviceIdService" />

<dubbo:service ref="passwordService" interface="comitecheastitedomainservicePasswordService" />

<dubbo:service ref="rolePermissionService" interface="comitecheastitedomainserviceRolePermissionService" />

provider是可以独立运行的，dubbojar里面有assembly目录，运行mvn assembly:directory就可以生成能直接运行的provider目录

assemblyxml内容，可以切换dir或targz两种格式

<assembly>

<id>assembly</id>

<formats>

<!-- <format>targz</format> -->

<format>dir</format>

</formats>

<includeBaseDirectory>true</includeBaseDirectory>

<fileSets>

<fileSet>

<directory>src/main/assembly/bin</directory>

<outputDirectory>bin</outputDirectory>

<fileMode>0755</fileMode>

</fileSet>

<fileSet>

<directory>src/main/assembly/conf</directory>

<outputDirectory>conf</outputDirectory>

<fileMode>0644</fileMode>

</fileSet>

<fileSet>

<directory>src/test/resources</directory>

<outputDirectory>conf</outputDirectory>

<fileMode>0644</fileMode>

</fileSet>

</fileSets>

<dependencySets>

<dependencySet>

<outputDirectory>lib</outputDirectory>

</dependencySet>

</dependencySets>

</assembly>

dubboproperties，运行startbat或startsh时，将从属性文件读取dubbo配置信息，provider节点可以多处复制并运行。

dubbocontainer=log4j,spring

dubboapplicationname=ite-provider

dubboregistryaddress=zookeeper://127001:2181

dubbomonitorprotocol=registry

dubboprotocolname=dubbo

dubboprotocolport=20880

dubbospringconfig=providerxml

dubbolog4jfile=logs/ite-providerlog

dubbolog4jlevel=WARN

消费者consumer的配置，使用dubbo:reference订阅注册中心里的服务即可，然后就可以@Autowired注入服务接口了。

<dubbo:application name="ite-consumer" />

<dubbo:registry address="zookeeper://127001:2181"/>

<dubbo:reference id="codeListService" interface="comitecheastitedomainserviceCodeListService" />

<dubbo:reference id="idService" interface="comitecheastitedomainserviceIdService" />

<dubbo:reference id="passwordService" interface="comitecheastitedomainservicePasswordService" />

<dubbo:reference id="rolePermissionService" interface="comitecheastitedomainserviceRolePermissionService" />

如果前端项目是一个消费者，就可以在webxml里直接加载consumerxml订阅服务了。

<listener>

<listener-class>orgspringframeworkwebcontextContextLoaderListener</listener-class>

</listener>

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>classpath:consumerxml,classpath:cachexml,classpath:shiroxml,classpath:frontxml</param-value>

</context-param>

实际上本地调试开发时，可以不必启用分布式配置，只需要更改webxml即可，所有的服务都已经是配置好了的。

<listener>

<listener-class>orgspringframeworkwebcontextContextLoaderListener</listener-class>

</listener>

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>classpath:ite-repositoryxml,classpath:ite-servicexml,classpath:cachexml,classpath:shiroxml,classpath:frontxml</param-value>

</context-param>

zookeeper的配置很简单，

wget >

答案是肯定可以的，我将从下面几点进行说明:

1dubbo 的调用流程

2Dubbo整体设计

3从源码上说明注册中心挂了还是可以继续通信的

Dubbo 调用流程

架构图

流程说明：

1Provider(提供者)绑定指定端口并启动服务

2提供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储

3Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心

4注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。

5Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。

6Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer

这么设计的意义：

Dubbo 整体设计

其协作流程如下：

从源码上说明注册中心挂了还是可以继续通信的

首先要把消费者注册到Zookeeper注册中心

然后使用RegistryDirectory 监听一下几个目录(会自动触发一次去获取这些目录上的当前数据)

当前所引入的服务的动态配置目录：/dubbo/config/dubbo/orgapachedubbodemoDemoService:111:g1configurators

比如监控providers 目录：

当有服务提供者注册，zookeeper会自动推动给订阅的消费者，然后转换为invoker存储到缓存中

我们在看调用时的代码：

我们看到 FailoverClusterInvoker 的doInvoke方法

Invoker invoker = select(loadbalance, invocation, copyInvokers, invoked);

此方法根据负载均衡器去缓存中获取一个invoker,

上面的 copyInvokers 就是上面我们缓存进去的 List

invokers = routerChainroute(getConsumerUrl(), invocation);

总结

在我们系统启动时，已经缓存了注册中心上的所有服务，后续的注册中心挂了只会影响到后续则注册，不会影响调用！

Dubbo分布式的RPC，微服务框架，

包括三个关键功能：基于接口的远程调用，容错与负载均衡，服务自动注册与发现。

Dubbo使得调用远程服务就像调用本地java服务一样简单。

参考Dubbo官方文档：包括实现细节，远程调用细节，服务提供者暴露服务。

主要流程。

1、provider向注册中心去注册

2、consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务

3、consumer调用provider

4、consumer和provider都异步的通知监控中心

基于zk作为注册中心：

提供者在启动时，向注册中心zk 注册自己提供的服务。

消费者在启动时，向注册中心zk 订阅自己所需的服务。

所以是可以的，消费者在启动时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用，消费者本地有一个生产者的列表，他会按照列表继续工作，倒是无法从注册中心去同步最新的服务列表，短期的注册中心挂掉是不要紧的，但一定要尽快修复，挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的

通常我们想调用别人的dubbo服务时，我们需要在项目中引入对应的jar包。而泛化调用的作用是，我们无需依赖相关jar包，也能调用到该服务。

这个特性一般使用在网关类项目中，在业务开发中基本不会使用。

假设我现在要调用下面的接口服务

在xml文件做以下配置

然后注入使用

在两种调用方式中，我们都需要使用被调用接口的字符串参数生成GenericService，通过GenericService的$invoke间接调用目标接口的接口。

$invoke的三个参数分别为，方法名，方法参数类型数组，方法参数数组。

可以看到泛化调用的一个复杂性在于$invoke的第三个参数的组装，下面介绍几种复杂入参的调用方式

首先丰富提供者接口

与入参相似，虽然$invoke的返回定义为Object，实际上针对不同类型有不同的返回。

泛化调用和直接调用在消费者者端，在 使用上的区别 是，我们调用服务时使用的接口为GenericService，方法为$invoker。在 底层的区别 是，消费者端发出的rpc报文发生了变化。

在使用上，不管哪种配置方式，我们都需要配置generic=true

设置generic=true后，RefereceConfig的interfaceClass会被强制设置为GenericService

这也使得我们的RefereanceBean返回的是GenericService类型的代理。

生成的代理是GenericService的代理只是我们使用方式上的变化，更为核心的是，底层发送的rpc报文发生了什么变化。

Dubbo的rpc报文分为header和body两部分。我们这边只需要关注body部分。构造逻辑如下

那么我们通过直接调用与泛化调用ByeService的bye方法在报文上有啥区别呢？

我一开始以为报文中的path是GenericeService，其实并没有，path就是我们调用的目标方法。

path来源？？？todo

而报文中的方法名，方法参数类型以及具体参数，还是按照GenericeService的$invoke方法入参传递的。

这么个二合一的报文，发送到提供者那边，它估计也会很懵逼，我应该怎么执行？

所以针对泛化调用报文还会把generic=true放在attchment中传递过去

具体逻辑在GenericImplFilter中。

GenericImplFilter中有很多其他逻辑，比如泛化调用使用的序列化协议，正常接口走泛化调用的模式，我们只需要设置attachment的那部分。

知道消费者端报文发生了什么变化，那么接下来就去看提供者端如何处理这个改造后的报文。

总结一下ReferenceConfig中interfaceClass和interfaceName的区别？(这道面试题好像不错)

interfaceClass用于指定生成代理的接口

interfaceName用于指定发送rpc报文中的path(告诉服务端我要调用那个服务)

消费者泛化调用的rpc报文传递到提供者还不能直接使用，虽然path是对的，但是实际的方法名，参数类型，参数要从rpc报文的参数中提取出来。

GenericFilter就是用来做这件事情。

在提供者这边，针对泛化调用的逻辑全部封装到了GenericFilter，解耦的非常好。

注意第4个条件，一开始很疑惑，后来发现rpc报文中的path是目标接口的，这边invokergetInterface()返回的肯定就是实际接口了

这边有个疑问，为什么这边还要再次反序列化一次，netty不是有decoder么？？

嗯，你别忘了，针对一个POJO你传过来是一个Map，从Map转换为POJO需要这边进一步处理。

这边需要注意一下！！针对接口的泛化调用，抛出的异常都会经过GenericException包装一下。

从功能上来看，泛化调用提供了在没有接口依赖情况下进行的解决方案，丰富框架的使用场景。

从设计上来看，泛化调用的功能还是通过扩展的方式实现的，侵入性不强，值得学习借鉴。

Dubbo是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。

Dubbo内部使用了 Netty、Zookeeper，保证了高性能高可用性，使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用和灵活扩展，使前端应用能更快速的响应多变的市场需求。

另外，分布式架构可以承受更大规模的并发流量。

Dubbo开始于电商系统，因此在这里先从电商系统的演变讲起。

当网站流量很小时，只需一个应用，将所有功能如下单支付等都部署在一起，以减少部署节点和成本。

缺点：单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加越来越难以维护

垂直应用架构解决了单一应用架构所面临的扩容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。

缺点：但是在垂直架构中相同逻辑代码需要不断地复制，不能复用。

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。

课程目标：

了解远程调用PRC的概念，分布式应用为什么使用RPC, 基于PRC协议的Dubbo的使用。Dubbo框架的特点，框架的组件;基于Dubbo服务提供者，消费者，注册中心Zookeeper的分布式应用的开发部署， Dubbo的负载均衡实现。微服务的开发 Spring + Dubbo + Zookeeper + Linux

适用人群：

适合有Java基础，要进入到互联网行业的开发人员，微服务开发。

动力节点的Dubbo课程以实战为主讲解，从基础开始手把手式地详细讲解RPC概念，PRC在分布式应用的重要作用。Dubbo分布式服务框架的应用入门基础。传统应用到分布式以及微服务的转变思想。Dubbo协议的特点。Dubbo分布式服务的详细开发流程、Dubbo服务的实施部署，Zookeeper的服务管理等。

课程目录：

•001dubbo视频教程-dubbo前言

•002dubbo视频教程-dubbo概述

•003dubbo视频教程-初识dubbo

•004dubbo视频教程-dubbo前世今生

•005dubbo视频教程-dubbo结构概述-1

•006dubbo视频教程-dubbo结构概述-2

•007dubbo视频教程-dubbo的使用-直连方式-1

•008dubbo视频教程-dubbo的使用-直连方式-2

•009dubbo视频教程-dubbo的使用-直连方式-3

•010dubbo视频教程-dubbo的使用-直连方式-4

•011dubbo视频教程-dubbo服务化最佳实践-概述

•012dubbo视频教程-dubbo服务化最佳实践-1

•013dubbo视频教程-dubbo服务化最佳实践-2

•014dubbo视频教程-dubbo服务化最佳实践-3

•015dubbo视频教程-dubbo服务化最佳实践-4

•016dubbo视频教程-dubbo服务化最佳实践-5

•017dubbo视频教程-注册中心概述

•018dubbo视频教程-windows下安装及配置zookeeper

•019dubbo视频教程-linux下安装及配置zookeeper

•020dubbo视频教程-内容回顾

•021dubbo视频教程-dubbo实例-使用注册中心-1

•022dubbo视频教程-dubbo实例-使用注册中心-2

•023dubbo视频教程-dubbo实例-使用注册中心-3

•024dubbo视频教程-dubbo实例-使用注册中心-4

•025dubbo视频教程-dubbo实例-使用注册中心-5

•026dubbo视频教程-dubbo实例使用linux注册中心

•027dubbo视频教程-dubbo实例-版本号version的使用-1

•028dubbo视频教程-dubbo实例-版本号version的使用-2

•029dubbo视频教程-dubbo实例-版本号version的使用-3

•030dubbo视频教程-dubbo实例-版本号version的使用-4

•031dubbo视频教程-解决学生问题

•032dubbo视频教程-dubbo配置中常见属性

•033dubbo视频教程-dubbo的高稳定性

•034dubbo视频教程-监控中心-1

•035dubbo视频教程-监控中心-2

Dubbo实战视频教程：

>

以上就是关于Dubbo-发布服务执行的流程全部的内容，包括:Dubbo-发布服务执行的流程、dubbo原理：服务暴露、Dubbo分布式服务框架介绍等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！