近年來，響應(yīng)式編程在開發(fā)者社區(qū)和客戶中很受歡迎，由于其以聲明的方式構(gòu)建應(yīng)用程序的能力，而不是強(qiáng)制，形成更加敏感和有彈性的應(yīng)用。Spring 5 將反應(yīng)系統(tǒng)納入其核心框架的事實(shí)已經(jīng)顯示出向聲明式編程的范式轉(zhuǎn)變。

響應(yīng)式編程管理數(shù)據(jù)生產(chǎn)者和消費(fèi)者之間的異步數(shù)據(jù)流，它們需要以流暢的方式對(duì)數(shù)據(jù)進(jìn)行響應(yīng)。所以，響應(yīng)式編程都是異步和事件驅(qū)動(dòng)的流暢應(yīng)用程序，需要少量的線程進(jìn)行縮放。

響應(yīng)式編程很難構(gòu)建基于線程的架構(gòu)，由于在基于共享可變狀態(tài)、線程和鎖的應(yīng)用程序擴(kuò)展過程中涉及到高度復(fù)雜性。

在響應(yīng)式編程的上下文中，“在流中有數(shù)據(jù)時(shí)，所有事物都是流并以流暢方式行為?！?nbsp;

為什么是響應(yīng)式編程

高層次的抽象與響應(yīng)式編程導(dǎo)致了代碼可讀性的提高，因此開發(fā)人員可以主要關(guān)注定義業(yè)務(wù)邏輯的事件的相互依存性。

在高度并發(fā)的環(huán)境中，響應(yīng)模式自然地適合于消息處理，這是一個(gè)常見的企業(yè)用例。

由于執(zhí)行反壓力的特性，響應(yīng)式方法最適合控制生產(chǎn)者和消費(fèi)者之間的流量，這將有助于避免內(nèi)存不足。

對(duì)于一個(gè)或幾個(gè)線程，IO綁定任務(wù)可以通過異步和非阻塞方式執(zhí)行，而且不阻塞當(dāng)前線程。

在高交互和實(shí)時(shí)應(yīng)用程序或任何操作/事件時(shí)，都可能觸發(fā)多個(gè)連接子系統(tǒng)的通知，在這種情況下響應(yīng)式編程可以更有效的進(jìn)行管理。

 用于響應(yīng)式編程實(shí)現(xiàn)的理想案例

1. 大量的交易處理服務(wù)，如銀行部門。
2. 大型在線購物應(yīng)用程序的通知服務(wù)，如亞馬遜。
3. 股票價(jià)格同時(shí)變動(dòng)的股票交易業(yè)務(wù)。

響應(yīng)流 (Reactive Streams)

“響應(yīng)流”定義一個(gè) API 規(guī)范，其中包含一組最小的接口，這些接口公開了定義非阻塞反壓力的數(shù)據(jù)流的操作和實(shí)體的方法。

隨著反壓力的引入，響應(yīng)流允許用戶控制來自出版商的數(shù)據(jù)交換速率。

響應(yīng)流 API java.util.concurrent.flow 已正式成為 java 9 的一部分。

響應(yīng)流主要用作互操作層。

 Spring 5 提供的響應(yīng)式編程

Spring-Web-Reactive 模塊和 Spring MVC 都支持相同的 @Controller 編程，但 Spring-Web-Reactive 是在 Reactive 和非阻塞引擎上執(zhí)行的。

遵循這個(gè)文檔，見：
http://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/html/web-reactive.html

Spring-Web-Reactive 模塊和 Spring MVC 共享許多通用的算法，但 Spring-Web-Reactive 模塊已經(jīng)重新定義了許多 Spring MVC 契約，例如 HandlerMapping和HandlerAdapter，以使它們變得異步和非阻塞，以及啟用響應(yīng)式 HTTP 請(qǐng)求和響應(yīng)（以 RouterFunction 和 HandlerFunction 的形式）。

除了現(xiàn)有的 RestTemplate 外，新的響應(yīng)式 WebClient 也在 Spring 5 中引入。

支持響應(yīng)式編程的 HTTP 客戶端（例如 Reactor、Netty、Undertow）已經(jīng)采用了一系列響應(yīng)式的 ClientHttpRequest 和 ClientHttpResponse 抽象，它們將請(qǐng)求和響應(yīng)體作為 Flux <DataBuffer> 公開，并且在讀寫端提供全面的背壓支持。

Spring 5 Framework 引入了 Reactor，作為 Reactive Streams 規(guī)范的實(shí)現(xiàn)。

Reactor 是用于在 JVM 上構(gòu)建非阻塞應(yīng)用程序的下一代 Reactive 庫。

Reactor 擴(kuò)展了基本的 Reactive Streams Publisher 契約，并定義了 Flux 和 Mono API 類型，分別為 0..N 和 0..1 的數(shù)據(jù)序列提供聲明性操作。

Spring Web Reactive 使用 Servlet 3.1 提供了非阻塞 I/O，并運(yùn)行在 Servlet 3.1 容器上。

Spring WebFlux 提供了兩種編程模型可供選擇。

1. 注解式控制器：這些與 Spring MVC 相同，在使用一些 Spring-Web 模塊提供的附加注解的情況下。Spring MVC 和 WebFlux 控制器都支持 Reactive 返回類型。另外，WebFlux 還支持 Reactive @RequestBody 參數(shù)。
2. 函數(shù)式編程模型：基于 lambda 的輕量級(jí)小型庫，用于給出路由和處理請(qǐng)求的實(shí)用程序。

 Spring Web Reactive vs. Spring Web MVC

Spring 5 包含了 Spring Web Reactive（在 spring-web-reactive 模塊下）和 Spring Web MVC（在 spring-webmvc 模塊下）。

雖然 Spring Web Reactive 和 Spring Web MVC 模塊共享了很多算法，但是由于 Spring Web Reactive 能夠在響應(yīng)式的非阻塞 Reactive Streams HTTP 適配器層上運(yùn)行，因此它們之間不共享代碼。

Spring MVC 執(zhí)行需要 Servlet 容器，而 Spring Web Reactive 也可以在非 Servlet 運(yùn)行時(shí)上運(yùn)行，比如在 Netty 和 Undertow 上運(yùn)行。

如果對(duì)具有輕量級(jí)、函數(shù)式的 Web 框架的非阻塞 Web 棧的必要要求，并與 Java 8 lambda 或 Kotlin一起使用，則應(yīng)該考慮從 Spring MVC 應(yīng)用程序切換到 Spring Web Reactive。

響應(yīng)式編程的基本結(jié)構(gòu)

這是一個(gè) 2.0.0 M5 版本的  pom.xml ，依賴于 WebFiux。

<parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.0.0.M5</version>
</parent>
<dependencies>   
 <dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-webflux</artifactId>        </dependency>
</dependencies>

傳統(tǒng)方法 VS. 響應(yīng)方法

在傳統(tǒng)方法中，執(zhí)行將被阻塞，并將一直等到您的服務(wù)執(zhí)行完成為止。在下面的代碼中，在第一個(gè) print 語句之后，程序執(zhí)行將被阻塞并等待服務(wù)執(zhí)行完成。在服務(wù)執(zhí)行完成后，將恢復(fù)程序執(zhí)行，并執(zhí)行第二個(gè) print 語句。

@GetMapping("/traditional")
public List < Product > getAllProducts() {
 System.out.println("Traditional way started");
 List < Product > products = prodService.getProducts("traditional");
 System.out.println("Traditional way completed");
 return products;
}

在響應(yīng)方法中，程序執(zhí)行將繼續(xù)，而不用等待服務(wù)執(zhí)行的完成。在下面的代碼中，在第一個(gè) print 語句之后，第二個(gè) print 語句將以非阻塞的方式執(zhí)行，而無需等待服務(wù)執(zhí)行的完成。Flux stream 將隨著產(chǎn)品數(shù)據(jù)的可用性而被填充。

@GetMapping(value = "/reactive", .TEXT_EVENT_STREAM_VALUE)
public Flux < Product > getAll() {
 System.out.println("Reactive way using Flux started");
 Flux < Product > fluxProducts = prodService.getProductsStream("Flux");
 System.out.println("Reactive way using Flux completed");
 return fluxProducts;
}

Reactive Web Client

除了現(xiàn)有的 RestTemplate 之外，Spring 5 還引入了 Reactive WebClient。

ClientHttpRequest 和 ClientHttpResponse 抽象將請(qǐng)求和響應(yīng)主體使用 Flux <DataBuffer> 公開，并在讀和寫端提供完全背壓支持。

來自 Spring Core 的編碼器和解碼器抽象也用在客戶端，用于將字節(jié)序的 Flus 序列化或發(fā)序列化成類型對(duì)象。

下面是一個(gè) Reactive WebClient 的示例，它調(diào)用終端并接收及處理 Reactive Stream Flux 對(duì)象。

@GetMapping("/accounts/{id}/alerts")
public Flux < Alert > getAccountAlerts(@PathVariable Long id) {
 WebClient webClient = new WebClient(new ReactorClientHttpConnector());
 return this.repository.getAccount(id).flatMap(account -> webClient.perform(get("/alerts/{key}", account.getKey())).extract(bodyStream(Alert.class)));
}

Spring 5 的局限

1. 對(duì) Reactive 應(yīng)用程序進(jìn)行故障診斷有點(diǎn)困難，并且你有可能在解決問題的同時(shí)，意外地阻塞了已經(jīng)引入的代碼。
2. 大多數(shù)傳統(tǒng)的基于 Java 的集成庫仍然是阻塞的。
3. 可用于 Reactive 數(shù)據(jù)存儲(chǔ)的選項(xiàng)是非常有限的，少數(shù) NoSQL 數(shù)據(jù)庫（如 MongoDB）除外。
4. Spring Security 仍然不被支持。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論