今天在知乎上看到了这样一个问题：Spring Cloud 和 Dubbo哪个会被淘汰?看了几个回答，都觉得不在点子上，所以要么就干脆写篇小文瞎逼叨一下。
简单说说个人观点
我认为这两个框架大概率会长期都存在。
时至今日，这两个框架放到现在，已经不存在谁取代谁这一说了。由于Spring Cloud Alibaba的出现，Dubbo已经很好的融入到了Spring Cloud体系，所以围绕Spring Cloud生态的各种周边产品都是可以无缝整合到一起来玩的。
Dubbo无缝整合Spring Cloud生态是啥意思呢?主要两方面：
- 如果你原来是Dubbo用户，那么现在可以把Spring Cloud引入进来。轻松便捷地整合Spring Cloud的配置中心、注册中心以及诸如分布式跟踪等好用的周边产品来管理你的分布式服务集群，与其他Spring Cloud Netflix用户享受同等的生态优势。
- 如果你原来不是Dubbo用户，但是你的场景在使用HTTP调用时候觉得不够效率不够经济，那么就可以考虑引入Dubbo，来提升你服务减调用的RPC性能。
到这里，可能有的看官要说了，你都是站在融合的角度来说的，我就是不喜欢Dubbo那种接口依赖的方式，坚决捍卫Spring Cloud原始生态!
行!这种坚持也是可以的，并没有什么错，通过HTTP契约方式管理服务接口，不用接口提供方的JAR，这在编译层面上就不会产生耦合，这点确实一直是目前不用Dubbo的一个重要论据。个人也觉得这种选择在很多方面是有优势的，但是对接口的兼容设计也是有非常高要求的，只要能执行到位，任何一种方案都可以做的很流畅。
但是，我认为Spring Cloud用户对这种方案的坚持并不会影响Dubbo生态的消亡。主要两点：
- Dubbo的原始用户群巨大，在Spring Cloud布道之前，Dubbo就拥有了极大的用户群体，现在既然有很好的融合方案，那么融合的考虑肯定要比重构的考虑要更为稳妥的。
- 有很多用户会质疑阿里巴巴的开源项目容易太监，这次Dubbo重新维护，又能坚持多久?其实这点这次就不用过多的担心，因为目前的Dubbo已经给了Apache基金会，由于Apache对开源项目在是否可长期维护的评估上有很高的要求(活跃度、贡献比例等)，能在Apache毕业的项目，除非出现了一个在各方面都能超越它的东西出现，不然就会很长时间的存在且并应用。
不论从Spring Cloud用户来说，还是Dubbo用户来说，都没有绝对要消亡另一方的场景存在。所以，个人认为这两个极大可能会成为好基友，尤其在国内的应用上。
【本文为51CTO专栏作者“翟永超”的原创稿件，转载请通过51CTO联系作者获取授权】
