java不会分布式已被淘汰,java高级培训：Spring Cloud 和 Dubbo哪个先被淘汰？

时至今日，这两个框架放到现在，已经不存在谁取代谁这一说了。由于SpringCloudAlibaba的出现，Dubbo已经很好的融入到了SpringCloud体系，所以围绕SpringCloud生态的各种周边产品都是可以无缝整合到一起来玩的。

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

如果您是Dubbo用户，现在可以介绍SpringCloud进来。轻松便捷地集成SpringCloud的配置中心，注册中心和有用的外围产品(例如分布式跟踪)来管理您的分布式服务集群，并享有与其他SpringCloudNetflix用户相同的生态优势。

如果你原来不是Dubbo用户，但是你的场景在使用HTTP调用时候觉得不够效率不够经济，那么就可以考虑引入Dubbo，来提升你服务间调用的RPC性能。

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

行！这种坚持也是可能的，并且没有错。服务接口通过HTTP协定进行管理，而没有接口提供程序的JAR。这不会在编译级别产生耦合。对于目前不使用Dubbo，这确实是一个重要的论点。我个人认为此选择在很多方面都有优势，但是对接口的兼容设计也有很高的要求。只要可以就地实施，任何解决方案都可以顺利完成。

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

Dubbo的原始用户群巨大，在SpringCloud布道之前，Dubbo就拥有了极大的用户群体，现在既然有很好的融合方案，那么融合的考虑肯定要比重构的考虑要更为稳妥的。

许多用户会质疑阿里巴巴的开源项目容易太监。这次Dubbo可以维持多长时间？实际上，这次不必担心太多，因为当前的Dubbo已经交给了ApacheFoundation。由于Apache对开放源代码项目的长期维护评估(活动，贡献比率等)有很高的要求，因此，一个可以从Apache毕业的项目，除非有在各个方面都可以超越它的东西，否则它将存在并成为申请了很长时间。

不论从SpringCloud用户来说，还是Dubbo用户来说，都没有绝对要消亡另一方的场景存在。所以，个人认为这两个极大可能会成为好基友，尤其在国内的应用上。

如果你想了解更多关于java架构师的专业知识，可以加入JAVA架构师交流群：1037935907，里面都是同行，有资源分享包括但不限于(分布式架构、高可扩展、高性能、高并 发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql 、Zookeeper、Tomcat、Docker、Dubbo、Nginx)。欢迎一到五年的工程师加入，合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！