Spring Cloud 和 Dubbo 哪一个会被淘汰？

今天看到了这样一个问题：Spring Cloud 和 Dubbo哪一个会被淘汰？看了几个回答，都以为不在点子上，因此要么就干脆写篇小文瞎逼叨一下。

简单说说我的观点

我认为这两个框架大几率会长期都存在。

时至今日，这两个框架放到如今，已经不存在谁取代谁这一说了。因为Spring Cloud Alibaba的出现，Dubbo已经很好的融入到了Spring Cloud体系，因此围绕Spring Cloud生态的各类周边产品都是能够无缝整合到一块儿来玩的。

Dubbo无缝整合Spring Cloud生态是啥意思呢？主要两方面：

1. 若是你原来是Dubbo用户，那么如今能够把Spring Cloud引入进来。轻松便捷地整合Spring Cloud的配置中心、注册中心以及诸如分布式跟踪等好用的周边产品来管理你的分布式服务集群，与其余Spring Cloud Netflix用户享受同等的生态优点。

2. 若是你原来不是Dubbo用户，可是你的场景在使用HTTP调用时候以为不够效率不够经济，那么就能够考虑引入Dubbo，来提高你服务减调用的RPC性能。

到这里，可能有的看官要说了，你都是站在融合的角度来讲的，我就是不喜欢Dubbo那种接口依赖的方式，坚定捍卫Spring Cloud原始生态！

行！这种坚持也是能够的，并无什么错，经过HTTP契约方式管理服务接口，不用接口提供方的JAR，这在编译层面上就不会产生耦合，这点确实一直是目前不用Dubbo的一个重要论据。我的也以为这种选择在不少方面是有优点的，可是对接口的兼容设计也是有很是高要求的，只要能执行到位，任何一种方案均可以作的很流畅。springcloud 项目to：www.1b23.com

可是，我认为Spring Cloud用户对这种方案的坚持并不会影响Dubbo生态的消亡。主要两点：

1. Dubbo的原始用户群巨大，在Spring Cloud布道以前，Dubbo就拥有了极大的用户群体，如今既然有很好的融合方案，那么融合的考虑确定要比重构的考虑要更为稳妥的。

2. 有不少用户会质疑阿里巴巴的开源项目容易太监，此次Dubbo从新维护，又能坚持多久？其实这点此次就不用过多的担忧，由于目前的Dubbo已经给了Apache基金会，因为Apache对开源项目在是否可长期维护的评估上有很高的要求（活跃度、贡献比例等），能在Apache毕业的项目，除非出现了一个在各方面都能超越它的东西出现，否则就会很长时间的存在且并应用。

不论从Spring Cloud用户来讲，仍是Dubbo用户来讲，都没有绝对要消亡另外一方的场景存在。因此，我的认为这两个极大可能会成为好基友，尤为在国内的应用上。