目录
spring 的第一个版本发布于2002年，他出现的使命就是替换EJB(J2EE规范，理论上很先进，开发效率低，且性能不好，已成功被spring彻底打败)。
springboot 诞生于2014年，他出现的使命就是简化spring的用法，早期spring bean等配置需要配置到xml中，这个思路应该很大程度来源于EJB 。其实这个时候微服务架构已经很流行了，苦于java没有全家桶方案，各厂商就各显神通，东拼西凑，rpc框架，注册中心、业务网关等组件都是各式各样的，这个时候程序员要说做过微服务是有很大溢价空间的。
Spring Cloud 为微服务而生，2016年珊珊来迟，经过几年发展，早已成了java微服务架构的标配了，基本上打败了市面上所有其他方案。
Spring核心能力：
控制反转（IOC）：
Spring通过IoC容器实现了对象之间的解耦，使得对象之间的依赖关系可以通过配置文件或注解来定义，而不是在代码中硬编码。
IoC容器负责对象的创建、管理和销毁，以及对象之间依赖关系的注入，从而降低了代码的耦合度和复杂性。
依赖注入（DI）：
依赖注入是IoC的一种实现方式，它允许开发者在运行时动态地将依赖对象注入到目标对象中。
面向切面编程（AOP）：
spring提供了AOP的支持，允许开发者在不修改原有代码的情况下，增加新的功能或行为。
AOP通过将横切关注点（如日志、事务管理等）与业务逻辑代码分离，提高了代码的可维护性和可重用性。
Spring Boot核心能力
约定优于配置：
Spring Boot通过一系列约定来简化配置过程，使得开发者可以更加专注于业务逻辑的实现。
嵌入式容器：
Spring Boot内嵌了Tomcat、Jetty等Web服务器，使得应用程序可以作为一个独立的可执行JAR或WAR文件运行，而不需要单独的服务器或容器。
自动配置：
Spring Boot通过检查项目的类路径、属性设置和其他条件，自动为开发者配置Spring应用程序。
丰富的starter：
Spring Boot提供了大量的starter，这些starter是预先配置好的Maven依赖项，可以简化Maven配置，并快速集成第三方库和工具。
Spring Cloud的特点
Spring Cloud是基于Spring Boot的分布式微服务架构解决方案。它提供了一系列的服务治理、熔断、限流等功能，使得开发者可以更加便捷地构建出高可用、高并发的微服务应用。
其主要特点包括Spring Cloud提供了一系列的组件和工具，用于支持微服务的开发和部署，包括服务注册与发现、负载均衡、断路器、网关、配置中心等。
提供了很多容错和故障恢复的机制，如服务熔断、降级、限流、重试等，保证了系统的高可用性和容错性。
三者关系
他们三者是层层递进的关系。
| spring | 提供了IOC 、DI 、AOP等底层核心能力，所有面相对象语言都必须解决这3个问题，否则代码就是一团乱麻。 |
| springboot | 感觉是springcloud的铺垫，从时间上也可以看出来，spring发布12年后才有springboot, springboot发布2年后就有了springcloud 。如果是单体应用，直接使用spring基于xml的配置bean问题不大; 如果是开发微服务,大量子模块以及他们的bean需要依赖配置，那么就会原地爆炸。 |
| Spring Cloud | 为微服务而生，微服务全家桶，基于springboot，让开发者拿来即用，免去了复杂配置的烦恼。 |
你真的需要SpringCloud吗？
其实大部分项目都不需要微服务，下面从不同维度对比分析：
1.项目阶段：
很多创业型项目在0到1验证阶段是不适合微服务的，这阶段资金少、人员少，甚至缺少技术优秀的人，开发人员都应该集中精力做业务开发。
如果用微服务，那么最低配的微服务也需要RPC框架、注册中心、网关，这些都需要占用很多机器成本，这些组件还需要花费程序员很多时间，碰到技术差点的，很多时间都花在解决这些基础组件问题上。
很多技术人员在0到1的阶段都会向老板忽悠：微服务好，可以保证支撑后续业务上量。这完全是胡扯：第一，0到1阶段较少投入情况下，微服务架构100%不可能做好；第二：0到1基本上就是反复调方向验证，就是小步快跑，不适合用很重的架构，业务跑通后，有资源了再重构； 市值100万的公司不可能提前干1个亿的活。
2. 复杂的B端业务：
B端业务大部分都是流量小、业务复杂。一个真正的微服务项目是需要拆库的，B端业务数据关联都很强，现阶段数据库分布式事务是没有真正解决方案的，拆库后数据一致性会是非常大的问题。
数据聚合查询对B端业务也是核心诉求，微服务后解决方案基本上就是再把数据合起来，代价非常大。
成本：微服务需要很多机器，如果B端业务微服务后，某个客户基于安全考虑提出私有化部署，那么基本上也只能是凉凉了。
3.微服务适合的场景：
发展起来的中大型互联网项目。
a.钱多： 能找到足有多的优秀的人，把微服务架构玩透，让微服务产生正向收益，而不是成为负担。
b.人多： 人多后，在一个项目写代码，相互影响，容易出问题，这时候模块化责任明确，方便管理。
c. 流量大： 微服务模块化后，可以对局部模块扩缩容，局部优化甚至重构，不会影响整体。
d.需求多迭代频繁： 各个模块自己独立开发、测试、发版，互不影响。
标签：Spring,服务,SpringBoot,spring,配置,Boot,SpringCloud,Cloud From： https://blog.csdn.net/zfj321/article/details/144440849