（10）響應式宣言、響應式系統與響應式編程——響應式Spring的道法術器

本系列文章索引《響應式Spring的道法術器》
前情提要 響應式編程 | 響應式流

1.5 響應式系統

1.5.1 響應式宣言

關注「響應式」的朋友不難搜索到關於「響應式宣言」的介紹，先上圖：

這張圖凝聚了許多大神的智慧和經驗，見官網，中文版官網，若是你承認這個宣言的內容，還能夠簽下你的大名。雖然這些內容多概念而少實戰，讓人感受是看教科書，可是字字千金，不時看一看都會有新的體會和收穫。

這也是新時代男友的行爲準則：

• Responsive，要及時響應，24小時在線，不許不接電話，微信回覆時間要在5分鐘之內；
• 如何作到Responsive呢，首先要Resilient，就是不管如何要有迴應。即便在玩LOL，也要接電話，哪怕正在聯合國演講，那麼也要設置好「對不起寶貝兒，稍後打給你麼麼噠~」的自動回覆；
• 作到Responsive的另外一點是Elastic，要彈性應對大量命令的到來。當奉天承運的聖旨過多時完不成怎麼辦？對不起，不存在的，若是學不會三頭六臂，那就拉幾個好友幫忙；
• 聖旨是經過異步方式傳遞的（Message Driven），給花店打電話訂花、到蛋糕店訂蛋糕等，別忘了購物車裏的「消息隊列」要及時處理嘍~ 這些訂單都是具備必定格式和目的地的消息，而後異步等待快遞上門。

以響應式系統方式構建的系統更加靈活，鬆耦合和可擴展。這使得它們更容易開發，並且更加擁抱變化。及時地響應，以保證良好的用戶體驗。系統錯誤和異常在所不免，當異常出現時，要優雅地處理之，不要任其蔓延、甚至到達用戶眼前。

關於宣言的具體內容官網上很詳細，就很少贅述了。

從落地方面，咱們不難想到一些具體技術來支撐響應式宣言的目標：

• 好比現在比較火熱的雲原生和DevOps的理念與實踐，以及更早一些的自動化運維，都有助於讓系統更加Elastic，不過系統架構的微服務化也是功不可沒；
• 相似於Hystrix的熔斷器（Circuit Breaker）使得系統更加Resilient，由於它可以及時將服務異常遏制在可控範圍內，避免雪崩；而相似kubernetes的雲原生應用可以及時發現和重建系統中的異常服務；
• 而相似RabbitMQ、ActiveMQ這樣的消息隊列產品有助於構建消息驅動的系統，併發揮解耦、提速、廣播、削峯的做用；
• 消息驅動有利於系統的彈性和可靠性，彈性和可靠性又使得系統的響應更加及時；
• 等等。

1.5.2 響應式編程與響應式系統

響應式宣言是一組架構與設計原則，符合這些原則的系統能夠認爲是響應式的系統。而響應式系統與響應式編程是不一樣層面的內容。

看到網上有些文章在介紹RxJava、Reactor等響應式編程技術的時候，會用響應式宣言來引出話題，稍微有點驢脣對馬嘴的感受（^_^）。響應式系統（或響應式宣言）與響應式編程又是一對容易被揉在一塊兒用的兩個術語（上一對容易被混用的術語是「響應式編程RP」和「函數響應式編程FRP」，見1.3.1 lambda與函數式），它們從關係上看雖然不如「雷鋒」和「雷峯塔」、Java和JavaScript那麼遠，但並不存在必然的因果關係。

做爲《響應式宣言》的做者，Jonas Bonér和Viktor Klang解釋了響應式編程與響應式系統的區別與聯繫（「Linux中國」上有翻譯版），其中也有對響應式宣言四個原則的解讀，值得學習。我從中總結了一些兩者的不一樣點：

1）戰術與戰略的區別

響應式編程是異步編程下的一個子集，是一種範式，有具體的開發庫，側重於由信息/數據流而不是命令式的控制流來推進邏輯的前進。

響應式宣言是一組設計原則，一種關於分佈式環境下系統架構與設計的思考方式，響應式系統是符合這一架構風格的系統。

2）事件驅動與消息驅動的區別

響應式編程——專一於短期的數據流鏈條上的計算——所以傾向於事件驅動；而響應式系統——關注於經過分佈式系統的通訊和協做所獲得的彈性和可靠性——則是消息驅動的。

響應式宣言中從定義上闡述了消息驅動與事件驅動的不一樣：

一條消息就是一則被送往一個明確目的地的數據。一個事件則是達到某個給定狀態的組件發出的一個信號。在一個消息驅動系統中，可尋址到的接收者等待消息的到來而後響應它，不然保持休眠狀態。在一個事件驅動系統中，通知的監聽者被綁定到消息源上，這樣當消息被髮出時它就會被調用。這意味着一個事件驅動系統專一於可尋址的事件源而消息驅動系統專一於可尋址的接收者。

3）組件範圍與系統範圍的區別

響應式編程的「活動範圍」是在組件內的，是一種管理組件或服務內部邏輯和數據流的技術，即便像1.4.2節中那樣數據流從服務B向服務A的流動，也並不是跨服務的消息傳遞，只是基於API的調用而已。

響應式系統，強調組件/服務間的信息交流，並經過響應式宣言提供了一種處理分佈式系統彈性與可靠性的原則，所以是面向分佈式的系統範圍的。

4）空間解耦能力的區別

正如前邊介紹到的異步調用方式那樣，事件驅動的響應式編程側重於時間上的解耦，從而在技術層面提供了一種更高性能的併發方式。然而其範圍限定了它不易於實現空間上的解耦。

消息驅動的異步性使得響應式系統既可以在時間上解耦，還具備空間的解耦能力。服務間不只能夠經過消息隊列實現分佈式協做，還能夠根據負載實現單個服務的彈性伸縮，從而實現響應式宣言中Elastic的能力。

5）總結

響應式編程技術一般用於在單個節點或服務中對數據流進行異步非阻塞的處理。當有多個結點時，就須要認真考量數據一致性（data consistency）、跨結點溝通（cross-node communication）、協調（coordination）、版本控制（versioning）、編排（orchestration）、錯誤管理（failure management）、關注與責任（concerns and responsibilities）分離等等的內容——這些都是響應式系統架構要考慮的內容。

相似的，Spring WebFlux是一種響應式編程框架，用於開發響應式應用，而Spring Cloud不只是更是一套適應於當今雲原生環境下微服務架構基礎，更加接近響應式宣言的目標和響應式系統的設計原則。

不過也應該看到，也正是因爲響應式宣言中對現代系統的Responsive、Resilient、Elastic和Message Driven的要求，使得對響應式編程技術的呼聲愈來愈高，顯然響應式編程技術是構建響應式系統的合適工具之一。尤爲是隨着面向響應式宣言的響應式流規範（Reactive Streams Specification）這一頂層設計的提出，相似Reactor、RxJava、Vert.x、Spring WebFlux等的響應式編程技術在響應式系統中必將發揮愈來愈大的做用。

關於響應式系統的話題比較大，涉及到許多的理念、技術。本系列的文章仍主要聚焦於響應式編程的範疇，並在最後討論響應式編程在Spring Cloud中的應用。