1.简介
SpringBoot最开始基于Spring4.0设计，是由Pivotal公司提供的框架。
SpringBoot发展史：
- 2003年Rod Johnson成立Interface公司，产品是SpringFramework
- 2004年，Spring框架开源，公司改名为Spring Source
- 2008年，收购Apache Servlet、Tomcat，为SpringBoot内嵌Web容器奠定基础，整个生态自己掌握
- 2009年，公司被VMWare以4.6亿美金收购
- 被收购后，Spring公司接连收购了很多优秀的开源中间件，比如RabbitMQ、Redis
- 2013年，VMWare、EMC、通用电气三者联合成立Pivotal公司，从这开始，Spring开始一路暴走
- 2014年，推出SpringBoot1.0，基于Spring4.0开发
- 2015年，推出SpringCloud
- 2018年，Pivotal公司上市
- 2018年3月，SpringBoot2.0发布，基于Spring5.0开发
SpringBoot、SpringCloud都是开源的，那么Pivotal靠什么盈利？
微服务是比较新的技术，传统企业要将业务开发微服务模式，肯定会有许多困难，而Pivotal就是靠提供技术服务支持盈利，全球500强公司有2/3的公司都与Pivotal有合作关系。
SpringBoot继承了Spring框架原有的优秀特性，比如IOC、AOP等，他并不是用来代替Spring的解决方案，而是和Spring框架紧密结合，进一步简化了Spring应用的整个搭建和开发过程。其设计目的是用来简化Spring应用的初始搭建以及开发过程。怎么简化的呢？就是通过提供默认配置方式让我们更容易使用。
再来详细解释一下，如果我们基于SSM框架进行过开发，我们可以理解，Spring在集成SpringMVC、Mybatis时，需要做大量的xml文件配置，在集成其他框架或中间件时，也是同样的道理。而再对比一下SpringBoot开发，我们可以发现，我们只需要引入不同的Starters的maven依赖，就可以开箱即用的进行开发。这就是SpringBoot为我们做的：提供默认的配置方式让我们更容易使用。
下面画图来帮助理解： 这是Spring的模块结构
这是我对SpringBoot的理解
关于SpringBoot有一句很出名的话就是约定大于配置。采用SpringBoot可以大大简化开发模式，他集成了大量常用的第三方库配置，所有你想集成的常用框架，他都有对应的组件支持，例如Redis、MongoDB、Dubbo、Kafka、ES等等。
SpringBoot应用中这些第三方类库几乎可以零配置地开箱即用，大部分的SpringBoot应用都只需要非常少量的配置代码，开发者能够更加专注于业务逻辑。另外SpringBoot通过集成大量的框架使得依赖包的版本冲突，以及引用的不稳定性等问题得到了很好的解决。
解释：
- 约定大于配置：使用SSM开发模式，Spring如果要集成Redis，就要在xml文件中配置bean，并为bean配置properties。
- 依赖包版本冲突：我们可以直接引入一个指定版本的spring-boot-starter-web的依赖，就可以导入不会冲突的web开发相关的jar包
总结
- 简化Spring应用开发的一个框架；
- 对整个企业级开发技术栈的一个大整合build anything；
- J2EE开发的一站式解决方案；
优点
- 快速构建一个独立的 Spring 应用程序 ；
- 嵌入的 Tomcat 、 Jetty 或者 Undertow，无须部署 WAR 文件；
- 提供starter POMs来简化Maven配置和减少版本冲突所带来的问题；
- 对Spring和第三方库提供默认配置，也可修改默认值，简化框架配置；
- 提供生产就绪型功能，如指标、健康检查和外部配置；
- 无需配置XML，无代码生成，开箱即用；
2.Why SpringBoot
在开始这个阶段的描述前，首先问自己一个问题，假如我原来使用的是SSM的开发模式，虽然SpringBoot确实简化了Spring开发的配置，但我真的会因为这个简化就去使用SpringBoot吗？
我的答案是不会。首先，我已经熟悉了SSM方式开发，更换成SpringBoot开发模式的成本太大。其实，有很多贡献者提供了方便的SSM脚手架，可以开箱即用。而且SSM开发是单体应用，我只需要做一次集成就够了。
所以上面提到的SpringBoot简化了Spring的开发，这只是最直观的一方面，但并能够让SpringBoot变得如此流行，而真正让他变得流行的是微服务开发模式，这也是谈SpringBoot必谈微服务的原因。可以说是Spring Cloud带动了SpringBoot ，SpringBoot成就了SpringCloud。
下面这张图描述了Spring、SpringBoot、SpringCloud之间的关系。
从谷歌关键词搜索中，我们也可以看到SpringBoot和微服务的火热程度是同步的。
微服务
说到微服务，不得不提到应用的架构演变过程。下面以电商为例做一个简要说明。
在传统应用开发中，我们所有的模块都在一个应用中开发与维护，也就是ALL-IN-ONE开发模式。如果是一个电商应用，那么这个应用中会包含用户模块、支付模块、订单模块、商品模块等等。如果用户提升，应用访问量上升，那么会使用负载均衡的架构，如下图：
但随着应用体积增加，访问量增多，单体应用难以维护、单个模块瓶颈等问题暴露了出来。比如随着开发人员增多，几百个人同时维护一个项目，代码的合并、项目的上线就是很大的问题。还有假如在某些活动时期，比如双11，订单模块流量是最多的，而商品、用户模块访问量可能与平时差不太多，那么如果去部署更多的单体应用服务器，会耗费更多的硬件资源，增加成本。因此也就催生出来微服务架构。
下图是微服务架构，从左到右。流量从左边进入，经过一个个节点，可能是订单模块的节点，可能是用户模块的节点，他们之间使用远程调用方式通信。直到最右边两排，最右边是mysql等持久层存储，挡在他前面的是缓存层，比如Redis。
继续说回SpringBoot。随着流量上升，微服务架构势在必行，或者说水平扩展应用势在必行，那么我如果继续以原来的SSM开发模式开发，原来只需要进行一次的Spring集成其他框架我需要集成很多次，那么就远不如SpringBoot更加快速方便，所以说Spring Cloud带动了SpringBoot ，SpringBoot成就了SpringCloud。
