嗨，Spring 的粉絲們！

你們知道我做了什麼嗎？我犯錯了，各位。我不小心在十二月的最後一周，也就是今年的最後一個月，發布了本週 Spring 大事！我不應該這樣做的。我不應該不這樣做的。通常，你會看到，我會把特定年份的最後一篇本週 Spring 大事變成名副其實的Spring 年度回顧，慶祝定義該年度的重大主題（嗯，至少從我的角度來看是這樣）。然後我會將通常的本週 Spring 大事摘要內聯包含進去。我忘記先做第一部分，所以我就把它作為一個單獨的帖子發布了。嘿，這是傳統。

啊，2020 年。真是持續帶來驚喜的一年。這是《虎王》之年。如果你在 2019 年告訴我，在 2020 年，我會被釘在沙發上，觀看 Netflix 上一位馴虎師的冒險經歷，害怕我的送貨食品，並且我會渴望在十個月內第一次登上飛機，我會笑得從椅子上摔下來！

今年，2020 年，開局很棒。2020 年是 VMware 收購 Pivotal 後 Spring 團隊回歸的第一年（左右）。你們中的一些人可能知道，在我們於 2013 年分拆成立 Pivotal 之前，Spring 團隊曾在 VMware 工作了幾年。現在我們又回來了。你可能會認為這會造成破壞，但事實並非如此。Pivotal 和 VMware 都是為幫助客戶實現生產目標而生的。我們一開始就全力以赴，並繼續提供重要且頻繁的成果。

這種興奮在史詩般的 SpringOne 2020（虛擬）活動中表現得最為明顯，今年吸引了來自各行各業、各種信仰、各個國家和各大洲的大約 40,000 人。這是如此甜蜜的甘露，我永遠不會忘記。

Spring 團隊一直以來在地理位置上分佈廣泛，這也很有幫助。例如，從技術上講，我自 2010 年以來一直是一名在家工作的員工。雖然今年壓力特別大，而且僅僅是為了額外的很多原因，但對我們中的許多人來說，弄清楚在家工作的日常事務根本不是其中之一。

在我撰寫本文時，是 2020 年 12 月 30 日，距離疫情新聞開始傳入西方已經一年了。我不想成為那種人，但我今年因為 COVID-19 失去了家人。我有一些朋友今年在呼吸器上度過了一段時間。我也認識失去家人和朋友的人。對於全世界很多人來說，這絕對是一場恐怖秀。然而，不知何故，我很榮幸能夠繼續撰寫關於軟體的部落格。這都是因為你，親愛的社群。雖然我一直非常感謝你，但今年我尤其如此。為你工作是一種榮幸。

疫情像野火一樣蔓延（有些東西不應該是開源的！），它淹沒了許多其他，有時是更積極的消息。本著這種精神，我想回顧一下 2020 年的一些亮點——一些重要主題。

Kubernetes

你可能聽說過 VMware Tanzu。你可能聽說過 Spring 團隊是 Tanzu 的一部分。你是否也知道 Kubernetes 的三位創始人中有兩位也是 Tanzu 的一部分？ 你是否知道 VMware 是 Kubernetes 的第三大貢獻者？我們對 Kubernetes 非常狂熱！

Tanzu Kubernetes Grid 是我們額外棒的 Kubernetes 發行版，可以在本地或公共基礎設施上運行。 Harbor 是一個企業級容器註冊表。 Tanzu Mission Control 提供跨雲的多叢集 Kubernetes 管理。 VMware 也是 Carvell 的重要貢獻者，它提供了一組可靠、單一用途、可組合的工具，可幫助您構建、配置和部署到 Kubernetes 的應用程式。 我們有 Tanzu Build Service，它以企業規模自動化容器的建立、管理和治理。 我相信我錯過了無數其他東西。

我們甚至改造了 Cloud Foundry，我們的平台即服務產品，使其可以在 Kubernetes 之上工作。 具有全脂 Kubernetes 容器編排的相同絲般柔滑以開發者為中心的工作流程體驗。

近年來，為了使 Java 和 Spring 在諸如 Kubernetes 之類的容器化雲基礎設施中更具相關性，已經進行了大量工作。

今年，Spring Boot 透過 CNCF Paketo buildpacks 專案引入了對 buildpacks 的內建支援。 有一個使用 2.3 或更高版本的 Spring Boot 專案嗎？ 試試這個：mvn spring-boot:build-image（也有 Gradle 等效項），您將在大約一分鐘內擁有一個容器化應用程式。 然後您可以 docker tag 和 docker push 該容器化應用程式到您選擇的 Kubernetes 叢集。 或者，實際上，到任何支援 OCI/Docker 映像的東西。

Spring Boot 本身現在可以從配置樹中提取配置。 配置樹是指當您將 Kubernetes ConfigMap 作為 Kubernetes 中的卷掛載時獲得的配置目錄。 它是另一種類型的配置來源，例如類路徑配置（application.properties、application.yaml 等）、環境變數、檔案 (file://${user.home}/config/my-config.properties) 等等。

Spring Boot 的 Actuator 模組可以公開端點，以用作 Kubernetes 存活探針和就緒探針。 就緒探針告訴 Kubernetes，剛啟動的服務是否已準備好投入輪換。 存活探針告訴 Kubernetes 服務是否仍然存活。 如果服務由於任何原因而生病，它將被移除輪換。

應用程式面臨的問題是：Kubernetes 應該立即銷毀應用程式，還是應該等待一個配置的時間間隔以允許正在進行的交易完成？ 可以在 Kubernetes 中配置此行為。 Spring Boot 支援耗盡任何正在進行的交易，並拒絕任何具有我們稱之為優雅關閉的新功能的請求。

Spring Boot 及其周圍的生態系統，包括用於 Kubernetes 的 Spring Cloud，是構建為雲原生 Kubernetes 環境設計的軟體的最佳方式，而且每天都在改進。 儘管如此，我們實際上才剛剛開始，敬請期待！

反應式程式設計

反應式程式設計是一種程式設計範例，可提供三種好處：資源效率、資料 API 的一致性和可組合性以及穩健性。 它透過使編寫程式碼變得簡單來提供更好的資源效率，這些程式碼可以很好地釋放原本閒置的執行緒以供重用。 它提供一致性，因為它為我們提供了一種抽象，一種思考不同資料流的方式。 是否有資料以 Java 8 Stream<T> 的形式傳入？ Collection<T>？ CompletableFuture<T>？ 單個值或陣列？ 沒問題。 反應式程式設計為我們提供了一種以一致的方式根據所有這些 API 描述資料流管道的方式。

在學習反應式類型方面存在輕微的逆境。 但是，在整個生態系統中所有可能的應用中進行攤銷後，我認為您會發現您將能夠忘記許多其他抽象和 API。 自 2011 年以來，Spring 生態系統（適度地）支援反應式程式設計，但真正的飛躍發生在 2017 年，當時我們在 Spring Framework 5 中引入了反應式程式設計支援。從那時起，反應式程式設計已滲透到 Spring 生態系統的各個方面。 我不記得我上次在反應式世界中想要某樣東西，卻被告知它仍在開發中的情況是什麼時候了。 2020 年肯定沒有發生！

我想要的一切都在這裡，並且普遍可用。 交易、SQL 資料存取、訊息傳遞和整合、反應式客戶端負載平衡、重試、速率限制、API 閘道、NoSQL 資料存取、HTTP、WebSocket、RPC、指標、分散式追蹤、可觀察性：所有這些（以及我可以想到的所有其他東西）現在都可以直接使用。 未來是非阻塞的，而正如今天設計的那樣，Spring 將在最前線與您同在。 我編寫並發布了一本關於 這些東西的書，所以請相信我，它非常棒。 反應式程式設計是一種強大的方式，可以使我們的服務在雲中表現更好（並更好地擴展！）。

使用 GraalVM 的原生映像

原生鏡像已成趨勢，而且它們非常棒。這一切看起來是如此簡單。如果我們採用 Java 傳奇的即時編譯器 (HotSpot)，並用它來預先主動地編譯整個應用程式呢？這似乎異常簡單。這個將原始碼轉換為原生碼的過程，在許多其他語言中簡稱為編譯。由於編譯成位元碼所引入的間接性，迫使我們為這種全新的直通式旅程採用一個新術語：預先編譯 (AOT)。哇哦。啊哈。

簡單。但事實證明並非如此。因為一旦編譯成原生鏡像，應用程式就不會像在 JVM 中執行時那樣擁有相同的運行時環境。一旦編譯成原生鏡像，運行時將無法執行我們期望從 JVM 獲得的一些更動態的技巧。想要將類別載入到類別載入器中嗎？使用 CGlib 代理？對沒有先驗運行時意識的類別進行反射？從類別載入器載入資源 (例如，一個 banner.txt 檔案) 嗎？所有這些在 GraalVM AOT 編譯這個古怪但美好的世界中都行不通。

Spring GraalVM 專案可以在這裡為您提供協助。它支援識別 Spring 應用程式可能想要執行這些操作的所有位置，並提供協助來註冊您可能執行的任何需要配置的操作。該專案正以驚人的速度增長，目標是到 Spring Boot 3 和 Spring Framework 6 時，所有這些都將內建並開箱即用。

為了換取所有這些偶然的複雜性，GraalVM 在啟動速度方面帶來了數倍的提升，並顯著降低了記憶體佔用。這使得 GraalVM 成為一個 (更好) 的 bin-packer，尤其是在容器化的雲端環境中，在這種環境中，資源消耗非常重要。我迫不及待想看看 Project Leydon 的未來會如何！

RSocket

RSocket 是一種二進位協定，可讓微服務之間的訊息交換變得輕而易舉。它將反應式串流概念物化於網路上，支援線路上的背壓。我喜歡 RSocket。當然，Spring Framework 和 Spring Boot 本身已內建了對它的新支援，並且還有 Spring Security 支援和 Spring Batch 支援。

RSocket 是我們與阿里巴巴、Facebook 和 Lightbend 一起集體捐贈給新興的 Reactive Foundation 的第一個專案。它現在比 HTTP 2 或 gRPC 更好，光是這一點就足以激起您的好奇心，但我同樣對未來感到興奮。最令人興奮的前景之一是 Spring 團隊和其他人正在開發的新 RSocket Broker。這個 Broker 可能會免除對諸如 Netflix Eureka 之類的服務註冊中心和諸如 RabbitMQ 之類的訊息匯流排的部分使用案例。RSocket JVM 客戶端使用 Reactor，這賦予它超能力：輕鬆重試、錯誤處理、背壓等。

像 Facebook 和阿里巴巴這樣的組織已經在大規模使用它，而 Spring 使它比以往任何時候都更容易。我迫不及待想看看人們在未來幾週、幾個月和幾年內用 RSocket 構建什麼。

Java 和 Kotlin

我最近非常興奮的另一件事是在最新版本的 Spring 中與最新版本的 Java 和 Kotlin 的深度整合。Spring Boot 每六個月發布一次版本，與 Java 的發布節奏完美契合。將 Spring Boot 與 Java 15 一起使用簡直是夢想。我做了一個關於 Java 14 的影片，其中介紹了該版本中的大量新功能，包括大量的預覽功能。但您甚至不需要查看所有這些內容。只需看看 Java 15 中開箱即用的東西！多行文字字串和 var 本身就使生活變得更加輕鬆。新版本的 Java 非常出色，更不用說最近幾代產品中所有底層的東西，這些東西使 Java 更快、更強大、更適合容器、更安全等等。

我正在使用其中一款新式的 Apple Silicon M1 MacBook Pro，並且正在使用 Microsoft OpenJDK 移植支援 ARM 晶片。它非常快。我的大多數應用程式在大約 0.8 秒內啟動！請記住，這些晶片是在幾個月前才發布的！Microsoft/Azul Systems 已經推出了可用的 OpenJDK 移植版本的想法證明了生態系統的活力。Java 是一個夢幻般技術的名稱，也是一個更加夢幻般的社群的名稱，我熱愛 Java。

Kotlin 今年對我來說是另一個亮點。我今年早些時候成為了 Kotlin Google Developer Expert，所以我可能帶有偏見。Kotlin 有 coroutine 這個概念。Kotlin 中的 coroutine 是一個語言關鍵字，它允許您將一段特定的程式碼標記為執行非同步操作，運行時可以重新安排其執行緒。它非常容易。Spring 基於這種機制構建，通過 coroutine 整合了反應式程式設計。因此，您可以在這裡獲得兩全其美：簡單、命令式的程式設計風格，受益於反應式程式碼的非阻塞特性。在 Spring 支援反應式 API 的任何地方，Spring 和 Kotlin 現在都支援 coroutine。

展望未來的一年

我的朋友們，我希望您相信 2020 年所代表的機會。我期待在未來的一年與大家交談。誰知道呢，如果科學和物流允許的話，我們甚至可能會見面。（向醫生們致敬！）這將會是有趣的一年。我希望大家都好好照顧自己，保持社交距離，戴口罩等等，我相信我可以代表整個 Spring 團隊祝您和您的家人新年快樂！