正如 Juergen 在他的 Spring Framework 5 M1 釋出公告中提到的，我們的 Spring 響應式倡議已合併到 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，提供了一種宣告式組合 API，類似於 Java 8 Stream，但更廣泛，更可與 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 容器構建並執行在其上的，但 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，我們在此主題上有一個主題演講和眾多會議。拉斯維加斯見！