SpringCloud,基于SpringBoot提供了一套微服务解决方案,包括服务注册与发现、配置中心、全链路监控、服务网关、负载均衡、熔断器等组件,除了基于Netflix的开源组件做高度抽象封装之外,还有一些选型中立的开源组件。
SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发,SpringCloud为开发人员提供了快速构建分布式系统的一些工具,包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等,它们都可以用SpringBoot的开发风格做到一键启动和部署。
SpringBoot并没有重复值造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
小结:分布式微服务架构下的一站式解决方案,是各个微服务架构落地技术的集合,俗称微服务全家桶。
SpringCloud和SpringBoot是什么关系?
1.SpringBoot关注的是维观,是一个一个具体的微服务module。而SpringCloud关注的是宏观,是整体微服务的架构。
2.SpringBoot可以单独使用不依赖于SpringCloud而SpringCloud依赖于SpringBoot
小结:SpringBoot专注于快速、方便的开发单个服务个体,SpringCloud关注全局的服务治理框架。
Dubbo和SpringCloud的区别,那些优点缺点让你去做技术选型?
|
Dubbo |
SpringCloud | |
|
服务注册中心 |
Zookeeper |
SpringCloud Netflix Eureka |
|
服务调用方式 |
RPC |
REST API |
|
服务监控 |
Dubbo-monitor |
SpringBoot Admin |
|
断路器 |
不完善 |
SpringCloud Netflix Hystrix |
|
服务网关 |
无 |
SpringCloud Netflix Zuul |
|
分布式配置 |
无 |
SpringCloud Config |
|
服务跟踪 |
无 |
SpringCloud Sleuth |
|
消息总线 |
无 |
SpringCloud Bus |
|
数据流 |
无 |
SpringCloud Steam |
|
批量任务 |
无 |
SpringCloud Task |
|
....... |
... |
... |
两大区别:SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式。
严格的来说,这两种方式各有优劣。虽然从一定的程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。
品牌机与组装机的区别
很明显,SpringCloud的功能比Dubbo更加强大,涵盖面更广,而且作为Spring的拳头项目,它也能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合,这些对于为服务而言是至关重不过要的。使用Dubbo构建的微服务架构就像组装电脑,个环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而SpringCloud就像品牌机,在SpringSource的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。
社区支持与更新力度
最为重要的是,Dubbo停止了5年左右的更新,虽然2017.7重启了。对于技术发展的新需求,需要自由开发者自行拓展升级(比如当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软件组织,显然是不太合适,中小公司没有这么强大的技术能力去修改Dubbo源码+周边的这一套解决方案,并不是每一个公司都有阿里的大牛+真正的线上生产环境测试过。
目前国内有哪些公司在用SpringCloud呢
华为,联通、阿里云等等等等
本文深入探讨了SpringCloud作为微服务架构一站式解决方案的角色,对比了SpringBoot与SpringCloud的关系,详细分析了SpringCloud与Dubbo在服务注册、调用方式、监控、断路器等多方面的区别。同时,讨论了品牌机与组装机的概念,以及社区支持和更新力度对技术选型的影响。

被折叠的 条评论
为什么被折叠?



