【读书笔记】SpringBoot读书笔记

时间 2019-11-11

原文原文链接

总体目录结构：
1、入门
2、开发第一个应用程序
3、自定义配置
4、测试
5、Groovy与Spring Boot Cli
6、在Spring Boot中使用Grails
7、深刻Actuator
8、部署Spring Boot应用程序
附录A、Spring Boot开发者工具
附录B：Spring Boot起步依赖
附录C：配置属性
附录D：Spring Boot依赖css

总体来讲这本书说明了什么？
经过最简单的案例和文字系统性的介绍了SpringBoot的几个核心原理和知识点：起步依赖、自动配置、自定义配置、Springboot Cli、测试、部署、工具支持、监控。而且经过Croovy和Grails等其余语言进行了最简单的案例演示。
做者细说了什么？怎么说的？
本书是一本工具书，开篇通常是对于原理的讲解，又讲解了优势，后续是具体案例的实施。
这本书说的有道理吗？是所有有道理仍是部分有道理？
无所谓道理，并无太多做者的观点，有观点基本上没有对错。
本书跟我有什么关系？
我但愿可以经过本书了解Springboot的核心内容和基本概念，了解因果原理，记录下实践所须要注意的点，在工做中提供一个解决问题的思路。html

第一章：入门
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的组件代码是轻量级的，但它的配置倒是重量级的。
全部这些配置都表明了开发时的损耗。
除此以外，项目的依赖管理也是件吃力不讨好的事情。
而且，依赖管理也是一种损耗，添加依赖不是写应用程序代码。java

Spring Boot 精要四个核心
自动配置：针对不少Spring应用程序常见的应用功能，Spring Boot能自动提供相关配置
起步依赖：告诉Spring Boot须要什么功能，它就能引入须要的库。
命令行界面：这是Spring Boot的可选特性，借此你只需写代码就能完成完整的应用程序，
无需传统项目构建。
Actuator：让你可以深刻运行中的Spring Boot应用程序，一探究竟。web

Spring Boot经过起步依赖为项目的依赖管理提供帮助。起步依赖其实就是特殊的Maven依赖和Gradle依赖，利用了传递依赖解析，把经常使用库聚合在一块儿，组成了几个为特定功能而定制的依赖。
Spring Boot CLI让只写代码便可实现应用程序成为可能。Spring Boot CLI是Spring Boot的非必要组成部分。
Actuator 则要提供在运行时检视应用程序内部状况的能力spring

Spring Boot 不是什么
首先，Spring Boot不是应用服务器。
Spring Boot也没有实现诸如JPA或JMS
Spring Boot没有引入任何形式的代码生成，而是利用了Spring 4的条件化配置特性，以及Maven和Gradle提供的传递依赖解析，以此实现Spring应用程序上下文里的自动配置。
简而言之，从本质上来讲，Spring Boot就是Spring，它作了那些没有它你本身也会去作的Spring Bean配置。shell

安装 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中找到对应的配置内容