Dubbo手记 - 学习Dubbo的调用流程与Dubbo多协议解析

Dubbo作为目前国内主流的微服务框架之一，可谓是耳熟能详了。 今天的主题就是希望可以与大家分享讨论关于Dubbo的服务调用流程，以及Dubbo的协议之间的关系与区别。

一、Dubbo的调用流程分析

Dubbo本身主要支持两种调用流程，包括直连提供者和基于注册中心的调用。这两种哪种重要肯定不需要我再声明了 o(￣︶￣)o ，我们一定是基于注册中心的使用方式了， 不过大家是否真的理解基于注册中心的使用方式呢？

首先，我们先来看一下直连提供者是个什么样子？

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

其次，我们来了解一下注册中心的形式

二、Dubbo协议剖析

Dubbo的协议部分已经被大家总结过很多遍，笔者在这里就不重复造车轮的事了，推荐搭建看一篇博客： blog.csdn.net/fuyuwei2015…

但是如果对底层没什么期待的童鞋，可以直接看下面的总结性内容： Dubbo框架默认支持的阿里的dubbo协议，同时还支持包括rmi、hessian、http、webservice、thrift、redis在内的多种协议，下面我们来了解一下这些协议的区别与适用场景。 图片描述

如果觉得上面的表单过于难理解，可以忽略 O(∩_∩)O哈哈~，我们直接来点干的。

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

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

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

WebService协议特点： 基于CXF的frontend-simple和transports-http实现，适用于系统集成，跨语言调用。 不过如非必要，强烈不推荐使用这个方式，WebService是一个相对比较重的协议传输类型，无论从性能、效率和安全性上都不太能满足微服务的需要，如果确实存在异构系统的调用，建议可以采用其他的形式。 其余的memcached、Redis的协议之类的，使用的场景比较少，在这里就不扩展了，大家可以参考上述的博客文件进行查看和测试。

链接：www.imooc.com/article/786…

来源：慕课网