精講響應式webclient第1篇-響應式非阻塞IO與基礎用法

筆者在以前已經寫了一系列的關於RestTemplate的文章，以下：

• 精講RestTemplate第1篇-在Spring或非Spring環境下如何使用
• 精講RestTemplate第2篇-多種底層HTTP客戶端類庫的切換
• 精講RestTemplate第3篇-GET請求使用方法詳解
• 精講RestTemplate第4篇-POST請求方法使用詳解
• 精講RestTemplate第5篇-DELETE、PUT等請求方法使用詳解
• 精講RestTemplate第6篇-文件上傳下載與大文件流式下載
• 精講RestTemplate第7篇-自定義請求失敗異常處理
• 精講RestTemplate第8篇-請求失敗自動重試機制
• 精講RestTemplate第9篇-如何經過HTTP Basic Auth認證
• 精講RestTemplate第10篇-使用代理做爲跳板發送請求

RestTemplate做爲spring-web項目的一部分，在Spring 3.0版本開始被引入。根據Spring官方文檔及源碼中的介紹，RestTemplate在未來的版本中它可能會被棄用， 做爲替代，Spring官方已在Spring 5中引入了WebClient做爲非阻塞式Reactive HTTP客戶端。

1、什麼是響應式非阻塞IO

在開始爲你們介紹webClient以前有必要爲你們介紹一下響應式非阻塞IO與傳統IO以前的區別。咱們先留下一個問題：webClient發送與接收單個HTTP請求比RestTemplate更快麼？答案是否認的。 看到這裏有的同窗已經蒙了，既然webClient沒有更快，那官方爲何還推薦使用它？聽我往下講。

1.1.傳統阻塞式IO模型

筆者用相對通俗的話爲你們說明一下阻塞IO與非阻塞IO之間的區別。咱們以軟件開發團隊的工做方式來作一個比喻。做爲軟件開發人員，咱們確定知道軟件開發的基本流程：

• 項目立項與可行性研究
• 需求分析與設計
• 代碼開發
• 迭代測試
• 上線及配置管理、運維

在以Spring MVC或者struct爲表明的框架都是基於sevlet的，其底層IO模型是阻塞IO模型。這種模型就好像你是公司的一個開發人員，上面的全部的5項工做全都由你一我的完成。若是公司有10我的，最多就只能同時進行10個需求。客戶需求增多了也沒有辦法，只能讓他們等着。以下圖：一個請求佔用一個線程，當線程池內的線程都被佔用後新來的請求就只能等待。

1.2.響應式IO模型

spring 社區爲了解決Spring MVC的阻塞模型在高併發場景下的性能瓶頸的問題，推出了Spring WebFlux，WebFlux底層實現是久經考驗的netty非阻塞IO通訊框架。該框架的請求處理與線程交互關係圖以下：

boosGroup用於Accetpt鏈接創建事件並分發請求， workerGroup用於處理I/O讀寫事件。netty我就不細說了，仍是用通俗的方式給你們講一下：若是通俗的將上圖中的各個任務池、線程池的組合比作一個軟件開發公司，那麼:

• 項目立項及可研，由公司項目經理及顧問來完成
• 需求分析與設計，由產品經理和架構師來完成
• 代碼研發，由項目經理帶領開發人員來完成
• 迭代測試，由測試團隊來完成
• 上線及配置管理、運維，可能由專門的devops團隊來完成

這樣一個公司內的全部人完成分工，就能在有限的資源的狀況下,去接觸更多的客戶，談更多的需求，合理的分配人力資源，達到併發處理能力最大化的極限水平。相比於一個員工從頭到位的負責一個項目，它的組織性更強，分工更明確，合理的利用空閒資源，專業的人最專業的事。
這種人力資源的合理利用及組織方式和非阻塞IO模型有殊途同歸之處，經過合理的將請求處理線程及任務進行分類，合理的利用系統的內存、CPU資源，達到單位時間內處理能力的最大化就是異步非阻塞IO的核心用意！ 回到上文給你們留下的問題，webClient處理單個HTTP請求的響應時長並不比RestTemplate更快，可是它處理併發的能力更強。因此響應式非阻塞IO模型的核心意義在於：提升了單位時間內有限資源下的服務請求的併發處理能力，而不是縮短了單個服務請求的響應時長。

2、WebClient 的優點

上文爲你們介紹完IO模型以後，我想你們已經能夠明白了。與RestTemplate相比，WebClient優點以下：

• 非阻塞響應式IO，單位時間內有限資源下支持更高的併發量
• 支持使用Java 8 lambda表達式函數
• 同時支持同步、異步與Streaming流式傳輸場景

3、項目引入WebClient

使用WebClient須要引入以下的Jar（能夠在包含spring-boot-starter-web的Spring Boot項目中引入）

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

那麼問題又來了，熟悉Spring 開發的朋友應該都知道。spring-boot-starter-webflux和spring-boot-starter-web表明的是兩套技術棧

• spring-boot-starter-web能夠實現目前比較成熟的基於servlet技術棧的Spring Boot應用
• spring-boot-starter-webflux能夠實現的是底層基於netty的響應式編程的技術棧的Spring Boot應用

兩者能夠共存麼？答案是：

• 做爲服務端實現Spring Boot應用而言，兩者在應用角度固然是不能共存的。截止20200820我寫稿的時間，若是在一個項目裏面將兩者都引入了，開發服務端應用其實使用的仍是spring-boot-starter-web的基於servlet的技術棧。
• 做爲HTTP客戶端而言，若是咱們只是要使用WebClient。不管怎樣，引入spring-boot-starter-webflux就對了。

4、WebClient 實例建立與基礎用法

建立WebClient有以下三種方式，咱們來一一爲你們介紹。

• WebClient.create()
• WebClient.create(String baseUrl)：指定了baseUrl，使用該客戶端發送請求都基於baseUrl
• WebClient.builder()返回一個WebClient.Builder，該對象能夠作鏈式調用，傳遞更多的參數。

爲了方便後續開發測試，首先介紹一個網站給你們。JSONPlaceholder是一個提供免費的在線REST API的網站，咱們在開發時可使用它提供的url地址測試下網絡請求以及請求參數。或者當咱們程序須要獲取一些模擬數據、模擬圖片時也可使用它。

4.1. WebClient.create()

建立WebClient發送GET請求，接收String類型單個Mono對象（Mono英文：單聲道、單體）。

public class SimpleTest {

  @Test
  void testSimple()  {
    WebClient webClient = WebClient.create();

    Mono<String> mono = webClient
            .get() // 發送GET 請求
            .uri("http://jsonplaceholder.typicode.com/posts/1")  // 請求路徑
            .retrieve()    // 獲取響應結果
            .bodyToMono(String.class); //響應數據類型轉換

    System.out.println("=====" + mono.block());  
  }
}

mono.block()方法仍然是阻塞式的數據響應接收方式，響應式的編程方法咱們後面文章會爲你們介紹。

4.2.WebClient.create(String baseUrl)

上面使用create()無參方法，在指定請求uri時每次都要指定完整的HTTP服務路徑，如"http://jsonplaceholder.typicode.com/posts/1"。使用WebClient.create(String baseUrl)能夠統一指定一個baseUrl，這樣請求指定請求uri時，能夠省略baseUrl部分，如"/posts/1"。

private WebClient webClient = WebClient.create("http://jsonplaceholder.typicode.com");

@Test
void testBaseUrl(){

  Mono<String> mono = webClient
          .get()
          .uri("/posts/1")  // 請求路徑,注意省略了baseurl部分
          .retrieve()
          .bodyToMono(String.class);

  System.out.println("=====" + mono.block());
}

上面代碼請求結果，和4.1結果是同樣的

4.3.WebClient.builder()

使用builder()建立WebClient對象，能夠一次性傳遞的參數內容就更加豐富了。cookies、headers等信息均可以使用builder來傳遞。
場景：好比你請求的服務端使用JWT token，每次請求都須要傳遞token。若是每次請求都單獨去建立一個WebClient，而後指定Token，那就麻煩了。咱們可使用builder在WebClient實例化的時候，統一設置Token。

private WebClient webClient = WebClient
        .builder()
        .defaultHeader("JWT-Token", "xxxyyy3fsfsfsff-fjdskfa")
        .build();

支持的可選配置以下：

• uriBuilderFactory: 自定義UriBuilderFactory靈活配置使用Url
• defaultHeader: 爲HTTP請求設置Headers請求頭
• defaultCookie: 爲HTTP請求設置Cookies
• defaultRequest: 自定義Http Request
• filter: 爲HTTP請求增長客戶端過濾器
• exchangeStrategies: HTTP 讀寫信息自定義
• clientConnector: HTTP客戶端鏈接器設置

歡迎關注個人博客，裏面有不少精品合集

• 本文轉載註明出處（必須帶鏈接，不能只轉文字）：字母哥博客。

以爲對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創做動力！ 。另外，筆者最近一段時間輸出了以下的精品內容，期待您的關注。

• 《手摸手教你學Spring Boot2.0》
• 《Spring Security-JWT-OAuth2一本通》
• 《實戰先後端分離RBAC權限管理系統》
• 《實戰SpringCloud微服務從青銅到王者》
• 《VUE深刻淺出系列》