共计 1178 个字符,预计需要花费 3 分钟才能阅读完成。
今天在知乎上看到了这样一个问题: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 用户来说,都没有绝对要消亡另一方的场景存在。所以,个人认为这两个极大可能会成为好基友,尤其在国内的应用上。
欢迎关注我的公众号:程序猿 DD,获得独家整理的学习资源和日常干货推送。
如果您对我的专题内容感兴趣,也可以关注我的博客:didispace.com。
本文首发于我的独立博客:Spring Cloud 和 Dubbo 哪个会被淘汰?,转载请注明出处。