正如 Juergen 在他的 Spring Framework 5 M1 發布公告 中提到的，我們的 Spring Reactive 計畫已併入 Spring Framework 本身，保留了一年多的所有貢獻和完整歷史記錄。

它是什麼？

簡而言之，反應式程式設計是關於非阻塞、事件驅動的應用程式，這些應用程式可以使用少量的執行緒進行擴展，並以背壓作為關鍵要素，旨在確保生產者不會壓倒消費者。Reactive Streams 規範（Java 9 也採用）能夠在不同供應商的層和函式庫之間傳達需求。例如，寫入用戶端的 HTTP 連線可以將其寫入可用性一直向上游傳達至從資料庫提取資料的資料儲存庫，以便在 HTTP 用戶端速度較慢的情況下，儲存庫也可以減速甚至暫停。如需反應式程式設計的更廣泛介紹，請查看 Dave Syer 的多部分系列 「反應式程式設計筆記」。

從命令式風格邏輯切換到非阻塞時，一個實際的挑戰是組合非同步邏輯的能力，而不會迷失在「回呼地獄」中。我們需要的 API 類型的良好範例是 Java 8 中的 CompletionStage 和 Stream API。但是，Stream 實際上是為集合而建構的，不太適合無限或延遲敏感的序列，例如我們在非阻塞 I/O 和事件驅動應用程式中經常遇到的情況。Reactor 及其即將推出的 3.0 GA 版本是 Reactive Streams 的實作，它使用 Flux 和 Mono API 類型擴展了 Reactive Streams Publisher，提供類似於 Java 8 Stream 的宣告式組合 API，但更廣泛，更可與 ReactiveX 模式相媲美。如需更多資訊，請查看 Sebastien Deleuze 的 「了解反應式類型」。

盒裝內容有哪些？

Spring Framework 5 採用 Reactive Streams 和 Reactor 用於其自身的反應式用途，以及許多核心 API 中。M1 版本提供了與 JSON (Jackson) 和 XML (JAXB) 之間進行反應式序列化和反序列化、支援 @Controller 程式設計模型的反應式 Web 框架，以及反應式 WebClient。這使得支援微服務、分散/收集、資料擷取等的輸入和輸出串流場景變得容易。

以下是一個控制器，它以完全非阻塞和反應式的方式從遠端伺服器取得和串流資料。

@GetMapping("/accounts/{id}/alerts")
public Flux<Alert> getAccountAlerts(@PathVariable Long id) {

  return this.repository.getAccount(id)
      .flatMap(account ->
          this.webClient
              .perform(get("/alerts/{key}", account.getKey()))
              .extract(bodyStream(Alert.class)));
}

支援此功能的反應式堆疊是什麼？Spring Web Reactive 位於新的 spring-web-reactive 模組中，緊鄰位於 spring-webmvc 模組中的現有（且受歡迎！）Spring Web MVC。這兩個模組共用許多演算法和機制，但實際上無法共用任何程式碼。這是因為 Spring Web Reactive 在 Reactive Streams HTTP 配接器層上執行，該配接器層完全是非阻塞和反應式的，一直到 HTTP 執行階段。因此，雖然 Spring MVC 是為 Servlet 容器而建構並在 Servlet 容器上執行，但 Spring Web Reactive 也可在非 Servlet 執行階段（例如 Netty 和 Undertow）上執行。

Spring Web Reactive 與 Spring Web MVC 的比較

您可能想知道 Spring Framework 團隊如何看待這兩個框架，以及我們建議您使用哪個框架？首先，我們的目標是在合理的範圍內實現最大的可能一致性。@Controller 程式設計模型和反應式方法之間沒有根本上的不相容之處。這一切都取決於底層發生了什麼來支援該模型，因此表面上沒有任何差異，除了完全支援反應式類型，例如 Flux 和 Mono 以及來自 RxJava 的 Observable 和 Single，無論是輸入還是輸出。

Spring Web Reactive 比 Spring MVC 更好嗎？Spring Framework 反應式支援和我們獨特定位的最大價值主張是，我們不會拋棄現有的應用程式。在 Spring 5 中，傳統的 Spring MVC 繼續在任何 Servlet 3.1 堆疊上執行，包括 Java EE 7 伺服器。對於 Spring Web Reactive，我們無條件支援 Tomcat、Jetty、Undertow 和 Netty，並且還可以適應任何 Servlet 3.1 容器。我們計劃繼續 Spring MVC 和 Spring Web Reactive 之間在共享演算法和機制方面的協同作用，以支援頂層相同的程式設計模型。Spring MVC 方面的改進請求或錯誤報告將使 Spring Web Reactive 受益，反之亦然。

這表示您身為開發人員可以選擇更適合您目的的方式。如果有人告訴您同步或阻塞是邪惡的，請別理會。事實並非如此，實際上這是一種權衡。命令式風格的邏輯易於編寫且更易於偵錯。當然，它的擴展性或效率不如反應式，但這就是權衡的所在。在許多情況下，命令式對於手頭的任務來說就足夠了，而在其他情況下，反應式和非阻塞是必須的。在微服務場景中，您甚至可以為每個服務選擇實作風格，所有這些都在相同的統一程式設計模型中。

試試看

如需更多詳細資訊並開始使用，請參閱 Spring Boot 反應式 Web 啟動器 以及參考文件中的新章節。

最後但同樣重要的是，我希望您能加入我們的 SpringOne Platform 2016，我們將在此舉辦關於此主題的主題演講和眾多場次。拉斯維加斯見！