（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中的應用。