經過一年多的工作、多個里程碑以及基於大量反饋的微調，我很高興地宣佈Reactor 3正式釋出。您可以在Maven Central上找到Reactor Core 3.0.2.RELEASE。

什麼是Reactor 3？

Reactor 3為基於Java 8的應用程式提供了一個強大高效的響應式程式設計模型。該模型建立在Reactor 2和RxJava 1的經驗之上，並引入了一種流暢的方式來組合非同步且支援背壓的事件處理。Spring Framework 5使用Reactor 3來構建並最終展現一個完整的響應式故事。

其設計依賴於可擴充套件的執行模型，該模型傾向於事件處理的共存。通常，Reactor 僅在明確要求時才在事件流階段之間跳轉執行緒。例如，記憶體操作（如列表訪問或負載轉換）通常不需要執行緒邊界。如果操作生產者或接收者可能耗時，使用者應使用 Flux#publishOn / Mono#publishOn 或 Flux#subscribeOn / Mono#subscribeOn 來操作其流，並選擇一個 排程器 來執行。或者，如果使用者組合了多個 Publisher 的結果，例如使用 merge 或 concat，Reactor 將以執行緒安全的方式隱式處理各種潛在的執行緒邊界。實際上，由 Publisher 託管的流階段可能至少由一個生產執行緒和一個接收執行緒遍歷。

所有這些都按照 Reactive Streams 規範 定義的行為實現。Reactor 致力於透過預製的運算子，將該規範變為庫編寫者或 Spring 開發人員的日常工具，您可以在流式和/或非同步場景中應用這些運算子。

Mono 和 Flux

流定義是 Reactor 根據流入定義流的容量稱之為 Flux 或 Mono 的鏈。這些型別在每個階段都實現了 Reactive Streams Publisher，並且可以通用地傳遞。那麼為什麼需要兩種響應式型別呢？因為基數對 Reactor 很重要。Flux 將觀察 0 到 N 個專案，並最終成功或失敗終止。Mono 將觀察 0 或 1 個專案，其中 Mono<Void> 最多提示 0 個專案。

讓我們看看以下阻塞 API

interface BlockingUserRepository {
     User get(String id);
     List<User> findAll();
     void save(User data) throws RepositoryException;
     List<User> findAllByUsernameLike(String s);
}

使用普通的 Reactive Streams Publisher，我們將得到以下契約

interface ReactiveUserRepository {
     Publisher<User> get(String id);
     Publisher<User> findAll();
     Publisher<Void> save(Publisher<? extends User> source);
     Publisher<User> findAllByUsernameLike(String s);
}

但使用 Reactor，我們可以保留預期的基數語義證據

interface ReactorUserRepository {
     Mono<User> get(String id);
     Flux<User> findAll();
     Mono<Void> save(Publisher<? extends User> source);
     Flux<User> findAllByUsernameLike(String s);
}

由於 Mono 和 Flux 都實現了 Publisher，我們可以輕鬆地將它們的任何引用作為響應式資料來源傳遞，同時使用 Mono<Void> 流式 API 返回明確的語義

// ReactorUserRepository userRepository;

userRepository.save(Mono.fromCallable(() -> new User("thomas")))
              .doOnSuccess(res -> success())
              .subscribe();

userRepository.save(Flux.just(new User("bob"), new User("robert")))
              .doOnSuccess(res -> success())
              .subscribe();

請記住，Flux 和 Mono 是為可能耗時的資料生產者而設計的。為了管理重入和執行緒安全，運算子有時必須在執行流中增加一些開銷。儘管如此，效率仍然是核心關注點，我們定期收到引擎貢獻者 David Karnok 的報告。Reactor 3 目前是 JVM 上 最高效 的響應式庫之一。除了這些直接相關的基準測試，我們現在也受益於 RxJava 2 社群的反饋，因為它在概念上源自同一個鐵匠鋪：Reactive Streams Commons。

接下來是什麼？

我們正在為接下來的幾周開發 3.0.3，並與 Spring 5、CloudFoundry 的最新需求以及 Reactive Streams Commons 的最新研究保持同步。

我們將優先解決以下問題：

• 新的測試支援：Reactor 3 原本計劃提供測試支援，但最初的反饋提出了一些使用者體驗問題。我們現在正在努力提供這缺失的一部分。與此同時，使用者可以輕鬆地複製我們測試中隔離的 TestSubscriber 以滿足自己的需求。

• 指南：雖然 Reactor 3 越來越受歡迎，但我們仍然需要大量的內部或外部人工互動，熟練掌握 Rx 知識的使用者以及 快速教程，該教程由 Sebastien Deleuze 貢獻。您將在本文末尾找到更多資源，但我們已經開始建立一些我們認為具體、有價值的端到端場景，這些場景將有助於塑造官方的 Reactor 參考指南。

Reactor IPC

IPC 代表程序間通訊（Inter-Process Communication），Reactor IPC 是一項持續進行的倡議，旨在回答“如何以 Reactive Streams 方式脫離 JVM”的問題。我們正在透過 Reactor Kafka、Reactor Aeron 和 Reactor Netty 進行初步的實現。事實上，目前正在進行大量工作，包括契約重新設計以及 Reactor Kafka/Netty 的工作，它們支援一些新的 Spring 響應式敘事。IPC 傘專案的目的是不建立新的 Web 或訊息傳遞框架，而是建立響應式驅動程式應用程式或庫，這些應用程式或庫可以基於此構建。它們將給定的執行時輸入/輸出轉換為 Flux 和 Mono 或 Subscriber，將響應式背壓傳播到 IO 訪問層。預計未來幾個月將有大量關於這些倡議的訊息。

致謝

讓我們花點時間感謝此次釋出背後的人們。David Karnok 是新 Reactor 引擎的主要架構師，並領導 Reactive Streams Commons 的研究工作。Spring、Eclipse STS 和 CloudFoundry 客戶端團隊在貢獻設計改進和反饋方面發揮了關鍵作用。除了 Pivotal，MuleSoft 在最新開發方面也提供了巨大的幫助和積極主動的支援。

RxJava 1 將主流響應式程式設計引入 JVM，其完整的函式式 Rx 代數已成為我們所遵循的行業標準。它啟發了我們透過 Reactive Streams 實現的顛覆性規範，並彙集了 Netflix、Oracle、Pivotal、Typesafe、Red Hat 等 JVM 關鍵參與者。

資源

• Reactor 3 概述
• 動手實踐
• 理解響應式型別
• Reactor + Spring 5
• Reactor + Spring Cloud Stream
• Dave Syer 響應式系列 第一部分、第二部分 和 第三部分
• 實現者用例：CloudFoundry Java 客戶端
• 公共網站
• Github 組織

敬請期待更多響應式故事！Pivotal 的 Reactor 之旅才剛剛開始，經過過去幾年大量的努力和研究，我們很高興能提供一種全新的體驗。我們的價值主張與 Spring OSS 直接相關，我們有一個獨特的機會，可以在所有 Spring 產品組合中以端到端的方式提供響應式管道。

最後，Spring 和 Reactor 讚揚我們的社群，即你們，給予的巨大支援、鼓勵和反饋。我們多年來建立的反饋迴圈不僅僅是一種很好的務實合作，它更是我們所有人逐步改變行業所需要的東西。