dubbo服务调用是阻塞的吗

不是。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

扩展资料

dubbo服务调用机制：

1、透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入，对现有的代码几乎零改动。

2、软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3、服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

4、Duibbo 对Spring 做了Schema 扩展支持，对于使用spring的项目来说非常的方便，对应用的Api几乎是没有入侵的，只需要在spring中配置启动即可。

--Dubbo

Dubbo是一种服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和  Spring框架无缝集成。

主要的核心部件：

Remoting: 网络通信框架，实现了 sync-over-async 和

request-response 消息机制

RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能

Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

已知，在项目启动过程中，我们会将dubbo的配置文件写到spring的配置文件里，如下xml文件：

<dubbo:application name="anyname_provider" />

<!-- 使用zookeeper注册中心暴露服务地址 -->

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

<!-- 用dubbo协议在20880端口暴露服务 -->

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

<!-- 声明需要暴露的服务接口 -->

<dubbo:service interface="comshxz130providerProvider"

ref="demoService" />

从官方文档中，我们能看到如下：

启动过程png

也就是说spring启动过程中，随着Spring在初始化过程中，碰到dubbo命名的标签，如（<dubbo:service>,<dubbo:registry>）等标签，会由DubboNamespaceHandler类处理，具体原理见链接Spring自定义标签

DubboBeanDefinitionParser代码如下：

public class DubboNamespaceHandler extends NamespaceHandlerSupport {    static {

VersioncheckDuplicate(DubboNamespaceHandlerclass);

}    public void init() {

registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfigclass, true));

registerBeanDefinitionParser("module", new DubboBeanDefinitionParser(ModuleConfigclass, true));

registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfigclass, true));

registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfigclass, true));

registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfigclass, true));

registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfigclass, true));

registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfigclass, true));

registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBeanclass, true));

registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBeanclass, false));

registerBeanDefinitionParser("annotation", new AnnotationBeanDefinitionParser());

}

}

遇到不同的标签，会由不同的Parser处理，这里重点看服务发布，这行代码：

registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBeanclass, true));

也就是说，当Spring容器处理完<dubbo:service>标签后，会在Spring容器中生成一个ServiceBean ，服务的发布也会在ServiceBean中完成。不妨看一下ServiceBean的定义：

public class ServiceBean<T> extends ServiceConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener<ContextRefreshedEvent>, BeanNameAware {

}

该Bean实现了很多接口，关于InitializingBean，DisposableBean，ApplicationContextAware，BeanNameAware,这些接口的使用介绍如下链接：

InitializingBean&DisposableBean

BeanNameAware& ApplicationContextAware

而在Spring初始化完成Bean的组装，会调用InitializingBean的afterPropertiesSet方法，在Spring容器加载完成，会接收到事件ContextRefreshedEvent，调用ApplicationListener的onApplicationEvent方法。

在afterPropertiesSet中，和onApplicationEvent中，会调用export()，在export()中，会暴露dubbo服务，具体区别在于是否配置了delay属性，是否延迟暴露，如果delay不为null，或者不为-1时，会在afterPropertiesSet中调用export()暴露dubbo服务，如果为null,或者为-1时，会在Spring容器初始化完成，接收到ContextRefreshedEvent事件，调用onApplicationEvent，暴露dubbo服务。

部分ServiceBean的代码如下：

public class ServiceBean<T> extends ServiceConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener<ContextRefreshedEvent>, BeanNameAware { //Spring容器初始化完成，调用

public void onApplicationEvent(ContextRefreshedEvent event) {        if (isDelay() && !isExported() && !isUnexported()) {            if (loggerisInfoEnabled()) {

               loggerinfo("The service ready on spring started service: " + getInterface());

           }            //暴露服务

           export();

       }

   }    //判断是否延迟发布

 private boolean isDelay() {

       Integer delay = getDelay();

       ProviderConfig provider = getProvider();        if (delay == null && provider != null) {

           delay = providergetDelay();

       }        return supportedApplicationListener && (delay == null || delay == -1);

   } //当bean初始化完成调用

public void afterPropertiesSet() throws Exception {        //此处省略10000行代码

       if (!isDelay()) {            //暴露服务

           export();

       }

   }

}

在export()，暴露服务过程中，如果发现有delay属性，则延迟delay时间，暴露服务，如果没有，则直接暴露服务。

public synchronized void export() {        //忽略若干行代码

       if (delay != null && delay > 0) {            //当delay不为null，且大于0时，延迟delay时间，暴露服务

           delayExportExecutorschedule(new Runnable() {                public void run() {                    //暴露服务

                   doExport();

               }

           }, delay, TimeUnitMILLISECONDS);

       } else {            //直接暴露服务

           doExport();

       }

   }

而在doExport()中，验证参数，按照不同的Protocol，比如(dubbo,injvm)暴露服务，在不同的zookeeper集群节点上注册自己的服务。

protected synchronized void doExport() {         //忽略10000行代码

       doExportUrls();        //忽略10000行代码

   } private void doExportUrls() {

       List<URL> registryURLs = loadRegistries(true);        for (ProtocolConfig protocolConfig : protocols) {            //按照不同的Protocal暴露服务

           doExportUrlsFor1Protocol(protocolConfig, registryURLs);

       }

   }

作者：一滴水的坚持

链接：https://wwwjianshucom/p/7f3871492c71

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

Dubbo是 Alibaba 开源的分布式服务框架远程调用框架，在网络间传输数据，就需要通信协议和序列化。

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是Dubbo官网是推荐我们使用Dubbo协议的，默认也是用的dubbo协议。

先介绍几种常见的协议：

缺省协议，使用基于mina117+hessian321的tbremoting交互。

连接个数：单连接

连接方式：长连接

传输协议：TCP

传输方式：NIO异步传输

序列化：Hessian二进制序列化

适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。

适用场景：常规远程服务方法调用

1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况

2、他不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

配置如下：

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

<dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo”

serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9”

buffer=“8192” accepts=“1000” payload=“8388608” />

3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。

<dubbo:protocol name="dubbo" connections="2" />

4、为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护

<dubbo:protocol name="dubbo" accepts="1000" />

Java标准的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：TCP

传输方式：同步传输

序列化：Java标准二进制序列化

适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。

适用场景：常规远程服务方法调用，与原生RMI服务互操作

RMI协议采用JDK标准的javarmi实现，采用阻塞式短连接和JDK标准序列化方式 。

基于Hessian的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：表单序列化

适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。

适用场景：需同时给应用程序和浏览器JS使用的服务。

1、Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。

2、Hessian是Caucho开源的一个RPC框架： http://hessiancauchocom ，其通讯效率高于WebService和Java自带的序列化。

基于http表单的远程调用协议。参见：[HTTP协议使用说明]

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：表单序列化

适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。

适用场景：需同时给应用程序和浏览器JS使用的服务。

基于WebService的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：SOAP文本序列化

适用场景：系统集成，跨语言调用

序列化是将一个对象变成一个二进制流就是序列化， 反序列化是将二进制流转换成对象

为什么要序列化？

Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默认hessian2。其中java、compactedjava、nativejava属于原生java的序列化。

hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的，它是dubbo RPC默认启用的序列化方式。

json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。

java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。

Dubbo是基于Netty搭建的RPC框架，为了更好地理解Netty在Dubbo中的应用，仿照Dubbo搭建了一个简易版的RPC框架。

整个调用逻辑如下：

1、生产者服务端启动Netty服务端。

2、消费者客户端通过JDK动态代理启动Netty客户端，通过注册中心地址连接生产者服务端，同时将接口调用信息（接口、方法、参数等）先序列化再发送给生产者服务端。

3、生产者服务端接收消息并通过反射调用相应方法，然后返回调用结果给消费者。

4、消费者接收生产者传来的调用结果。

新建DubboRequest类(相当于POJO)，作为消息载体

新建Dubbo消费者调用接口IUserFacade

新建Dubbo消费者拦截器

新建Dubbo服务代理类

新建Dubbo消费者

新建 dubbo服务端实现类

dubbo生产者拦截器

Dubbo生产者服务端

1、启动生产者服务端DubboServer。

2、启动消费者调用端DubboClient。

消费者客户端控制台显示如下：

生产者服务端控制台显示如下：

源码地址： https://githubcom/MAXAmbitious/netty-study/tree/master/netty-dubbo