一、前言

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

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

(資料圖片僅供參考)

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

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

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

Spring 響應(yīng)式編程未來(lái)的趨勢(shì)如何？

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

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

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

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

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

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

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

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

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

3.1 回調(diào)機(jī)制

我們來(lái)看下面這個(gè)圖：

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

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

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

3.2 Future 機(jī)制

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

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

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

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

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

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

3.3.2 響應(yīng)式宣言

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

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

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

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

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

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

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

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

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

下一篇老周會(huì)來(lái)說(shuō)下響應(yīng)式流的核心機(jī)制是什么？敬請(qǐng)期待~

---

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

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