在快速入門一節中,咱們輕鬆的實現了一個簡單的RESTful API應用,體驗了一下Spring Boot給咱們帶來的諸多優勢,咱們用很是少的代碼量就成功的實現了一個Web應用,這是傳統的Spring應用沒法辦到的,雖然咱們在實現Controller時用到的代碼是同樣的,可是在配置方面,相信你們也注意到了,在上面的例子中,除了Maven的配置以後,就沒有引入任何的配置。java
這就是以前咱們所提到的,Spring Boot針對咱們經常使用的開發場景提供了一系列自動化配置來減小本來複雜而又幾乎不多改動的模板化配置內容。可是,咱們仍是須要去了解如何在Spring Boot中修改這些自動化的配置內容,以應對一些特殊的場景需求,好比:咱們在同一臺主機上須要啓動多個基於Spring Boot的web應用,若咱們不爲每一個應用指定特別的端口號,那麼默認的8080端口必將致使衝突。mysql
若是您還有在讀個人Spring Cloud系列教程,其實有大量的工做都會是針對配置文件的。因此咱們有必要深刻的瞭解一些關於Spring Boot中的配置文件的知識,好比:它的配置方式、如何實現多環境配置,配置信息的加載順序等。git
在快速入門示例中,咱們介紹Spring Boot的工程結構時,有提到過 src/main/resources
目錄是Spring Boot的配置目錄,因此咱們要爲應用建立配置個性化配置時,就是在該目錄之下。github
Spring Boot的默認配置文件位置爲: src/main/resources/application.properties
。關於Spring Boot應用的配置內容均可以集中在該文件中了,根據咱們引入的不一樣Starter模塊,能夠在這裏定義諸如:容器端口名、數據庫連接信息、日誌級別等各類配置信息。好比,咱們須要自定義web模塊的服務端口號,能夠在application.properties
中添加server.port=8888
來指定服務端口爲8888,也能夠經過spring.application.name=hello
來指定應用名(該名字在Spring Cloud應用中會被註冊爲服務名)。web
Spring Boot的配置文件除了可使用傳統的properties文件以外,還支持如今被普遍推薦使用的YAML文件。spring
YAML(英語發音:/ˈjæməl/,尾音相似camel駱駝)是一個可讀性高,用來表達資料序列的格式。YAML參考了其餘多種語言,包括:C語言、Python、Perl,並從XML、電子郵件的數據格式(RFC 2822)中得到靈感。Clark Evans在2001年首次發表了這種語言,另外Ingy döt Net與Oren Ben-Kiki也是這語言的共同設計者。目前已經有數種編程語言或腳本語言支援(或者說解析)這種語言。YAML是"YAML Ain't a Markup Language"(YAML不是一種標記語言)的遞迴縮寫。在開發的這種語言時,YAML 的意思實際上是:"Yet Another Markup Language"(還是一種標記語言),但爲了強調這種語言以數據作爲中心,而不是以標記語言爲重點,而用反向縮略語從新命名。AML的語法和其餘高階語言相似,而且能夠簡單表達清單、散列表,標量等資料形態。它使用空白符號縮排和大量依賴外觀的特點,特別適合用來表達或編輯數據結構、各類設定檔、傾印除錯內容、文件大綱(例如:許多電子郵件標題格式和YAML很是接近)。儘管它比較適合用來表達階層式(hierarchical model)的數據結構,不過也有精緻的語法能夠表示關聯性(relational model)的資料。因爲YAML使用空白字元和分行來分隔資料,使得它特別適合用grep/Python/Perl/Ruby操做。其讓人最容易上手的特點是巧妙避開各類封閉符號,如:引號、各類括號等,這些符號在巢狀結構時會變得複雜而難以辨認。 —— 維基百科sql
YAML採用的配置格式不像properties的配置那樣以單純的鍵值對形式來表示,而是以相似大綱的縮進形式來表示。好比:下面的一段YAML配置信息數據庫
environments: dev: url: http://dev.bar.com name: Developer Setup prod: url: http://foo.bar.com name: My Cool App 複製代碼
與其等價的properties配置以下。編程
environments.dev.url=http://dev.bar.com
environments.dev.name=Developer Setup
environments.prod.url=http://foo.bar.com
environments.prod.name=My Cool App
複製代碼
經過YAML的配置方式,咱們能夠看到配置信息利用階梯化縮進的方式,其結構顯得更爲清晰易讀,同時配置內容的字符量也獲得顯著的減小。除此以外,YAML還能夠在一個單個文件中經過使用spring.profiles
屬性來定義多個不一樣的環境配置。例以下面的內容,在指定爲test環境時,server.port
將使用8882端口;而在prod環境,server.port
將使用8883端口;若是沒有指定環境,server.port
將使用8881端口。數組
server: port: 8881 --- spring: profiles: test server: port: 8882 --- spring: profiles: prod server: port: 8883 複製代碼
注意:YAML目前還有一些不足,它沒法經過@PropertySource
註解來加載配置。可是,YAML加載屬性到內存中保存的時候是有序的,因此當配置文件中的信息須要具有順序含義時,YAML的配置方式比起properties配置文件更有優點。
咱們除了能夠在Spring Boot的配置文件中設置各個Starter模塊中預約義的配置屬性,也能夠在配置文件中定義一些咱們須要的自定義屬性。好比在application.properties
中添加:
book.name=SpringCloudInAction
book.author=ZhaiYongchao
複製代碼
而後,在應用中咱們能夠經過@Value
註解來加載這些自定義的參數,好比:
@Component public class Book { @Value("${book.name}") private String name; @Value("${book.author}") private String author; // 省略getter和setter } 複製代碼
@Value
註解加載屬性值的時候能夠支持兩種表達式來進行配置:
${...}
,大括號內爲PlaceHolder#{...}
,大括號內爲SpEL表達式在application.properties
中的各個參數之間,咱們也能夠直接經過使用PlaceHolder的方式來進行引用,就像下面的設置:
book.name=SpringCloud book.author=ZhaiYongchao book.desc=${book.author} is writing《${book.name}》 複製代碼
book.desc
參數引用了上文中定義的book.name
和book.author
屬性,最後該屬性的值就是ZhaiYongchao is writing《SpringCloud》
。
在一些特殊狀況下,有些參數咱們但願它每次加載的時候不是一個固定的值,好比:密鑰、服務端口等。在Spring Boot的屬性配置文件中,咱們能夠經過使用${random}
配置來產生隨機的int值、long值或者string字符串,這樣咱們就能夠容易的經過配置來屬性的隨機生成,而不是在程序中經過編碼來實現這些邏輯。
${random}
的配置方式主要有一下幾種,讀者可做爲參考使用。
# 隨機字符串 com.didispace.blog.value=${random.value} # 隨機int com.didispace.blog.number=${random.int} # 隨機long com.didispace.blog.bignumber=${random.long} # 10之內的隨機數 com.didispace.blog.test1=${random.int(10)} # 10-20的隨機數 com.didispace.blog.test2=${random.int[10,20]} 複製代碼
該配置方式能夠用於設置應用端口等場景,避免在本地調試時出現端口衝突的麻煩
回顧一下在本章的快速入門中,咱們還介紹瞭如何啓動Spring Boot應用,其中提到了使用命令java -jar
命令來啓動的方式。該命令除了啓動應用以外,還能夠在命令行中來指定應用的參數,好比:java -jar xxx.jar --server.port=8888
,直接以命令行的方式,來設置server.port屬性,另啓動應用的端口設爲8888。
在命令行方式啓動Spring Boot應用時,連續的兩個減號--
就是對application.properties
中的屬性值進行賦值的標識。因此,java -jar xxx.jar --server.port=8888
命令,等價於咱們在application.properties
中添加屬性server.port=8888
。
經過命令行來修改屬性值是Spring Boot很是重要的一個特性,經過此特性,理論上已經使得咱們應用的屬性在啓動前是可變的,因此其中端口號也好、數據庫鏈接也好,都是能夠在應用啓動時發生改變,而不一樣於以往的Spring應用經過Maven的Profile在編譯器進行不一樣環境的構建。其最大的區別就是,Spring Boot的這種方式,可讓應用程序的打包內容,貫穿開發、測試以及線上部署,而Maven不一樣Profile的方案每一個環境所構建的包,其內容本質上是不一樣的。可是,若是每一個參數都須要經過命令行來指定,這顯然也不是一個好的方案,因此下面咱們看看若是在Spring Boot中實現多環境的配置。
咱們在開發任何應用的時候,一般同一套程序會被應用和安裝到幾個不一樣的環境,好比:開發、測試、生產等。其中每一個環境的數據庫地址、服務器端口等等配置都會不一樣,若是在爲不一樣環境打包時都要頻繁修改配置文件的話,那必將是個很是繁瑣且容易發生錯誤的事。
對於多環境的配置,各類項目構建工具或是框架的基本思路是一致的,經過配置多份不一樣環境的配置文件,再經過打包命令指定須要打包的內容以後進行區分打包,Spring Boot也不例外,或者說更加簡單。
在Spring Boot中多環境配置文件名須要知足application-{profile}.properties
的格式,其中{profile}
對應你的環境標識,好比:
application-dev.properties
:開發環境application-test.properties
:測試環境application-prod.properties
:生產環境至於哪一個具體的配置文件會被加載,須要在application.properties
文件中經過spring.profiles.active
屬性來設置,其值對應配置文件中的{profile}
值。如:spring.profiles.active=test
就會加載application-test.properties
配置文件內容。
下面,以不一樣環境配置不一樣的服務端口爲例,進行樣例實驗。
針對各環境新建不一樣的配置文件application-dev.properties
、application-test.properties
、application-prod.properties
在這三個文件均都設置不一樣的server.port
屬性,如:dev環境設置爲1111,test環境設置爲2222,prod環境設置爲3333
application.properties中設置spring.profiles.active=dev
,就是說默認以dev環境設置
測試不一樣配置的加載
執行java -jar xxx.jar
,能夠觀察到服務端口被設置爲1111
,也就是默認的開發環境(dev)
執行java -jar xxx.jar --spring.profiles.active=test
,能夠觀察到服務端口被設置爲2222
,也就是測試環境的配置(test)
執行java -jar xxx.jar --spring.profiles.active=prod
,能夠觀察到服務端口被設置爲3333
,也就是生產環境的配置(prod)
按照上面的實驗,能夠以下總結多環境的配置思路:
application.properties
中配置通用內容,並設置spring.profiles.active=dev
,以開發環境爲默認配置application-{profile}.properties
中配置各個環境不一樣的內容在上面的例子中,咱們將Spring Boot應用須要的配置內容都放在了項目工程中,雖然咱們已經可以經過spring.profiles.active
或是經過Maven來實現多環境的支持。可是,當咱們的團隊逐漸壯大,分工愈來愈細緻以後,每每咱們不須要讓開發人員知道測試或是生成環境的細節,而是但願由每一個環境各自的負責人(QA或是運維)來集中維護這些信息。那麼若是仍是以這樣的方式存儲配置內容,對於不一樣環境配置的修改就不得不去獲取工程內容來修改這些配置內容,當應用很是多的時候就變得很是不方便。同時,配置內容都對開發人員可見,自己這也是一種安全隱患。對此,如今出現了不少將配置內容外部化的框架和工具,後續將要介紹的Spring Cloud Config就是其中之一,爲了後續能更好的理解Spring Cloud Config的加載機制,咱們須要對Spring Boot對數據文件的加載機制有必定的瞭解。
Spring Boot爲了可以更合理的重寫各屬性的值,使用了下面這種較爲特別的屬性加載順序:
SPRING_APPLICATION_JSON
中的屬性。SPRING_APPLICATION_JSON
是以JSON格式配置在系統環境變量中的內容。java:comp/env
中的JNDI
屬性。System.getProperties()
得到的內容。random.*
配置的隨機屬性{profile}
環境的配置文件內容,例如:application-{profile}.properties
或是YAML
定義的配置文件{profile}
環境的配置文件內容,例如:application-{profile}.properties
或是YAML
定義的配置文件application.properties
和YAML
配置內容application.properties
和YAML
配置內容@Configuration
註解修改的類中,經過@PropertySource
註解定義的屬性SpringApplication.setDefaultProperties
定義的內容優先級按上面的順序有高到低,數字越小優先級越高。
能夠看到,其中第7項和第9項都是從應用jar包以外讀取配置文件,因此,實現外部化配置的原理就是今後切入,爲其指定外部配置文件的加載位置來取代jar包以內的配置內容。經過這樣的實現,咱們的工程在配置中就變的很是乾淨,咱們只須要在本地放置開發須要的配置便可,而其餘環境的配置就能夠不用關心,由其對應環境的負責人去維護便可。
在Spring Boot 2.0中推出了Relaxed Binding 2.0,對原有的屬性綁定功能作了很是多的改進以幫助咱們更容易的在Spring應用中加載和讀取配置信息。下面本文就來講說Spring Boot 2.0中對配置的改進。
在Spring Boot 2.0中對配置屬性加載的時候會除了像1.x版本時候那樣移除特殊字符外,還會將配置均以全小寫的方式進行匹配和加載。因此,下面的4種配置方式都是等價的:
spring.jpa.databaseplatform=mysql
spring.jpa.database-platform=mysql
spring.jpa.databasePlatform=mysql
spring.JPA.database_platform=mysql
複製代碼
spring: jpa: databaseplatform: mysql database-platform: mysql databasePlatform: mysql database_platform: mysql 複製代碼
Tips:推薦使用全小寫配合-
分隔符的方式來配置,好比:spring.jpa.database-platform=mysql
在properties文件中使用[]
來定位列表類型,好比:
spring.my-example.url[0]=http://example.com
spring.my-example.url[1]=http://spring.io
複製代碼
也支持使用逗號分割的配置方式,上面與下面的配置是等價的:
spring.my-example.url=http://example.com,http://spring.io
複製代碼
而在yaml文件中使用可使用以下配置:
spring: my-example: url: - http://example.com - http://spring.io 複製代碼
也支持逗號分割的方式:
spring:
my-example:
url: http://example.com, http://spring.io
複製代碼
注意:在Spring Boot 2.0中對於List類型的配置必須是連續的,否則會拋出UnboundConfigurationPropertiesException
異常,因此以下配置是不容許的:
foo[0]=a
foo[2]=b
複製代碼
在Spring Boot 1.x中上述配置是能夠的,foo[1]
因爲沒有配置,它的值會是null
Map類型在properties和yaml中的標準配置方式以下:
spring.my-example.foo=bar
spring.my-example.hello=world
複製代碼
spring: my-example: foo: bar hello: world 複製代碼
注意:若是Map類型的key包含非字母數字和-
的字符,須要用[]
括起來,好比:
spring: my-example: '[foo.baz]': bar 複製代碼
簡單類型
在環境變量中經過小寫轉換與.
替換_
來映射配置文件中的內容,好比:環境變量SPRING_JPA_DATABASEPLATFORM=mysql
的配置會產生與在配置文件中設置spring.jpa.databaseplatform=mysql
同樣的效果。
List類型
因爲環境變量中沒法使用[
和]
符號,因此使用_
來替代。任何由下劃線包圍的數字都會被認爲是[]
的數組形式。好比:
MY_FOO_1_ = my.foo[1]
MY_FOO_1_BAR = my.foo[1].bar
MY_FOO_1_2_ = my.foo[1][2]
複製代碼
另外,最後環境變量最後是以數字和下劃線結尾的話,最後的下劃線能夠省略,好比上面例子中的第一條和第三條等價於下面的配置:
MY_FOO_1 = my.foo[1]
MY_FOO_1_2 = my.foo[1][2]
複製代碼
簡單類型
系統屬性與文件配置中的相似,都以移除特殊字符並轉化小寫後實現綁定,好比下面的命令行參數都會實現配置spring.jpa.databaseplatform=mysql
的效果:
-Dspring.jpa.database-platform=mysql
-Dspring.jpa.databasePlatform=mysql
-Dspring.JPA.database_platform=mysql
複製代碼
List類型
系統屬性的綁定也與文件屬性的綁定相似,經過[]
來標示,好比:
-D"spring.my-example.url[0]=http://example.com" -D"spring.my-example.url[1]=http://spring.io" 複製代碼
一樣的,他也支持逗號分割的方式,好比:
-Dspring.my-example.url=http://example.com,http://spring.io
複製代碼
上文介紹了Spring Boot 2.0中對屬性綁定的內容,能夠看到對於一個屬性咱們能夠有多種不一樣的表達,可是若是咱們要在Spring應用程序的environment中讀取屬性的時候,每一個屬性的惟一名稱符合以下規則:
.
分離各個元素.
將前綴與屬性名稱分開-
來分隔單詞[
和]
,用於List的索引因此,若是咱們要讀取配置文件中spring.jpa.database-platform
的配置,能夠這樣寫:
this.environment.containsProperty("spring.jpa.database-platform") 複製代碼
而下面的方式是沒法獲取到spring.jpa.database-platform
配置內容的:
this.environment.containsProperty("spring.jpa.databasePlatform") 複製代碼
注意:使用@Value
獲取配置內容的時候也須要這樣的特色
在Spring Boot 2.0中增長了新的綁定API來幫助咱們更容易的獲取配置信息。下面舉個例子來幫助你們更容易的理解:
例子一:簡單類型
假設在propertes配置中有這樣一個配置:com.didispace.foo=bar
咱們爲它建立對應的配置類:
@Data @ConfigurationProperties(prefix = "com.didispace") public class FooProperties { private String foo; } 複製代碼
接下來,經過最新的Binder
就能夠這樣來拿配置信息了:
@SpringBootApplication public class Application { public static void main(String[] args) { ApplicationContext context = SpringApplication.run(Application.class, args); Binder binder = Binder.get(context.getEnvironment()); // 綁定簡單配置 FooProperties foo = binder.bind("com.didispace", Bindable.of(FooProperties.class)).get(); System.out.println(foo.getFoo()); } } 複製代碼
例子二:List類型
若是配置內容是List類型呢?好比:
com.didispace.post[0]=Why Spring Boot
com.didispace.post[1]=Why Spring Cloud
com.didispace.posts[0].title=Why Spring Boot
com.didispace.posts[0].content=It is perfect!
com.didispace.posts[1].title=Why Spring Cloud
com.didispace.posts[1].content=It is perfect too!
複製代碼
要獲取這些配置依然很簡單,能夠這樣實現:
ApplicationContext context = SpringApplication.run(Application.class, args); Binder binder = Binder.get(context.getEnvironment()); // 綁定List配置 List<String> post = binder.bind("com.didispace.post", Bindable.listOf(String.class)).get(); System.out.println(post); List<PostInfo> posts = binder.bind("com.didispace.posts", Bindable.listOf(PostInfo.class)).get(); System.out.println(posts); 複製代碼
本教程配套倉庫:
若是您以爲本文不錯,歡迎Star、Follow支持!您的關注是我堅持的動力!