兩年摸爬滾打 Spring Boot，總結了這 16 條最佳實踐

Spring Boot是最流行的用於開發微服務的Java框架。在本文中，我將與你分享自2016年以來我在專業開發中使用Spring Boot所採用的最佳實踐。這些內容是基於個人我的經驗和一些熟知的Spring Boot專家的文章。

在本文中，我將重點介紹Spring Boot特有的實踐（大多數時候，也適用於Spring項目）。如下依次列出了最佳實踐，排名不分前後。

一、使用自定義BOM來維護第三方依賴

這條實踐是我根據實際項目中的經歷總結出的。

Spring Boot項目自己使用和集成了大量的開源項目，它幫助咱們維護了這些第三方依賴。可是也有一部分在實際項目使用中並無包括進來，這就須要咱們在項目中本身維護版本。若是在一個大型的項目中，包括了不少未開發模塊，那麼維護起來就很是的繁瑣。

怎麼辦呢？事實上，Spring IO Platform就是作的這個事情，它自己就是Spring Boot的子項目，同時維護了其餘第三方開源庫。咱們能夠借鑑Spring IO Platform來編寫本身的基礎項目platform-bom，全部的業務模塊項目應該以BOM的方式引入。這樣在升級第三方依賴時，就只須要升級這一個依賴的版本而已。

 

二、使用自動配置

Spring Boot的一個主要特性是使用自動配置。這是Spring Boot的一部分，它能夠簡化你的代碼並使之工做。當在類路徑上檢測到特定的jar文件時，自動配置就會被激活。

使用它的最簡單方法是依賴Spring Boot Starters。所以，若是你想與Redis進行集成，你能夠首先包括：

 

若是你想與MongoDB進行集成，須要這樣：

 

但只有在絕對必要時才應該這樣作。

有關自動配置點擊這裏有一篇實戰文章，官方文檔可在此處找到：https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html。

三、使用Spring Initializr來開始一個新的Spring Boot項目

這一條最佳實踐來自Josh Long （Spring Advocate，@starbuxman）。

Spring Initializr（https://start.spring.io/）提供了一個超級簡單的方法來建立一個新的Spring Boot項目，並根據你的須要來加載可能使用到的依賴。

使用Initializr建立應用程序可確保你得到通過測試和驗證的依賴項，這些依賴項適用於Spring自動配置。你甚至可能會發現一些新的集成，但你可能並無意識到這些。

四、考慮爲常見的組織問題建立本身的自動配置

這一條也來自Josh Long（Spring Advocate，@starbuxman）——這個實踐是針對高級用戶的。

若是你在一個嚴重依賴Spring Boot的公司或團隊中工做，而且有共同的問題須要解決，那麼你能夠建立本身的自動配置。

這項任務涉及較多工做，所以你須要考慮什麼時候獲益是值得投入的。與多個略有不一樣的定製配置相比，維護單個自動配置更容易。

若是將這個提供Spring Boot配置以開源庫的形式發佈出去，那麼將極大地簡化數千個用戶的配置工做。有關自動配置點擊這裏有一篇實戰文章。

五、正確設計代碼目錄結構

儘管容許你有很大的自由，可是有一些基本規則值得遵照來設計你的源代碼結構。

避免使用默認包。確保全部內容（包括你的入口點）都位於一個名稱很好的包中，這樣就能夠避免與裝配和組件掃描相關的意外狀況；

將Application.java（應用的入口類）保留在頂級源代碼目錄中；

我建議將控制器和服務放在以功能爲導向的模塊中，但這是可選的。一些很是好的開發人員建議將全部控制器放在一塊兒。不論怎樣，堅持一種風格！

六、保持@Controller的簡潔和專一

Controller應該很是簡單。你能夠在此處閱讀有關GRASP中有關控制器模式部分的說明（https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Controller）。你但願控制器做爲協調和委派的角色，而不是執行實際的業務邏輯。如下是主要作法：

控制器應該是無狀態的！默認狀況下，控制器是單例，而且任何狀態均可能致使大量問題；

控制器不該該執行業務邏輯，而是依賴委託；

控制器應該處理應用程序的HTTP層，這不該該傳遞給服務；

控制器應該圍繞用例/業務能力來設計。

要深刻這個內容，須要進一步地瞭解設計REST API的最佳實踐。不管你是否想要使用Spring Boot，都是值得學習的。

七、圍繞業務功能構建@Service

Service是Spring Boot的另外一個核心概念。我發現最好圍繞業務功能/領域/用例（不管你怎麼稱呼都行）來構建服務。

在應用中設計名稱相似AccountService, UserService, PaymentService這樣的服務，比起像DatabaseService、ValidationService、CalculationService這樣的會更合適一些。

你能夠決定使用Controler和Service之間的一對一映射，那將是理想的狀況。但這並不意味着，Service之間不能互相調用！

八、使數據庫獨立於核心業務邏輯以外

我以前還不肯定如何在Spring Boot中最好地處理數據庫交互。在閱讀了羅伯特·C·馬丁的「Clear Architecture」以後，對我來講就清晰多了。

你但願你的數據庫邏輯於服務分離出來。理想狀況下，你不但願服務知道它正在與哪一個數據庫通訊，這須要一些抽象來封裝對象的持久性。

羅伯特C.馬丁強烈地說明，你的數據庫是一個「細節」，這意味着不將你的應用程序與特定數據庫耦合。過去不多有人會切換數據庫，我注意到，使用Spring Boot和現代微服務開發會讓事情變得更快。

九、保持業務邏輯不受Spring Boot代碼的影響

考慮到「Clear Architecture」的教訓，你還應該保護你的業務邏輯。將各類Spring Boot代碼混合在一塊兒是很是誘人的……不要這樣作。若是你能抵制誘惑，你將保持你的業務邏輯可重用。

部分服務一般成爲庫。若是不從代碼中刪除大量Spring註解，則更容易建立。

十、推薦使用構造函數注入

這一條實踐來自Phil Webb（Spring Boot的項目負責人, @phillip_webb）。

保持業務邏輯免受Spring Boot代碼侵入的一種方法是使用構造函數注入。 不只是由於@Autowired註解在構造函數上是可選的，並且還能夠在沒有Spring的狀況下輕鬆實例化bean。

十一、熟悉併發模型

我寫過的最受歡迎的文章之一是「介紹Spring Boot中的併發」（https://www.e4developer.com/2018/03/30/introduction-to-concurrency-in-spring-boot/）。我認爲這樣作的緣由是這個領域常常被誤解和忽視。若是使用不當，就會出現問題。

在Spring Boot中，Controller和Service是默認是單例。若是你不當心，這會引入可能的併發問題。 你一般也在處理有限的線程池。請熟悉這些概念。

若是你正在使用新的WebFlux風格的Spring Boot應用程序，我已經解釋了它在「Spring’s WebFlux/Reactor Parallelism and Backpressure」中是如何工做的。

十二、增強配置管理的外部化

這一點超出了Spring Boot，雖然這是人們開始建立多個相似服務時常見的問題……

你能夠手動處理Spring應用程序的配置。若是你正在處理多個Spring Boot應用程序，則須要使配置管理能力更增強大。

我推薦兩種主要方法：

使用配置服務器，例如Spring Cloud Config；

將全部配置存儲在環境變量中（能夠基於git倉庫進行配置）。

這些選項中的任何一個（第二個選項多一些）都要求你在DevOps更少工做量，但這在微服務領域是很常見的。

1三、提供全局異常處理

你真的須要一種處理異常的一致方法。Spring Boot提供了兩種主要方法：

你應該使用HandlerExceptionResolver定義全局異常處理策略；

你也能夠在控制器上添加@ExceptionHandler註解，這在某些特定場景下使用可能會頗有用。

這與Spring中的幾乎相同，而且Baeldung有一篇關於REST與Spring的錯誤處理的詳細文章（https://www.baeldung.com/exception-handling-for-rest-with-spring），很是值得一讀。

1四、使用日誌框架

你可能已經意識到這一點，但你應該使用Logger進行日誌記錄，而不是使用System.out.println()手動執行。這很容易在Spring Boot中完成，幾乎沒有配置。只需獲取該類的記錄器實例：

 

這很重要，由於它可讓你根據須要設置不一樣的日誌記錄級別。有關Spring Boot日誌集成點擊這裏有一篇實戰文章

1五、測試你的代碼

這不是Spring Boot特有的，但它須要提醒——測試你的代碼！若是你沒有編寫測試，那麼你將從一開始就編寫遺留代碼。

若是有其餘人使用你的代碼庫，那邊改變任何東西將會變得危險。當你有多個服務相互依賴時，這甚至可能更具風險。

因爲存在Spring Boot最佳實踐，所以你應該考慮將Spring Cloud Contract用於你的消費者驅動契約，它將使你與其餘服務的集成更容易使用。有關Spring Boot單元測試點擊這裏有一篇實戰文章

1六、使用測試切片讓測試更容易，而且更專一

這一條實踐來自Madhura Bhave（Spring 開發者, @madhurabhave23）。

使用Spring Boot測試代碼可能很棘手——你須要初始化數據層，鏈接大量服務，模擬事物……實際上並非那麼難！答案是使用測試切片。

使用測試切片，你能夠根據須要僅鏈接部分應用程序。這能夠爲你節省大量時間，並確保你的測試不會與未使用的內容相關聯。來自spring.io的一篇名爲Custom test slice with Spring test 1.4的博客文章（https://spring.io/blog/2016/08/30/custom-test-slice-with-spring-boot-1-4）解釋了這種技術。

總結

感謝Spring Boot，編寫基於Spring的微服務正變得史無前例的簡單。我但願經過這些最佳實踐，你的實施過程不只會變得很快，並且從長遠來看也會更增強大和成功。祝你好運！

歡迎工做一到五年的Java工程師朋友們加入Java架構開發：744677563

本羣提供免費的學習指導 架構資料 以及免費的解答

不懂得問題均可以在本羣提出來 以後還會有職業生涯規劃以及面試指導