經過 一年多的努力、多個里程碑以及根據大量回饋進行的微調後，我很榮幸地宣布 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 操作其流程，並選擇一個 Scheduler 在其上執行。或者，如果使用者正在組合多個 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> fluent 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 社群的回饋，因為它在概念上源自相同的 smith 和 forge：Reactive Streams Commons。

接下來是什麼？

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

在優先順序上，我們將處理

• 新的測試支援：Reactor 3 計劃包含測試支援，但是最初的回饋提出了一些使用者體驗問題。我們現在正在努力交付缺少的這一部分。同時，使用者可以輕鬆複製我們測試中的隔離 TestSubscriber 以滿足他們的需求。

• 指南：雖然 Reactor 3 越來越受歡迎，但我們仍然在內部或外部進行大量人際互動，與具有 Rx 知識的進階使用者以及 快速教學（由 Sebastien Deleuze 貢獻）合作。您將在本篇文章末尾找到更多資源，但我們已經開始建立一些端對端場景，我們發現這些場景具體、有價值，並且將有助於塑造官方參考 Reactor 指南。

Reactor IPC

IPC 代表跨行程通訊，而 Reactor IPC 是一項正在進行的倡議，旨在回答「如何在 Reactive Streams 模式下遠離 JVM」的問題。我們正在使用 Reactor Kafka、Reactor Aeron 和 Reactor Netty 開發一組初始實作。事實上，目前正在進行許多工作，包括合約重新設計和 Reactor Kafka/Netty 工作，這些工作支援 Spring 反應式故事中的一部分。IPC umbrella 的目的不是建立新的 Web 或訊息傳遞框架，而是應用程式或程式庫可以基於其建構的反應式驅動程式。它們將給定的執行階段輸入/輸出轉換為 Flux 和 Mono 或 Subscriber，將反應式背壓傳播到 IO 訪問層。預計在未來幾個月內會有很多關於這些倡議的新聞。

致謝

讓我們花一些時間感謝此版本背後的人們。David Karnok 是新 Reactor 引擎的主要架構師，並領導 Reactive Streams Commons 研究工作。Spring、Eclipse STS 和 CloudFoundry Client 團隊在貢獻設計改進和回饋方面也發揮了重要作用。除了 Pivotal 之外，MuleSoft 在最新開發方面也提供了巨大的幫助和積極性。

RxJava 1 將主流 Reactive 帶到了 JVM，其完整的功能性 Rx 代數已成為工業標準，我們與之保持一致。它啟發了我們透過 Reactive Streams 實作的革命性規範，並將 JVM 的主要參與者聚集在一起，例如 Netflix、Oracle、Pivotal、Typesafe、Red Hat 等等。

資源

• Reactor 3 總覽
• 實作練習
• 理解反應式類型
• Reactor + Spring 5
• Reactor + Spring Cloud Stream
• Dave Syer 反應式系列 第一部分、第二部分 和 第三部分
• 實作案例：CloudFoundry Java Client
• 公共網站
• Github Org

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

總之，Spring 和 Reactor 讚揚我們的社群（也就是您）提供的巨大支持、鼓勵和回饋。多年來我們建立的回饋迴路不僅僅是一個很好的務實合作，更是我們所有人逐步轉型產業所需要的。