扫码关注公众号，领取更多资源

        Spring Boot 是由 Pivotal 团队提供用来简化 Spring 的搭建和开发过程的全新框架。随着近些年来微服务技术的流行，Spring Boot 也成了时下炙手可热的热点技术。         Spring Boot 去除了大量的 xml 配置文件，简化了复杂的依赖管理，配合各种 starter 使用，基本上可以做到自动化配置。Spring 可以做的事情，现在用 Spring boot都可以做。         过去使用Spring创建一个可运行的项目需要进行大量的配置工作，很是繁琐，SpringBoot使用习惯优于配置的理念，内置一个默认配置，无需手动，可以让项目快速运行起来。

        打开http://start.spring.io/，选择Java语言开发，填写项目信息，然后下载代码。如下图：

        解压后可以得到一个Spring Boot的启动类，代码如下：

        直接选择当前启动类选择运行，一个简单的Spring Boot项目就启动成功了。

        @SpringBootApplication是一个复合的注解，他是如下几个注解组合而成：

        在启动类上加上如上三个注解可以达到与@SpringBootApplication一样的效果，显然后者更加方便些。

        这里的就是Spring IOC中使用的那个配置。既然Spring Boot本质上就是一个Spring应用，那么自然也需要加载某个IOC容器配置，所以加上@Configuration，本质上也是IOC容器的配置类。         所以上面的启动类也可以拆分为如下两个类：

        在如上两个类中，DemoApplication其实就是一个普通的启动类，而DemoConfiguration就是一个普通的配置类而已。

        @EnableAutoConfiguration也是一个复合的注解，主要包含如下两个：

        其中最关键的是@Import(EnableAutoConfigurationImportSelector.class)，他借助EnableAutoConfigurationImportSelector这个类，将当前应用所有符合条件的@Configuration配置都加载到当前Spring Boot应用的IOC容器中去。

        SpringApplication在没有特殊要求的情况下，默认使用模板化的情动流程，但是SpringApplication也在合适的流程节点开放了不用类型的扩展，我们可以对这些扩展点对SpringBoot的启动和关闭流程进行修改扩展。

        在之前的启动类的main方法中只有这么简单的依据话：

        正常情况下，一个SpringBoot项目启动后会在打印台或者日志中打印一个字符画。

        但是我们可以在SpringApplication中来修改打印的内容，对启动流程进行扩展：

        修改banner还有一个简单的方式，就是把需要打印的字符放到一个资源文件中，然后通过ResourceBanner加载：

        正常情况下我们不需要对这个设置进行定制，因为真正的启动逻辑才是我们需要关注的，这只是为了好玩。

        SpringApplication中的run()方法主要的流程大体可以概括为如下几个步骤：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fsJsNZkq-1604679639272)(Boot.assets/屏幕快照 2020-11-03 13.22.30.png)]

在实例化SpringApplication的时候，会提前做好如下几件事情

        至此，一个完整的SpringBoot应用启动完毕。启动的过程很多都是一些通知事件的扩展点，如果忽略这些过程，可以将启动的逻辑精简到如下几步：

        对比可以发现，SpringApplication提供的扩展点占了启动逻辑的很大一部分，除了初始化并准备好ApplicationContext之外，剩下的大部分工作都是通过扩展点完成的，下面对这些扩展点进行详细的讲解。

        SpringApplicationRunListener是一个在SpringBoot的main方法执行过程中接收事件通知的监听者，主要方法如下：

        正常情况下，我们并不需要自己实现一个SpringApplicationRunListener，SpringBoot也只是实现了一个EventPublishingRunListener，用于处理SpringBoot启动时不同的ApplicationEvent。         假如我们需要自定义一个SpringApplicationRunListener，在实现类DemoSpringApplicationRunListener的构造方法中需要两个参数SpringApplication和args，然后可以通过SpringFactoriesLoader的规定，在classpath下的META-INF/spring.factories 中添加如下配置：

        随后SpringApplication就会在运行的时候调用他了。

        SpringApplication是java中监听者模式的一种实现方式。如果需要添加自定的SpringListener，可以有如下两种方式：

       ApplicationContextInitializer的目的就是在ConfigurableApplicationContext的ApplicationContext执行refresh()之前，对ConfigurableApplicationContext的实例做一些设置或处理。        实现一个自定义的ApplicationContextInitializer有如下两种方法：

       CommandLineRunner的源码很简单，如下：

       需要注意的两点：

       以上几个扩展点都建议使用@org.springframework.core.annotation.Order进行注解或者实现org.springframework.core.Ordered接口，便于对他们的执行顺序进行调整，避免阻塞。

       之前在将@EnableAutoConfiguration的时候说了，这个配置可以借助SpringFactoriesLoader的帮助，将注解了@Configuration的Java类汇总并加载到ApplicationContext中去。        实际上，@EnableAutoConfiguration还能够对自动配置进行正价细化的配置和控制。

       在Spring框架中，可以使用@Conditional这个注解配合@Configuration或者@Bean来设置一个配置或者实例是否生效，生成一个类似于if-else条件的生成逻辑。

关注公众号回复“Conditional”获取注解相关详解

       如果要基于条件配置，只需要在@Conditional中指定自己的Condition实现类就好了，如下：

       @Conditional除了可以注解在类和方法上之外，还可以注解在其他Annotation实现类上，组成一个符合的注解，SpringBoot中已经实现了一批，如下：

       除了可以设置基于条件的配置，我们还可以对当前配置或者组件的加载顺序进行调整，以便于在创建加载过程中解决依赖分析和组装的问题。        @AutoConfigureBefore或者@AutoConfigureAfter可以配置当前组件或者配置的加载在其他的之前或者之后进行。比如需要某个配置的加载在另外一个之后，可以进行如下配置：

       之前说过，SpringBoot对开发者的影响主要有以下两点：

       SpringBoot提供了很多以Spring-Boot-Starter开头的依赖模块，这些模块有着默认的配置，正常情况下开箱即用，下面对常用的几个模块做一下介绍：

       Java中有很多日志工具，比如log4j,log4j2,sel4j等等，在SpringBoot中，我们可以直接引用现成的依赖包，即可达到开箱即用的效果。比如添加如下Maven依赖：

       那么SpringBoot就会自动使用logback作为应用的日志框架，在应用启动的时候，初始化LoggingApplicationListener并使用。        如果我们要对日志系统做响应的设置，可以通过如下几种方式进行配置：

       初次之外，还有其他的日志框架，可自行选择，比如： spring-boot-starter-log4j和 spring-boot-starter-log4j2等等，在实际项目中只需要引用一个即可。

       通常情况下，我们开发的项目都是一个web项目，需要使用相应的容器来部署。在SpringBoot的maven依赖中添加下面的配置，就可以得到一个可直接运行的web应用。

       在引入这个依赖之后，启动当前项目，会自动嵌入一个默认的tomcat容器，当前服务就运行在这个容器之中。        spring-boot-starter-web默认将当前项目打包成jar包，在运行的时候可以直接使用java -jar xxx.jar来运行，然后访问响应的请求地址就可以得到响应的response。

       如果项目中需要使用到数据库，那么添加如下依赖：

       正常情况下我们在一个服务中只需要使用一个数据库，那么这种情况下，只需要在application.yml中添加如下配置即可：

       某些特殊情况下，如果一个服务中需要使用到多个DataSource，那么只需要配置如下实例就好：

       但是在添加完上面的代码之后，直接启动会报错，我们需要在启动类上排除SpringBoot在启动的时候对默认的DataSource的加载。

       或者在上面配置多个的DataSource上加上@Primary，可同时达到默认的DataSource和定制化的多个DataSource同时加载的两全其美的效果。        除此之外，还有很多适配不同数据库的依赖，spring-boot-starter-data-jpa、spring-boot-starter-data-mongodb 等，在实际项目中可以根据不同的数据库自行选择。

       SpringBoot还有很多其他的maven依赖，比如：

       SpringBoot微服务部署到响应的环境之后需要对外提供服务，通常情况下，微服务很少单兵作战，而是同时部署多个节点集群部署。        在这种情况下，如果访问者发出一个请求，这个请求具体访问哪一个节点，如何才能找到对应的节点，这个过程就是服务的发现，而一个服务需要作为一个主题对外提供服务，这个构件主体的过程就成为服务的注册过程。        服务的注册和发现在结构上可以简单的展现为下图的三角关系：

       在这整个三角关系中，提供服务的注册者Service Registry是整个关系的核心，他负责登记和保存哪些服务是可以对外提供服务的。当服务的访问者Service Accessor发出请求访问某个服务节点的时候，需要先访问服务注册者，获取可以访问的服务节点信息，这样服务访问者就可以根据返回的信息访问响应的服务。        SpringBoot的微服务注册与发现是有SpringBoot微服务提供服务方式来决定的，如果是基于Dubbo框架的微服务发现方式 ，则很可能是基于Redis或者Zookeeper的注册和发现机制。

       上面这种方式，服务的访问者需要了解服务注册机制，获取到服务节点之后再去访问对应的微服务。但是对于用户而言，服务的访问者就是使用者，不应该过多的去了解服务端有多少节点，而且需要多次访问才能获取响应的请求结果。        一个更好的方案是在服务访问者和注册者之后添加一个服务访问代理，访问者直接对代理发出请求，获取可用节点，对可用节点再次发出请求的工作都交给服务代理去做。优化之后的结构如下：

       经过这样的调整之后，服务的访问者只需要与服务代理打交道，具体服务代理如何发现服务并访问的，对于访问者来说都只是一个黑盒，并不需要做过多的关心。