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

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

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

微服务主要的优势如下:

640?wx_fmt=png&wxfrom=5&wx_lazy=1

一、核心部件

微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置,基于上述几种必要条件对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种框架支持的协议类型以及运行效率方面进行比较;

640?wx_fmt=png

三、服务依赖方式

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

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

Molel层:服务的DTO对象层,

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

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

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

640?wx_fmt=png

▲Dubbo接口依赖方式

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

640?wx_fmt=png

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

四、组件运行流程

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

640?wx_fmt=png

▲Dubbo组件运行流程

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

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

Zookeeper:原子服务注册到zk上

640?wx_fmt=png

Spring Cloud 组件运行

Spring Cloud

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

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

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

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

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

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

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

640?wx_fmt=png

(一)架构分解

640?wx_fmt=png

(二)注意事项

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

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

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

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


六、总结

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

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

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

希望本文对你有帮助,求帮谢谢


公众号推荐:

公众号:VOA英语每日一听

微信号: voahk01

可长按扫码关注,谢谢

640?wx_fmt=jpeg


猜你喜欢

转载自blog.csdn.net/gv7lzb0y87u7c/article/details/80115523
今日推荐