Spring官网:https://spring.io/
目前成熟的互联网架构:应用服务化拆分+消息中间件
严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。
很明显,Spring Cloud的功能比DUBBO更加强大,涵盖面更广,而且作为Spring的拳头项目,它也能够与SpringFramework、Spring Boot、Spring Data、Spring Batcn等Spring项目完美融合,这些对于微服务而言至关重要。使用Dubbo构建的微服务架构就像组装电脑,各环节我的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,而SpringCloud就像品牌机,在Spring Source的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。
最为重要的是,DUBBO停止了5年左右的更新,虽然2017.7重后了。对于技术发展的新需求,需要由开发者自行拓展升级(比如当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软件组织,显然是不太合适的,中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案,并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。
曾风靡国内的开源RPC服务框架Dubbo在重启维护后,令许多用户为之雀跃,但同时,也迎来了一些质疑的声音。互联网技术发展迅速,Dubbo是否还能跟上时代? Dubbo与Spring Cloud相比又有何优势和差异?是否会有相关举措保证 Dubbo的后续更新频率?
人物:Dubbo重启维护开发的刘军,主要负责人之一
刘军,阿里巴巴中间件高级研发工程师,主导了Dubbo重启维护以后的几个发版计划,专注于高性能RPC框架和微服务相关领域。曾负责网易考拉RPC框架的研发及指导在内部使用,参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。
解决的问题域不一样: Dubbo的定位是一款RPC框架,Spring Cloud的目标是微服务架构下的一站式解决方案
Distributed/versioned configuration(分布式/版本控制配置).
Service registration and discovery(服务注册与发现)
Routing(路由)
Service-to-service calls(服务到服务的调用).
Load balancing (负载均衡配置)
Circuit Breakers(断路器)
Distributed messaging (分布式消息管理)
官网:http://projects.spring.io/spring-cloud/
spring cloud是一个由众多独立子项目组成的大型综合项目,每个子项目有不同的发行节奏,都维护着自己的发布版本号。spring cloud通过一个资源清单BOM(Bil7 of Materials)来管理每个版本的子项目清单。为避免与子项目的发布号混淆,所以没有采用版本号的方式,而是通过命名的方式。
这些版本名称的命名方式采用了伦敦地铁站的名称,同时根据字母表的顺序来对应版本时间顺序,比如:最早的Release版本:Ange1,第二个Release版本: Brixton,然后是camden、Dalston、Edgware,目前最新的是Finchley版本。
参考书:
https://springcloud.cc/spring-cloud-netflix.html
中文APIl文档: https://springcloud.cc/spring-cloud-dalston.html
SpringCloud中国社区http://springcloud.cn/
SpringCloud中文网https://springcloud.cc
原文:https://www.cnblogs.com/saxonsong/p/15088516.html