為了詳細(xì)介紹下基于Spring Framework 5 & Spring Boot 2 的WebFlux的響應(yīng)式編程，先畫下如下邏輯圖，后文將以邏輯圖箭頭方向逐一解釋關(guān)于響應(yīng)式編程的點(diǎn)點(diǎn)滴滴。

創(chuàng)新互聯(lián)服務(wù)項目包括灞橋網(wǎng)站建設(shè)、灞橋網(wǎng)站制作、灞橋網(wǎng)頁制作以及灞橋網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，灞橋網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到灞橋省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

1. Spring Framework5

自 2013 年12月Spring Framework4.0.0發(fā)布以后，時隔接近4年Spring才迎來了下一個大版本，這其中引入的新特性中， 最受人關(guān)注的主要圍繞在兩個方面，即響應(yīng)式編程+全異步非阻塞，知乎上的回答有人戲稱這是Spring堵上未來的一擊，react spring+JDK9像是一種新的Java語言。

1.1 The Reactive Manifesto/Rx Java

自從大名鼎鼎的響應(yīng)式宣言/The Reactive Manifesto（https://www.reactivemanifesto.org）提出以來，現(xiàn)代web應(yīng)用構(gòu)建在沿著其提出的思路一步一步演進(jìn)，并且不是一時趨勢。其主要內(nèi)容翻譯成中文如下圖：

我們需要系統(tǒng)具備以下特質(zhì)：即時響應(yīng)性（Responsive）、回彈性（Resilient）、彈性（Elastic）以及消息驅(qū)動（Message Driven）。 對于這樣的系統(tǒng)，我們稱之為反應(yīng)式系統(tǒng)（Reactive System）。

閱讀對應(yīng)的響應(yīng)式宣言，我們會發(fā)現(xiàn)核心思想就是通過回彈性（Resilient）、彈性（Elastic）以及消息驅(qū)動（Message Driven）三種手段來實(shí)現(xiàn)系統(tǒng)高可用的健壯易維護(hù)系統(tǒng)。

其中對三種形式手段做了詳細(xì)介紹：

回彈性：系統(tǒng)在出現(xiàn)失敗時依然保持即時響應(yīng)性。 這不僅適用于高可用的、 任務(wù)關(guān)鍵型系統(tǒng)——任何不具備回彈性的系統(tǒng)都將會在發(fā)生失敗之后丟失即時響應(yīng)性。 回彈性是通過復(fù)制、 遏制、 隔離以及委托來實(shí)現(xiàn)的。 失敗的擴(kuò)散被遏制在了每個[組件](/glossary.zh-cn.md#組件)內(nèi)部， 與其他組件相互隔離， 從而確保系統(tǒng)某部分的失敗不會危及整個系統(tǒng)，并能獨(dú)立恢復(fù)。 每個組件的恢復(fù)都被委托給了另一個（外部的）組件， 此外，在必要時可以通過復(fù)制來保證高可用性。 （因此）組件的客戶端不再承擔(dān)組件失敗的處理。

彈性： 系統(tǒng)在不斷變化的工作負(fù)載之下依然保持即時響應(yīng)性。 反應(yīng)式系統(tǒng)可以對輸入（負(fù)載）的速率變化做出反應(yīng)，比如通過增加或者減少被分配用于服務(wù)這些輸入（負(fù)載）的資源。 這意味著設(shè)計上并沒有爭用點(diǎn)和中央瓶頸， 得以進(jìn)行組件的分片或者復(fù)制， 并在它們之間分布輸入（負(fù)載）。 通過提供相關(guān)的實(shí)時性能指標(biāo)， 反應(yīng)式系統(tǒng)能支持預(yù)測式以及反應(yīng)式的伸縮算法。 這些系統(tǒng)可以在常規(guī)的硬件以及軟件平臺上實(shí)現(xiàn)成本高效的彈性。

消息驅(qū)動：反應(yīng)式系統(tǒng)依賴異步的消息傳遞，從而確保了松耦合、隔離、位置透明的組件之間有著明確邊界。 這一邊界還提供了將失敗作為消息委托出去的手段。 使用顯式的消息傳遞，可以通過在系統(tǒng)中塑造并監(jiān)視消息流隊列， 并在必要時應(yīng)用回壓， 從而實(shí)現(xiàn)負(fù)載管理、 彈性以及流量控制。 使用位置透明的消息傳遞作為通信的手段， 使得跨集群或者在單個主機(jī)中使用相同的結(jié)構(gòu)成分和語義來管理失敗成為了可能。 非阻塞的通信使得接收者可以只在活動時才消耗資源， 從而減少系統(tǒng)開銷。

ReactiveX項目（Reactive Extension）是基于響應(yīng)式異步編程的一個跨語言項目，其中Rx Java為Java版本的對應(yīng)實(shí)現(xiàn)，在Spring項目中，其基于Reative Streams 實(shí)現(xiàn)了一套對應(yīng)的響應(yīng)式編程實(shí)現(xiàn)（Flux/Mono）.

1.2 None-Blcoking/Tomcat 8 & Netty

非阻塞的概念由來已久，其不僅僅在HTTP通訊中涉及，在其他讀寫中也普遍涉及，Netty給出了一個非常優(yōu)雅的實(shí)現(xiàn)方式，其隱藏了我們在JDK7種常見的一些類似Selector/Channel等復(fù)雜概念，可以快速簡單的構(gòu)建出一個非阻塞Web服務(wù)器。對于Tomcat而言，其非阻塞模型主要針對我們常見的大量連接情況，傳統(tǒng)的BIO性能拖累主要集中在大量的連接請求和工作線程數(shù)據(jù)綁定導(dǎo)致無法彈性削峰填谷，而最新的Tomcat版本是用輪詢的方式減少對連接請求的資源消耗的問題，其把對應(yīng)的請求接收后放入隊列中，等待后續(xù)處理。以Tomcat為例，其NIO性能提升關(guān)鍵如下圖所示（基于Servlet3.1），分別是BIO和NIO性能區(qū)別關(guān)鍵：

2. Spring WebFlux

WebFlux，簡而言之，是一套Spring Team認(rèn)為未來需要代替Spring MVC體系的web框架，其構(gòu)建于響應(yīng)式編程規(guī)范之上，提供流式非阻塞具體實(shí)現(xiàn)。在官網(wǎng)提供的各種資料中，目前我們可以認(rèn)為Spring MVC和Spring WebFlux是兩套平行的架構(gòu)體系。在Spring Boot2.0.0版本以及后續(xù)中，我們通過Spring Initializer引入對應(yīng)的web模塊或者web reactive 模塊，即可發(fā)現(xiàn)其分別對應(yīng)著Spring MVC和Spring WebFlux。

2.1 Spring MVC VS Spring WebFlux

選放出官方對比圖：

這張圖代表了以MVC的Servlet Stack和以WebFlux為代表的Reactive Stack的框架對比圖，從各個層面做了對比，具體解釋如下：

@Controller/@RequestMapping VS Router Functions：我們知道MVC體系在SpringBoot中， 只要在Controller層加標(biāo)注@RestController以及對應(yīng)方法加上@GetMapping/@PostMapping方法即可在啟動Tomcat容器以后自動根據(jù)Annotation來加載對應(yīng)的mapping關(guān)系。在Reactive Stack中，我們需要在啟動的時候通過Lambda風(fēng)格的Router Functions統(tǒng)一把所有的Web入口注冊一遍（雖然我覺得很怪，但是目前就是這么實(shí)現(xiàn)的）。

spring-webmvc VS spring-webflux模塊：MVC體系中我們通常是命令式語法，WebFlux體系中，我們需要結(jié)合流式寫法加上基于對應(yīng)Router Functions注冊的方法對流式處理對返回結(jié)果做一定的轉(zhuǎn)化（詳細(xì)見后續(xù)例子）。

Servlet API VS HTTP/Reactive Streams：MVC體系目前可以基于Servlet3.1實(shí)現(xiàn)異步通信，但是實(shí)現(xiàn)流式通信的實(shí)現(xiàn)較復(fù)雜。WebFlux天生基于流式異步通信，編程方式較友好。

Servlet Container Vs Reactive Stream Contrainers：WebFlux天生構(gòu)建于異步流式非阻塞模式，所以它適用于對應(yīng)的特定支持Web容器。

具體寫法舉例如下截圖解釋：

以查詢某人繼續(xù)解釋，根據(jù)上圖我們會去PersonHandler里面的getPerson方法構(gòu)建返回結(jié)果。

可以看出，Handler類相當(dāng)于我們MVC體系中的Service層，MVC中的Controller層集合相當(dāng)于上面舉例的RounterFunctions中不斷構(gòu)建的入口列表。

根據(jù)gradle.build中引入的starter組件，我們分別注釋掉對應(yīng)的一部分starter組件，如下：

implementation()
implementation()

可以分別嘗試用Tomcat和Netty啟動服務(wù)器，reactive stack默認(rèn)使用netty啟動，我們可以觀察對應(yīng)的Idea啟動日志，以及啟動對應(yīng)的Visual VM來觀察對應(yīng)的線程，截圖如下：需要注意的是，其中，reactor-http-nio線程池是由程序根據(jù)系統(tǒng)的CPU數(shù)量來決定的。

Tomcat如下：

Reactive Stack中，Netty如下：

從截圖中我們可以清楚看到對應(yīng)的線程工作狀態(tài)。看到這里，大部分人應(yīng)該認(rèn)識到，對于Reactive Stack來說，我們并不需要去管理線程池，程序是在根據(jù)系統(tǒng)資源在決定我們應(yīng)該創(chuàng)建多少線程，替我們管理線程的生命周期，線程的調(diào)度。也就是說，Reactive Stack中，我們基本可以不用去管ThreadPoolExecutor。站在更高的角度看，這一層是很有深意的，需要我們?nèi)プ屑?xì)思考這樣到底帶來了哪些好處。

2.2 Spring WebFlux的幾個特性介紹以及和Spring MVC對應(yīng)特性的橫向?qū)Ρ取?/p>

通過2.1小節(jié)，我們基本知道了在SpringBoot中，如何引入WebFlux，以及對應(yīng)的寫法實(shí)踐和Spring MVC的對比，接下來介紹下對應(yīng)的響應(yīng)式特性（及優(yōu)缺點(diǎn)）。

由于不用關(guān)心線程池，加上Reactive模式的核心是沒有全局單點(diǎn)，這決定了一件事，任何一個請求在WebFlux框架中走一圈，耗時應(yīng)該是相同的（假設(shè)我們所有的組件都是None-Blocking的，尤其是數(shù)據(jù)庫層），如下圖：

這是ReactiveX官網(wǎng)上的一張圖，它的寓意就是：假設(shè)我們現(xiàn)在看到每個顏色的圓點(diǎn)都是一個HTTP請求，那么從他們落入我們的網(wǎng)卡開始到離開我們的網(wǎng)卡，對于開發(fā)者來說，我們?nèi)绻＞幋a，這些請求的耗時是完全相同的，這一點(diǎn)很重要，其實(shí)是對應(yīng)著響應(yīng)式宣言的“彈性（Elastic）”，這進(jìn)而可以讓我們確定一點(diǎn)：系統(tǒng)的性能瓶頸是可預(yù)測的。這點(diǎn)的重要性在于，當(dāng)我們預(yù)測可預(yù)見的未來訪問請求增加1000倍，我們的部署資源增加1000倍即可，這即對應(yīng)了響應(yīng)式宣言中的彈性。由于線程資源的固定，不存在頻繁的線程切換/生成/銷毀等等，所有的性能類似于固定成通過水流的管道，那么根據(jù)水流的大小，我們就可以確定管道的數(shù)量。

根據(jù)上一段，進(jìn)而要提到一個概念；背壓（BackPressure），如果當(dāng)前流入管道的水流速率超過了管道規(guī)定的上限，那么上游的發(fā)送源會收到反向的發(fā)送壓力，網(wǎng)上有一張形象的圖片就是消防員拿著消防栓噴水滅火時，被反作用力壓的往后退。“背壓”是一種現(xiàn)象，通常來說，解決背壓的方式有兩種：一種是返回源頭錯誤告警，一種是忽略請求。

流：在WebFlux中，我們的請求可以通過Flux<T>類型來返回一系列的數(shù)據(jù)，而通過我們的WebClient客戶端 + application/json+stream 模式，我們完成數(shù)據(jù)的持續(xù)流式傳輸，例如客戶端請求1W個客戶的具體信息->服務(wù)端通過Luttuce每秒去Redis獲取100個客戶，那么對應(yīng)的返回數(shù)據(jù)會在100秒內(nèi)持續(xù)的返回對應(yīng)的客戶端。通過這種方式，我們可以做到網(wǎng)絡(luò)均衡的傳輸。

完全非阻塞調(diào)用鏈：

根據(jù)最新的GA版本，我們的系統(tǒng)調(diào)用大部分時間是可以實(shí)現(xiàn)完全的非阻塞系統(tǒng)調(diào)用的-->關(guān)系型數(shù)據(jù)庫（MySQL）除外。因為原來的 Spring 事務(wù)管理（Spring Data JPA）都是基于 ThreadLocal 傳遞事務(wù)的，其本質(zhì)是基于阻塞IO模型，不是異步的。但Reactive是要求異步的，不同線程里面 ThreadLocal 肯定取不到值了。根據(jù)最新的進(jìn)展，好消息是目前的R2DBC項目已經(jīng)實(shí)現(xiàn)postgresql的非阻塞實(shí)現(xiàn)，相信在不久的將來，MySQL也會最終加入Reactive Stack的拼圖。

2.3 Reactive Stack 性能測試

先想一想，結(jié)果會是怎樣？答案是，和Servlet Stack（MVC）沒多大差距，甚至可能還弱一點(diǎn)。Google上給出的大部分測試結(jié)果已經(jīng)證明了這一點(diǎn)，為什么呢？想了一下，應(yīng)該是因為以下幾點(diǎn)：

• Spring MVC是一個經(jīng)過時間和實(shí)踐檢驗的成熟體系，沒有短板，在相同的把CPU，內(nèi)存，IO等資源吃滿的情況下，只要合理的控制好Thread對CPU時間片的浪費(fèi)，MVC完全是可以做到最優(yōu)解的。

• WebFlux的線程管理模式，包括背壓在內(nèi)的一系列特性，其實(shí)熟悉線程管理來說，就相當(dāng)于是ScheduledThreadPoolEXecutor根據(jù)對應(yīng)參數(shù)設(shè)置，并且對應(yīng)的設(shè)置好rejectHandler policy。

• DefferredResult，ResponseBodyEmmiter，SseEmmiter等類讓MVC體系也可以毫無壓力完成異步以及流等高性能響應(yīng)方式，從終極實(shí)踐方式來說，兩者并無本質(zhì)上的差異。

3 總結(jié)與展望

說了這么多，好像發(fā)現(xiàn)WebFlux也沒啥？Spring 堵上未來的一擊會成功嗎？誠然，就官方目前的說法也是，不太適合大規(guī)模應(yīng)用，但是小范圍的改造是OK的。

但是，回到最開始，讓我們再看看響應(yīng)式宣言。Spring WebFlux費(fèi)盡心思搞了這么一套和MVC平行的體系架構(gòu)，其本質(zhì)思想已經(jīng)基本默默地在反映著響應(yīng)式宣言。即時響應(yīng)性，彈性，回彈性，消息驅(qū)動。這整個一套技術(shù)棧，其實(shí)是在構(gòu)建一套可預(yù)測的，更加健壯的，開發(fā)人員更加少干預(yù)的Web框架，從而讓大家專注于業(yè)務(wù)層面的實(shí)現(xiàn)，進(jìn)一步忽略/屏蔽底層系統(tǒng)的細(xì)節(jié)。

如果說Spring Cloud是從【宏觀系統(tǒng)層面的開發(fā)】角度在實(shí)踐健壯的高可用系統(tǒng)+系統(tǒng)運(yùn)維，K8S在【DEV OPS】層面實(shí)踐更好的系統(tǒng)運(yùn)維，Service Mesh在【基礎(chǔ)設(shè)施層（infra）】實(shí)踐健壯的高可用系統(tǒng)+系統(tǒng)運(yùn)維，那么WebFlux（包括整個Reactive Stack體系的其他成員）就是從【微觀項目層面的開發(fā)】角度在實(shí)踐健壯的高可用系統(tǒng)+系統(tǒng)運(yùn)維。或多或少，它們都從各個維度在朝著“更少的人治”角度去努力。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

分享標(biāo)題：ReactiveStack系列（一）：響應(yīng)式編程從入門到放棄-創(chuàng)新互聯(lián)
路徑分享：http://www.chinadenli.net/article16/dcsegg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、面包屑導(dǎo)航、企業(yè)建站、關(guān)鍵詞優(yōu)化、網(wǎng)站設(shè)計公司、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)