Spring Boot 對比 Spring MVC 最大的優點就是使用簡單,約定大於配置。不會像之前用 Spring MVC 的時候,時不時被 xml 配置檔案搞的暈頭轉向,冷不防還因為 xml 配置上的一點疏忽,導致整個專案莫名其妙的不可用,頓感生活無所依戀,簡稱生無可戀。
這要歸功於組成了 Spring Boot 的各種各樣的 starters,有官方提供的,也有第三方開源出來。可以這麼說,基本上你打算用的功能都可以找到,如果沒有找到,那就再找一找。
用 Spring Boot 的功能元件(例如 spring-boot-starter-actuator、 spring-boot-starter-data-redis 等)的步驟非常簡單,用著名的把大象放冰箱的方法來概括的話,有以下三步就可以完成元件功能的使用:
STEP 1
在 pom 檔案中引入對應的包,例如:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
STEP 2
在應用配置檔案中加入相應的配置,配置都是元件約定好的,需要檢視官方文件或者相關說明。有些比較複雜的元件,對應的引數和規則也相應的較多,有點可能多大幾十上百了。
STEP 3
以上兩步都正常的情況下,我們就可以使用元件提供的相關介面來開發業務功能了。
沒錯吧,這個過程我們在日常的開發中不知道已經實踐了多少遍。那麼 Spring Boot 為什麼能做到如此簡單易用呢,它內部是什麼樣的工作機制呢,不知道你有沒有研究過。
以下是為了理解 Spring Boot 元件的實現機制而製作的一個 demo starter。理解其中的原理,對我們日後的工作有什麼意義呢?
1. 遇到問題的時候,可以幫助我們更有頭緒的排查問題;
2. 可以幫助我們正確的閱讀原始碼,元件的切入口在哪兒,配置屬性是什麼等等;
以上
以下,開始實現這個簡單的 starter,這個 starter 並沒有什麼實際的功能,只是為了做個演示而已。
開始之前,我們要理解一下 spring boot starter 是什麼呢?
實際上 starter 並不會包含多少功能程式碼,我們可以把它理解成一個「連線包」(我自己造的概念),按照這個概念來說:
它首先是一個包,一個集合,它把需要用的其他功能元件囊括進來,放到自己的 pom 檔案中。
然後它是一個連線,把它引入的元件和我們的專案做一個連線,並且在中間幫我們省去複雜的配置,力圖做到使用最簡單。
實現一個 starter 有四個要素:
- starter 命名 ;
- 自動配置類,用來初始化相關的 bean ;
- 指明自動配置類的配置檔案 spring.factories ;
- 自定義屬性實體類,宣告 starter 的應用配置屬性 ;
好了,開始實現我們的 demo
1. 給 starter 起個名字
也就是我們使用它的時候在 pom 中引用的 artifactId。命名有有規則的,官方規定:
官方的 starter 的命名格式為 spring-boot-starter-{name} ,例如上面提到的 spring-boot-starter-actuator。
非官方的 starter 的命名格式為 {name}-spring-boot-starter,我們把自定的 starter 命名為 kite-spring-boot-starter,命名在 pom 檔案裡。
<groupId>kite.springcloud</groupId>
<artifactId>kite-spring-boot-starter</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
2. 引入自動配置包及其它相關依賴包
實現 starter 主要依賴自動配置註解,所以要在 pom 中引入自動配置相關的兩個 jar 包
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-autoconfigure</artifactId>
</dependency>
除此之外,依賴的其他包當然也要引進來。
3. 建立 spring.factories 檔案
在 resource/META-INF 目錄下建立名稱為 spring.factories 的檔案,為什麼在這裡?當 Spring Boot 啟動的時候,會在 classpath 下尋找所有名稱為 spring.factories 的檔案,然後執行裡面的配置指定的自動載入類,將指定類(一個或多個)中的相關 bean 初始化。
例如本例中的配置資訊是這樣的:
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
kite.springcloud.boot.starter.example.KiteAutoConfigure
等號前面是固定的寫法,後面就是我們自定義的自動配置類了,如果有多個的話,用英文逗號分隔開。
4. 編寫自動配置類
自動配置類是用來初始化 starter 中的相關 bean 的。可以說是實現 starter 最核心的功能。
@Configuration
@ConditionalOnClass(KiteService.class)
@EnableConfigurationProperties(KiteProperties.class)
@Slf4j
public class KiteAutoConfigure {
@Autowired
private KiteProperties kiteProperties;
@Bean
@ConditionalOnMissingBean(KiteService.class)
@ConditionalOnProperty(prefix = "kite.example",value = "enabled", havingValue = "true")
KiteService kiteService(){
return new KiteService(kiteProperties);
}
}
程式碼非常簡單,放眼望去,最多的就是各種註解。
@Configuration 這個不用解釋,表示這是個自動配置類,我們平時做專案時也會用到,一般是用作讀取配置檔案的時候。
@ConditionalOnClass(KiteService.class) :
只有在 classpath 中找到 KiteService 類的情況下,才會解析此自動配置類,否則不解析。
@EnableConfigurationProperties(KiteProperties.class):
啟用配置類。
@Bean:例項化一個 bean 。
@ConditionalOnMissingBean(KiteService.class):
與 @Bean 配合使用,只有在當前上下文中不存在某個 bean 的情況下才會執行所註解的程式碼塊,也就是當前上下文還沒有 KiteService 的 bean 例項的情況下,才會執行 kiteService() 方法,從而例項化一個 bean 例項出來。
@ConditionalOnProperty:
當應用配置檔案中有相關的配置才會執行其所註解的程式碼塊。
這個類的整體含義就是: 當 classpath 中存在 KiteService 類時解析此配置類,什麼情況下才會在 classpath 中存在呢,就是專案引用了相關的 jar 包。並且在上下文中沒有 KiteService 的 bean 例項的情況下,new 一個例項出來,並且將應用配置中的相關配置值傳入。
5. 實現屬性配置類
@Data
@ConfigurationProperties("kite.example")
public class KiteProperties {
private String host;
private int port;
}
配置類很簡單,只有兩個屬性,一個 host ,一個 port 。配置引數以 kite.example 作為字首。稍後我們在使用這個 starter 的時候會看到如何宣告配置屬性。
6. 實現相關功能類
也就是前面一直提到的 KiteService,其實嚴格來講,這個業務功能類不應該放在 starter 中,應該放在單獨的 jar 包裡,但是此處 demo 非常簡單,也就在這裡寫了。
@Slf4j
public class KiteService {
private String host;
private int port;
public KiteService(KiteProperties kiteProperties){
this.host = kiteProperties.getHost();
this.port = kiteProperties.getPort();
}
public void print(){
log.info(this.host + ":" +this.port);
}
}
一個建構函式和一個 print 方法。
7. 打包
通過 maven 命令將這個 starter 安裝到本地 maven 倉庫
mvn install
也可以通過 mvn package deploy
釋出到你的私服
或者釋出到中央倉庫。
上面已經完成了 starter 的開發,並安裝到了本地倉庫,然後就是在我們的專案中使用它了。
1. 建立專案,在 pom 中引用
<dependency>
<groupId>kite.springcloud</groupId>
<artifactId>kite-spring-boot-starter</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
2. 應用配置項
建立 application.yml ,配置如下:
server:
port: 3801
kite:
example:
enabled: true # 開啟才生效
host: 127.0.0.1
port: 3801
3. 呼叫 KiteService 的服務方法
@RestController
@RequestMapping(value = "use")
public class UseController {
@Autowired
private KiteService kiteService;
@GetMapping(value = "print")
public void print(){
kiteService.print();
}
}
4. 啟動服務,並訪問介面
訪問 /use/print 介面,會發現在日誌中列印出了配置資訊
2019-05-24 16:45:04.234 INFO 36687 --- [nio-3801-exec-1] k.s.boot.starter.example.KiteService : 127.0.0.1:3801
順著上面的思路,我們來看一下官方的 starters 的結構。先來把 Spring Boot 從 github 上 clone 一份下來。用 idea 開啟,可以看到專案結構如下
Spring-boot-starters 中就是官方提供的主要 starters,比如 jdbc、redis、security、web 等等。
我們拿 spring-boot-starter-data-redis 這個 starter 作為例子,來說一說官方是怎麼組織專案結構的,以及閱讀原始碼的順序應該是怎樣的。
1. 展開 Spring-boot-staters 下的 redis starter,我們看到目錄結構如下
其中並沒有 Java 程式碼,只有一個 spring.provides 檔案,裡面的內容如下:
provides: spring-data-redis,lettuce-core
意思就是說,本專案依賴 spring-data-redis 和 lettuce-core 這兩個包,並且在 pom 檔案中引用了。其目的就是告知使用者在引用此包的時候,不必再引用 provides 中的依賴包了。
2. 然後就是自動註解了,所有 stater 的自動註解類、屬性配置類都放到了 spring-boot-autoconfigure 這個專案下
看到熟悉的 spring.factories 沒有,前面我們自己實現過。這個內容比較多,我們只看 redis 相關的
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,\
org.springframework.boot.autoconfigure.data.redis.RedisReactiveAutoConfiguration,\
org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
包含三個自動配置檔案,然後順著配置,我們找到所在 package
然後就可以開始閱讀程式碼了。其他的 starter 也是同樣的結構。
如果你覺得寫的還可以的話,請點個「推薦」吧
歡迎關注,不定期更新本系列和其他文章
古時的風箏
,進入公眾號可以加入交流群
參考內容:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html#boot-features-custom-starter