【注】本文譯自：How to build a Spring Boot 12-Factor app (theserverside.com)
在這裡，我們看看 Spring Boot 框架如何支援十二因素應用的方法，以及 GitHub、Docker 和 Kubernetes 等工具填補了哪些空白。
沒有國際標準組織指定 Spring Boot 應用作為微服務必須滿足的標準。Heroku 聯合創始人 Adam Wiggins 向部署到 Heroku 平臺的開發人員提供的 12 條建議是開發人員最接近的一套雲原生開發指南。
這 12 條戒律被稱為“十二因素應用方法論”，已成為建立現代的以 Docker 和 Kubernetes 為部署目標的現代雲原生微服務的事實標準。
開發基於 Java 的微服務最流行的平臺是 Spring Boot。以下是 Spring Boot 如何支援十二因素應用方法論的原則。

1. Spring Boot 程式碼庫

並非每個 12 因素的原則都直接對映到 Spring Boot。程式碼庫原則就是責任落在 Spring 框架之外的一個例子。
根據十二因素應用，每個 Spring Boot 微服務都應該有自己獨立的程式碼庫。這可以通過建立單個 Git 儲存庫來實現，開發人員可以在其中貢獻程式碼、合併分支和修復錯誤。如果您的 Spring Boot 應用託管在其自己的 Git 儲存庫中，那麼您已經正確地實現了 12 因素程式碼庫要求。

2. 外部化依賴管理

如果您使用 Spring Boot 初始化器建立一個專案，則必須在 Gradle 或 Maven 之間進行選擇作為專案的構建工具。這兩個工具都將管理依賴項外部化。
如果您將 JAR 檔案放在專案的 lib 目錄之外，並在 Maven POM 或 Gradle 構建檔案中列出程式的所有外部依賴項，則您的 Spring Boot 應用程式將正確實現 12 因素 依賴項管理。

3. Spring Boot 和 Kubernetes 配置

根據十二因素應用方法論，Spring Boot 應用程式應該從環境中讀取其配置資料。 例如，如果將雲原生 Spring Boot 應用程式部署到 Docker 容器並在 Kubernetes 叢集中進行管理，則應用程式應該從 Kubernetes ConfigMap 讀取其配置資料——而不是從 JavaBean 欄位甚至應用程式屬性檔案。Spring 的級聯配置處理系統完全滿足了這個 12-因素要求。
任何用 Spring @ConfigurationProperties 註解修飾的 JavaBean 都會在多個地方尋找配置資料。 @ConfigurationProperties 修飾的 bean 的規則是始終使用最高外部化級別的配置。在 JavaBean 中硬編碼的屬性將被 ApplicationProperties 檔案中的資料覆蓋，這些資料將被 JVM 引數覆蓋，最終將被 Docker 或 Kubernetes ConfigMap 提供的引數覆蓋。
使用 @ConfigurationProperties 註解，您的 12 因素 Spring Boot 應用將符合配置。

4. 支援服務和 Spring Boot

將支援服務視為附加資源的能力自 Java 語言一開始就已經融入到 Java 語言中，因此即使開發人員齊心協力，也很難違反這個 12 因素 約束。
例如，所有通過 Java 資料庫連線 (JDBC) 訪問的資料庫都需要一個 URL 和驅動程式，這隱式地使資料庫成為附加資源。 如果不將資料庫視為支援服務，就不可能在 Java 中執行 JDBC 或 JPA。 NoSQL 資料庫、Kafka 佇列和 RESTful Web 服務也是如此。如果您在 Jakarta EE 或 Spring Boot 中編寫程式碼，則幾乎必須按照 12-因素指南將所有外部資源視為支援服務。

5. 構建、釋出和執行

開發人員遵循嚴格的構建、釋出和執行策略的建議似乎有些不言而喻。 具有諷刺意味的是，這也可能是最常違反的 12 因素規則之一。
這裡的想法是您應該始終從您的程式碼庫構建您的程式碼。釋出是與版本化配置檔案相關聯的標記構建。它是您在伺服器上部署和執行的標記構建和版本化配置資料的組合。
不應更新在伺服器上執行的程式碼來修復錯誤。不應在執行時調整配置設定來克服 Java 效能問題。進入部署的所有程式碼都來自構建，它基於在裸 Git 儲存庫中進行版本控制的程式碼。
一旦與構建配對以建立釋出，配置資料就不得更改。如果需要更改，團隊必須再次經歷完整的構建、釋出和執行週期。 不應該有違反 12 因素構建、釋出和執行原則的捷徑。

6. 無狀態 Spring Boot 程序

Java 和 Jakarta EE API 有許多類和介面，它們隱式地嚮應用程式新增狀態，其中最重要的是 Servlet 和 JSP API 的 HttpSession 物件。
為了實現 12 因素合規性，Spring Boot 為 HttpSession 提供了一個替代品，稱為 Spring Session。這有助於外部化資料，否則這些資料將被有狀態地儲存在 Tomcat 或 Jetty 等應用程式伺服器上。這是 Spring Boot 如何提供額外 API 並重新實現常用類以確保應用程式和微服務保持 12 因素合規性的一個主要示例。
此外，Spring Boot 允許開發人員輕鬆地將 NoSQL 資料庫（如 Cassandra 和 MongoDB）中的狀態外部化，這也有助於簡化無狀態微服務的開發。
必須指出的是，確保微服務作為無狀態程序執行的責任也很大程度上落在了軟體開發人員的肩上。如果開發人員決定將使用者狀態儲存在一個例項變數中，而不是在共享資源中將該資料外部化，那麼 Spring、Docker 或 Kubernetes 無法讓該應用程式作為無狀態程序進行擴充套件。

7. 埠繫結

埠繫結是另一個 12 因素 原則，它超出了 Spring Boot 框架的範圍。相反，Docker 容器會將 Tomcat 或 Undertow 伺服器使用的內部埠對映到公共埠。在叢集環境中，kubectl 實用程式會將 Kubernetes Pod 的埠繫結為公共服務。無論哪種方式，Spring Framework 都不負責埠繫結要求。
Spring 確實提供了更改打包的 Spring Boot 應用程式內部使用的埠的能力，但 Kubernetes 或 Docker 將負責外部埠繫結，使雲原生應用程式可公開訪問。

8. 併發性

根據十二因素應用方法論，雲原生應用應該能夠橫向擴充套件，以支援來自客戶端的大容量併發請求-響應週期。只要 Spring Boot 應用是無狀態的，Kubernetes 副本集就會負責使用 Docker 容器建立新的 Pod，這些容器可以同時處理不斷增加的工作負載。

9. 快速啟動和關閉

十二因素應用方法論的第 9 條原則是可處置性，它堅持微服務應該快速啟動並優雅地關閉。
為了便於處理，Spring Boot 實現了延遲載入設計模式。它還執行智慧初始化以減少在雲原生微服務啟動時建立的物件數量。此外，當開發人員使用 Spring 框架提供的資源類時，控制能力的反轉確保資源在 Kubernetes 節點耗盡或 Docker 容器下線時優雅地終止。

10. 環境之間的奇偶校驗

開發、使用者驗收測試、預生產和生產環境之間總會存在差異。但十二因素方法堅持這些環境儘可能相似。
為了促進環境對等，Spring Boot 構建將建立一個可執行的 JAR 檔案，其中嵌入了一個應用程式伺服器，例如 Tomcat。 打包在 Docker 容器中的相同嵌入式 Tomcat JAR 檔案將用於每個不同的部署環境。 由於每個環境都部署了相同的編譯程式碼和應用伺服器，最終實現了環境間的對等。
此外，Spring Profiles 提供了一種簡單的方法來定義和配置需要從一個環境更改到另一個環境的屬性，從而允許開發人員解決不可避免地發生的環境之間的差異。

11. 日誌作為事件流

十二因素應用堅持將日誌視為事件流。
Spring Boot 使用的所有標準 Java 日誌框架都將它們的資料寫入事件流，該事件流被儲存到執行 Docker 容器的 Kubernetes 節點上的公共目錄中。然後這些日誌檔案很容易被 Kubernetes DaemonSets 使用，比如 FluentD 或 Logstash。這些 DaemonSet 然後將日誌流式傳輸到 Elasticsearch 和 Logstash 等工具以供使用。
只要您使用框架標準的 Java 日誌框架，您就可以放心，在日誌消耗方面，您擁有一個符合 12 因素標準的 Spring Boot 應用程式。

12. 管理程序管理

應用通常需要執行管理程序，這些程序與處理客戶端-伺服器互動的請求-響應迴圈沒有直接聯絡的。根據十二因素應用，不應將實現這些過程的程式碼放在單獨的程式碼庫中。管理程序應打包為標準的、受版本控制的構建的一部分，並且程序本身應在應用使用的相同執行時環境中執行。
在雲原生 Spring Boot 應用程式中新增對管理程序的支援非常容易。Spring Batch 專案可以輕鬆新增對執行一次並退出的作業的支援。 此外，任何 Git 儲存庫都可以配置為包含資料夾，這些資料夾允許新增可以在需要時在 REPL shell 中執行的指令碼。
雲原生微服務的開發沒有明確的標準，但十二要素應用方法很接近。如果您是一名 Java 開發人員並且想要建立 12 因素應用，Spring Boot 將幫助您的團隊保持雲原生合規性。