Dubbo 和 SpringCloud 微服务架构对比

/ DubboSpringCloudmiroservice / 没有评论 / 3017浏览

Dubbo 和 SpringCloud 微服务架构对比

Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵,设计的目的还是服务于自身的业务为主。

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

虽然微服务架构没有公认的技术标准和规范或者草案,但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路,例如 DubboSpring Cloud

各大互联网公司也有自研的微服务框架,但其模式都与这二者相差不大。

微服务主要的优势

降低复杂度

将原来耦合在一起的复杂业务拆分为单个服务,规避了原本复杂度无止境的积累。

每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界;每个服务开发者只专注服务本身,通过使用缓存、DAL 等各种技术手段来提升系统的性能,而对于消费方来说完全透明。

可独立部署

由于微服务具备独立的运行进程,所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可,降低了测试的工作量同时也降低了服务发布的风险。

容错

在微服务架构下,当某一组件发生故障时,故障会被隔离在单个服务中。比如通过限流、熔断等方式降低错误导致的危害,保障核心业务正常运行。

扩展

单块架构应用也可以实现横向扩展,就是将整个应用完整的复制到不同的节点。

当应用的不同组件在扩展需求上存在差异时,微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。

本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较 Dubbo 和 Spring Cloud 这 2 种开发框架。

架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程。

核心部件

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

总体架构

Dubbo 核心部件(如下图)

2020321224658-dubbo-struct

Spring Cloud总体架构(如下图)

2020321224939-springcloud-struct

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

对比

2020321225132-dubbo-compare-springcloud

Dubbo 只是实现了服务治理,而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件,服务治理只是其中的一个方面。

Dubbo 提供了各种 Filter,对于上述中“无”的要素,可以通过扩展 Filter 来完善。例如:

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

通讯协议

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

Dubbo 使用 RPC 通讯协议,提供序列化方式

Spring Cloud 使用 HTTP 协议的 REST API

性能比较

使用一个 Pojo 对象包含 10 个属性,请求 10 万次,Dubbo 和 Spring Cloud 在不同的线程数量下,每次请求耗时(ms)如下:

202032123128-dubbo-springcloud-performance

**说明:**客户端和服务端配置均采用阿里云的 ECS 服务器,4 核 8G 配置,Dubbo 采用默认的 Dubbo 协议。

**点评:**Dubbo 支持各种通信协议,而且消费方和服务方使用长链接方式交互,通信速度上略胜 Spring Cloud,如果对于系统的响应时间有严格要求,长链接更合适。

服务依赖方式

Dubbo

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

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

通过 maven 的 install & deploy 命令把 Interface 和 Model 层发布到仓库中,服务调用方只需要依赖 Interface 和 Model 层即可。

在开发调试阶段只发布 Snapshot 版本,等到服务调试完成再发布 Release 版本,通过版本号来区分每次迭代的版本。通过 xml 配置方式即可接入 Dubbo,对程序无入侵。

Spring Cloud

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

202032123723-service-depend

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

组件运行流程

Dubbo

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

202032123101-dubbo-process

Dubbo 组件运行:

Spring Cloud

202032123129-springcloud-process

Spring Cloud组件运行:

**点评:**业务部署方式相同,都需要前置一个网关来隔绝外部直接调用原子服务的风险。

Dubbo 需要自己开发一套 API 网关,而 Spring Cloud 则可以通过 Zuul 配置即可完成网关定制。使用方式上 Spring Cloud 略胜一筹。

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

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

2020321231549-internet-scene-sample

架构分解

注意事项:

总结

Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵,设计的目的还是服务于自身的业务为主。

虽然阿里内部原因 Dubbo 曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求。

如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中增加了使用 Dubbo 的难度。

Spring Cloud 是大名鼎鼎的 Spring 家族的产品, 专注于企业级开源框架的研发。

Spring Cloud 自从发布到现在,仍然在不断的高速发展,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。

Dubbo 于 2017 年开始又重启维护,发布了更新后的 2.5.7 版本,而 Spring Cloud 更新的非常快,目前已经更新到 Finchley.M2。

因此,企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题,不管是 Dubbo 还是 Spring Cloud 都是实现微服务有效的工具。