为了账号安全,请及时绑定邮箱和手机立即绑定

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

2018.09.13 12:05 1357浏览
字号

大字

中字

小字

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

一、Dubbo的调用流程分析

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

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

图片描述

上述内容是直接截取的Dubbo官方网站的内容,从内容中不难看出,直连提供者一般都是在开发和测试环境下使用,可是为什么呢? 这件事情我们姑且存个疑问,后面再给大家揭开面纱。现在我们主要看一下内容的图片,可能略微有些凌乱,没关系,我们用Visio图来给他翻译一下。
图片描述

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

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

图片描述

上图就是Dubbo官方给出的架构图,对这个图建议牢记,真的有面试官会问哦
其实上图就是对直连提供者的演进或补充,我们先来解释一下这个流程:【按照图中标注的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也支持自定义扩展中心和多注册中心的配置。详情可以参见以下内容:

二、Dubbo协议剖析

Dubbo的协议部分已经被大家总结过很多遍,笔者在这里就不重复造车轮的事了,推荐搭建看一篇博客:

但是如果对底层没什么期待的童鞋,可以直接看下面的总结性内容:
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的协议之类的,使用的场景比较少,在这里就不扩展了,大家可以参考上述的博客文件进行查看和测试。

以上,就是本次与大家分析讨论的内容,大家如果有什么意见,可以随时联系我,希望对大家能产生一些帮助。
另外,Dubbo的实战课程刚刚上线,会涉及到Dubbo和微服务的诸多内容,包括异步调用、分布式事务、全链路监控以及与Dubbo、微服务相关的面试题等,也希望可以给大家带来一些收获。
《打造仿猫眼项目 以Dubbo为核心解锁微服务》

再次感谢大家。

11人推荐

若觉得本文不错,就分享一下吧!

共同学习,写下你的评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消