Spring boot与Spring cloud之间的关系

Spring boot 是 Spring 的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务，Spring Boot，看名字就知道是Spring的引导，就是用于启动Spring的，使得Spring的学习和使用变得快速无痛。不仅适合替换原有的工程结构，更适合微服务开发。

Spring Cloud基于Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来；spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现。

学过Spring的都知道，Spring开发有非常头疼的三点:

以启动一个带Hibernate的Spring MVC为例。
1. 依赖太多了，而且要注意版本兼容。这个应用，要添加10-20个依赖，Spring相关的包10多个，然后是Hibernate包，Spring与Hibernate整合包，日志包，json包一堆，而且要注意版本兼容性。

2. 配置太多了，要配置注解驱动，要配置数据库连接池，要配置Hibernate，要配置事务管理器，要配置Spring MVC的资源映射，要在web.xml中配置启动Spring和Spring MVC等

3.部署和运行麻烦。要部署到tomcat里面。不能直接用java命令运行。

太多重复和大家都一样的配置了。

Spring Boot的哲学(核心思想)就是约定大于配置。既然很多东西都是一样的，为什么还要去配置。

1. 通过starter和依赖管理解决依赖问题。
2. 通过自动配置，解决配置复杂问题。
3. 通过内嵌web容器，由应用启动tomcat，而不是tomcat启动应用，来解决部署运行问题。

Spring Cloud体系就比较复杂了。基本可以理解为通过Spring Boot的三大魔法，将各种组件整合在一起，非常简单易用。

你可以把spring boot的官方的包分为两类，一种是为了搭建一个服务用的，比如hibernate jpa，比如 message。另外一种含有cloud关键字的，是为了各个spring boot之前管理和使用的包。

因为当把集群、CI等方法集中进来一起考虑的时候，这件事情就复杂了。

多个小有服务整合成的大服务，要有一个消息总线来用于互相通知和调用，要有一个服务发现程序来管理某个小服务上线可用，同时在服务离线时也要能处理，各个小服务要尽量各自独立，还要考虑服务的依赖性，集群的负载均衡，配置文件的分离。

再把CI和Docker拿进来一起考虑的话，更乱。

但我认为这样完成的一个服务是更具有可插拔性，更容易维护的。而且遵循了上面的cloud方案的话，在服务的健壮性上面也很强。

写到这里对于新接触的我认为可以先从单独的spring boot程序开始入门，当要添加一个新功能时，考虑拆分成另外服务。两个程序间可以通过 jmx或是 其它消息中间件或是rest通讯。最后实现了一个各自独立的功能集群。

总结一句：Spring boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring boot，属于依赖的关系。

spring -> spring boot > spring cloud

关于“约定大于配置”

人类社会在不断文明的过程就是不断建立契约的过程，基于契约建立了我们想要的稳定的社会关系。契约亦或是约定，消除了不同事物在合作过程中的不协调的地方，使得对于共同理想能够更容易的建立一致建设意见。

在软件编程中，需要面对技术上的各种选型、系统组件组合上的各种适配、以及业务需求描述的复杂多变。建立从业务需求描述到技术实现的映射，建立上层调用方式与底层实现逻辑的相互协作，这里面有大量的变量需要考虑和抉择。事实上，在不同的描述体系下，相同或类似事物的地位和作用本质上是一致的，但要建立起两种不同描述体系的自由转换需要一个"翻译工具"。

但这个翻译工具怎么也无法完美地完成翻译工作，原因在于该工具不能像人一样建立起具体的上下文图景，无法拥有人在参与社会实践的地位。如此就免不了这个翻译工具将大量的抉择交给人类完成，这些抉择在软件开发中大多以配置项目的形式提供。

如果配置太多，就加大了人类的思维工作负担，不符合人类利用机器偷懒的初衷。干脆为所有配置提供一个默认选择，或者提供一个自助决策规则，如此建立起人与机器的基本约定。这样在其他类似场景中，机器工具就可以拿来即用。

所以约定大于配置，其实是要建立起尽力减少配置项，采用约定方案的思想。

在SpringBoot中，约定大于配置可以从以下两个方面来理解：

1、开发人员仅需规定应用中不符合约定的部分

2、在没有规定配置的地方，采用默认配置，以力求最简配置为核心思想

总的来说，上面两条都遵循了推荐默认配置的思想。当存在特殊需求的时候，自定义配置即可。这样可以大大的减少配置工作，这就是所谓的“约定”。

那么SpringBoot中有哪些约定呢？

1、Maven的目录结构。默认有resources文件夹,存放资源配置文件。src-main-resources,src-main-java。默认的编译生成的类都在targe文件夹下面

2、spring boot默认的配置文件必须是，也只能是application.命名的yml文件或者properties文件，且唯一

3、application.yml中默认属性。数据库连接信息必须是以spring: datasource: 为前缀；多环境配置。该属性可以根据运行环境自动读取不同的配置文件；端口号、请求路径等