一 微服务架构的基础框架选择:Spring Cloud还是Dubbo
最近一段时间不论互联网还是传统行业,凡是涉及信息技术范畴的圈子几乎都在讨论 微服务架构
。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验,这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言,还是有不少激励的。
目前,Spring Cloud在国内的知名度并不高,在前阵子的求职过程中,与一些互联网公司的架构师、技术VP或者CTO在交流时,有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系,除了Dubbo本身较为完善的中文文档之外,不少科技公司的架构师均出自阿里系,所以就目前情况看,短期国内还是Dubbo的天下。
那么第一次实施微服务架构时,我们应该选择哪个基础框架更好呢?
以下内容均为作者个人观点,知识面有限,如有不对,纯属正常,不喜勿喷。
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略胜一筹。不过,英雄不问出处,在背景这一点上,不能作为选择框架的主要因素,当您一筹莫展的时候,可以作为参考依据。
我们选择一个开源框架,社区的活跃度是我们极为关注的一个要点。社区越活跃,解决问题的速度越快,框架也会越来越完善,不然当我们碰到问题,就不得不自己解决。而对于团队来说,也就意味着我们不得不自己去维护框架的源码,这对于团队来说也将会是一个很大的负担。
下面看看这两个项目在github上的更新时间,下面截图自2016年7月30日:
最后更新时间为:2016年5月6日
最后更新时间为:12分钟前
可以看到Dubbo的更新已经是几个月前,并且更新频率很低。而Spring Cloud的更新是12分钟前,仍处于高速迭代的阶段。
小结:在社区活跃度上,Spring Cloud毋庸置疑的优于Dubbo,这对于没有大量精力与财力维护这部分开源内容的团队来说,Spring Cloud会是更优的选择。
或许很多人会说Spring Cloud和Dubbo的对比有点不公平,Dubbo只是实现了服务治理,而Spring Cloud下面有17个子项目(可能还会新增)分别覆盖了微服务架构下的方方面面,服务治理只是其中的一个方面,一定程度来说,Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上,方案完整度恰恰是一个需要重点关注的内容。
根据Martin Fowler对 微服务架构 的描述中,虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点,但是由于分布式环境下解耦,也带出了不少测试与运维复杂度。
根据微服务架构在各方面的要素,看看Spring Cloud和Dubbo都提供了哪些支持。
以上列举了一些核心部件,大致可以理解为什么之前说Dubbo只是类似Netflix的一个子集了吧。当然这里需要申明一点,Dubbo对于上表中总结为“无”的组件不代表不能实现,而只是Dubbo框架自身不提供,需要另外整合以实现对应的功能,比如:
虽然,Dubbo自身只是实现了服务治理的基础,其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现,但是几乎大部分关键组件都能找到第三方开源来实现,这些组件主要来自于国内各家大型互联网企业的开源产品。
另外,由于Dubbo是基础框架,其实现的内容对于我们实施微服务架构是否合理,也需要我们根据自身需求去考虑是否要修改,比如Dubbo的服务调用是通过RPC实现的,但是如果仔细拜读过Martin Fowler的 microservices 一文,其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢?
先来说说,使用Dubbo的RPC来实现服务间调用的一些痛点:
相信这些痛点也是为什么当当网在dubbox(基于Dubbo的开源扩展)中增加了对REST支持的原因之一。
小结:Dubbo实现了服务治理的基础,但是要完成一个完备的微服务架构,还需要在各环节去扩展和完善以保证集群的健康,以减轻开发、测试以及运维各个环节上增加出来的压力,这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些(如果您读过我之前关于Spring Cloud的一些核心组件使用的文章,应该能体会这些让人兴奋而激动的特性, 传送门 )。所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud,相对来说每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。
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的系列文章,我会继续写下去。也欢迎各位朋友一起交流,共同进步。
作者:帅康
链接:https://www.zhihu.com/question/45413135/answer/368054381
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置,基于上述几种必要条件对 Dubbo 和 Spring Cloud 做出对比。
Dubbo 核心部件(如下图):
Spring Cloud总体架构(如下图):
点评:从整体架构上来看,二者模式接近,都需要服务提供方,注册中心,服务消费方。
Dubbo 只是实现了服务治理,而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件,服务治理只是其中的一个方面。
Dubbo 提供了各种 Filter,对于上述中“无”的要素,可以通过扩展 Filter 来完善。例如:
点评:从核心要素来看,Spring Cloud 更胜一筹,在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合,而 Dubbo 却需要通过实现各种 Filter 来做定制,开发成本以及技术难度略高。
通讯协议
基于通讯协议层面对 2 种框架支持的协议类型以及运行效率方面进行比较。
Dubbo
Dubbo 使用 RPC 通讯协议,提供序列化方式如下:
Spring Cloud
Spring Cloud 使用 HTTP 协议的 REST API。
性能比较
使用一个 Pojo 对象包含 10 个属性,请求 10 万次,Dubbo 和 Spring Cloud 在不同的线程数量下,每次请求耗时(ms)如下:
<img src="https://pic2.zhimg.com/50/v2-bf8fb9e9caddf41a67add4c696b5d9fb_hd.jpg" data-caption="" data-size="normal" data-rawwidth="288" data-rawheight="208" class="content_image" width="288">说明:客户端和服务端配置均采用阿里云的 ECS 服务器,4 核 8G 配置,Dubbo 采用默认的 Dubbo 协议。
点评:Dubbo 支持各种通信协议,而且消费方和服务方使用长链接方式交互,通信速度上略胜 Spring Cloud,如果对于系统的响应时间有严格要求,长链接更合适。
Dubbo
服务提供方与消费方通过接口的方式依赖,服务调用设计如下:
因此需要为每个微服务定义各自的 Interface 接口,并通过持续集成发布到私有仓库中。调用方应用对微服务提供的抽象接口存在强依赖关系,开发、测试、集成环境都需要严格的管理版本依赖。
通过 maven 的 install & deploy 命令把 Interface 和 Model 层发布到仓库中,服务调用方只需要依赖 Interface 和 Model 层即可。
在开发调试阶段只发布 Snapshot 版本,等到服务调试完成再发布 Release 版本,通过版本号来区分每次迭代的版本。通过 xml 配置方式即可接入 Dubbo,对程序无入侵。
<img src="https://pic4.zhimg.com/50/v2-f923af5f0574b8f018cc2d908ac22762_hd.jpg" data-caption="" data-size="normal" data-rawwidth="520" data-rawheight="198" class="origin_image zh-lightbox-thumb" width="520" data-original="https://pic4.zhimg.com/v2-f923af5f0574b8f018cc2d908ac22762_r.jpg">Spring Cloud
服务提供方和服务消费方通过 Json 方式交互,因此只需要定义好相关 Json 字段即可,消费方和提供方无接口依赖。通过注解方式来实现服务配置,对于程序有一定入侵。
<img src="https://pic1.zhimg.com/50/v2-268c70494d2991607e72dcdde4005107_hd.jpg" data-caption="" data-size="normal" data-rawwidth="560" data-rawheight="126" class="origin_image zh-lightbox-thumb" width="560" data-original="https://pic1.zhimg.com/v2-268c70494d2991607e72dcdde4005107_r.jpg">点评:Dubbo 服务依赖略重,需要有完善的版本管理机制,但是程序入侵少。
而 Spring Cloud 通过 Json 交互,省略了版本管理的问题,但是具体字段含义需要统一管理,自身 Rest API 方式交互,为跨平台调用奠定了基础。
Dubbo
下图中的每个组件都是需要部署在单独的服务器上,Gateway 用来接受前端请求、聚合服务,并批量调用后台原子服务。每个 Service 层和单独的 DB 交互。
<img src="https://pic3.zhimg.com/50/v2-e1f475119f53744c5ea3b00b7cab566c_hd.jpg" data-caption="" data-size="normal" data-rawwidth="640" data-rawheight="270" class="origin_image zh-lightbox-thumb" width="640" data-original="https://pic3.zhimg.com/v2-e1f475119f53744c5ea3b00b7cab566c_r.jpg">Dubbo 组件运行:
Spring Cloud
Spring Cloud组件运行:
点评:业务部署方式相同,都需要前置一个网关来隔绝外部直接调用原子服务的风险。
Dubbo 需要自己开发一套 API 网关,而 Spring Cloud 则可以通过 Zuul 配置即可完成网关定制。使用方式上 Spring Cloud 略胜一筹。
到底使用是 Dubbo 还是 Spring Cloud 并不重要,重点在于如何合理的利用微服务。
下面是一张互联网通用的架构图,其中每个环节都是微服务的核心部分。
<img src="https://pic1.zhimg.com/50/v2-68bda9b4fdb13348bb3ddc92f70da04a_hd.jpg" data-caption="" data-size="normal" data-rawwidth="640" data-rawheight="357" class="origin_image zh-lightbox-thumb" width="640" data-original="https://pic1.zhimg.com/v2-68bda9b4fdb13348bb3ddc92f70da04a_r.jpg">Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵,设计的目的还是服务于自身的业务为主。
虽然阿里内部原因 Dubbo 曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求。
如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是大名鼎鼎的 Spring 家族的产品, 专注于企业级开源框架的研发。
Spring Cloud 自从发布到现在,仍然在不断的高速发展,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。
Dubbo 于 2017 年开始又重启维护,发布了更新后的 2.5.7 版本,而 Spring Cloud 更新的非常快。
因此,企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题,不管是 Dubbo 还是 Spring Cloud 都是实现微服务有效的工具。