springboot基础入门

1.基础入门

1、spring与springboot

spring

spring能做什么

如下：微服务、响应式、云、web应用、无服务架构（类似java里的函数式编程）、批处理

spring的生态

具体请看链接https://spring.io/projects/spring-boot
覆盖了：web开发、数据访问、安全控制、分布式、消息服务、移动开发、批处理

spring5重大升级

1.响应式编程

左边响应式栈、右边Servlet栈

2.内部源码设计更新

基于Java8的一些新特性，spring也做了相应更新，如：接口默认实现。重新设计源码架构。

为什么用springboot

SpringBoot是整合Spring技术栈的一站式框架 SpringBoot是简化Spring技术栈的快速开发脚手架 Spring Boot makes
it easy to create stand-alone, production-grade Spring based Applications that
you can “just run”. 因为其能能快速创建出生产级别的Spring应用

springboot的优点

创建独立Spring应用、并自动配置Spring以及第三方功能
自动starter依赖，简化构建配置、无代码生成、无需编写XML，使之更专注业务本身
内嵌web服务器
提供生产级别的监控、健康检查及外部化配置

springboot缺点

人称版本帝，迭代快，需要时刻关注变化
封装太深，内部原理复杂，不容易精通

微服务+分布式+云

微服务（MicroService）

[James Lewis and Martin Fowler(2014)(https://martinfowler.com/articles/microservices.html) 提出微服务完整概念。
https://martinfowler.com/microservices/

• 微服务是一种架构风格
• 一个应用拆分为一组小型服务，应用围绕业务功能拆分服务
• 每个服务运行在自己的进程内，也就是可独立部署和升级
• 服务之间使用轻量级HTTP交互
• 可以由全自动部署机制独立部署
• 去中心化，服务自治。服务可以使用不同的语言、不同的存储技术

分布式

概念：就是怎么进行微服务，相当于微服务的实现方式

困难
远程调用、服务发现、负载均衡、服务容错、配置管

• 理、服务监控、链路追踪、日志管理、任务调度
• 解决方案: springboot + springcloud

云原生（涉及docker）

上云的困难

服务自愈、弹性伸缩、服务隔离、自动化部署、灰度发布、流量治理

上云的解决

如何学习springboot

spring.io进入官网 -> project -> springboot -> learn ->
reference GA表示稳定版本，SNAPSHOT快照版本是很不稳定的。

官方文档架构

以下三张照片

如何查看新版本特性

https://github.com/spring-projects/spring-boot/wiki#release-notes

2、springboot2入门

1、各工具版本要求 (java、maven、idea)

怎么查看系统要求？ 通过reference docs（参考文档）里的 Getting Started（入门）

Java 8 & 兼容java15 . Maven 3.3+ idea 2019.1.2

2、maven设置

在 maven/config/setting.xml里面增加如下设置。

然后在idea的setting -> Build -> maven里改变maven的来源和配置文件的位置

3、创建springboot项目

需求：浏览器发送/hello请求，响应 Hello，Spring Boot 2

1.创建maven工程

2.引入依赖

刚创建的maven项目，其pom.xml是空的，需要引入父项目和依赖，可以根据springboot的官方引导文件(getting started)。


spring-boot-starter-web依赖
spring-boot-starter-web依赖称为web的场景启动器。 适用于开发web场景。如下图，此依赖包包含很多文件：比如 日志、autoconfigure、json、tomcat、aop、beans、context、core、mvc

3.创建主程序

4.编写业务

在controller包下

5.测试：直接运行main方法

4、springboot项目的优势

简化配置

之所以说简化配置，是因为现在不需要各种复杂的配置文件，只需要一个：application.properties(创建方法：new -> File)
比如改变端口号： server.port=8888
配置文件到底能改哪些配置？
在reference doc里的application properties里可以看到

简化部署

最终效果：把项目打成jar包，直接在目标服务器执行。
打包后的jar直接拥有各种运行的环境（包括tomcat）
springboot也可以简化部署，比如如果想把项目达成jar包，直接在pom.xml引入下面build
build

然后，点击左侧的maven，选择clean，package然后运行

最后在该jar文件目录下打开cmd运行jar文件
那怎么运行jar文件呢？ java -jar 文件名

注意点：取消掉cmd的快速编辑模式，否则cmd运行jar的时候很容易被打断（鼠标一点就会打断）

一个运行cmd的小妙招：直接在目录上cmd，就可以运行

3、了解自动配置原理

springboot特点

1.依赖管理

父项目做依赖管理

开发导入starter场景启动器

spring-boot-starter-是官方提供的、-spring-boot-starter是第三方提供的
1、见到很多 spring-boot-starter-* ： *是指某种场景
2、只要引入starter，这个场景所有常规需要的依赖都会被自动引入
3、SpringBoot所有支持的场景：cache、mail、security等，更多查看下列链接 https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-starter
4、见到的 *-spring-boot-starter： 是第三方为我们提供的简化开发的场景启动器。
5、所有场景启动器最底层的依赖
依赖管理的好处：无需关注版本号，自动版本仲裁
1、引入依赖默认都可以不写版本号。（因为所有场景启动器都启用最底层的依赖）
2、引入非版本仲裁的jar，要写版本号，否则就会启用最底层依赖。（如果pom.xml里有properties，并且增加了相应的版本号，那么引入依赖的时候，就不用写。）
也可以修改默认版本号
办法：进入 mvnrepository.com，找到想要的依赖及其版本，然后在pom.xml里增加属性，然后添加想要的值

2.自动配置

springboot有没有复杂的配置文件和复杂的包结构？ 有，只不过这些配置springboot都默认配置好了而已。
1.回顾spring和springmvc的整合

spring和springmvc里整合，有三个配置文件：web.xml，spring配置，springmvc配置。 web.xml里配置
servlet和filter，两者同级 springmvc配置里 配置视图解析器
1.首先要在web.xml里配置 DispatcherServlet的servlet，作用是拦截所有请求，如下。

2.spring和springmvc里，为了解决中文乱码问题，在filter里配置了characterEncodingFilter，这样能保证所有代码里的中文，在显示到前端页面的时候，全是UTF-8，以此避免乱码问题

3.springmvc里，有视图解析器view.InternalResourceViewResolver。

2.查看上面在springboot里的相关配置

查看springboot里的DispatchServlet、字符编码、视图解析器
如果springboot里配置了mvc，那么肯定配置DispatcherServlet，所以通过查看IOC容器里是否有此组件来反证mvc被配置

运行结果



3.透过上面的操作，发现
引入相关场景之后，springboot会 1.自动引入相关依赖； 2.并且默认配置好。比如，进入spring-boot-starter-web里面，发现里面有tomcat依赖。
自动配好Tomcat
引入Tomcat依赖。

配置Tomcat
自动配好SpringMVC
引入SpringMVC全套组件
自动配好SpringMVC常用组件（功能）
自动配好Web常见功能，如：字符编码问题
SpringBoot帮我们配置好了所有web开发的常见场景
默认的包结构
主程序所在包及其下面的所有子包里面的组件都会被默认扫描进来（即同级及下级）。如下

无需以前的包扫描配置
想要改变扫描路径怎么办？
@ SpringBootApplication (scanBasePackages=“com.atguigu”)

或者@ComponentScan 指定扫描路径。其实这个不会起作用，因为@SpringBootApplication里还有ComponentScan，故而会覆盖上面的ComponentScan

配置：各项配置拥有默认值
默认配置最终都是映射到某个类上，如：MultipartProperties
配置文件的值最终会绑定每个类上，这个类会在容器中创建对象
按需加载所有自动配置项
非常多的starter
引入了哪些场景这个场景的自动配置才会开启
SpringBoot所有的自动配置功能都在 spring-boot-autoconfigure 包里面
小知识：@SpringBootApplication和@ComponentScan
@ SpringBootApplication = @ SpringBootConfiguration + @ EnableAutoConfiguration + @ ComponentScan(“com.atguigu.boot”)，因为

容器功能

组件添加：一个bean就是一个组件，bean和组件是同一个概念

回顾spring的配置文件实现组件添加

之前添加组件的方式都是创建bean.xml，在里面写标签。如下

springboot实现配置文件

怎么实现？使用@Configuration注解。
@ Configuration注解：告诉springboot，被其标注的类是配置类（一个配置类：等同于以前的一个配置文件，比如bean.xml）
此类里一个方法代表一个bean标签。
方法名 == id
方法返回值类型 == class
方法返回值 == 此bean对应的ioc容器里的实体

实例1：配置之后，查看ioc容器里的组件名

注解功能

1.底层注解@Configuration

作用上面有讲；配置类里的一个方法就是一个bean，且是单例的
配置类本身也是一个组件

proxyBeanMethods属性
如下，默认为true

作用：代理bean的方法。外部无论调用多少次这个配置类中的这个组件的注册方法，获取的都是之前注册到容器中的单实例对象
如下代码，答案为true

注意，如果是config不是从容器中取的，那么就不归spring管理，此时和正常的java代码一样，不存在单实例的问题
答案为false

适用场景：组件依赖
组件依赖：组件之间的互相依赖，确保是同一个组件。（单例模式）
答案是true。确定组件依赖的实例和取出的实例是同一个（单例模式）。


有两种模式
Full(proxyBeanMethods = true)
Lite(proxyBeanMethods=false)
Lite的好处：springboot启动的时候会跳过检查，这样springboot启动快
所以可推断出使用两种模式的原则：如果别人不需要依赖我们的组件，就用Lite，否则用Full（怎么判断是否依赖呢？比如上面的pet就被user依赖，而user不被任何组件依赖）

2.@Bean、@Component、@Controller、@Service、@Repository

@Bean：导入第三方包里面的组件。
上面也是添加组件的常用方法：用在Controller层、Service层、数据库层

3. @ComponentScan、@Import

ComponentScan上面有讲，就是一个指定扫描规则
@Import：快速给容器中导入一个组件
@Import（要导入到容器中的组件）：容器中就会自动注册这个组件，id默认是全类名

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WCTOzHnt-1615982718403)(https://api2.mubu.com/v3/document_image/e0e6f807-ed84-46e5-88c7-5e996acc183a-10388460.jpg)]

4.@Conditional

条件装配：满足Conditional指定的条件，则进行组件注入

相当于if，满足if语句，下面的代码才继续执行
conditional是根类

如下，可以加在方法上，也可以加在类上。作用是一样的，满足条件才向下执行。加在方法上的条件不满足，方法就不执行；如果加载类上条件不满足，那么整个类的代码都不会被执行


一个方法：run.containsBean(String s);

5.@ImportResource：导入原生配置文件

使用场景：如果springboot里有原生的配置文件，比如spring.xml，运行看看，结果如下



上面说明，配置文件并没有发挥作用，因为springboot 根本不认识这个文件。怎么办？通过ImportResource引入。 至于该注解放到哪个类上，这都是可以的，因为后面springboot会全部扫描对应的包结构里的所有的类的注解。

6.@ConfigurationProperties：属性绑定(类和配置文件中的属性值)

只和核心配置文件里（application. properties）的内容绑定
法1、@Component + @ ConfigurationProperties
代码测试（用controller层进行测试）：




法2、@EnableConfigurationProperties + @ ConfigurationProperties

有可能会有第三方包中的类，没有@Component，那就只能采取这种办法。
EnableConfigurationProperties是开启属性配置功能，但是一定要指明开启的谁的属性配置功能。
代码测试2：
此Car类的作用只是为了使用EnableConfigurationProperties。Car类可以是任何内容。

自动配置原理入门

引导加载自动配置类 @.SpringBootApplication

下面是该类的源码分析，最好通过脑图方式查看 @SpringBootApplication --此文件是源码分析，最好用脑图方式看
按需开启 自动配置项

举例

举例2：下文的DispatchServletConfiguration就不爆红，说明条件满足

两个实例：源码研究

研究一下底层的DispatcherServletAutoConfiguration

然后看一下DispatcherServletAutoConfiguration类里的一个小配置类。解读注解和方法
源代码

注解
重点说一下EnableConfigurationProperties这个注解，点进WebMvcProperties

注意：第一张图里有EnableConfigurationProperties注解，然后第二张图里有ConfigurationProperties，因为这两个属性就是配合着一起用的。
说明如果配置文件（application. properties）里有spring.mvc的配置，就会被应用到这里的配置文件里。
方法
除此之外，下面这个DispatcherServlet（）就是容器中 dispatcherServlet的来源

另外，同样属于该类的 multipartResolver()（文件上传解析器方法）也很值得研究。

第一个Conditional：当容器里有该组件时
第二个Conditional：当容器里没有 该名字的 组件时，名字的值如下

上面两个合起来就是：当容器里有MultipartResolver而id又不是multipartResolver的时候，从容器里找到此类型的组件，然后重新返回到容器里（只不过此时id已经是这个方法的名字，即multipartResolver）
这里面还涉及到了一个知识点：给@Bean标注的方法传入了对象参数，这个参数的值就会从容器中找。
这样做的目的是
防止有些用户配置的文件上传解析器不符合规范（因为用户很可能给文件上传解析器起一个乱七八糟的名字，毕竟用户没看过底层源码）
再研究一下HttpEncodingAutoConfiguration

如上图两个注解，当容器中没有characterEncodingFilter这个组件时，创建一个这样的filter，并且把它加到容器里（@ Bean）。
那么想想，如果容器里有这个组件会怎么样？另外，你觉得如果有容器里有，最有可能是谁加进去的？这样的设计有什么好处？

总结：springboot的设计规则（如果用户自定义了，就以用户的优先）

通过上面两个实例验证了按需开启的原则。而且体现了springboot的一个设计规则。
SpringBoot默认会在底层配好所有的组件。但是如果用户自己配置了以用户的优先

总结2：xxAutoConfiguration、xxProperties实现配置文件赋值

最佳实践

如果想查看相关场景都自动配置了那些东西，这么看？

1.自己分析，去 xxxAutoConfiguration类下去找。
引入的场景，其对应的自动配置一般都生效了
2.在配置文件中加上 debug=true，开启自动配置报告

上面配置是否开启，以及开启的原因都写的很详细
Negative不生效，Positive生效

怎么知道修改配置项？

首先去看配置项的默认内容，有两种办法
1.去官方文档https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html#common-application-properties
2.找底层源码，自己分析：找xxxProperties绑定了配置文件的哪些项
然后是修改内容，有两种办法
1.@Bean、@Component（自己先往容器里加，底层就不加了）
2.在配置文件中修改相关配置项
还有更多，比如自定义器 XXXXXCustomizer；

实例1：修改springboot的banner

通过查文档，找到banner的配置项如下。

然后，再配置文件里修改如下

springmvc

作用：用于处理Http请求

怎么实现

首先要做的第一件事情就是要 为每个url找到对应的java类及方法

寻找方法很多，下面是几个例子
简单的做法，可以用一个Map保存所有url和“java类及方法”之间的映射
复杂一点的，使用注解来定义方法和url的关系
所以，自然而然的，我们可以抽象出一个接口来表示这个寻找动作，不同的人可以按照自己的需求订制这种寻找过程。

接口如何设计？里面肯定有一个方法，入参是HttpServletRequest，出参是java类和方法。 关键就在出参上，出参面临下面几个问题
返回的出参（类和方法）必须具有执行请求的能力，简单说就是能够解析入参，执行java方法，返回结果。要实现这个就比较复杂了，因为参数的解析方式多种多样，每个java类的会有很多方法，每个方法的出入参也千差万别。所以SpingMVC在设计的时候，将这个复杂的逻辑交给了HandleAdaptor，HandleMapping只需要返回需要执行的类就行了。
以前，我们定义拦截器可以实现Filter接口，然后在web.xml配置需要拦截的path就行，但是这样的拦截器没法交给SpingMVC管理，为了实现统一的管理，SpringMVC实现自定义了拦截器接口。定义拦截器接口、实现拦截器都很简单，麻烦的时候，拦截器什么时候应该调用，应该拦截哪些请求。最好的办法是每次处理请求时，返回java类的时候，一并返回这次请求的拦截器

流程