【读书笔记】SpringBoot读书笔记

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

整体目录结构：

一、入门

二、开发第一个应用程序

三、自定义配置

四、测试

五、Groovy与Spring Boot Cli

六、在Spring Boot中使用Grails

七、深入Actuator

八、部署Spring Boot应用程序

附录A、Spring Boot开发者工具

附录B：Spring Boot起步依赖

附录C：配置属性

附录D：Spring Boot依赖

整体来说这本书说明了什么？

通过最简单的案例和文字系统性的介绍了SpringBoot的几个核心原理和知识点：起步依赖、自动配置、自定义配置、Springboot Cli、测试、部署、工具支持、监控。并且通过Croovy和Grails等其他语言进行了最简单的案例演示。

作者细说了什么？怎么说的？

本书是一本工具书，开篇一般是对于原理的讲解，又讲解了优点，后续是具体案例的实施。

这本书说的有道理吗？是全部有道理还是部分有道理？

无所谓道理，并没有太多作者的观点，有观点基本上没有对错。

本书跟我有什么关系？

我希望能够通过本书了解Springboot的核心内容和基本概念，了解因果原理，记录下实践所需要注意的点，在工作中提供一个解决问题的思路。

第一章：入门

SpringBoot的背景和问题

Spring Boot提供了一种新的编程范式，能在最小的阻力下开发Spring应用程序。有了它，你可以更加敏捷地开发Spring应用程序，专注于应用程序的功能，不用在Spring的配置上多花功夫，甚至完全不用配置。

Spring诞生时是Java企业版(Java Enterprise Edition，JEE，也称J2EE)的轻量级代替品。无需开发重量级的Enterprise JavaBean(EJB)，Spring为企业级Java开发提供了一种相对简单的方法，通过依赖注入和面向切面编程，用简单的Java对象(Plain Old Java Object，POJO)实现了EJB的功能。

虽然Spring的组件代码是轻量级的，但它的配置却是重量级的。

所有这些配置都代表了开发时的损耗。

除此之外，项目的依赖管理也是件吃力不讨好的事情。

并且，依赖管理也是一种损耗，添加依赖不是写应用程序代码。

Spring Boot 精要四个核心

自动配置：针对很多Spring应用程序常见的应用功能，Spring Boot能自动提供相关配置

起步依赖：告诉Spring Boot需要什么功能，它就能引入需要的库。

命令行界面：这是Spring Boot的可选特性，借此你只需写代码就能完成完整的应用程序，

无需传统项目构建。

Actuator：让你能够深入运行中的Spring Boot应用程序，一探究竟。

Spring Boot通过起步依赖为项目的依赖管理提供帮助。起步依赖其实就是特殊的Maven依赖和Gradle依赖，利用了传递依赖解析，把常用库聚合在一起，组成了几个为特定功能而定制的依赖。

Spring Boot CLI让只写代码即可实现应用程序成为可能。Spring Boot CLI是Spring Boot的非必要组成部分。

Actuator 则要提供在运行时检视应用程序内部情况的能力

Spring Boot 不是什么

首先，Spring Boot不是应用服务器。

Spring Boot也没有实现诸如JPA或JMS

Spring Boot没有引入任何形式的代码生成，而是利用了Spring 4的条件化配置特性，以及Maven和Gradle提供的传递依赖解析，以此实现Spring应用程序上下文里的自动配置。

简而言之，从本质上来说，Spring Boot就是Spring，它做了那些没有它你自己也会去做的Spring Bean配置。

安装 Spring Boot CLI

手工安装Spring Boot CLI
使用Software Development Kit Manager进行安装
使用Homebrew进行安装
使用MacPorts进行安装
开启命令行补全：一个是针对BASH的，另一个是针对zsh的

Spring Boot CLI为Spring Boot提供了快速上手和构建简单原型应用程序的途径。

使用 Spring Initializr 初始化 Spring Boot 项目

使用Spring Initializr的Web界面
在Spring Tool Suite里创建Spring Boot项目
在IntelliJ IDEA里创建Spring Boot项目
在Spring Boot CLI里使用Initializr

小结：

Spring Boot为Spring应用程序的开发提供了一种激动人心的新方式，框架本身带来的阻力很小。自动配置消除了传统Spring应用程序里的很多样板配置;Spring Boot起步依赖让你能通过库所提供的功能而非名称与版本号来指定构建依赖;Spring Boot CLI将Spring Boot的无阻碍开发模型提升到了一个崭新的高度，在命令行里就能简单快速地用Groovy进行开发;Actuator让你能深入运行中的应用程序，了解Spring Boot做了什么，是怎么做的。

第二章：开发第一个应用程序

1. 启动引导Spring：

配置和启动引导。虽然Spring Boot的自动配置免除了很多Spring配置，但你还需要进行少量配置来启用自动配置。

SpringBootApplication

@SpringBootApplication开启了Spring的组件扫描和Spring Boot的自动配置功能。实际上，@SpringBootApplication将三个有用的注解组合在了一起。

Spring的@Configuration:标明该类使用Spring基于Java的配置。

Spring的@ComponentScan:启用组件扫描.

Spring Boot的@EnableAutoConfiguration:这个不起眼的小注解也可以称为 @Abracadabra1，就是这一行配置开启了Spring Boot自动配置的魔力，让你不用再写成篇的配置了。

2. 测试Spring Boot应用程序

@RunWith(SpringJUnit4ClassRunner.class)

一个典型的Spring集成测试会用@ContextConfiguration注解标识如何加载Spring的应用

程序上下文。但是为了充分发挥Spring Boot的魔力，这里应该用@SpringApplication- Configuration注解。

3. 配置应用程序属性

Initializr为你生成的application.properties文件是一个空文件。但大部分的配置都存在于这里

2.1.2 Spring Boot 项目构建过程解析

Spring Boot为Gradle和Maven提供了构建插件，以便辅助构建Spring Boot项目。

构建插件的主要功能是把项目打包成一个可执行的超级JAR(uber-JAR)，包括把应用程序的所有依赖打入JAR文件内，并为JAR添加一个描述文件，其中的内容能让你用java -jar来运行应用程序。

2.2.1 指定基于功能的依赖

Spring Boot通过提供众多起步依赖降低项目依赖的复杂度。起步依赖本质上是一个Maven项目对象模型(Project Object Model，POM)，定义了对其他库的传递依赖，这些东西加在一起即支持某项功能。

2.2.2 覆盖起步依赖引入的传递依赖

你可以通过构建工具中的功能，选择性地覆盖它们引入的传递依赖的版本号，排除传递依赖，当然还可以为那些Spring Boot 起步依赖没有涵盖的库指定依赖。

2.3 使用自动配置

程序引入依赖后就能够自行启动了，但是某处肯定是有些配置的。配置是Spring Framework的核心元素，必须要有东西告诉Spring 如何运行应用程序。有个名为spring-boot-autoconfigure的JAR文件，其中包含了很多配置类。它们利用了Spring的条件化配置，条件化配置允许配置存在于应用程序中，但在满足某些特定条件之前都忽略这个配置。

在Spring里可以很方便地编写你自己的条件，你所要做的就是实现Condition接口，覆盖它的matches()方法。

@Conditional(JdbcTemplateCondition.class)

表2-1 自动配置中使用的条件化注解

@ConditionalOnBean配置了某个特定Bean

@ConditionalOnMissingBean:没有配置特定的Bean

@ConditionalOnClass:Classpath里有指定的类

@ConditionalOnMissingClass:Classpath里缺少指定的类

@ConditionalOnExpression:给定的Spring Expression Language(SpEL)表达式计算结果为true

@ConditionalOnJava:Java的版本匹配特定值或者一个范围值

@ConditionalOnJndi:参数中给定的JNDI位置必须存在一个，如果没有给参数，则要有JNDI InitialContext

@ConditionalOnProperty:指定的配置属性要有一个明确的值

@ConditionalOnResource:Classpath里有指定的资源

@ConditionalOnWebApplication:这是一个Web应用程序

@ConditionalOnNotWebApplication:这不是一个Web应用程序

Spring Boot自动配置承担起了配置Spring的重任，因此你能专注于编写自己的应用程序。

2.4 小结

通过Spring Boot的起步依赖和自动配置，你可以更加快速、便捷地开发Spring应用程序。起步依赖帮助你专注于应用程序需要的功能类型，而非提供该功能的具体库和版本。与此同时，自动配置把你从样板式的配置中解放了出来。这些配置在没有Spring Boot的Spring应用程序里非常常见。

第三章：自定义配置

本章我们将看到两种影响自动配置的方式——使用显式配置进行覆盖和使用属性进行精细化配置。我们还会看到如何使用Spring Boot提供的钩子引入自定义的错误页。

3.1 覆盖 Spring Boot 自动配置

覆盖自动配置很简单，就当自动配置不存在，直接显式地写一段配置。

3.2 通过属性文件外置配置

事实上，Spring Boot自动配置的Bean提供了300多个用于微调的属性。当你调整设置时，只要在环境变量、Java系统属性、JNDI(Java Naming and Directory Interface)、命令行参数或者属性文件里进行指定就好了。

Spring Boot应用程序有多种设置途径。

(1) 命令行参数

(2) java:comp/env里的JNDI属性

(3) JVM系统属性

(4) 操作系统环境变量

(5) 随机生成的带random.* 前缀的属性(在设置其他属性时，可以引用它们，比如${random. long})

(6) 应用程序以外的application.properties或者appliaction.yml文件

(7) 打包在应用程序内的application.properties或者appliaction.yml文件

(8) 通过@PropertySource标注的属性源

(9) 默认属性

这个列表按照优先级排序，也就是说，任何在高优先级属性源里设置的属性都会覆盖低优先

级的相同属性。例如，命令行参数会覆盖其他属性源里的属性。 application.properties和application.yml文件能放在以下四个位置。都按照优先级排序

(1) 外置，在相对于应用程序运行目录的/config子目录里。

(2) 外置，在应用程序运行的目录里。

(3) 内置，在config包内。

(4) 内置，在Classpath根目录。

3.2.1 自动配置微调

1. 禁用模板缓存

2. 配置嵌入式服务器

3. 配置日志

默认情况下，Spring Boot会用Logback(http://logback.qos.ch)来记录日志，并用INFO级别输出到控制台。在运行应用程序和其他例子时，你应该已经看到很多INFO级别的日志了。

一般来说，你不需要切换日志实现;Logback能很好地满足你的需要。

那么你只需要修改依赖，引入对应该日志实现的起步依赖，同时排除掉 Logback。

4. 配置数据源

如果Classpath里有Tomcat的连接池DataSource，那么就会使用这个连接池; 否则，Spring Boot会在Classpath里查找以下连接池:

 HikariCP

 Commons DBCP

 Commons DBCP 2

3.2.2 应用程序 Bean 的配置外置

@ConfigurationProperties注解，@ConfigurationProperties(prefix="amazon")，prefix属性说明应该注入带amazon前缀的属性

开启配置属性从技术上来说，@ConfigurationProperties注解不会生效，除非先向Spring配置类添加@EnableConfigurationProperties注解。但通常无需这么做，因为Spring Boot自动配置后面的全部配置类都已经加上了@EnableConfigura- tionProperties注解。因此，除非你完全不使用自动配置(那怎么可能?)，否则就无需显式地添加@EnableConfigurationProperties。

还有一点需要注意，Spring Boot的属性解析器非常智能，它会自动把驼峰规则的属性和使用

连字符或下划线的同名属性关联起来。换句话说，amazon.associateId这个属性和

amazon.associate_id以及amazon.associate-id都是等价的。用你习惯的命名规则就好。

不过最好在一个类里面收集属性

3.2.3 使用Profile进行配置

Spring Framework从 Spring 3.1开始支持基于Profile的配置。Profile是一种条件化配置，基于运行时激活的Profile，会使用或者忽略不同的Bean或配置类。

Spring Boot支持为application.properties和application.yml里的属性配置Profile。

1. 使用特定于Profile的属性文件

如果你正在使用application.properties，可以创建额外的属性文件，遵循application-{profile}. properties这种命名格式，这样就能提供特定于Profile的属性了。

与此同时，那些并不特定于哪个Profile或者保持默认值(以防万一有哪个特定于Profile的配置不指定这个值)的属性，可以继续放在application.properties里。

2. 使用多Profile YAML文件进行配置

但既然用了YAML，你就可以把所有Profile的配置属性都放在一个application.yml文件里。通过添加层级结构进行区分。

3.3 定制应用程序错误页面

实现了Spring的View接口的Bean，其 ID为error(由Spring的BeanNameViewResolver所解析)。

定义异常解析视图：error.html、error.ftl、error.vm、error.jsp、

异常描述状态：timestamp、status、error、exception、message、errors

小结：

Spring Boot消除了Spring应用程序中经常要用到的很多样板式配置。让Spring Boot处理全部配置，你可以仰仗它来配置那些适合你的应用程序的组件。当自动配置无法满足需求时，Spring Boot允许你覆盖并微调它提供的配置。

覆盖自动配置其实很简单，就是显式地编写那些没有Spring Boot时你要做的Spring配置。 Spring Boot的自动配置被设计为优先使用应用程序提供的配置，然后才轮到自己的自动配置。

即使自动配置合适，你仍然需要调整一些细节。Spring Boot会开启多个属性解析器，让你通过环境变量、属性文件、YAML文件等多种方式来设置属性，以此微调配置。这套基于属性的配置模型也能用于应用程序自己定义的组件，可以从外部配置源加载属性并注入到Bean里。

Spring Boot还自动配置了一个简单的白标错误页，虽然它比异常跟踪信息友好一点，但在艺术性方面还有很大的提升空间。幸运的是，Spring Boot提供了好几种选项来自定义或完全替换这个白标错误页，以满足应用程序的特定风格。

第四章：测试

Spring的SpringJUnit4ClassRunner可以在基于JUnit的应用程序测试里加载Spring应用程序上下文。在测试Spring Boot应用程序时，Spring Boot除了拥有Spring的集成测试支持，还开启了自动配置和Web服务器，并提供了不少实用的测试辅助工具。

4.1 集成测试自动配置

Spring Framework的核心工作是将所有组件编织在一起，构成一个应用程序。整个过程就是读取配置说明(可以是XML、基于Java的配置、基于Groovy的配置或其他类型的配置)程序上下文里初始化Bean，将Bean注入依赖它们的其他Bean中。

对Spring应用程序进行集成测试时，让Spring遵照生产环境来组装测试目标Bean是非常重要的一点。当然，你也可以手动初始化组件，并将它们注入其他组件，但对那些大型应用程序来说，这是项费时费力的工作。

@RunWith和@ContextConfiguration注解

@RunWith的参数是SpringJUnit4ClassRunner.class，开启了Spring集成测试支持。1与此同时，@ContextConfiguration指定了如何加载应用程序上下文。此处我们让它加载Address- BookConfiguration里配置的Spring应用程序上下文。

SpringApplication不仅加载应用程序上下文，还会开启日志、加载外部属性(application.properties或application.yml)，以及其他Spring Boot特性。用@Context- Configuration则得不到这些特性。

要在集成测试里获得这些特性，可以把@ContextConfiguration替换为Spring Boot的@SpringApplicationConfiguration。

@SpringApplicationConfiguration的用法和@ContextConfiguration大致相同，但也有不同的地方，@SpringApplicationConfiguration加载Spring应用程序上下文的方式同 SpringApplication相同，处理方式和生产应用程序中的情况相同。这包括加载外部属性和 Spring Boot日志。

4.2 测试Web应用程序

Spring MVC有一个优点:它的编程模型是围绕POJO展开的，在POJO上添加注解，声明如何处理Web请求。你还可以针对这些控制器编写测试，就像测试POJO一样。Spring Boot开发者有两个可选的方案能实现这类测试。

Spring Mock MVC :能在一个近似真实的模拟Servlet容器里测试控制器，而不用实际启动应用服务器。

Web集成测试 :在嵌入式Servlet容器(比如Tomcat或Jetty)里启动应用程序，在真正的应用服务器里执行测试。

模拟SpringMVC

要在测试里设置Mock MVC，可以使用MockMvcBuilders，该类提供了两个静态方法。

standaloneSetup():构建一个Mock MVC，提供一个或多个手工创建并配置的控制器。

webAppContextSetup():使用Spring应用程序上下文来构建Mock MVC，该上下文里

可以包含一个或多个配置好的控制器。

两者的主要区别在于，standaloneSetup()希望你手工初始化并注入你要测试的控制器，而webAppContextSetup()则基于一个WebApplicationContext的实例，通常由Spring加载。

前者同单元测试更加接近，你可能只想让它专注于单一控制器的测试，而后者让Spring加载控制

器及其依赖，以便进行完整的集成测试。

我们要用的是webAppContextSetup()。Spring完成了ReadingListController的初始化，并从Spring Boot自动配置的应用程序上下文里将其注入，我们直接对其进行测试。

webAppContextSetup()接受一个WebApplicationContext参数。因此，我们需要为测试类加上@WebAppConfiguration注解，使用@Autowired将WebApplicationContext作为实例变量注入测试类。

4.2.2 测试Web安全

首先要引入安全框架通过起步依赖和自动配置加入，Spring Security提供了两个注解。

@WithMockUser:加载安全上下文，其中包含一个UserDetails，使用了给定的用户名、密码和授权。

@WithUserDetails:根据给定的用户名查找UserDetails对象，加载安全上下文。

Spring Security的安全上下文都会加载一个UserDetails对象，添加了该注解的测试方法在运行过程中都会使用该对象。

@WithMockUser注解是两者里比较基础的那个，允许显式声明一个UserDetails，并加载到安全上下文，绕过了UserDetails对象的正常查询，用给定的值创建了一个UserDetails对象取而代之。在简单的测试里，这就够用了。

但我们的测试需要Reader(实现了UserDetails)而非@WithMockUser创建的通用UserDetails。为此，我们需要 @WithUserDetails。@WithUserDetails注解使用事先配置好的UserDetailsService来加载UserDetails对象。

4.3 测试运行中的应用程序

Spring Boot的@WebIntegrationTest注解就是这么做的，在测试类上添加@Web- IntegrationTest注解，可以声明你不仅希望Spring Boot为测试创建应用程序上下文，还要启动一个嵌入式的Servlet容器。一旦应用程序运行在嵌入式容器里，你就可以发起真实的HTTP请求，断言结果了。

4.3.1 用随机端口启动服务器

@WebIntegrationTest 的value属性接受一个String数组，数组中的每项都是键值对，形如name=value，用来设置测试中使用的属性

@WebIntegrationTest(value={"server.port=0"})

@WebIntegrationTest("server.port=0")

@WebIntegrationTest(randomPort=true)

4.3.2 使用Selenium测试HTML页面

添加项目依赖、@BeforeClass静态方法openBrowser()会通过Selenium创建一个FirefoxDriver的实例，它将打开Firefox浏览器(需要在运行测试的服务器上安装该浏览器)来验证具体浏览器中的效果。

4.4 小结

单元测试专注于单一组件或组件中的一个方法，此处并不一定要使用Spring。Spring提供了一些优势和技术——松耦合、依赖注入和接口驱动设计。这些都简化了单元测试的编写。但Spring 不用直接涉足单元测试。

Spring Framework以JUnit类运行器的方式提供了集成测试支持，JUnit类运行器会加载Spring 应用程序上下文，把上下文里的Bean注入测试。Spring Boot在Spring的集成测试之上又增加了配置加载器，以Spring Boot的方式加载应用程序上下文，包括了对外置属性的支持和Spring Boot日志。

Spring Boot还支持容器内测试Web应用程序，让你能用和生产环境一样的容器启动应用程序。这样一来，测试在验证应用程序行为的时候，会更加接近真实的运行环境。

第五章：Groovy与Spring Boot CLI

Groovy与Spring Boot CLI

5.1 开发 Spring Boot CLI 应用程序、5.1.1 设置 CLI 项目、5.1.2 通过 Groovy 消除代码噪声、5.1.3 发生了什么

5.2 获取依赖、5.2.1 覆盖默认依赖版本、5.2.2 添加依赖仓库

5.3 用 CLI 运行测试

5.4 创建可部署的产物

5.5 小结

Spring Boot CLI利用了Spring Boot自动配置和起步依赖的便利之处，并将其发扬光大。借由Groovy语言的优雅，CLI能让我们在最少的代码噪声下开发Spring应用程序。

本章中我们彻底重写了第2章里的阅读列表应用程序，只是这次我们用Groovy把它写成了 Spring Boot CLI应用程序。通过自动添加很多常用包和类的import语句，CLI让Groovy更优雅。

它还可以自动解析很多依赖库。

对于CLI无法自动解析的库，基于CLI的应用程序可以利用Grape的@Grab注解，不用构建说

明也能显式地声明依赖。Spring Boot的CLI扩展了@Grab注解，针对很多常用库依赖，只需声明 Module ID就可以了。

最后，你还了解了如何用Spring Boot CLI来执行测试和构建可部署产物，这些通常都是由构建系统来负责的。

Spring Boot和Groovy结合得很好，两者的简洁性相辅相成。

第六章：：在Spring Boot中使用Grails

在Spring Boot刚发布时，经常有人问我在Spring Boot和Grails之间该如何选择。两者都构建于 Spring Framework之上，都旨在简化应用程序的开发。实际上，它们就像花生酱和巧克力。两个都很好，具体如何选择取决于个人爱好。

Grails和Spring Boot之间的联系。我们会先看到Spring Boot中Grails对 6 象关系映射(Grails Object Relational Mapping，GORM)和Groovy服务器页面(Groovy Server Page， GSP)这样的Grails特性，还会看到Grails 3是如何基于Spring Boot重写的

6.1 使用 GORM 进行数据持久化

6.2 使用 Groovy Server Pages 定义视图

6.3 结合 Spring Boot 与 Grails 3

6.4 小结

Grails和Spring Boot都旨在让开发者的生活更简单，大大简化基于Spring的开发模型，因此两者看起来是互相竞争的框架。但在本章中，我们看到了两者如何结合在一起，综合优势。

我们了解了如何向典型的Spring Boot应用程序中添加GORM和GSP视图，这两个都是知名的 Grails特性。GORM是Spring Boot里一个很受欢迎的特性，能让你直接针对领域模型执行持久化操作，消除了对模型仓库的需求。

第七章：深入Actuator

Spring Boot的Actuator。它提供了很多生产级的特性，比如监控和度量Spring Boot应用程序。Actuator的这些特性可以通过众多REST端点、远程shell和JMX获得。我们先来看看Actuator的REST端点，这种最为人所熟知的使用方式提供了最完整的功能。

要启用Actuator的端点，只需在项目中引入Actuator的起步依赖即可。

GET /env 获取全部环境属性

GET /env/{name} GET /health 根据名称获取特定的环境属性值

GET /info 报告应用程序的健康指标，这些值由HealthIndicator的实现类提供

GET /mappings 描述全部的URI路径，以及它们和控制器(包含Actuator端点)的映射关系

GET /metrics 报告各种应用程序度量信息，比如内存用量和HTTP请求计数

GET /metrics/{name} 报告指定名称的应用程序度量值

POST /shutdown 关闭应用程序，要求endpoints.shutdown.enabled设置为true

GET /trace 提供基本的HTTP请求跟踪信息(时间戳、HTTP头等)

要启用Actuator的端点，只需在项目中引入Actuator的起步依赖即可。

compile 'org.springframework.boot:spring-boot-starter-actuator'

三大类:配置端点、度量端点和其他端点。

Actuator有一些端点不仅可以显示组件映射关系，还可以告诉你自动配置在配置 Spring应用程序上下文时做了哪些决策。

1. 获得Bean装配报告 ：/beans它会返回一个JSON文档，描述上下文里每个Bean的情况，包括其Java类型以及注入的其他Bean。

2. 详解自动配置 ：/beans端点产生的报告能告诉你Spring应用程序上下文里都有哪些Bean。/autoconfig端点能告诉你为什么会有这个Bean，或者为什么没有这个Bean。

3. 查看配置属性 ：/env端点会生成应用程序可用的所有环境属性的列表，无论这些属性是否用到。这其中包括环境变量、JVM属性、命令行参数，以及applicaition.properties或application.yml文件提供的属性。

4. 生成端点到控制器的映射 ：如果Web界面的控制器和请求处理方法数量多，那最好能有一个列表，罗列出应用程序发布的全部端点。/mappings端点就提供了这么一个列表

7.1.2 运行时度量

1. 查看应用程序的度量值 ：运行中的应用程序有诸多计数器和度量器，/metrics端点提供了这些东西的快照。

表7-2 /metrics端点报告的度量值和计数器提供表在P131页

2. 追踪Web请求 ：尽管/metrics端点提供了一些针对Web请求的基本计数器和计时器，但那些度量值缺少详细信息。知道所处理请求的更多信息是很有帮助的，尤其是在调试时，所以就有了/trace这个端点。

3. 导出线程活动 ：在确认应用程序运行情况时，除了跟踪请求，了解线程活动也会很有帮助。/dump端点会生成当前线程活动的快照。

4. 监控应用程序健康情况 ：如果你想知道自己的应用程序是否在运行，可以直接访问/health端点。

表7-3 Spring Boot自带的健康指示器提供表：P134页

7.1.3 关闭应用程序

关闭运行中的应用程序，其中某个实例有问题了，你决定关闭该实例并让云服务提供商为你重启这个有问题的应用程序。在这个场景中，Actuator的/shutdown端点就很有用了。

7.1.4 获取应用信息

/info端点能展示各种你希望发布的应用信息。

7.2 连接 Actuator 的远程 shell

Actuator通过REST端点提供了不少非常有用的信息。另一个深入运行中应用程序内部的方式是使用远程shell。Spring Boot集成了CRaSH，一种能嵌入任意Java应用程序的shell。Spring Boot 还扩展了CRaSH，添加了不少Spring Boot特有的命令，提供了与Actuator端点类似的功能。

与这个密码搭配使用的用户名是user。密码本身是随机生成的，每次运行应用程序时都会有所变化。它监听的端口号是2000。

远程shell提供了24个可以在运行应用程序上下文中执行的命令，其中大部分都是CRaSH自带的。但Spring Boot也添加了一些。表7-4列出了这些Spring Boot特有的命令。

7.2.1 查看 autoconfig 报告

autoconfig 命令生成了一个与 Actuatord 的 /autoconfig 端点类似的报告

7.2.2 列出应用程序的 Bean ：发现beans命令的输出和/beans端点的输出一样

7.2.3 查看应用程序的度量信息 ：metricsshell命令会输出与Actuator的/metrics端点一样的信息

7.2.4 调用 Actuator 端点 ：并非所有的Actuator端点都有对应的shell命令。

但endpoint命令可以让你在shell里调用Actuator的端点。在shell提示符中键入endpoint list就能获得端点的列表。你可以使用endpoint invoke命令，传入不带Endpoint 后缀的Bean名称。举例来说，要调用健康检查端点，可以在shell提示符里键入endpoint invoke health

7.3 通过 JMX 监控应用程序

Actuator的端点都发布在org.springframework.boot域下。比如，你想要查看应用程序的请求映射关系，那么可以看一下图7-6(通过JConsole查看请求映射端点)。

7.4 定制 Actuator

7.4.1 修改端点 ID

7.4.2 启用和禁用端点

7.4.3 添加自定义度量信息

实际上，自动配置允许Actuator创建CounterService的实例，并将其注册为Spring的应用程序上下文中的Bean。CounterService这个接口里定义了三个方法，分别用来增加、减少或重置特定名称的度量值。

Actuator的自动配置还会配置一个GaugeService类型的Bean。该接口与CounterService类似，能将某个值记录到特定名称的度量值里。

你无需实现这些接口。Spring Boot已经提供了两者的实现。我们所要做的就是把它们的实例注入所需的Bean，在适当的时候调用其中的方法，更新想要的度量值。使用了自动织入机制，通过控制器的构造方法注入 CounterService和GaugeService，随后把它们保存在实例变量里。

尽管CounterService和GaugeService用起来很简单，但还是有一些度量值很难通过增加计数器或记录指标值来捕获。对于那些情况，我们可以实现PublicMetrics接口，提供自己需要的度量信息。该接口定义了一个metrics()方法，返回一个Metric对象的集合，Actuator会调用metrics()方法，收集ApplicationContextMetrics提供的度量信息。该方法调用了所注入的ApplicationContext上的方法，获取我们想要报告为度量的数量。每个度量值都会创建一个Metrics实例，指定度量的名称和值，将其加入要返回的列表。

7.4.4 创建自定义跟踪仓库

默认情况下，/trace端点报告的跟踪信息都存储在内存仓库里，100个条目封顶。一旦仓库满了，就开始移除老的条目，给新的条目腾出空间。在开发阶段这没什么问题，但在生产环境中，大流量会造成跟踪信息还没来得及看就被丢弃。为了避免这个问题，你可以声明自己的InMemoryTraceRepository Bean，将它的容量调整至100以上。如下配置类可以将容量调整至1000个条目。另外可以引入只需实现Spring Boot的TraceRepository接口即可的实现，将数据存储到另外的数据库中。TraceRepository只要求我们实现两个方法:一个方法查找所有存储的Trace 对象，另一个保存了一个Trace，包含跟踪信息的Map对象。

7.4.5 插入自定义健康指示器

如前文所述，Actuator自带了很多健康指示器，能满足常见需求，比如报告应用程序使用的数据库和消息代理的健康情况。但如果你的应用程序需要和一些没有健康指示器的系统交互，自己实现Healthindicator即可。并且还能够记录原因

7.5 保护 Actuator 端点

实际上，Actuator的端点保护可以用和其他URL路径一样的方式——使用Spring Security。在 Spring Boot应用程序中，这意味着将Security起步依赖作为构建依赖加入，然后让安全相关的自动配置来保护应用程序，其中当然也包括了Actuator端点。

我们已经添加了一些自定义安全配置，仅限带有READER权限的授权用访问根URL路径(/)。要保护Actuator的端点，我们需要对SecurityConfig.java的configure()方法做些修改。

小结：

。Spring Boot的Actuator为你打开了一扇大门，深入Spring Boot应用程序的内部细节。它发布的组件、度量和指标能帮你理解应用程序的运作情况。

在本章，我们先了解了Actuator的Web端点——通过HTTP发布运行时细节信息的REST端点。这些端点的功能包括查看Spring应用程序上下文里所有的Bean、查看自动配置决策、查看Spring MVC映射、查看线程活动、查看应用程序健康信息，还有多种度量、指标和计数器。

除了Web端点，Actuator还提供了另外两种获取它所提供信息的途径。远程shell让你能在shell 里安全地连上应用程序，发起指令，获得与Actuator端点相同的数据。与此同时，所有的Actuator 端点也都发布成了MBean，可以通过JMX客户端进行监控和管理。

随后我们还了解了如何定制Actuator，包括如何通过端点的ID来修改Actuator端点的路径，如何启用和禁用端点，诸如此类。我们还插入了一些定制的度量信息，创建了定制的跟踪信息仓库，替换了默认的内存跟踪仓库。

最后，我们学习了如何保护Actuator的端点，只让经过授权的用户访问它们。

接下来，在第8章里，我们将看到如何让应用程序从编码阶段过渡到生产阶段，了解Spring Boot如何协助我们在多种不同的平台上进行部署，包括传统的应用容器和云平台。

第八章：部署Spring Boot应用程序

我们的焦点都集中在使用Spring Boot的特性帮助大家开发应用程序。我们遇到了不少惊喜。但如果不越过终点线，应用程序没有部署，这一切都是徒劳。

8.1 衡量多种部署方式

在IDE中运行应用程序(涉及Spring ToolSuite或IntelliJ IDEA)。

使用Maven的spring-boot:run或Gradle的bootRun，在命令行里运行。

使用Maven或Gradle生成可运行的JAR文件，随后在命令行中运行。

使用Spring Boot CLI在命令行中运行Groovy脚本。

使用Spring Boot CLI来生成可运行的JAR文件，随后在命令行中运行。

表8-1 Spring Boot部署选项

Groovy源码手写 Cloud Foundry及容器部署，比如Docker

可执行JAR Maven、Gradle或Spring Boot CLI 云环境，包括Cloud Foundry和Heroku，还有容器部署，比如Docker

WAR Maven或Gradle Java应用服务器或云环境，比如Cloud Foundry

8.2 部署到应用服务器

8.2.1 构建 WAR 文件

<packaging>war</packaging>

它提供的SpringBootServletInitializer是一个支持 Spring Boot的Spring WebApplicationInitializer实现。除了配置Spring的Dispatcher- Servlet，SpringBootServletInitializer还会在Spring应用程序上下文里查找Filter、 Servlet或ServletContextInitializer类型的Bean，把它们绑定到Servlet容器里。

要使用SpringBootServletInitializer，只需创建一个子类，覆盖configure()方法来指定Spring配置类。代码清单8-1是ReadingListServletInitializer，也就是我们为阅读列表应用程序写的SpringBootServletInitializer的子类。

configure()方法传入了一个SpringApplicationBuilder参数，并将其作为结果返回。期间它调用sources()方法注册了一个Spring配置类。@SpringBootApplication注解。这会隐性开启组件扫描，而组件扫描则会发现并应用其他配置类。

就算我们在构建的是WAR文件，这个文件仍旧可以脱离应用服务器直接运行。如果你没有删除Application里的main()方法，构建过程生成的WAR文件仍可直接运行，一如可执行的JAR文件:

这样一来，同一个部署产物就能有两种部署方式了!

8.2.2 创建生产 Profile

这个@Bean方法最关键的一点是，它还添加了@Profile注解，说明只有在production

但最方便的还是在运行应用服务器的机器上设置一个系统环境变量,我需要像这样设置SPRING_PROFILES_ACTIVE环境变量

8.2.3 开启数据库迁移

一个比较好的选择是使用数据库迁移库(database migration library)。它使用一系列数据库脚本，而且会记录哪些已经用过了，不会多次运用同一个脚本。应用程序的每个部署包里都包含了这些脚本，数据库可以和应用程序保持一致。

Spring Boot为两款流行的数据库迁移库提供了自动配置支持。

Flyway(http://flywaydb.org)

Liquibase(http://www.liquibase.org)

1. 用Flyway定义数据库迁移过程

Flyway是一个非常简单的开源数据库迁移库，使用SQL来定义迁移脚本。它的理念是，每个

脚本都有一个版本号，Flyway会顺序执行这些脚本，让数据库达到期望的状态。它也会记录已执行的脚本状态，不会重复执行。

Flyway脚本就是SQL。让其发挥作用的是其在Classpath里的位置和文件名。Flyway 脚本都遵循一个命名规范，含有版本号

Flyway脚本需要放在相对于应用程序Classpath根路径的/db/migration路径下

在应用程序部署并运行起来后，Spring Boot会检测到Classpath里的Flyway，自动配置所需的 Bean。Flyway会依次查看/db/migration里的脚本，如果没有执行过就运行这些脚本。每个脚本都执行过后，向schema_version表里写一条记录。应用程序下次启动时，Flyway会先看schema_version 里的记录，跳过那些脚本。、

2. 用Liquibase定义数据库迁移过程

Flyway用起来很简便，在Spring Boot自动配置的帮助下尤其如此。但是，使用SQL来定义迁移脚本是一把双刃剑。SQL用起来便捷顺手，却要冒着只能在一个数据库平台上使用的风险。

Liquibase并不局限于特定平台的SQL，可以用多种格式书写迁移脚本，不用关心底层平台(其中包括XML、YAML和JSON)。如果你有这个期望的话，Liquibase当然也支持SQL脚本。

应用程序启动时，Liquibase会读取db.changelog-master.yaml里的变更集指令集，与之前写入 databaseChangeLog表里的内容做对比，随后执行未运行过的变更集。

Spring Boot的自动配置让Liquibase和Flyway的使用变得轻而易举。

8.3 推上云端

服务器硬件的购买和维护成本很高。大流量很难通过适当扩展服务器去处理，这种做法在某些组织中甚至是禁忌。现如今，相比在自己的数据中心运行应用程序，把它们部署到云上是更引人注目，而且划算的做法。

目前有多个云平台可供选择，而那些提供Platform as a Service(PaaS)能力的平台无疑是最有吸引力的。PaaS提供了现成的应用程序部署平台，带有附加服务(比如数据库和消息代理)，可以绑定到应用程序上。除此之外，当你的应用程序要求提供更大的马力时，云平台能轻松实现应用程序在运行时向上(或向下)伸缩，只需添加或删除实例即可。

之前我们已经把阅读列表应用程序部署到了传统的应用服务器上，现在再试试将其部署到云上。我们将把应用程序部署到Cloud Foundry和Heroku这两个著名的PaaS平台上。

8.3.1 部署到 Cloud Foundry

8.3.2 部署到 Heroku

8.4 小结

Spring Boot应用程序的部署方式有好几种，包括使用传统的应用服务器和云上的PaaS平台。 6 在本章，我们了解了其中的一些部署方式，把阅读列表应用程序以WAR文件的方式部署到Tomcat 和云上(Cloud Foundry和Heroku)。

Spring Boot应用程序的构建说明经常会配置为生成可执行的JAR文件。我们也看到了如何对构建进行微调，如何编写一个SpringBootServletInitializer实现，生成WAR文件，以便部署到应用服务器上。 7

随后，我们进一步了解了如何将应用程序部署到Cloud Foundry上。Cloud Foundry非常灵活，能够接受各种形式的Spring Boot应用程序，包括可执行JAR文件、传统WAR文件，甚至还包括原始的Spring Boot CLI Groovy脚本。我们还了解了Cloud Foundry如何自动将内嵌式数据源替换为绑定到应用程序上的数据库服务。

了如何通过添加Spring Cloud Foundry库来实现一样的效果。这里使用绑定的数据库服务，而非内嵌式数据库。

在本章，我们还了解了如何在Spring Boot里使用Flyway和Liquibase这样的数据库迁移工具。在初次部署应用程序时，我们通过数据库迁移的方式完成了数据库的初始化，在后续的部署过程中，我们可以按需修改数据库。

附录 A Spring Boot开发者工具

Spring Boot 1.3引入了一组新的开发者工具，可以让你在开发时更方便地使用Spring Boot，包括如下功能。

自动重启:当Classpath里的文件发生变化时，自动重启运行中的应用程序。

LiveReload支持:对资源的修改自动触发浏览器刷新。

远程开发:远程部署时支持自动重启和LiveReload。

默认的开发时属性值:为一些属性提供有意义的默认开发时属性值。

Spring Boot的开发者工具采取了库的形式，可以作为依赖加入项目。

compile "org.springframework.boot:spring-boot-devtools"

A.1 自动重启

有些Classpath里的资源变更后不需要重启应用程序。像Thymeleaf这样的视图模板可以直接编辑，不用重启应用程序。在/static或/public里的静态资源也不用重启应用程序，所以Spring Boot 开发者工具会在重启时排除掉如下目录:/META-INF/resources、/resources、/static、/public和 /templates。

A.2 LiveReload

在Web应用程序开发过程中，最常见的步骤大致如下。

(1) 修改要呈现的内容(比如图片、样式表、模板)。

(2) 点击浏览器里的刷新按钮，查看修改的结果。

(3) 回到第1步。

虽然这并不难，但如果能不点刷新就直接看到修改结果，那岂不是更好?

Spring Boot的开发者工具集成了LiveReload(http://livereload.com)，可以消除刷新的步骤。

激活开发者工具后，Spring Boot会启动一个内嵌的LiveReload服务器，在资源文件变化时会触发浏览器刷新。你要做的就是在浏览器里安装LiveReload插件。

A.3 远程开发

在远程运行应用程序时(比如部署到服务器上或云上)，开发者工具的自动重启和LiveReload 特性都是可选的。此外，Spring Boot开发者工具还能远程调试Spring Boot应用程序。

A.4 默认的开发时属性

实际上，这就是说在开发者工具激活后，如下属性会设置为false。

这样一来，就不用在开发时(在一个开发时使用的Profile配置里)禁用它们了。

A.5 全局配置开发者工具

附录 B Spring Boot起步依赖 ：1.3.0版本含有的起步依赖清单

附录 C 配置属性 ：配置文件所对应的配置版本和说明

附录 D Spring Boot依赖的版本号

获取上述的内容应该可以在官方文档，以及官方配置的start中找到对应的配置内容