Dubbo与SpringCloud的区别和优缺点

经常会有同学问我，Dubbo和SpringCloud的选择。甚至也经常会有面试官就这个问题刨根问底。 说实话，其实我不太喜欢回答这个问题，本质上来讲，Dubbo的SpringCloud可以算是完全不同赛道的两种东西，就好像问大家西瓜和土豆我应该怎么选一样，不过为了让大家在面试时可以更好的回答这个问题，在此我们就分析一下Dubbo和SpringCloud的区别

定义上的区别

Apache Dubbo |ˈdʌbəʊ| 提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems 。
翻译：springcloud为开发人员提供了快速构建分布式系统中一些常见模式的工具

以上内容均为官方定义，截图如下：

Dubbo官方定义

SpringCloud官方定义

从以上定义中我们不难看出，Apache Dubbo的目标是基于RPC调用为主，并扩展相应的功能。 而SpringCloud是致力于提供分布式服务的各种工具。可以这样讲，Apache Dubbo从概念上讲只相当于SpringCloud中的feign而已。

出发点不同

Apache Dubbo： 诞生于阿里巴巴的线上需求，主要是为了应对微服务场景下高并发的处理，所以Apache Dubbo的核心关注点就是解决微服务之间调用的性能。 并且将包括服务注册/发现、负载均衡等微服务的核心内容进行了集成。最后在核心调用流程稳定的情况下完成了包括本地存根、Mock、版本控制等诸多特性的集成。

SpringCloud： SpringCloud是Spring家族中在微服务领域的关键组成部分，延续了Spring一贯的风格：为大家提供好用的工具，可以屏蔽底层实现，一站式完成业务开发。包括后面的SpringCloud Netflix和SpringCloud Alibaba等都是基于此完成工具的开发。我们可以大概数一数SpringCloud的工具内容，Ribbon【负载均衡】、Feign【HTTP服务】、Hystrix【熔断降级】、Gateway【网关】等等，从其中我们不难发现，SpringCloud对于微服务的调用的性能并不太关心，它更关心的是处理微服务调用以外的内容，虽然他勉为其难的搞了一个Feign，但是我们都知道，HTTP的调用是非常耗时的，它与RPC的调用效率完全不可同日而语。

综上所述：Apache Dubbo的目标是为了高效调用服务。SpringCloud的目标是一条龙解决微服务的治理问题，那么出发点都不同，比较的意义又在哪里呢。

真实工作场景

事实上，目前我接触和了解的互联网大厂的项目里，单纯的使用SpringCloud的非常少。虽然不全是选用Apache Dubbo， 还有包括Thrift、Zero等微服务框架，但是Apache Dubbo的市场占有率会相对比较高，也是很多大厂项目的首选。
但是Apache Dubbo的服务治理其实并不太好用，比如熔断降级、限流等，同时Apache Dubbo还有一个比较麻烦的问题， 就是没有HTTP调用的逻辑，这一点对前后端分离的项目非常不友好。
基于以上内容，其实在实际项目中， Apache Dubbo和SpringCloud相结合才是目前比较主流的使用方式。服务之间的调用使用Apache Dubbo。熔断、网关、限流等使用SpringCloud。尤其是在拥有了SpringCloud Alibaba以后，SpringCloud与Apache Dubbo的结合更加紧密，这才是我个人建议的使用方式。