理解Dubbo的调用流程与Dubbo多协议解析

84 阅读 0 评论 56 点赞

我是靠谱客的博主怡然大白，最近开发中收集的这篇文章主要介绍理解Dubbo的调用流程与Dubbo多协议解析，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

Dubbo作为目前国内主流的微服务框架之一

一、Dubbo的调用流程分析

Dubbo本身主要支持两种调用流程，包括直连提供者和基于注册中心的调用

直连提供者一般都是在开发和测试环境下使用

我们将所有的配置和实现细节过滤，其实它就只是说明一件事， Consumer明确知道Provider的家庭住址，稍不顺心就直接抄家伙去Provider家去找它麻烦，这其实就是直连提供者。
在我们的分布式环境中，直连提供者会带来很大的问题 - 动态扩容，设想我们如果每上线一个新的服务都要让Consumer知道producer的地址，是一个非常麻烦的事情，实现的不好的就是将这些写在代码里了。实现的灵活点的会将地址写在配置文件里，但无论哪种形式，都需要重启所有Consumer，是不是很崩溃，所以我们说，这种实现仅仅适用于测试和开发环境。

Dubbo基于注册中心调用架构图：

基于注册中心调用形式对直连提供者的演进或补充，解释一下这个流程：【按照图中标注的0，1，2，3，4，5的顺序】

0：Container是Dubbo提供的容器，用于承载Provider，这个我们可以暂时忽略

1：Provider会在启动时，将自己的“家庭地址”注册在注册中心里

2：Consumer这个私家侦探，会在注册中心留下眼线【subscribe】

3：当注册中心出现变化时，就通知【notify】相关的Consumer，Consumer会将这些地址缓存在本地中，产生一个Provider住址列表

4：当Consumer需要时，就会根据本地缓存的住址列表，抄家伙去对应的家庭住址找Provider的麻烦

5：dubbo本身是有监控的【Monitor】，provider和consumer都会将一些统计信息进行监控。

刨除0和5我们不管，其实我们可以很容易的发现，无论是直连提供者还是注册中心的形式，最终Consumer都会根据详细住址找到的Provider，只不过是获取家庭住址的形式变化了。

      Dubbo的注册中心最常见的是Zookeeper和Redis这些常见的分布式中间件，同时Dubbo也支持自定义扩展中心和多注册中心的配置。详情可以参见以下内容：
      https://dubbo.gitbooks.io/dubbo-user-book/content/demos/multi-registry.html
      https://dubbo.gitbooks.io/dubbo-dev-book/content/impls/registry.html

二、Dubbo协议剖析

Dubbo的协议部分已经被大家总结过很多遍，推荐搭建看一篇博客：https://blog.csdn.net/fuyuwei2015/article/details/72848310/

Dubbo框架默认支持的阿里的dubbo协议，同时还支持包括rmi、hessian、http、webservice、thrift、redis在内的多种协议，下面我们来了解一下这些协议的区别与适用场景

Dubbo协议特点：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串，基于以上描述，我们一般建议Dubbo用于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

RMI协议特点：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。基于以上描述，我们一般对传输管道和效率没有那么高的要求，同时又有传输文件这一类的要求时，可以尝试采用RMI协议。

Hessian协议特点：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。比较适用于需同时给应用程序和浏览器JS使用的服务，Hessian协议的相关内容与HTTP基本差不多，这里就不再赘述了。

WebService协议特点：基于CXF的frontend-simple和transports-http实现，适用于系统集成，跨语言调用。不过如非必要，强烈不推荐使用这个方式，WebService是一个相对比较重的协议传输类型，无论从性能、效率和安全性上都不太能满足微服务的需要，如果确实存在异构系统的调用，建议可以采用其他的形式。

其余的memcached、Redis的协议之类的，使用的场景比较少，在这里就不扩展，了解即可