總體目錄結構:
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 Initializr 初始化 Spring Boot 項目編程
小結:
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中找到對應的配置內容