今天，經過一年半的努力，我很高興地宣布我們正在推出 Spring Native 的 Beta 版本，並可在 start.spring.io 上使用！

實際上，除了 Spring 從一開始就支援的常規 Java 虛擬機器之外，我們還新增了 Beta 版支援，可將 Spring 應用程式編譯為使用 GraalVM 的 原生映像檔，以便提供部署 Spring 應用程式的新方式。 支援 Java 和 Kotlin。

這些原生 Spring 應用程式可以部署為獨立的可執行檔（不需要安裝 JVM），並提供一些有趣的特性，包括幾乎即時的啟動（通常 < 100 毫秒）、即時的峰值效能和較低的記憶體消耗，但代價是更長的建置時間和比 JVM 更少的執行階段最佳化。

透過簡單的 mvn spring-boot:build-image 或 gradle bootBuildImage 指令，您可以產生一個最佳化的容器映像檔，其中將包含一個最小的 OS 層和一個小的原生可執行檔，該檔案僅包含 JDK、Spring 和您在應用程式中使用的依賴項所需的位元。 例如，請參閱下面一個最小的容器映像檔，其中包含一個 50MB 的可執行檔，其中包含 Spring Boot、Spring MVC、Jackson、Tomcat、JDK 和應用程式。

在許多使用案例中，原生對於您的 Spring 應用程式來說可能是有意義的

• 使用 Spring Cloud Function 的無伺服器

• 更便宜且更永續地託管您的 Spring 微服務

• 非常適合像 VMware Tanzu 這樣的 Kubernetes 平台

• 想要建立最佳化的容器映像檔來封裝您的 Spring 應用程式和服務

我相信令人驚嘆的 Spring 社群會找到更多，例如 Piotr Mińkowski 撰寫的關於如何在 Knative 上使用 Spring Boot 和 GraalVM 建立原生微服務的 這篇精彩教程。

團隊合作

Spring Native Beta 是 Spring 團隊及其專案組合（Spring Framework、Spring Boot，以及 Spring Data、Spring Security、Spring Cloud 和 Spring Initializr）廣泛合作的成果。觀看此影片，了解 Spring 團隊如何建構 Spring Native Beta 以及它提供的功能，包括全新 start.spring.io 支援的示範。

由於原生涉及更廣泛的 JVM 生態系統，因此我們的原生工作範圍比 Spring 更廣泛，因此我們一直在與 GraalVM 團隊合作，以提高原生映像檔的相容性和佔用空間。以下是 GraalVM 團隊的 Vojin Jovanovic 的引言

「很高興能與 Spring 團隊合作打造原生 JVM 生態系統：他們深厚的技術知識，以及對社群的敏感觸覺，總是能帶來最佳的解決方案。最新的 Spring Native 版本及其在 JVM 生態系統中的眾多用法，為廣泛採用原生編譯鋪平了道路。」

支援範圍

隨著 Spring Native 從 Alpha 版升級到 Beta 版，我認為有必要澄清我們提供的支援範圍。

Alpha 是我們進行大量實驗並在一組樣本上改進 Spring Native（之前稱為 Spring GraalVM Native）架構、相容性和佔用空間的第一步，其中有很多重大變更。我們也報告了 許多問題，GraalVM 團隊已修復這些問題，以縮小 JVM 和 Spring 應用程式原生程式之間的差距。

雖然它仍然被認為是實驗性的，但 Beta 意味著 Spring 現在提供 對 Spring 生態系統子集的原生支援。如果您的專案使用受支援的依賴項，您可以嘗試在您的專案中使用它，並且在發生錯誤時 提出錯誤 或 貢獻提取請求。Spring Native 的新版本將針對最新 Spring Boot 2.x 次要版本的每個修補程式版本發布。Spring Native 0.9.0 支援 Spring Boot 2.4.3，Spring Native 0.9.1 將支援 Spring Boot 2.4.4，依此類推。可能會發生重大變更，但我們會記錄遷移路徑。文件品質已達到新的水準：參考文件可以作為 html 單頁 或 pdf 取得，並且我們為原生提示公用 API 發布 Javadoc。

start.spring.io

Stéphane Nicoll 已在 start.spring.io 和相關 IDE 整合中引入對 Spring Native 的支援，因此從今天開始，這可能是探索如何使用 Spring 建構原生應用程式的最簡單方法。

新增 Spring Native 依賴項將自動使用所需的依賴項和外掛程式設定您的 Maven 或 Gradle 專案，以支援原生程式。應用程式程式碼本身沒有變更。

請務必查看產生的 HELP.md 檔案，其中包含有用的連結和文件，但也指示您是否選擇了某些已知不受原生程式支援的依賴項。

預先轉換

原生程式與 JVM 不同：類別路徑在建置時是固定的，反射或資源等需要設定，沒有類別延遲載入（可執行檔中運送的所有內容都在啟動時載入到記憶體中），並且可以在建置時調用一些程式碼。

為了完全擁抱這些特性，並允許 Spring 應用程式以最大的相容性和最小的佔用空間在原生程式上執行，Brian Clozel 在此版本中引入了 Spring 預先 (AOT) Maven 和 Gradle 外掛程式，這些外掛程式對您的應用程式執行預先轉換。

第一種轉換旨在根據由令人驚嘆的 Andy Clement 設計和實作的推理引擎產生 GraalVM 原生設定（反射、資源、proxy、native-image 選項），該引擎了解 Spring 程式設計模型和基礎結構是什麼。例如，對於每個用 @Controller 註解的類別，都會在產生的 reflect-config.json 檔案中新增一個項目。

有些原生設定無法推斷出來，對於這些情況，我們正在引入 原生提示註解（請參閱 Javadoc 以取得更多詳細資訊），這使 Spring Native 能夠以比基於 JSON 的常規原生映像檔設定更具可維護性、型別安全性和彈性的方式支援原生設定。例如，使用 Spring Native 的 MySQL 驅動程式支援提供提示，這些提示將允許在原生映像檔 reflect-config.json、resource-config.json 和 native-image.properties 中產生正確的項目，如下所示

@NativeHint(
    trigger = Driver.class,
    options = "--enable-all-security-services",
    types = @TypeHint(types = {
       FailoverConnectionUrl.class,
       FailoverDnsSrvConnectionUrl.class,
       // ...
    }), resources = {
	@ResourceHint(patterns = "com/mysql/cj/TlsSettings.properties"),
	@ResourceHint(patterns = "com.mysql.cj.LocalizedErrorMessages",
                      isBundle = true)
})
public class MySqlHints implements NativeConfiguration {}

NativeConfiguration 和其他 動態設定機制 允許更強大和動態的設定產生，但請注意，它們的 API 在即將到來的版本中將會發生很大的變化。

Spring 開發人員也可以使用特定於應用程式的原生提示直接註解他們的 @Configuration 或 @SpringBootApplication 類別，例如，透過程式設計 API（如 RestTemplate 或 WebClient）將 Book 類別序列化為 JSON

@TypeHint(types = Book.class)
@SpringBootApplication
public class WebClientApplication {
    // ...
}

在使用預先編譯轉換系統時，最後一個，也可能是最強大的機制是能夠自動產生原生優化的程式碼（原始碼和位元組碼）。這利用了 Spring Boot 部署模型引入的封閉世界假設，以及 GraalVM Native Image 的特性。 這裡的目標是限制所需的額外原生配置量，藉此提高相容性。方法是使用可由 Native Image 編譯器直接分析的程式碼結構，並通過減少反射、資源或代理所需的配置量來降低資源佔用。 一個具體的例子是對各種 spring.factories（Spring Boot 背後的擴展機制）進行預先編譯轉換，將其轉換為優化的程式化版本，無需反射，並過濾掉應用程式上下文中不需要的條目。

這只是 Spring AOT 的一個開始，我們計劃添加更強大的轉換，例如將 @Configuration 轉換為函數式配置，以通過預先編譯分析來取代運行時反射，並自動產生使用程式化結構（如 Lambda 和方法引用）的配置類別。這將允許 GraalVM Native Image 編譯器直接理解 Spring 配置，而無需任何反射配置或 *.class 資源。

要記住的一個關鍵點是，當在 JVM 上使用 Spring Native 時，這個 AOT 產生的程式碼也會預設使用，以便您可以使用 JVM 允許的短迴圈回饋、您的偵錯器和所有常規工具來執行“原生友好的程式碼路徑”。

雖然 Spring AOT 轉換目前主要由原生需求驅動，但其中很多並非原生專用，並且某些轉換可能會為在 JVM 上運行 Spring Boot 應用程式提供優化。 像往常一樣，對於這類主題，重要的是要以資料為驅動，因此我們將衡量效率和效能來驅動我們的決策。

我們可能會完善 IDE 的整合。目前，請務必閱讀相關文件，了解在 IDE 中運行應用程式之前更新產生的原始碼的潛在手動配置步驟。

結論

Spring 走向原生的策略有兩個主要支柱。 第一個是調整 Spring 基礎架構以適應原生，而無需對數百萬個現有的 Spring Boot 應用程式進行重大更改。 這包括我們在 Spring 頂級專案中進行的更改，使其對原生友好，例如 @NativeHint 的基礎架構，以及我們在 Spring Native 中成熟的 Spring AOT 建置外掛程式。 請查看我們的 路線圖，以獲取有關即將發布的步驟的更多資訊。

第二個支柱比 Spring 本身更廣泛，原生是一個具有與 JVM 不同特性的平台，但 Java 生態系統需要盡可能保持一致，以避免出現兩種非常不同的 Java 風味，而這將難以維護。 這就是為什麼我們與 GraalVM 團隊密切合作以縮小這種差距的原因。 這種合作將集中於在未來幾個月內改善更廣泛的 JVM 生態系統的原生測試和原生配置。

Spring 開發人員可以通過我們提供的各種範例了解更多關於原生的資訊，訪問 start.spring.io 測試我們新的原生支援，閱讀更新的 參考指南，閱讀版本說明，尤其是當您從以前的版本升級時，或者甚至貢獻對您最喜歡的依賴項的支援。 如果您想了解更多關於相關 Spring 商業支援的資訊，也可以 聯絡我們。

最後，我要非常感謝 Spring 社群已經提供了許多有用的回饋和貢獻，感謝 GraalVM 團隊的精彩合作，以及 Spring 團隊為使 Spring 開發人員更容易採用原生所做的努力。

祝您使用愉快！