Spring(25) 为什么使用 SpringCloud，而不是用 Dubbo？

一、背景

引言： 我们在做的项目中，大部分都是使用的 SpringCloud 框架，大家有没有思考过：为什么使用 SpringCloud，而不是用 Dubbo？

对于微服务了解不深的同学可能会说：“Dubbo 已经过时了。”

注意：这样的回答是错误的！！！下面就介绍一下使用 SpringCloud 不使用 Dubbo 框架的真正原因。

---

二、问题解答

我们知道，在微服务的架构中，我们会遇到很多难题。比如我们在做 RPC 远程调用的过程中，会发生一些服务治理，例如：

• 我们需要管理我们的接口地址，于是我们的 注册中心 就诞生了，有 Eureka、Nacos、ZK 等。
• 我们希望能够对我们的接口做 服务的保护，我们就可以使用到 Hystrix、Sentinel 来对我们的接口做一些服务的限流和保护。
• 还有 网关，网关在微服务的架构中是非常重要的。我们所有的请求入口会先到达我们的网关，再通过网关路由转发到我们真实的应用服务当中，它对我们的接口是有一定的保护作用的。
• 还有 服务链路，假如在 RPC 整个调用链过程当中，某个环节报错了，我们能够方便地定位问题并进行解决。

由此可知，在我们进行微服务的开发过程当中，如果我们使用的是 SpringCloud 框架，那么基本上遇到什么难题，SpringCloud 都有一套完整的解决方案。所以我们的 SpringCloud 是我们的 微服务全家桶框架。

什么是微服务全家桶框架？也就是说如果我们当前在使用 SpringCloud 框架，只要遇到什么难题，都有对应的组件帮我们去解决。反过来，Dubbo 是属于我们的 RPC 框架，它对标的是 SpringCloud 框架中的 OpenFeign 组件来实现 RPC。

为了方便理解，我们举一个生活中的例子：

• 比如我们现在要去买一台电脑。电脑一般买回来就可以直接使用，它就类似于我们的 SpringCloud 框架。
• 反过来，如果你在这个时候只是买了电脑的一个组件（比如：CPU），那么在你真正想要使用电脑的情况下，还需要去买硬盘、内存等其他很多组件。所以，Dubbo 相当于我们电脑中的某个组件。

如果我们使用 Dubbo 做一些分布式微服务项目，这样每当我们遇到问题的时候都需要自己去找一些能够对应分布式微服务治理的这一套框架，而且还要确认它是否可以很好地支持我们这样一个 Dubbo 框架。例如：

• 示例1：我想做一个服务注册，就需要确认 Nacos 是否支持 Dubbo 框架。
• 示例2：或者我想去做一个服务链路的追踪，也需要确认这个链路组件是否支持 Dubbo 框架。

从以上两个例子可以看出来，如果我们 每次遇到问题都需要去找能够兼容的组件就很麻烦了。

所以我们再回到 SpringCloud 框架上，就会发现，只要遇到微服务方面的难题 SpringCloud 都有对应的组件来进行解决，这样就很方便。

但是，在很多顶级的互联网企业当中，压根是不会使用到 SpringCloud 的，而是使用公司自己写的 RPC 框架。为什么呢？因为大公司资金比较雄厚，基本上对于核心组件，只要遇到类似 RPC 这种难题，都是公司自己研发框架去解决。尤其是百度、美团、阿里这种非常顶级的互联网企业。

相反，在一些中小型企业中，如果只使用 Dubbo 这种微服务框架是满足不了实际需要的，只能去使用 SpringCloud 这样把很多 RPC 远程调用这样的组件集成好的全家桶框架，从而减少公司内部研发框架的成本。

---

三、总结

一般中小型企业选择 SpringCloud 框架是没有问题的，但如果是顶级互联网企业，基本上都是自己去研发这样的组件的。

所以整体来说，Dubbo 框架在 RPC 方面还是比较优秀的，要综合公司的整体情况对框架进行选择。

整理完毕，完结撒花~🌻