經過 一年多的努力、多個重要里程碑以及基於大量反饋進行的微調，我很高興宣佈 Reactor 3 正式釋出（General Availability）。您可以在 Maven Central 上找到 Reactor Core 3.0.2.RELEASE。

什麼是 Reactor 3？

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

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

所有這些都按照 Reactive Streams 規範定義的行為實現。Reactor 致力於使該規範成為庫作者或 Spring 開發者們的便利工具，提供了在流處理或非同步場景中應用的預製運算子。

Mono 和 Flux

流定義（flow definition）是 Reactor 稱呼的一種鏈式結構，取決於流入已定義流的資料量，它可能是 Flux 或 Mono。這些型別在每個階段都實現了 Reactive Streams 的 Publisher 介面，並且可以泛型地傳遞。那麼為什麼需要 兩種 響應式型別呢？因為數量基數（cardinality）對 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 適用於可能耗時的資料生產者。為了管理重入（reentrance）和執行緒安全，運算子有時必須在執行流中增加一些開銷。儘管如此，效率仍然是核心關注點，我們收到了引擎貢獻者 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 Client 團隊也在設計改進和反饋方面做出了重要貢獻。除了 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 組織

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

最後，Spring 和 Reactor 感謝我們的社群，感謝你們給予的巨大支援、鼓勵和反饋。我們多年來建立的反饋迴圈不僅僅是一種良好的務實協作，更是我們所有人逐步改變這個行業所需要的。