一、前言

響應式編程是啥？

為啥要有響應式編程？

(資料圖片僅供參考)

響應式流的核心機制是什么？

Spring 響應式編程能解決我們平時開發的什么痛點？

Spring 響應式編程有哪些應用場景？

Spring 響應式編程未來的趨勢如何？

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

二、響應式編程是啥？

在計算中，響應式編程或反應式編程（Reactive programming）是一種面向數據串流和變化傳播的聲明式編程范式。這意味著可以在編程語言中很方便地表達靜態或動態的數據流，而相關的計算模型會自動將變化的值通過數據流進行傳播。

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

命令式編程有個最大的弊端是：當正在執行的任務被阻塞了，特別是一個 IO 任務，例如將數據寫入到數據庫或從遠程服務器獲取數據，那么調用該任務的線程將無法做任何事情，直到任務完成。說白了，阻塞的線程就是一種浪費，在如今的環境，線程的資源是那么的寶貴。

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

三、為啥要有響應式編程？

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

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

3.1 回調機制

我們來看下面這個圖：

服務 B 的 methodB() 方法調用服務 A 的 methodA() 方法，然后服務 A 的 methodA() 方法執行完畢后，再主動調用服務 B 的 callback() 方法。

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

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

3.2 Future 機制

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

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

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

3.3 響應式編程實現方法3.3.1 數據流與響應式

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

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

3.3.2 響應式宣言

響應式宣言是一份構建現代云擴展架構的處方。這個框架主要使用消息驅動的方法來構建系統，在形式上可以達到彈性和韌性，最后可以產生響應性的價值。所謂彈性和韌性，通俗來說就像是橡皮筋，彈性是指橡皮筋可以拉長，而韌性指在拉長后可以縮回原樣。

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

韌性：系統在出現失敗時依然保持即時響應性。這不僅適用于高可用的、任務關鍵型系統——任何不具備回彈性的系統都將會在發生失敗之后丟失即時響應性。回彈性是通過復制、遏制、隔離以及委托來實現的。失敗的擴散被遏制在了每個組件內部，與其他組件相互隔離，從而確保系統某部分的失敗不會危及整個系統，并能獨立恢復。每個組件的恢復都被委托給了另一個（外部的）組件，此外，在必要時可以通過復制來保證高可用性。（因此）組件的客戶端不再承擔組件失敗的處理。

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

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

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

響應式宣言指出了兩者的區別：“消息驅動”中消息數據被送往明確的目的地址，有固定導向；“事件驅動”是事件向達到某個給定狀態的組件發出的信號，沒有固定導向，只有被觀察的數據。

在一個消息驅動系統中，可尋址的接收者等待消息的到來然后響應消息，否則保持休眠狀態，消息驅動系統專注于可尋址的接收者。響應式系統更加關注分布式系統的通信和協作以達到解耦、異步的特性，滿足系統的彈性和容錯性，所以響應式系統更傾向于使用消息驅動模式。

在一個事件驅動系統中，通知的監聽者被綁定到消息源上。這樣當消息被發出時，它就會被調用，所以，響應式編程更傾向于事件驅動。

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

---

歡迎大家關注我的公眾號【老周聊架構】，Java后端主流技術棧的原理、源碼分析、架構以及各種互聯網高并發、高性能、高可用的解決方案。

關鍵詞： 事件驅動 異步執行 消息傳遞