我謹代表 Reactor 團隊，很高興宣布 Reactor 最新的里程碑版本，Californium-M1 ? ?

團隊一直忙於開發 Californium，這是 Reactor 3 的第三個主要版本。我們現在已準備好接收您對一些特定問題的回饋，並且我們也準備了許多增強功能和錯誤修復供您使用。

Californium-M1 BOM

在其第三個發行版本列車中，我們繼續沿用元素週期表上按字母順序遞增的名稱主題。鉲 (Californium) 是一種最初在加州合成的元素。

此里程碑版本的 BOM 包含

• reactor-core 3.2.0.M3
• reactor-extra 3.2.0.M1 (包含一些 API 對齊變更)
• reactor-netty 0.8.0.M1

今年稍早 (M1)，reactor-core 有一個早期預覽版本，僅專注於「錯誤模式繼續」功能，而 core 也在六月發布了列車外的里程碑版本 (M2)。這篇部落格文章涵蓋了後者的變更，以及全新的 M3 中的變更。

Reactor Netty 0.8.0.M1

這裡的重點是 reactor-netty。敬請期待更完整的部落格文章，詳細說明 API 變更和新功能背後的理由，其中包括

API 全面改版

團隊對 API 進行了大規模的全面改版，在建構用戶端和伺服器時更具指導性，避免了在 0.7.x 版本系列中太容易發生的難以原諒的組態錯誤。

新的 API 也更清楚地概述了生命週期。

HTTP2 支援

是的，HTTP2 支援 ? 目前主要是透明地升級到 HTTP2，但我們正在努力在不久的將來將 HTTP2 個別串流新增為一級公民。

Reactor Core 3.2.0

總之，與之前的 Bismuth 版本相比，M2 和 M3 總共帶來了超過 70 個變更。

與 reactor-netty 相比，reactor-core 中的 API 變更較少，而更新考量主要在於里程碑版本之間的差異。有關更多詳細資訊，請參閱 M2 和 M3 的「更新考量」章節。

我們最需要您針對以下功能提供回饋

指標

已新增 Micrometer 和 .metrics() 支援 (#1183、#1123)。新的 .metrics() 運算子只有在類別路徑上有 Micrometer 時才會執行某些動作。

它會記錄 onNext 時序、訂閱到完成時序、訊號計數以及其他指標 — 所有這些都是從直接上游運算子產生的訊號角度來看。

它是在 M2 中引入的，但在 M3 中進行了改進，並且在某些標籤名稱中進行了 (重大) 變更 (#1245)。

請注意，一個重要的目標是避免在公用 Reactor API 中公開 Micrometer 的內容。我們不希望強制依賴 Micrometer，並且我們努力將其使用限制在內部類別中，只有在我們偵測到類別路徑上有 Micrometer 時才會載入這些類別。

接下來：在 GA 之前，也應該為 Schedulers (或者更確切地說是支援某些 Schedulers 的 ExecutorServices) 提供基本檢測支援。我們也在研究一種為 Reactor 全域選擇特定 MeterRegistry 的方法，同樣不會公開參考 MeterRegistry 介面的公用 API。

進階重試

我們新增了 retryWhen 的預先組態替代方案，具有指數退避和抖動 (retryBackoff()。請參閱 #1122)。

此版本的重試反映了我們認為業界在重試方面的最佳實務。它是過於簡單的 retry(n)、複雜的 retryWhen(Function) 和來自 reactor-addons 的更可組態的 RetryFunction 之間的良好中間地帶。

以資源為基礎的反應式關閉

為了協助您建構反應式交易區塊，我們新增了 usingWhen。與 using 類似，它會包裝資源，從中產生 Flux，並確保在 Flux 終止時正確清理資源。

主要差異在於

• 資源是透過 Publisher 異步提供的。
• 清理也是異步的 (Function<Resource, Publisher>)，並且只延遲終止訊號的傳播，而不是 onNext 訊號。
• 運算子可以針對完成、錯誤和取消終止具有個別的異步「清理」。

這是在 M2 中引入的，但在 M3 中進行了輕微變更，以修正 Context 傳播並支援取消 Publisher<Resource>。透過在甚至發出 Resource 之前取消此運算子傳回的主要 Flux<T>，您的取消指示會傳播到 Publisher<Resource>。

onDiscard Hook

這個全域 Hook 採用 Consumer<Object> 的形式，旨在作為進階使用者處理需要特殊清理的堆外物件的最後一個遺失部分。

通常，Netty 的 ByteBuf 或 Spring 5 的 DataBuffer 屬於此類別：它們是集區化的、堆外的，並且在不再使用時需要呼叫 release()，否則會發生記憶體洩漏。

在三種廣泛的情況下，此類元素可能會在反應式序列的裂縫之間掉落，並且永遠不會到達使用者程式碼

1. 運算子的來源格式錯誤，並且不遵守 RS 規格 (例如，在發出 onComplete 訊號之後，它會發出 ByteBuf)。
2. 運算子會篩選某些元素作為其語意的一部分 (例如 filter)。
3. 運算子會為了背壓最佳化目的而預先提取，並且會被取消，從而捨棄其預先提取佇列。

案例 (1) 已由 onNextDropped Hook 涵蓋，但案例 (3) 絕對沒有。案例 (2) (篩選語意) 有點介於中間，有可能在篩選 Predicate 內部進行清理，例如。但這很麻煩且容易被遺忘。

因此，我們在 Hooks 的列表中新增了 onDiscard，以涵蓋 (2) 和 (3)。請注意，與「錯誤時繼續」功能不同，目前沒有公用 API 可在特定 Flux 執行個體上設定 Hook。有一個使用 Context 的不受支援的變通方法，而且官方 API 很可能會在 GA 或稍後的維護版本中出現。

onDiscard Hook 具有以下特性和需求

• 它是累加的，這表示呼叫 Hooks.onDiscard(Consumer) 兩次將使用 Consumer#andThen 合併兩個消費者。
• 它不是鍵控的，這表示雖然多次呼叫是累加的，但它只能完全重設 (而不是以每個 Consumer 為基礎)。
• Consumer 必須在轉換之前執行 instanceof 檢查，因為它將與不同類型的物件一起使用。
• Consumer 不得擲回例外，並且應包含必要的 try catch 區塊。
• Consumer 必須是等冪的，因為它可能會在同一個執行個體上多次調用 (例如，在緩衝區重疊的情況下)。

在另一方面，errorStrategyContinue() 已在 M3 中重新命名為 onErrorContinue()。

Reactor Extra 3.2.0.M1

最後，reactor-extra 在重試/重複公用程式方面有較小的 API 變更。它與 core 運算子對齊，使用相同的預設值和 Long 而不是 Integer 索引。

下一步

reactor-core 的下一步是重新設計 Processor 物件的公開方式。目前的 FluxProcessor<IN, OUT> 有點臃腫，因為它擴展並公開了整個 Flux API。

此外，FluxProcessor#sink() 和關聯的 FluxSink 太容易被誤用，尤其是在有人尋求將 Processor 訂閱到 Publisher 來源，同時又透過 sink() 手動將資料推送給它時，目前並不真正支援這種情況。sink() 應該呼叫一次，並且應該重複使用傳回的 FluxSink<T> 執行個體這一事實也不夠明確。

因此，我們正在研究 Processor<T, T> 上的一個外觀模式，它直接實作 FluxSink (而不是 Flux)，在兩者都用作訂閱者和接收器時都能運作，並且具有 asFlux() 檢視方法，可以選擇性地在其之上建構 Flux 運算子的鏈。

MonoProcessor 很可能會遵循這些步驟，成為一個 (更簡單的) 介面，而具體實作將重新命名為 MonoNextProcessor。我們也在研究提供 MonoSink 的獨立實作，使用者可以直接操作它，而無需使用 Mono.create()。

結論

酷炫的人不會等待 GA 版本！快去體驗一下這個閃亮的里程碑版本，而且一如既往，歡迎提供回饋。 :)

祝您反應式編碼愉快！