一、前言

響應(yīng)式編程是啥？

為啥要有響應(yīng)式編程？

(資料圖片僅供參考)

響應(yīng)式流的核心機制是什么？

Spring 響應(yīng)式編程能解決我們平時開發(fā)的什么痛點？

Spring 響應(yīng)式編程有哪些應(yīng)用場景？

Spring 響應(yīng)式編程未來的趨勢如何？

開篇六連問，等咱們熟悉完再來真香也不遲，我們廢話少說，直接來暢游 Spring 響應(yīng)式編程的世界。

二、響應(yīng)式編程是啥？

在計算中，響應(yīng)式編程或反應(yīng)式編程（Reactive programming）是一種面向數(shù)據(jù)串流和變化傳播的聲明式編程范式。這意味著可以在編程語言中很方便地表達(dá)靜態(tài)或動態(tài)的數(shù)據(jù)流，而相關(guān)的計算模型會自動將變化的值通過數(shù)據(jù)流進(jìn)行傳播。

有點抽象？沒有關(guān)系，老周這就來說道說道。核心的一點響應(yīng)式編程是聲明式編程范式，對命令式編程進(jìn)行替代的一個范例，這種替代的存在是因為響應(yīng)式編程解決了命令式編程的限制。大多數(shù)開發(fā)者都是命令式編程起步的，你寫的代碼就是一行接一行的指令，按照它們的順序一次一條地出現(xiàn)。一個任務(wù)被執(zhí)行，程序就需要等到它執(zhí)行完了，才能執(zhí)行下一個任務(wù)。每一步，數(shù)據(jù)都需要完全獲取到了才能被處理，因此它需要作為一個整體來處理。

命令式編程有個最大的弊端是：當(dāng)正在執(zhí)行的任務(wù)被阻塞了，特別是一個 IO 任務(wù)，例如將數(shù)據(jù)寫入到數(shù)據(jù)庫或從遠(yuǎn)程服務(wù)器獲取數(shù)據(jù)，那么調(diào)用該任務(wù)的線程將無法做任何事情，直到任務(wù)完成。說白了，阻塞的線程就是一種浪費，在如今的環(huán)境，線程的資源是那么的寶貴。

相反，響應(yīng)式編程是函數(shù)式和聲明式的。響應(yīng)式編程涉及描述通過該數(shù)據(jù)流的 pipeline 或 stream，而不是描述的一組按順序執(zhí)行的步驟。響應(yīng)式流處理數(shù)據(jù)時只要數(shù)據(jù)是可用的就進(jìn)行處理，而不是需要將數(shù)據(jù)作為一個整體進(jìn)行提供。

三、為啥要有響應(yīng)式編程？

我們上面也說了命令式編程會線程阻塞，而響應(yīng)式編程是聲明式編程范式的，是對命令式編程進(jìn)行替代的一個范例。

對于命令式編程的同步阻塞，其實業(yè)界是有一些處理方案的，比如在 Java 中，為了實現(xiàn)異步非阻塞，一般會采用回調(diào)和 Future 這兩種機制，但這兩種機制都存在一定局限性。

3.1 回調(diào)機制

我們來看下面這個圖：

服務(wù) B 的 methodB() 方法調(diào)用服務(wù) A 的 methodA() 方法，然后服務(wù) A 的 methodA() 方法執(zhí)行完畢后，再主動調(diào)用服務(wù) B 的 callback() 方法。

回調(diào)體現(xiàn)的是一種雙向的調(diào)用方式，實現(xiàn)了服務(wù) A 和服務(wù) B 之間的解耦。在這個 callback 回調(diào)方法中，回調(diào)的執(zhí)行是由任務(wù)的結(jié)果來觸發(fā)的，所以我們就可以異步來執(zhí)行某項任務(wù)，從而使得調(diào)用鏈路不發(fā)生任何的阻塞。

回調(diào)的最大問題是復(fù)雜性，一旦在執(zhí)行流程中包含了多層的異步執(zhí)行和回調(diào)，那么就會形成一種嵌套結(jié)構(gòu)，給代碼的開發(fā)和調(diào)試帶來很大的挑戰(zhàn)。所以回調(diào)很難大規(guī)模地組合起來使用，因為很快就會導(dǎo)致代碼難以理解和維護(hù)，從而造成所謂的“回調(diào)地獄”問題。之前公司就遇到代碼“回調(diào)地獄”問題，十幾層的回調(diào)，后面的人進(jìn)來維護(hù)估計會吐。

3.2 Future 機制

我們再來看看 Future 這種機制，有一個需要處理的任務(wù)，然后把這個任務(wù)提交到 Future，F(xiàn)uture 就會在一定時間內(nèi)完成這個任務(wù)，而在這段時間內(nèi)我們可以去做其他事情。下面我們來看看來自 Doug Lea 大神在 Java 中的 Future 接口設(shè)計：

我們可以看到，大神在上面的設(shè)計來達(dá)到一定的異步執(zhí)行效果。但從本質(zhì)上講，F(xiàn)uture 以及由 Future 所衍生出來的 CompletableFuture 等各種優(yōu)化方案就是一種多線程技術(shù)。多線程假設(shè)一些線程可以共享一個 CPU，而 CPU 時間能在多個線程之間共享，這一點就引入了“上下文切換”的概念。

如果想要恢復(fù)線程，就需要涉及加載和保存寄存器等一系列計算密集型的操作。因此，大量線程之間的相互協(xié)作同樣會導(dǎo)致資源利用效率低下。

3.3 響應(yīng)式編程實現(xiàn)方法3.3.1 數(shù)據(jù)流與響應(yīng)式

數(shù)據(jù)流就是數(shù)據(jù)像水流一樣源源不斷的輸入過來，而系統(tǒng)的響應(yīng)能力就體現(xiàn)在對這些數(shù)據(jù)流的即時響應(yīng)過程上。我們可以不采用傳統(tǒng)的同步調(diào)用方式來處理數(shù)據(jù)，而是由處于數(shù)據(jù)庫上游的各層組件自動來執(zhí)行事件，從web到service再到dao層，這個過程就像水流一樣，整個數(shù)據(jù)傳遞鏈路都應(yīng)該是采用事件驅(qū)動的方式來進(jìn)行運作的，這個過程都應(yīng)該是異步非阻塞的，這就是響應(yīng)式編程的核心特點。

相較傳統(tǒng)開發(fā)所普遍采用的“拉”模式，在響應(yīng)式編程下，基于事件的觸發(fā)和訂閱機制，這就形成了一種類似“推”的工作方式。說白了，就類似現(xiàn)在的 Kafka 等消息引擎，大部分都采用事件驅(qū)動的 pub/sub 模式的架構(gòu)。這種模式的最大優(yōu)勢是生成事件和消費事件的過程是異步執(zhí)行的，意味著資源之間的競爭關(guān)系較少，故服務(wù)器的響應(yīng)能力也就越高。

3.3.2 響應(yīng)式宣言

響應(yīng)式宣言是一份構(gòu)建現(xiàn)代云擴(kuò)展架構(gòu)的處方。這個框架主要使用消息驅(qū)動的方法來構(gòu)建系統(tǒng)，在形式上可以達(dá)到彈性和韌性，最后可以產(chǎn)生響應(yīng)性的價值。所謂彈性和韌性，通俗來說就像是橡皮筋，彈性是指橡皮筋可以拉長，而韌性指在拉長后可以縮回原樣。

響應(yīng)性: ：只要有可能，系統(tǒng)就會及時地做出響應(yīng)。即時響應(yīng)是可用性和實用性的基石，而更加重要的是，即時響應(yīng)意味著可以快速地檢測到問題并且有效地對其進(jìn)行處理。即時響應(yīng)的系統(tǒng)專注于提供快速而一致的響應(yīng)時間，確立可靠的反饋上限，以提供一致的服務(wù)質(zhì)量。這種一致的行為轉(zhuǎn)而將簡化錯誤處理、建立最終用戶的信任并促使用戶與系統(tǒng)作進(jìn)一步的互動。

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

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

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

問題：消息驅(qū)動與上面提到的事件驅(qū)動有啥區(qū)別呢？

響應(yīng)式宣言指出了兩者的區(qū)別：“消息驅(qū)動”中消息數(shù)據(jù)被送往明確的目的地址，有固定導(dǎo)向；“事件驅(qū)動”是事件向達(dá)到某個給定狀態(tài)的組件發(fā)出的信號，沒有固定導(dǎo)向，只有被觀察的數(shù)據(jù)。

在一個消息驅(qū)動系統(tǒng)中，可尋址的接收者等待消息的到來然后響應(yīng)消息，否則保持休眠狀態(tài)，消息驅(qū)動系統(tǒng)專注于可尋址的接收者。響應(yīng)式系統(tǒng)更加關(guān)注分布式系統(tǒng)的通信和協(xié)作以達(dá)到解耦、異步的特性，滿足系統(tǒng)的彈性和容錯性，所以響應(yīng)式系統(tǒng)更傾向于使用消息驅(qū)動模式。

在一個事件驅(qū)動系統(tǒng)中，通知的監(jiān)聽者被綁定到消息源上。這樣當(dāng)消息被發(fā)出時，它就會被調(diào)用，所以，響應(yīng)式編程更傾向于事件驅(qū)動。

下一篇老周會來說下響應(yīng)式流的核心機制是什么？敬請期待~

---

歡迎大家關(guān)注我的公眾號【老周聊架構(gòu)】，Java后端主流技術(shù)棧的原理、源碼分析、架構(gòu)以及各種互聯(lián)網(wǎng)高并發(fā)、高性能、高可用的解決方案。

關(guān)鍵詞： 事件驅(qū)動 異步執(zhí)行 消息傳遞