(五)为什么选择SpringCloud作为微服务架构

 1.选型依据

  • 整体解决方案和框架成熟度

  • 社区热度

  • 可维护性

  • 学习曲线

 

2.当前各大IT公司用的微服务架构

  • 阿里Dubbo/HSF
  • 京东JSF
  • 新浪微博Motan
  • 当当网DubboX
  • ......

 

3.各微服务框架对比

(五)为什么选择SpringCloud作为微服务架构_第1张图片

 

 4.SpringCloud与Dubbo的对比

     (1)社区活跃度

           SpringCloud:https://github.com/spring-cloud

           Dubbo:https://github.com/dubbo

     (2)详细对比结果

(五)为什么选择SpringCloud作为微服务架构_第2张图片

  • 最大区别:SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式。

严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。
 

  • 品牌机与组装机的区别

很明显,Spring Cloud的功能比DUBBO更加强大,涵盖面更广,而且作为Spring的拳头项目,它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合,这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而Spring Cloud就像品牌机,在Spring Source的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。
 

  • 社区支持与更新力度

最为重要的是,DUBBO停止了5年左右的更新,虽然2017.7重启了。对于技术发展的新需求,需要由开发者自行拓展升级(比如当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软件组织,显然是不太合适的,中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案,并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。
 

5.总结SpringCloud与Dubbo 

问题:
曾风靡国内的开源 RPC 服务框架 Dubbo 在重启维护后,令许多用户为之雀跃,但同时,也迎来了一些质疑的声音。互联网技术发展迅速,Dubbo 是否还能跟上时代?Dubbo 与 Spring Cloud 相比又有何优势和差异?是否会有相关举措保证 Dubbo 的后续更新频率?
 
人物:Dubbo重启维护开发的刘军,主要负责人之一
 
刘军,阿里巴巴中间件高级研发工程师,主导了 Dubbo 重启维护以后的几个发版计划,专注于高性能 RPC 框架和微服务相关领域。曾负责网易考拉 RPC 框架的研发及指导在内部使用,参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。
 

(五)为什么选择SpringCloud作为微服务架构_第3张图片

(五)为什么选择SpringCloud作为微服务架构_第4张图片


 
 

 

 

 

你可能感兴趣的:(SpringCloud)