Spring Cloud的系统结构更简单,“注册+springmvc=springcloud”,而 Dubbo 各种复杂的 URL、protocol、register、invocation、dubbofilter、dubboSPI,dubbo序列化……炫技的成分更多一些。
从性能考虑
Dubbo 的网络消耗小于 Spring Cloud,但是在国内95%的公司内,网络消耗不是什么太大问题。如果真的成了问题,通过压缩、二进制、高速缓存、分段降级等方法,很容易解。
从开发难易度考虑
Dubbo 的神坑是 jar 包依赖,开发阶段难度极大。我曾经带一个三十人的团队,因为 jar 包升级问题,把每个人的电脑都操作过。尤其每个人电脑的库路径、命令、快捷键、键盘,鼠标快慢都不一样,那会儿我默默的(此处省略200字)。Spring Cloud比较自由,但带来的问题是无法“强力约束接口规范”,建议用行政方式解决,且我们团队的强力行政约束做的还是比较好的,在接口管控层面比较强效,一个没有行政组织能力的IT团队真的是个废渣,用什么框架都不好使。
Spring Cloud 由众多子项目组成,如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等,提供了搭建分布式系统及微服务常用的工具,如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 token、全局锁、选主、分布式会话和集群状态等,满足了构建微服务所需的所有解决方案。比如使用 Spring Cloud Config 可以实现统一配置中心,对配置进行统一管理;使用Spring Cloud Netflix 可以实现 Netflix 组件的功能—服务发现(Eureka)、智能路由(Zuul)、客户端负载均衡(Ribbon)。
但它并没有重复造轮子,而是选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架(我们需要特别感谢 Netflix ,这家很早就成功实践微服务的公司,几年前把自家几乎整个微服务框架栈贡献给了社区,Spring Cloud 主要是对 Netflix 开源组件的进一步封装),通过 Spring Boot 进行封装集成并简化其使用方式。基于 Spring Boot,意味着其使用方式如 Spring Boot 简单易用;能够与Spring Framework、Spring Boot、Spring Data 等其它 Spring 项目完美融合,意味着能从 Spring 获得巨大的便利,意味着能减少已有项目的迁移成本。
Spring 推出 Spring Boot/Cloud 也是因为自身的很多原因。Spring 最初推崇的轻量级框架,随着不断的发展也越来越庞大,随着集成项目越来越多,配置文件也越来越混乱,慢慢的背离最初的理念。随着这么多年的发展,微服务、分布式链路跟踪等更多新的技术理念的出现,Spring 急需一款框架来改善以前的开发模式,因此才会出现 Spring Boot/Cloud 项目,我们现在访问 Spring 官网,会发现 Spring Boot 和 Spring Cloud 已经放到首页最重点突出的三个项目中的前两个,可见 Spring 对这两个框架的重视程度。
总结一下,Dubbo 曾经确实很牛逼,但是 Spring Cloud 是站在近些年技术发展之上进行开发,因此更具技术代表性。Spring Cloud 是整机,Dubbo 需要自己组装;整机的性能有保证,组装的机子更自由。