微服务的核心要素在于服务的服务的发现、注册、路由、熔断、降级、分布式配置,基于上诉几种必要条件对 Dubbo 和Spring Cloud 做出对比
总结:从整体架构上来看,二者模式接近,都需要服务提供方,注册中心,服务消费方
核心要素 | Dubbo | Spring Cloud |
---|---|---|
服务注册中心 | Zookeeper、Redis | 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 基于Redis,Rabbit,Kafka 实现的消息微服务 |
批量任务 | 无 | Spring Cloud Task |
Dubbo 只是实现了服务治理,而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件,服务治理只是其中的一个方面。
Dubbo 提供了各种 Filter,对于上述中“无”的要素,可以通过扩展 Filter 来完善。例如:
总结 : 从核心要素来看,Spring Cloud 更胜一筹,在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合,而 Dubbo 却需要通过实现各种 Filter 来做定制,开发成本以及技术难度略高。
基于通讯协议层面对2种框架支持的协议类型以及运行效率方面进行比较
Dubbo 使用RPC通讯协议,提供序列化方式如下:
使用一个 Pojo 对象包含 10 个属性,请求 10 万次,Dubbo 和 Spring Cloud 在不同的线程数量下,每次请求耗时(ms)如下:
线程数 | Dubbo | Spring Cloud |
---|---|---|
10线程 | 2.75 | 6.52 |
20线程 | 4.18 | 10.03 |
50线程 | 10.3 | 28.14 |
100线程 | 20.13 | 55.23 |
200线程 | 42 | 110.21 |
说明:客户端和服务端配置均采用阿里云的 ECS 服务器,4 核 8G 配置,Dubbo 采用默认的 Dubbo 协议。
总结 : Dubbo 支持各种通信协议,而且消费方和服务方使用长链接方式交互,通信速度上略胜 Spring Cloud,如果对于系统的响应时间有严格要求,长链接更合适。
服务提供方与消费方通过接口的方式依赖,服务调用设计如下:
因此需要为每个微服务定义各自的 Interface 接口,并通过持续集成
发布到私有仓库中。调用方应用对微服务提供的抽象接口存在强依赖关系,开发、测试、集成环境都需要严格的管理版本依赖。
通过 maven 的 install & deploy 命令把 Interface 和 Model 层发布到仓库中,服务调用方只需要依赖 Interface 和 Model 层即可。
在开发调试阶段只发布 Snapshot 版本,等到服务调试完成再发布 Release 版本,通过版本号来区分每次迭代的版本。通过 xml 配置方式即可接入 Dubbo,对程序无入侵。
服务提供方和服务消费方通过 Json 方式交互,因此只需要定义好相关 Json 字段即可,消费方和提供方无接口依赖。通过注解方式来实现服务配置,对于程序有一定入侵。
总结 : Dubbo 服务依赖略重,需要有完善的版本管理机制,但是程序入侵少。
而 Spring Cloud 通过 Json 交互,省略了版本管理的问题,但是具体字段含义需要统一管理,自身 Rest API 方式交互,为跨平台调用奠定了基础。
下图中的每个组件都是需要部署在单独的服务器上,Gateway 用来接受前端请求、聚合服务,并批量调用后台原子服务。每个 Service 层和单独的 DB 交互。
总结 : 业务部署方式相同,都需要前置一个网关来隔绝外部直接调用原子服务的风险。
Dubbo 需要自己开发一套 API 网关,而 Spring Cloud 则可以通过 Zuul 配置即可完成网关定制。使用方式上 Spring Cloud 略胜一筹。
到底使用是 Dubbo 还是 Spring Cloud 并不重要,重点在于如何合理的利用微服务。
下面是一张互联网通用的架构图,其中每个环节都是微服务的核心部分。
Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵,设计的目的还是服务于自身的业务为主。
虽然阿里内部原因 Dubbo 曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求。
如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是大名鼎鼎的 Spring 家族的产品, 专注于企业级开源框架的研发。
Spring Cloud 自从发布到现在,仍然在不断的高速发展,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。
Dubbo 于 2017 年开始又重启维护,发布了更新后的 2.5.7 版本,而 Spring Cloud 更新的非常快。
因此,企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题,不管是 Dubbo 还是 Spring Cloud 都是实现微服务有效的工具。
微服务架构是互联网很热门的话题,是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。