1 传统 Java 开发之痛

1.1 Java EE 开发标准

• Java 作为一门优秀的编程语言，不仅使用范围广泛，同时也称为了所有企业技术平台开发的首选语言，然而在早期的 JavaEE 技术开发中，受困于当时的硬件条件、软件技术、网络带宽等因素的影响，人们普遍会选择 JavaEE（后来更名为 JarkartaEE ） 标准架构来进行项目的开发工作。

• 如果要想一窥 JarkartaEE 的全貌，那么就需要熟悉一下给出的官方标准，这个标准实际上是早期的 SUN 公司推出的企业级的标准。在 JavaEE 的开发过程之中容器始终是一个核心的话题，那么对于容器来讲就存在了如下的两类容器环境：
  • WEB 容器：只提供了 JSP/Servlet 的标准支持，包括引擎、连接器等等。
    • 免费容器：Tomcat、Jetty、Undertow、JBoss。
  • EJB 容器：纯粹的基于业务中心的构建。
    • 免费容器：JBoss。
• 如果按照原生的 JavaEE 来讲肯定是强调分布式开发的，将所有可能牵扯到业务处理的部分统一交给 EJB 进行处理，而在 EJB 之中又提供了如下的三类 Bean 类型：
  • 会话 Bean ：业务层，主要是依靠若干个数据层来完成最终所需要的处理形式。
  • 实体 Bean ：数据层，主要依靠 JDBC 来和数据库产生关联，同时最重要的是实现 Bean 的实现不需要用户编写代码。
  • 消息驱动 Bean ：整合异构的处理平台，早期的开发是基于 JMS 实现的，是属于应用上的实现而不是协议上的实现，所以性能上并不是很好，后期除了收费的容器可以提供良好的 JMS 支持之外，最终也只剩下 Apache ActiveMQ 来实现了。
• 虽然整个 EJB 的实现理想非常好，而且前景也很好，但是现实很悲催的是，没有一家公司能将 EJB 完美落地，因为 EJB 实在是太笨重了，早期的软件开发受困于当时的网络环境、IO 设备等因素的影响，造成数据量并不像今天这么庞大，早期的 EJB 是考虑将所有的数据放在内存之中进行统一的有效管理。

1.2 Java EE 架构的优化

• 既然发现所有的技术开发，靠容器的分布式技术无法正常完成，所以后期的开发者开始对传统的 JavaEE 架构进行了优化，如：将业务层和数据层统一交到 WEB 容器之中进行完成，将整个 EJB 容器在需要的环境下就使用一个无状态的会话 Bean （类似 HTTP 协议的方式不保存用户的状态），但是这种情况下性能也是非常堪忧的。

1.3 自定义的分层结构

• 利用自定义的分层结构可以直接在一个 WEB 容器中实现所有的程序代码，这样就避免了昂贵的 EJB 容器以及繁琐的远程调用，但是这样一来就会导致项目中的代码量过于庞大，那么就需要项目开发人员对代码进行规范化的管理，同时对不同层之间的调用进行相应的接口设计以及明确的开发分工。

2 Spring 之伤

2.1 Spring 框架出现的原因

• 在 JavaWeb 开发过程之中，实际上出现了很多优秀的开发框架，从 2000年之后出现了 Struts、WebWork（Struts 2.x）等，但是这些框架都只是解决了 MVC 的问题，它们都是基于已经存在的 WEB 容器来帮助开发者进行项目的开发。
• 在使用传统的 JavaEE 架构的时候是存在有 EJB 容器的，它是可以帮助开发者进行各类的容器 Bean 的管理，所以为了解决这个 EJB 容器在 WEB 容器中的使用问题，Spring 框架出现了（Spring 的设计理念来源于 EJB ，但是实现优于 EJB ）。

2.2 Spring 框架是什么？

• Spring 是由 Pivotal 公司推出的一个 JavaEE 的开发框架，最早是由 Rod Johnson 在 2002 年发起的开源项目，是基于 EJB 设计理念实现的一个轻量级容器，可以在不使用 EJB 容器的情况下，利用 Spring 运行容器方便的实现 Bean 的生命周期管理。
• Rod Johnson 在 2002年编著的《Expert One-on-One J2EE Design and Development》一书中，对 Java EE 系统框架臃肿、抵消、脱离现实的种种现状提出了质疑，并积极寻找探索革新之道。
• 同年，他又推出了一部堪称经典的力作《Expert One-on-One J2EE Development without EJB》，该书在 Java 界掀起了轩然大波，不断改变着 Java 开发者程序设计和开发的思考方式。
• 如果真正的去了解过 EJB ，应该清楚 EJB 最大的特点在于其良好的容器实现机制，EJB 容器可以帮助开发者生成大量的程序代码，并且简化各类的应用操作，但是实在是太重了，所占用的 CPU 和内存资源过于庞大。
• Spring 框架提供了非常方便的 Bean 管理机制，使得开发者可以从繁琐的对象实例化和 GC 管理中彻底解脱出来，而后基于 IOC 和 DI 的依赖管理机制，可以方便的实现不同 Bean 对象之间的引用维护，同时利用 AOP 技术可以有效的实现切面控制。由于 Spring 开发框架的日趋成熟使得越来越多的框架都提供了和 Spring 整合的支持，这样使得 Spring 框架的应用范围更加广泛。最重要的是 Spring 是一个被长期维护的开源项目，这样使得其使用的群体广泛，解决了企业中的框架维护和人员学习成本。

• Spring 当时的开发框架并不像今天这样有了一个所谓的 Spring 全家桶 的称号，最早的 Spring 仅仅提供了一个完善的容器（这个容器是模拟 EJB 容器概念而产生的）。最早的容器仅仅实现了一些 Bean 的管理以及一些开发框架的整合（Hibernate、Struts 等），同时当时对于 Spring 里面就只有两个核心的组成结构：IOC && DI 、AOP（是基于程序类的方式实现的，并不是像现在基于切面表达式的方式来进行处理的）。

2.3 Spring 框架的发展

• 随着后来技术的不断进步，Spring 也开始进行了自己全方位技术布局，包括：使用了 SpringMVC 替代了 Struts ；而后又不断的进行了 Spring 框架的改进，例如：Spring 3.x 之后追加了 Bean 的配置，Spring 5.x 又追加了响应式编程，随着技术的全面开花，市面上出现的大量的新型的而且被广泛使用的开发框架以及各种的软件工具组件，都需要和 Spring 进行整合。
• 在实际的开发之中，需要使用 Spring 框架对接的产品：JPA、Mybatis、MybatisPlus、Shiro、WebSocket、AMQP、Kafka、Hadoop……
• 后来很多的开发者还需要不断的去考虑所谓的环境的使用问题，比如：dev、test、prod……，就需要使用 profiles 和 XML 配置进行有效的分离处理了，于是配置文件又开始满天飞了，导致项目的开发极为困难。
• Spring 框架到目前为止已经是 JavaEE 事实上的标准了，但是其本身所带来的代码整合的难度以及繁琐程度也越来越高了（XML 配置文件过长），那么就需要有一种可以改变现状的开发框架，于是 SpringBoot 应运而生。

3 走进 SpringBoot

3.1 SpringBoot 框架产生的背景

• Spring 框架在业内已经得到了足够的认可，而后 2014 年的时候 Spring 团队对 Spring 框架进一步升级，于是得到了 SpringBoot，而在国内是从 2016 年的时候正式引入了 SpringBoot 框架，SpringBoot 是基于 Spring 框架已有的技术特点，形成了更加简化的运行模式，这就是 SpringBoot 产生的背景。

3.2 SpringBoot 的 “零配置”

• 在传统的 Spring 框架开发中，如果要进行服务整合必然需要编写大量的配置文件，但是在 SpringBoot 中将开发者常规的开发操作进行了抽象，使得可以采用 "零配置" 的方式进行组件整合，即不需要再编写 XML 配置文件了。
• 开发者在使用 SpringBoot 开发的时候，只需要将一些重要的服务信息定义在 profile 文件中，而后通过构建工具引入相关的组件模块后，即可实现自动配置。

注意：SpringBoot 的 零配置，有人也会称之为 约定大于配置 。

• 除了简化 Spring 的配置目的之外，推出 SpringBoot 还有什么目的呢？虽然 SpringMVC 所提供的功能已经足够深化了，但是SpringBoot 是为了满足于当前的 微服务 设计要求而准备的。

3.3 微服务

• 在传统的项目架构设计中，会将所有的程序代码保存在一个 war 文件之中，然后进行部署，随着业务的不断完善，单机服务（单体应用）无法承受大规模的并发访问，这样就需要将整体的服务进行拆分，形成一个个小型的微服务，这样不仅可以得到良好的性能，而且代码的扩展性和维护性也得到了极大的改善。

3.4 SpringBoot 的技术特点

• ① 独立运行的 Spring 项目：SpringBoot 可以以 jar 包的形式来直接运行在拥有 JDK 的主机上。
• ② 内嵌 Web 容器： SpringBoot 内嵌了 Tomcat、Jetty 以及 Undertow 容器，这样可以不局限于 war 包的部署形式。
• ③ 简化配置：在实际开发之中需要编写大量的 Maven 或 Gradle 依赖，在 SpringBoot 中提供了 starter 的依赖配置来简化 maven 配置文件的定义。
• ④ 自动配置：采用合理的项目组织结构可以使 Spring 的配置注解自动生效。
• ⑤ 减少 XML 配置：在 SpringBoot 中依然支持 XML 配置，但是也可以使用注解和自动配置机制来减少 XML 配置文件的定义。