这是个老生常谈的问题，每个技术团队在业务转型微服务化架构的时候都会纠结过这个选型问题。
首先，dubbo 之前确实在 2012 年的时候发布了最后一个版本 2.5.3 并且停止维护更新，在2017年的时候又”起死回生“，官方宣布重启更新，并重点投入开源建设；终于在 2017 年 9 月，新发布了 2.5.4 版本，这中间"沉寂"的 5 年的时间究竟是出于什么原因，我们无需关注，幸运的是，Dubbo 于 2018 年 2 月通过投票进入 Apacha 基金会孵化器，并且宣布框架不再仅局限于 java 语言，这对于国内的很大一部分开发者而言算是一大福音；
所以想说的是，dubbo 框架并没有废弃，相反现在正处于积极活跃的开源孵化中，因此对于想使用 dubbo 的用户而言，大可不必担心，它确实是一个非常不错的分布式技术选型对象。
那接下来我们再聊聊 Dubbo 与 SpringCloud 的区别，希望能为后续同样纠结在这个问题上的同学提供一些参考意见。
从严格意义上来说，Dubbo和SpringCloud的定位是不一样的，dubbo 包括官方对自身的定义很清楚，从github的项目简介即可看出——Apache Dubbo is a high-performance, java based, open source RPC framework. 翻译过来就是，Dubbo 是一个高性能的、基于java的开源 RPC框架；划重点：高性能 和 RPC框架；
而 Spring Cloud呢，官方对于它的定义可以直接参考官网：
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).
简单介绍就是 SpringCloud 提供了一系列通用工具来帮助开发者在分布式系统里快速构建一些常见模式，比如分布式配置管理、服务发现、熔断降级、智能路由、微代理、控制总线、一次性令牌、全局锁、分布式选主、分布式session等等一系列你可能目前还没想到，但是开发过程中也许会碰到的问题；看到这里大家应该已经会有一个比较初步的感觉，SpringCloud 的设计目标是提供一整套服务治理能力，它是一个完整的体系，涉及范围很广；
而 dubbo ，它只是一个分布式的 RPC 框架，如果一定要按照分布式系统架构里的功能来定义的话，只是解决了服务发现、服务路由、服务降级和负载均衡方面的能力，新版本里也提供了动态配置中心和服务治理相关的能力，但相比 Sprin Cloud 而言，还是差了相当一部分的能力；
从功能支持上来说，dubbo 的角色定位可能更像是另外一个大名鼎鼎的框架，那就是 gRPC，而且两者在使用的方式以及工作原理上都非常相似，都是基于序列化协议来解决分布式系统中的远程调用问题，在使用上可以通过约定接口或者通过 proto 文件生成代码文件来“提升用户的使用”
那么问题来了，功能越多一定越好吗？答案显然不是，取决于你究竟想要什么？
如果你在系统设计之初就已经考虑到了后续可能会涉及到各种服务治理能力，比如分布式配置、全局锁、分布式session等常见需求，那么使用 SpringCloud 将会减少你很多的工作，因为这些基本上都是"套件"，相互配合使用会非常顺畅。如果你想要的只是解决分布式架构后的远程调用问题，那么 Dubbo 是一个不错的选择。
SpringCloud 和 Dubbo 的基本差异大概就是如上所述，很多同学可能还是觉得很迷茫，不知道该如何做选择，这里再补充几个比较关键的差异点，希望能帮助你更好的结合自身业务做出选择：
1、能力支持方面
上文也提到，SpringCloud 提供了一整套微服务治理的功能组件，很多组件基本上都是"开箱即用"的，并且相互之间能很好的兼容，举个例子，如果要在 Spring Cloud 里实现服务发现、负载均衡和熔断降级，你只需要引用SpringCloud 的依赖组件即可，直接通过注解便可使用，基本上零配置；而 dubbo 框架，除了上述提到的能力支持之外，如果想要使用熔断降级，那你可能需要额外引用 hystrix 或者 resilience4j 来实现；温馨提示，hystrix 官方目前也已经宣布不再更新，并且推荐使用 resilience4j 。
2、协议兼容方面
SpringCloud 里并没有限制服务之间的通信协议，但是主流的一些客户端比如 restTemple、feign 等都是直接支持使用 Ribbon 来做服务注册发现和智能路由的，其底层通信的协议都是HTTP；而dubbo框架缺省是基于NIO异步传输使用 TCP 长连接并采用 Hessian 二进制序列化方式通信的；
这会涉及后续系统在扩展上的兼容性问题，比如需要调用一个三方系统或者是被第三方系统调用，相比而言 HTTP 协议可能更加通用。
3、模型定义方面
dubbo 在模型设计上将一个接口定义为一个服务，而 SpringCloud 里则是将一个应用定义为一个服务，这两者在模型上是存在很大差异的，你也许会奇怪，这个对使用会有影响吗？从现有使用方面来说是没有什么影响的，但是你如果有关注 Service Mesh 最新微服务技术的话，目前对 Dubbo 协议这块可能支持暂时还不完善，其中很大一部分原因就是因为在服务模型上与 K8S 的服务模型有差异；
4、调用性能方面
如果分布式系统中比较关注远程调用的性能，那 Dubbo 可能是一个较好的选择，基于 NIO 和 TCP 长连接的通信传输方式，在性能上相比 HTTP 协议是有绝对优势的；当然基于 SpringCloud 你也可以使用 gRPC 协议来解决性能问题，那就是另外一个问题了。
利益相关：我网易轻舟就以 Spring Cloud 和 Service Mesh 作为微服务基础设施，适用于微服务改造、业务中台、数字化转型、工业互联网、开放平台等多种场景。
