Spring Cloud Alibaba 到底坑不坑？
最近有读者转来一篇题为《坑爹项目 spring-cloud-alibaba，我们也来一个》的文章，询问我的看法。简单聊了几句后，我决定抽空整理一下思路，逐点说说我的观点。
说实话，那篇文章博眼球的成分比较高。它的解读逻辑与之前某些自媒体发布的《Eureka 2.0 开源工作宣告停止，继续使用风险自负》一文有异曲同工之'妙'。如果读者没有真正理解 Spring Cloud 与 Spring Cloud Alibaba 的区别，很容易产生误解，进而得出一些片面的结论：
- 感觉很有道理，这东西真垃圾
- 标题很燃，必须转发
下面具体来说说该文章中，我认为不太正确的解读。
第一点：远程调用 RPC
看看这篇文章的解读
SpringCloud 默认的是 Feign 和 Ribbon，主要是提供了远程调用请求和解析，以及负载均衡的功能。客观点来说，如果不用这两个组件，就会越来越四不像，干脆也别叫 SpringCloud 了，所以替换不得。RPC 会大量使用动态代理的功能，将你的字符串或者配置（因为网络传输方便）搞成动态的接口。
你也可以写一个 RPC 进行集成，有很多教程教你手撸一个。
爸爸版的集成了个 dubbo，dubbo 就是个 RPC。所以你一用这玩意，其他的一些关键组件也得跟着全套的换，组件就不叫组件了!
作者的核心观点是：Spring Cloud 的负载均衡和远程调用必须使用 Feign 和 Ribbon，这是 Spring Cloud 的默认实现。如果换成 Dubbo，就是四不像了。
说说我的想法
其实，这种看法有些偏激。Spring Cloud 本身就是一个生态体系，而非单一框架。Feign 和 Ribbon 确实是其经典组合，但并不意味着排斥其他优秀的 RPC 方案。Dubbo 作为成熟的 RPC 框架，在性能、治理等方面有其独特优势。将其引入 Spring Cloud 环境，并非'四不像'，而是微服务架构中常见的混合模式。关键在于如何根据业务场景选择合适的工具，而不是被所谓的'标准'束缚。
