微服务中 Dubbo 和 Spring Cloud 架构技术路线对比

微服务架构是互联网很热门的话题,是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。虽然微服务架构没有公认的技术标准和规范或者草案,但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路,例如Dubbo和Spring Cloud。各大互联网公司也有自研的微服务框架,但其模式都于这二者相差不大。

微服务主要的优势如下:

一、核心部件

微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置,基于上述几种必要条件对Dubbo和Spring Cloud做出对比。

1、总体架构

Dubbo 核心部件(如下图):

Provider: 暴露服务的提供方,可以通过jar或者容器的方式启动服务

Consumer:调用远程服务的服务消费方。

Registry: 服务注册中心和发现中心。

Monitor: 统计服务和调用次数,调用时间监控中心。(dubbo的控制台页面中可以显示,目前只有一个简单版本)

Container:服务运行的容器。

▲Dubbo 总体架构

Spring Cloud总体架构如下图

Service Provider: 暴露服务的提供方。

Service Consumer:调用远程服务的服务消费方。

EureKa Server: 服务注册中心和服务发现中心。

▲Spring Cloud总体架构

点评:从整体架构上来看,二者模式接近,都需要需要服务提供方,注册中心,服务消费方。

2、微服务架构核心要素

Dubbo只是实现了服务治理,而Spring Cloud子项目分别覆盖了微服务架构下的众多部件,而服务治理只是其中的一个方面。Dubbo提供了各种Filter,对于上述中“无”的要素,可以通过扩展Filter来完善。

例如

1.分布式配置:可以使用淘宝的diamond、百度的disconf来实现分布式配置管理

2.服务跟踪:可以使用京东开源的Hydra,或者扩展Filter用Zippin来做服务跟踪

3.批量任务:可以使用当当开源的Elastic-Job、tbschedule

点评:从核心要素来看,Spring Cloud 更胜一筹,在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合,而Dubbo缺需要通过实现各种Filter来做定制,开发成本以及技术难度略高。

二、通讯协议

基于通讯协议层面对2种框架支持的协议类型以及运行效率方面进行比较;

三、服务依赖方式

Dubbo:服务提供方与消费方通过接口的方式依赖,服务调用设计如下:

interface层:服务接口层,定义了服务对外提供的所有接口

Molel层:服务的DTO对象层,

business层:业务实现层,实现interface接口并且和DB交互

因此需要为每个微服务定义了各自的interface接口,并通过持续集成发布到私有仓库中,调用方应用对微服务提供的抽象接口存在强依赖关系,开发、测试、集成环境都需要严格的管理版本依赖。

通过maven的install & deploy命令把interface和Model层发布到仓库中,服务调用方只需要依赖interface和model层即可。在开发调试阶段只发布Snapshot版本。等到服务调试完成再发布Release版本,通过版本号来区分每次迭代的版本。通过xml配置方式即可方面接入dubbo,对程序无入侵。

▲Dubbo接口依赖方式

Spring Cloud:服务提供方和服务消费方通过json方式交互,因此只需要定义好相关json字段即可,消费方和提供方无接口依赖。通过注解方式来实现服务配置,对于程序有一定入侵。

点评:Dubbo服务依赖略重,需要有完善的版本管理机制,但是程序入侵少。而Spring Cloud通过Json交互,省略了版本管理的问题,但是具体字段含义需要统一管理,自身Rest API方式交互,为跨平台调用奠定了基础。

四、组件运行流程

下图中的每个组件都是需要部署在单独的服务器上,gateway用来接受前端请求、聚合服务,并批量调用后台原子服务。每个service层和单独的DB交互。

▲Dubbo组件运行流程

gateWay:前置网关,具体业务操作,gateWay通过dubbo提供的负载均衡机制自动完成

Service:原子服务,只提供该业务相关的原子服务

Zookeeper:原子服务注册到zk上

Spring Cloud 组件运行

Spring Cloud

所有请求都统一通过 API 网关(Zuul)来访问内部服务。

网关接收到请求后,从注册中心(Eureka)获取可用服务。

由 Ribbon 进行均衡负载后,分发到后端的具体实例。

微服务之间通过 Feign 进行通信处理业务。

点评:业务部署方式相同,都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关,而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。

五、微服务架构组成以及注意事项

到底使用是dubbo还是Spring Cloud其实并不重要,重点在于如何合理的利用微服务。下面是一张互联网通用的架构图,其中每个环节都是微服务的核心部分。

(一)架构分解

(二)注意事项

服务启动方式建议使用jar方式启动,启动速度快,更容易监控

缓存、缓存、缓存,系统中能使用缓存的地方尽量使用缓存,通过合理的使用缓存可以有效的提高系统的TPS

服务拆分要合理,尽量避免因服务拆分而导致的服务循环依赖

合理的设置线程池,避免设置过大或者过小导致系统异常

六、总结

Dubbo出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过spring配置的方式即可完成服务化,对于应用无入侵。设计的目的还是服务于自身的业务为主。虽然阿里内部原因dubbo曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求。如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中增加了使用 Dubbo 的难度。

Spring Cloud 是大名鼎鼎的 Spring 家族的产品, 专注于企业级开源框架的研发。 Spring Cloud 自从发展到现在,仍然在不断的高速发展,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。

Dubbo于2017年开始又重启维护,发布了更新后的2.5.6版本,而Spring Cloud更新的非常快,目前已经更新到Finchley.M2。因此,企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题,不管是Dubbo还是Spring Cloud都是实现微服务有效的工具。

原文发布于微信公众号 - IT技术精选文摘(ITHK01)

原文发表时间:2018-04-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏喔家ArchiSelf

解读六边形架构

追溯微服务架构的渊源,一般会涉及到六边形架构。追溯六边形架构的起源,要看始作俑者Alistair Cockburn的这篇文章 http://alistair.c...

873
来自专栏北京马哥教育

15个NoSql数据库

随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是...

3488
来自专栏Java社区

如何自学Python爬虫技术(文末有福利)

1555
来自专栏蘑菇先生的技术笔记

给公司部门设计的SOA架构

1916
来自专栏成猿之路

为什么前后端分离了,你比从前更痛苦?

前后端分离早已经不是新闻,当真正分离之后确遇到了更多问题。要想解决现在的痛,就要知道痛的原因:

823
来自专栏圣杰的专栏

eShopOnContainers 知多少[4]:Catalog microservice

Catalog microservice(目录微服务)维护着所有产品信息,包括库存、价格。所以该微服务的核心业务为:

663
来自专栏FreeBuf

关于Fuzz工具的那些事儿

前段时间一直在研究fuzz工具,这里就写篇文章总结一下下。 在安全测试中,模糊测试(fuzz testing)是一种介于完全的手工渗透测试与完全的自动化测试之间...

6345
来自专栏竹清助手

如何理解一个高度抽象化的架构风格本质

REST本身是一个高度抽象化的架构风格,因而总是很难对它有一个比较深入且印象深刻的理解。写这篇文章的目的,是自己对学习REST的一个总结,也希望可以通过这篇文章...

1293
来自专栏刘君君

Rest Notes-架构上的教训(论文部分完结)

1586
来自专栏java思维导图

为什么前后端分离了,你比从前更痛苦?

前后端分离早已经不是新闻,当真正分离之后确遇到了更多问题。要想解决现在的痛,就要知道痛的原因:

452

扫码关注云+社区