【Springcloud】第三篇 Springcloud和Dubbo的对比

最新推荐文章于 2024-06-20 10:45:42 发布

CathyDuangDuang

最新推荐文章于 2024-06-20 10:45:42 发布

阅读量853

点赞数 1

分类专栏： ——Springcloud 【后端】文章标签： Springcloud dubbo

本文链接：https://blog.csdn.net/wyj19950908/article/details/95859689

版权

【后端】同时被 2 个专栏收录

16 篇文章 0 订阅

订阅专栏

——Springcloud

3 篇文章 0 订阅

订阅专栏

一、架构对比

Dubbo

在这里插入图片描述

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

Springcloud

在这里插入图片描述

节点	角色说明
Service Provider	暴露服务的提供方。
Service Consumer	调用远程服务的服务消费方。
EureKa Server	服务注册中心和服务发现中心。

总结

都是由注册中心、服务生产者和服务消费者构成，差异不是很大。

二、组成对比

Dubbo

使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；

Springcloud

而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

总结

很明显，Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。
在这里插入图片描述

三、通信方式

Dubbo

采用RPC通信方式，Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费机器数远大于服务提供者机器数的情况。Dubbo支持各种通信协议，而且消费方和服务方使用长连接方式交互，通信速度上略胜Springcloud，如果对于系统的响应时间有严格要求，长连接更加适合。

Springcloud

采用的是基于HTTP协议的REST方式

总结

严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

四、服务依赖对比

Dubbo

Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。

Springcloud

Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础。

五、组件运行流程对比

Dubbo

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

Springcloud

所有请求都统一通过 API 网关（Zuul）来访问内部服务。网关接收到请求后，从注册中心（Eureka）获取可用服务。由 Ribbon 进行均衡负载后，分发到后端的具体实例。微服务之间通过 Feign 进行通信处理业务。

总结

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

六、社区支持与更新力度对比

github上更新频率

Dubbo

在这里插入图片描述

Springcloud

在这里插入图片描述

总结

最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级（比如当当网弄出了DubboX），这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。
通过github上的更新程度来看Springcloud更加活跃

七、总结

Dubbo的定位始终是一款RPC框架，而Springcloud的目标是微服务架构下的一站式解决方案。当前由于RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo和Springcloud只能二选一，因此Dubbo拿来与Springcloud作对比。Dubbo之后会积极寻求是配到Springcloud生态，比如作为Springcloud的二进制通信解决方案来发挥Dubbo的性能优势，或者Dubbo通过模块化以及对http的支持适配到Springcloud。——刘军（Dubbo重启维护开发的主要负责人）

参考文献：
Dubbo和SpringCloud的优劣势比较–总体架构