SpringBoot的核心原理（扒笔记记录）_spring boot5核心原理pdf-CSDN博客

本文链接：https://blog.csdn.net/YimBa/article/details/126911727

这一课的主要重点：

自动装配以及starter
JDBC数据库连接池
ORM、JPA、MyBatis、Hibernate这样相关的一些技术

从Spring到SpringBoot

我们在工作中都可能用过了SpringBoot，特别是最近几点，Java开发者大军里的一员，我们一般可能上手就是SpringBoot。但是大家有没有想过，为什么有了Spring技术以后，又搞出来一个SpringBoot，为了搞清楚这个问题，我们来简短回顾一下Spring的发展过程：特别是装配这块和功能这块。

简单来说，Spring从差不多20年前就开始，只有XML的配置，这种全局化的一个XML文件。或者分开几个文件然后通过input方式，在汇总成一个文件。这种全局的配置方式，慢慢地就进化到可以使用注解的方式。我们把配置分散到我们具体的一些类的文件上，在类上面加注解。比如说：@Service、@Componet、@Repository。这样的一些注解。再接下来我们有了配置类（@Configuration），我们有了所谓的@Bean的注解，我们就可以把一些注解放到方法上。在方法的级别上让所有的这些方法的返回值，变成我们的Spring容器里的对象，Spring里的Bean。进而进一步地让Bean的配置更加的灵活、更加的分散，力度越来越小了。这样一来，在使用更灵活的同时，其实带来了一个大麻烦，就是我们所有的注解其实满天飞。你都不知道你现在Spring容器加载起来以后，你的这些Bean到底在哪里、哪里配置的，乱了。这个其实只是一个表象，如果我们再追更深一层来看待这个问题，它本质的原因其实是Spring整个技术体系整个框架，加上它上面集成的各种功能，越来越庞大，越来越复杂，越来越臃肿。Spring从1.0、2.0、2.5、3.0、3.1然后四点几，到现在的五点几，这个过程中不断地在添加新的功能新的组件，慢慢地Spring自己内部，整合各种不同的技术，就像Messaging、JMS集成其他的AMQP、RabbitMQ、Kafka等乱七八糟的。Spring整个技术体系组件越来越多，已经是成百上千个了，这个时候我们使用Spring整个技术体系的时候，就会带来很多的副作用。它本身就变得很复杂、很庞大、很臃肿了。特别是2010年以后，这个问题越来越突出，以至于有时候我们就认为Spring大概在2002 03年的时候横空出世，作为当时反对更庞大更臃肿的J2EE、EJB体系的这样的一个屠龙的勇士站出来，经过了10多年的发展，它自己本身看起来也变成了一条恶龙。所以这个时候Spring体系本身很臃肿很庞大，很多人就在思考，我们怎么能够简化Spring的使用。Spring本身它的目标是使Java开发变得更简单，它现在自己变复杂了，那么很多人自然就会想到了，怎么给他减负。所以这一切，就是SpringBoot发展的一个动力，具体来说就三点：怎么让开发变得更简单、怎么让配置变得更简单、怎么让运行变得更简单。

说到这里就不得不提一个概念，就是什么是限定性框架和非限定性框架？Spring本身其实是一个非限定性框架，什么意思呢。就是他像是一些原始的材料，你拿到一些面粉，你加了水，发了面，和了面以后，包饺子，做包子，蒸馒头干什么都可以。他不限制你的使用，也不限制你到底要把它跟别的什么东西，什么馅儿，还是没有馅儿，还是炸油条，跟什么东西混在一块来用。你想怎么搭配怎么搭配。你可以改里面的任何东西。这是所谓的非限定情况下对你不做任何限制。什么叫限定性框架。比如说你已经搭配好的一个脚手架SSH，这简单的来看，就可以看作是一个限定性框架。有一些关键的技术选型已经帮你选好了。帮你选好的意思就是说，就这么搭配的，这个面是用来炸油条的，不能包饺子。它里面对着各种别的东西，发酵粉、碱、加的水的比例等，就是配合好了用来做油条的。简单来说限定性框架用途相对来说要更窄，但是它把一些基础的东西已经帮你选好了，这时候就不会让你有所谓的选择困难症，或者是让你从头再去搭配比例。简单来讲限定性框架其实是在现有的各种原材料的基础上做了一个初步的整合，正是这种整合能够让我们不用所有东西从头开始，从去磨面粉甚至是种小麦那个层次开始，我们从中间这个步骤就可以接下来来干我们想做的事情。

在Spring的具体的领域上，其实国内国外都中间有很多尝试，比如说国内在早期有一个著名的框架，江南白衣的SpringSide，他就尝试了在我们的当前这个项目的脚手架里，把各种常见的RPC的，MQ的各种组件全都集成进去，变成一个依赖的模块，然后你想使用的时候把SpringSide拿过去，基于他的基础上你就可以相当于选择你想用的这几个组件直接来用了。但是当时各种这种简化其实做的并不是很彻底，因为条件没有成熟，第二方面Spring团队，Spring技术体系本身对这块，没有一些特别直接和特别好的支持。最终一直到SpringBoot的出现，SpringBoot其实引入了两个最大的改进点：因为SpringBoot同时考虑了站在Spring框架的内和外来看我们应该怎么来简化Spring本身。这块最终采取了一个优化的最大的特点是：约定大于配置。什么意思呢，举例来说，就像我们用JVM的时候，跟大家讲过，JVM内置的命令行参数，各种调入的参数，有1000多个，实际上我们不使用任何一个参数，直接用java命令，-jar运行一个jar包或者Java HelloWorld就可以运行起来一个类，不需要配置任何参数，为什么可以这样，原因就在于约定大于配置。所有的参数基本上都有默认值，如果我们没有配置的话，没有配置那些参数没有指定他们的值那么就使用默认值，当我们在Spring体系里面，一方面，我们引入所有的参数配置，用这种使用默认值约定大于配置。另外呢，我们各种组件先关的整合，组建的搭配，也是用这种约定大于配置。那么很多东西自然而然的就被SpringBoot把他给整合，把框架和框架，技术和技术，中间差的这层裂缝给粘合了。所以SpringBoot很多时候我们看做他是一个整体的粘合剂。

SpringBoot如何做到简化：

所以我们要总结一下SpringBoot为什么能够做到Spring开发的技术做到极致的简化。原因可以归纳为四点：

随着Spring技术本身的成熟和完善，各方面第三方的组件，大家其实可以发现再过去的十年里Spring基本上就是整个J2EE开发的实施标准，这样的话已他最为标准，各种第三方的技术都会主动的跟他适配，跟他来集成，这样的话他跟第三方组件的集成越来越完善，越来越成熟。什么千奇百怪、乱七八糟的组件，他都能够很好的集成和搭配Spring一块来使用。特别是在这个过程中，Spring本身的自动化配置，自动化装配的成熟。这个成熟其实最终催生了SpringBoot这个体系的产生。并且非常快速的发展，
Spring团队在去Web容器化这方面的努力，很多同学可能不知道这个事情，就是SpringBoot最开始是怎么来的，最开始是Spring团队的一帮人觉得，一方面Spring当时非常庞大非常难使用；另外一方面，觉得Spring创建出来的现在的部分都是Web项目，这些Web项目必须跑在Web容器，就是Tomcat里。那么我们部署运行就会相对的比较麻烦，需要一个Tomcat的容器。所以早期我们开发不管是用IDEA，还是Eclipse的时候大家就会发现我们必须先在IDEA或者在Eclipse里先配置一个Tomcat，然后再把我们的项目运行的时候，运行在配置的Tomcat里，那么我们有没有可能不需要任何东西就直接把我们当前的工程，这个jar包就run起来，只有做到这一点，Spring技术体系才是一个真正能够完整自洽的不需要再依赖任何其他的东西了。这样的话一个技术体系，所以他们干的第一件事，就是把Tomcat的内核抽出来。Tomcat也是用Java实现的，抽出来以后就形成了一个嵌入式的Tomcat，有了这个嵌入式的Tomcat，SpringBoot开发的Web应用程序，可以呢，我们通过FatJar的形式打包成一个大的把所有的依赖都抽出来打进去的这样一个jar包。那么就可以直接运行这个jar包了。不需要任何其他的依赖，依赖一堆的Lab，比如说很多Spring的，比如说解析XML的。Log4j的这样的话一大堆jar，都不需要了，因为打包到一个大的jar里了。一方面自己run起来对吧，内部内置了一个嵌入的Tomcat的，也不需要一个单独的Tomcat的web容器了，很干净很清爽。简化到极致了。
基于Maven和POM的Java生态体系，整合POM末班成为可能。好多人不知道POM，POM这种Java整个包管理，库依赖的这个体系的成熟。POM是什么呢，是Maven里面我们用来描述一个项目结构，一个项目的定义依赖关系，它的组织名、组件名、版本号以及他怎么编译，要依赖哪些Maven插件，怎么打包，怎么发布等等。整个项目描述的一个模型。所以他叫项目对象模型（Project Object Model）。这个模型，再加上Maven的中央库，这两个因素其实是当前Maven基础上是Java开发的构建、包管理、项目打包这样一个环境的标准工具。虽然后面有很多其他的工具：SBT基于Scala的、然后有Gradle基于Groovy的。但是其实现在用的都没有Maven广。而且SBT和Gradle其实都是构建在Maven的体系的基础上的。随着Maven，我们把所有依赖的第三方的开源的各种jar包类库都统一地管理我们在Maven中央库上，当然我们本地也可以有一个Nexus的这样一个我们私有的仓库来同步和管理它。这个时候我们就可以基于POM文件的结构，把所有Spring整合到第三方，所有的依赖统一的打包到一起来，也就是我们前面讲的给大家搭配好的面粉，别的一些调料，加了一些水比例统一的都在POM文件里面调配好了。这时候当你去需要使用它的时候，你就只需要引入这样一个SpringBoot的POM，在里面勾选上你需要的这几种成分就可以了。
避免大量Maven导入和各种版本冲突。就在刚才的基础上他自己搭配好的各种组装的成分。中间避免了成分和成分之间的冲突。比如一个Jar包和另外一个Jar包版本不一致。两个依赖发生冲突，这个东西都已经帮我们解决好了。也就是说我们不需要考虑，直接使用它帮我们搭配好的本成品的原材料里面，有两种元素发生冲突，导致有毒，或者导致他俩的营养成分失效，这些因素都不需要考虑了，我们自己往往去重头来搭建一个项目骨架的时候，我们引入两个包，他们俩有可能版本冲突或者他俩没冲突，但是他俩再依赖了比如Netty包，依赖Netty包一个是四点几，一个是五点几，然后里面API不一样，他俩冲突了。这些问题SpringBoot先天帮我们搭配好的这样一个配方里，已经把这些潜在的问题帮我们消灭掉了。所以我们整体来说SpringBoot是Spring的一套快速开发、快速打包、快速运行的一个脚手架。他关注什么，他关注于我们的自动配置以及我们的配置驱动。就是说我们只需要使用最少量的配置，甚至零配置，都能把我们的程序run起来。非常快速。然后所有的体系，什么叫体系，运行的时候有什么东西，都是根据我们的配置，配置驱动来拉起来的，没配就没有了，你配了他可能才有。当然了，这一切的前提就是背后的那套约定：约定大于配置。这里大家可以思考一下什么是脚手架。什么是框架。

SpringBoot是Spring的一套快速配置脚手架，关注与自动配置，配置驱动。

什么是SpringBoot

我们零零总总的说了这么多，可能有些同学还会比较模糊，SpringBoot到底是个啥。我们这里调一下书袋，这些内容都是SpringBoot官网上的内容：

SpringBoot使创建独立运行、生产级别的Spring应用变得容易，你可以直接运行它。我们对Spring平台和第三方库采用限定性视角，以此让大家能在最小的成本下上手。大部分SpringBoot应用仅仅需要最少量的配置。

这句话什么意思呢，SpringBoot做出来的程序一般情况下都是可以直接运行的，独立部署的，不需要web容器的。就是一个大包，也不需要各种依赖，不仅在开发环境是这样，你把这个大的包挪到生产环境，生产环境的服务器上只要有JDK，有JVM，都可以把它run起来。我们对Spring平台和第三方视角采用限定性视角，以此让大家在最小的成本下上手。什么意思，就是说，里面组合集成的各种框架，各种技术都是SpringBoot的团队已经帮我们组装好了，默认开箱即用。如果有些组装好的你不想用，你想用另外的，对不起，默认这套东西是不支持的。当然你可以用我们后面讲到的各种自定义starter这类技术和引用第三方的额外的starter技术。把他拼装起来也是支持的。但是默认这套东西，帮你搭配好了，你可以在里面选，但超出这块的他默认是不支持的。为什么这样，还是为了让我们约定大于配置。让我们使用的代价最小，帮你搭配好了原材料。最后一句，大部分SpringBoot的应用仅仅需要最少量的配置。基于前面那些特性，自然而然的有这一句了。所以使用起来非常方便了。我们像Spring1.0/2.0/2.5/5.6之类的版本里面，动辄上千行的XML相关的Spring配置，现在可以简化到几乎没有了。

然后我们再来看下SpringBoot的六个官方提供的功能特性：

创建独立运行的Spring应用
直接嵌入Tomcat或Jetty，Undertow，无需部署WAR包
提供限定性的starter依赖简化配置（就是脚手架）
在必要时自动化配置Spring和其他三方依赖库
提供生产production-ready特性，例如指标度量，健康检查，外部配置等
完全零代码生产和不需要XML配置

当然这里没有说全，实际上远远不止六个，第一个是创建独立运行的Spring应用，第二个直接嵌入Tomcat或Jetty，UnderTow，无需部署WAR包。像最新的版本Spring 5里面的WebFlux，内置的WebServer，是基于Netty的。第三个提供限定性的starter依赖简化配置，其实就是他自己拼装好的脚手架，比如跟Mybatis，Hibernate之类的这样的一些集成都提供好了现成的供starter直接拿来即用。第四个在必要时自动化配置Spring以及其他的第三方依赖库，很多的框架和框架之间整合，如果我们之前都是自己来搭框架，自己来做项目骨架，就会发现项目和项目之间，整合之间我们要做大量的工作，相当于在中间抹胶水抹水泥，把他们合到一起去。现在统统不需要你做了。SpringBoot帮你全都做好了。第五个，提供生产production-ready特性，例如指标度量，健康检查，外部配置等。也就是说在生产环境下已经部署好，正在运行的这样的一些应用，提供了一些额外的指标的监控，服务是不是可用，外部的一些配置，甚至配置的一些更新相关的操作，都帮我们做好了，不仅仅让Spring只负责做开发，然后打包，系统的run起来之前的加载过程，现在甚至在系统运行的过程中，他也能帮我们做一部分的工作了。第六个，完全不需要XML配置了，全都是通过我们的注解或者Properties文件或者跟Properties文件等价的YAML配置文件。

以上这块就是官方对SpringBoot这个项目，它的定位，它的功能，它的特点这一类进行的描述。通过这个我们就可以对SpringBoot这个框架有一个大致的认知。他能干什么，他的特点是什么，跟以前的Spring有什么样的不同。

快速构建基础Maven项目：

刚才我们一直在说构建一个SpringBoot项目特别特别的容易，基本上你不需要干啥，从零开始就可以打出来一个框子了。脚手架就是线程的。

具体怎么做，常见有两种方法：一种直接在我们的IDE里面，一般我们现代化的IDE都已经支持了直接用来创建SpringBoot的项目，另一种我们也可以用Spring官方网页上提供的一个initializr这样一个工具，选择你需要的各种环境参数，然后填上你再组织构建的名字，项目的名字，甚至去选一些你的依赖的官方各种搭配好的其他整合框架，比如说Mybtis像这种东西，最后点Generate，他就帮我们自动的把脚手架生成出来了。生成出来的是一个zip包。下载下来之后直接导入到我们的开发工具里就可以用了。

Group：组织的名字，io.github.yimba

Artifact：当前这个构建的名字，demoidea

Version：版本号，默认不用