文档章节

微服务架构的基础框架选择:Spring Cloud还是Dubbo?

 结局丶都一样
发布于 2017/04/07 15:22
字数 3320
阅读 16
收藏 1
点赞 0
评论 0

最近一段时间不论互联网还是传统行业,凡是涉及信息技术范畴的圈子几乎都在讨论微服务架构。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验,这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言,还是有不少激励的。

目前,Spring Cloud在国内的知名度并不高,在前阵子的求职过程中,与一些互联网公司的架构师、技术VP或者CTO在交流时,有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系,除了Dubbo本身较为完善的中文文档之外,不少科技公司的架构师均出自阿里系,所以就目前情况看,短期国内还是Dubbo的天下。

那么第一次实施微服务架构时,我们应该选择哪个基础框架更好呢?

以下内容均为作者个人观点,知识面有限,如有不对,纯属正常,不喜勿喷。

Round 1:背景

Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的,比如:JStorm捐赠给Apache并加入Apache基金会等,为中国互联网人争足了面子,使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。

Spring Cloud,从命名我们就可以知道,它是Spring Source的产物,Spring社区的强大背书可以说是Java企业界最有影响力的组织了,除了Spring Source之外,还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。

小结:如果拿Dubbo与Netflix套件做对比,前者在国内影响力较大,后者在国外影响力较大,我认为在背景上可以打个平手;但是若要与Spring Cloud做对比,由于Spring Source的加入,在背书上,Spring Cloud略胜一筹。不过,英雄不问出处,在背景这一点上,不能作为选择框架的主要因素,当您一筹莫展的时候,可以作为参考依据。

Round 2:社区活跃度

我们选择一个开源框架,社区的活跃度是我们极为关注的一个要点。社区越活跃,解决问题的速度越快,框架也会越来越完善,不然当我们碰到问题,就不得不自己解决。而对于团队来说,也就意味着我们不得不自己去维护框架的源码,这对于团队来说也将会是一个很大的负担。

下面看看这两个项目在github上的更新时间,下面截图自2016年7月30日:

最后更新时间为:2016年5月6日

最后更新时间为:12分钟前

可以看到Dubbo的更新已经是几个月前,并且更新频率很低。而Spring Cloud的更新是12分钟前,仍处于高速迭代的阶段。

小结:在社区活跃度上,Spring Cloud毋庸置疑的优于Dubbo,这对于没有大量精力与财力维护这部分开源内容的团队来说,Spring Cloud会是更优的选择。

Round 3:架构完整度

或许很多人会说Spring Cloud和Dubbo的对比有点不公平,Dubbo只是实现了服务治理,而Spring Cloud下面有17个子项目(可能还会新增)分别覆盖了微服务架构下的方方面面,服务治理只是其中的一个方面,一定程度来说,Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上,方案完整度恰恰是一个需要重点关注的内容。

根据Martin Fowler对微服务架构的描述中,虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点,但是由于分布式环境下解耦,也带出了不少测试与运维复杂度。

根据微服务架构在各方面的要素,看看Spring Cloud和Dubbo都提供了哪些支持。
























































 

  Dubbo Spring Cloud
服务注册中心 Zookeeper Spring Cloud Netflix Eureka
服务调用方式 RPC REST API
服务网关 Spring Cloud Netflix Zuul
断路器 不完善 Spring Cloud Netflix Hystrix
分布式配置 Spring Cloud Config
服务跟踪 Spring Cloud Sleuth
消息总线 Spring Cloud Bus
数据流 Spring Cloud Stream
批量任务 Spring Cloud Task
…… …… ……

以上列举了一些核心部件,大致可以理解为什么之前说Dubbo只是类似Netflix的一个子集了吧。当然这里需要申明一点,Dubbo对于上表中总结为“无”的组件不代表不能实现,而只是Dubbo框架自身不提供,需要另外整合以实现对应的功能,比如:

  • 分布式配置:可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外,由于其存储可以使用git,因此它天然的实现了配置内容的版本管理,可以完美的与应用版本管理整合起来。
  • 服务跟踪:可以使用京东开源的Hydra
  • 批量任务:可以使用当当开源的Elastic-Job
  • ……

虽然,Dubbo自身只是实现了服务治理的基础,其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现,但是几乎大部分关键组件都能找到第三方开源来实现,这些组件主要来自于国内各家大型互联网企业的开源产品。

RPC vs REST

另外,由于Dubbo是基础框架,其实现的内容对于我们实施微服务架构是否合理,也需要我们根据自身需求去考虑是否要修改,比如Dubbo的服务调用是通过RPC实现的,但是如果仔细拜读过Martin Fowler的microservices一文,其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢?

先来说说,使用Dubbo的RPC来实现服务间调用的一些痛点:

  • 服务提供方与调用方接口依赖方式太强:我们为每个微服务定义了各自的service抽象接口,并通过持续集成发布到私有仓库中,调用方应用对微服务提供的抽象接口存在强依赖关系,因此不论开发、测试、集成环境都需要严格的管理版本依赖,才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题,以及这也会直接影响本地开发的环境要求,往往一个依赖很多服务的上层应用,每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具,这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化,服务提供方和调用方的依赖只是依靠一纸契约,不存在代码级别的强依赖,当然REST接口也有痛点,因为接口定义过轻,很容易导致定义文档与实际实现不一致导致服务集成时的问题,但是该问题很好解决,只需要通过每个服务整合swagger,让每个服务的代码与文档一体化,就能解决。所以在分布式环境下,REST方式的服务依赖要比RPC方式的依赖更为灵活。
  • 服务对平台敏感,难以简单复用:通常我们在提供对外服务时,都会以REST的方式提供出去,这样可以实现跨平台的特点,任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时,不得不实现一层代理,用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在,当要对外提供服务时,主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

相信这些痛点也是为什么当当网在dubbox(基于Dubbo的开源扩展)中增加了对REST支持的原因之一。

小结:Dubbo实现了服务治理的基础,但是要完成一个完备的微服务架构,还需要在各环节去扩展和完善以保证集群的健康,以减轻开发、测试以及运维各个环节上增加出来的压力,这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些(如果您读过我之前关于Spring Cloud的一些核心组件使用的文章,应该能体会这些让人兴奋而激动的特性,传送门)。所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud,相对来说每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

Round 4:文档质量

Dubbo的文档可以说在国内开源框架中算是一流的,非常全,并且讲解的也非常深入,由于版本已经稳定不再更新,所以也不太会出现不一致的情况,另外提供了中文与英文两种版本,对于国内开发者来说,阅读起来更加容易上手,这也是dubbo在国内更火一些的原因吧。

Spring Cloud由于整合了大量组件,文档在体量上自然要比dubbo多很多,文档内容上还算简洁清楚,但是更多的是偏向整合,更深入的使用方法还是需要查看其整合组件的详细文档。另外由于Spring Cloud基于Spring Boot,很多例子相较于传统Spring应用要简单很多(因为自动化配置,很多内容都成了约定的默认配置),这对于刚接触的开发者可能会有些不适应,比较建议了解和学习Spring Boot之后再使用Spring Cloud,不然可能会出现很多一知半解的情况。

小结:虽然Spring Cloud的文档量大,但是如果使用Dubbo去整合其他第三方组件,实际也是要去阅读大量第三方组件文档的,所以在文档量上,我觉得区别不大。对于文档质量,由于Spring Cloud的迭代很快,难免会出现不一致的情况,所以在质量上我认为Dubbo更好一些。而对于文档语言上,Dubbo自然对国内开发团队来说更有优势。

总结

通过上面再几个环节上的分析,相信大家对Dubbo和Spring Cloud有了一个初步的了解。就我个人对这两个框架的使用经验和理解,打个不恰当的比喻:使用Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而Spring Cloud就像品牌机,在Spring Source的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。

从目前Spring Cloud的被关注度和活跃度上来看,很有可能将来会成为微服务架构的标准框架。所以,Spring Cloud的系列文章,我会继续写下去。也欢迎各位朋友一起交流,共同进步。

【一些文章与示例的汇总】:http://git.oschina.net/didispace/SpringBoot-Learning

【转载请注明出处】:http://blog.didispace.com/microservice-framework/

本文转载自:http://blog.didispace.com/microservice-framework/

共有 人打赏支持
粉丝 0
博文 10
码字总数 2354
作品 0
昌平
微服务选择Spring Cloud还是Dubbo?

点击关注 异步图书,置顶公众号 每天与你分享 IT好书 技术干货 职场知识 参与文末话题讨论,每日赠送异步图书。 ——异步小编 在阿里巴巴的生态中,微服务逐渐成为主要的服务形态,伴随着容器...

异步社区 ⋅ 04/27 ⋅ 0

微服务架构实战学习(四):RPC 框架对比

下面是对市面上比较流行的 RPC 框架的对比 以上对比是我结合各框架的网上资料以及官方文档资源总结的,在实际的使用过程中。我们可以结合我们的业务场景来选择不同的框架。 虽然说没有最好的...

雨林_a1d6 ⋅ 06/11 ⋅ 0

微服务架构的基础框架选择:Spring Cloud还是Dubbo?

最近一段时间不论互联网还是传统行业,凡是涉及信息技术范畴的圈子几乎都在讨论。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验,这对于最近正在整理Sprin...

毛爷爷夸我帅 ⋅ 2016/10/13 ⋅ 0

微服务架构的基础框架选择:Spring Cloud还是Dubbo?

最近一段时间不论互联网还是传统行业,凡是涉及信息技术范畴的圈子几乎都在讨论。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验,这对于最近正在整理Sprin...

努力学的程序员 ⋅ 2016/11/01 ⋅ 0

【开源访谈】刘军:无需“二选一”,Dubbo 将积极适配 Spring Cloud 生态

曾风靡国内的开源 RPC 服务框架 Dubbo 在重启维护后,令许多用户为之雀跃,但同时,也迎来了一些质疑的声音。互联网技术发展迅速,Dubbo 是否还能跟上时代?Dubbo 与 Spring Cloud 相比又有何...

王练 ⋅ 01/08 ⋅ 17

终极对决!Dubbo 和 Spring Cloud 微服务架构到底孰优孰劣?

前言   微服务架构是互联网很热门的话题,是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。虽然微服务架构没有公...

qq_35246620 ⋅ 01/02 ⋅ 0

Dubbo&hsf&Spring-cloud的区别

Dubbo: 简介:Dubbo是一个分布式服务框架,以及SOA治理方案。其功能主要包括:高性能NIO通讯及多协议集成,服务动态寻址与路由,软负载均衡与容错,依赖分析与降级等。 底部NIO基于netty框架...

English0523 ⋅ 2017/12/29 ⋅ 0

微服务Dubbo与Spring Cloud架构对比

微服务架构是互联网很热门的话题,是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。虽然微服务架构没有公认的技术标...

禁区铁铍人 ⋅ 2017/11/27 ⋅ 0

放弃Dubbo,选择最流行的Spring Cloud微服务架构实践与经验总结

上次写了一篇文章叫Spring Cloud在国内中小型公司能用起来吗?介绍了Spring Cloud是否能在中小公司使用起来,这篇文章是它的姊妹篇。其实我们在这条路上已经走了一年多,从16年初到现在。在使...

纯洁的微笑 ⋅ 2017/10/19 ⋅ 0

中小型互联网公司微服务实践-经验和教训

上次写了一篇文章叫Spring Cloud在国内中小型公司能用起来吗?介绍了Spring Cloud是否能在中小公司使用起来,这篇文章是它的姊妹篇。其实我们在这条路上已经走了一年多,从16年初到现在。在使...

纯洁的虫纸 ⋅ 2017/10/19 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

构建自定义组件

#前言 接上篇,因项目需由H5转到小程序,故需打造自定义对话框。而这块需使用到微信小程序的自定义组件功能。 小程序自定义组件 点击此处,可以查看小程序自定义组件的api。 从自定义组件的样...

387 ⋅ 15分钟前 ⋅ 0

Maven 项目添加本地jar包的三种方式

Maven 项目添加本地jar包的三种方式 翻译自3 ways to add local jar to maven project [TOC] 简介 在构建 Maven 项目时,有时候需要导入本地的jar包,本文介绍了三种添加本地jar包的方法。 ...

Os_yxguang ⋅ 15分钟前 ⋅ 0

long超过16位之后浏览器自动截断问题处理。

java前后端交互的过程中,定义的Long字段超过16位之后,js发生截断,从而不能跟后台数据进行匹配。 处理方法 把long型字段转成string进行处理。(可以使用json注解转换或者springmvc统一拦截...

strict_nerd ⋅ 17分钟前 ⋅ 0

一文带你搞定Integer

1.1 前言 Integer是int对应的包装类,它包含一个int类型的字段存储数据,并提供了多个基本操作,能在 int 类型和 String 类型之间互相转换。在Java5中,引入了自动装箱和自动拆箱功能,Java可...

筱虾米 ⋅ 18分钟前 ⋅ 0

Linux kernel脉络和主干总结

写在前面 前人常说,对Linux操作系统/内核的理解,是计算机行业从业者的内功,决定了你在技术领域想走多远。但内核的庞大以及学习曲线之陡峭,总让我在学习途中觉得犹如“管中窥豹”。 随着工...

Markz0928 ⋅ 33分钟前 ⋅ 0

在gcc中使用intel风格的内联汇编

很简单,内联汇编使用asm(“.intel_syntax noprefix/n”)声明一下,以后的内联汇编就可以用intel风格了,构建可执行文件时给gcc加上-masm=intel参数。 先写一个小程序测试一下: [cpp] view...

simpower ⋅ 43分钟前 ⋅ 0

NIO 之 ByteBuffer实现原理

相关文章 BIO、NIO、AIO 内部原理分析 NIO 之 Selector实现原理 NIO 之 Channel实现原理 前言 Java NIO 主要由下面3部分组成: Buffer Channel Selector 在传统IO中,流是基于字节的方式进行...

轨迹_ ⋅ 52分钟前 ⋅ 0

Jenkins docker权限问题

环境Ubuntu Server 工具 jenkins-war:2.89.2 报错信息 Cannot connect to the Docker daemon. Is the docker daemon running on this host?Build step 'Execute shell' marked build as fai......

Pulsar-V ⋅ 52分钟前 ⋅ 0

180621-一个简单的时间窗口设计与实现

如何设计一个计数的时间窗口 时间窗口,通常对于一些实时信息展示中用得比较多,比如维持一个五分钟的交易明细时间窗口,就需要记录当前时间,到五分钟之前的所有交易明细,而五分钟之前的数...

小灰灰Blog ⋅ 今天 ⋅ 0

Android之Dalvik、ART、JIT、AOT

Android之Dalvik、ART、JIT、AOT 本文内容:Dalvik、ART、JIT、AOT之间关系 本文定位:知识记录 学习过程记录,加深理解,提升文字组合表达能力。也希望能给学习的同学一些灵感 本文整理于[...

lichuangnk ⋅ 今天 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部