1 響應式程式設計之道

1.1 什麼是響應式程式設計？

在開始討論響應式程式設計（Reactive Programming）之前，先來看一個我們經常使用的一款堪稱“響應式典範”的強大的生產力工具——電子表格。

舉個簡單的例子，某電商網站正在搞促銷活動，任何單品都可以參加“滿199減40”的活動，而且“滿500包郵”。吃貨小明有選擇障礙（當然主要原因還是一個字：窮），他有個習慣，就是先在Excel上根據預算算好自己要買的東西：

相信大家都用過Excel中的公式，這是一個統計購物車商品和訂單應付金額的表格，其中涉及到一些公式：

上圖中藍色的線是公式的引用關係，從中可以看出，“商品金額”是通過“單價x數量”得到的，“滿199減40”會判斷該商品金額是否滿199並根據情況減掉40，右側“訂單總金額”是“滿199減40”這一列的和，“郵費”會根據訂單總金額計算，“最終應付款”就是訂單總金額加上郵費。

1.1.1 變化傳遞（propagation of change）

為什麼說電子表格軟體是“響應式典範”呢，因為“單價”和“數量”的任何變動，都會被引用（“監聽”）它的單元格實時更新計算結果，如果還有圖表或資料透檢視引用了這塊資料，那麼也會相應變化，做到了實時響應。變化的時候甚至還有動畫效果，使用者體驗一級棒！

這是響應式的核心特點之一：變化傳遞（propagation of change）。一個單元格變化之後，會像多米諾骨牌一樣，導致直接和間接引用它的其他單元格均發生相應變化。

這裡我們說的是一種生產者只負責生成併發出資料/事件，消費者來監聽並負責定義如何處理資料/事件的變化傳遞方式。

1.1.2 資料流（data stream）

這些資料/事件在響應式程式設計裡會以資料流的形式發出。

我們再觀察一下購物車，這裡有若干商品，小明每次往購物車裡新增或移除一種商品，或調整商品的購買數量，這種事件都會像過電一樣流過這由公式串起來的多米諾骨牌一次。這一次一次的操作事件連起來就是一串資料流（data stream），如果我們能夠及時對資料流的每一個事件做出響應，會有效提高系統的響應水平。這是響應式的另一個核心特點：基於資料流（data stream）。

如下圖是小明選購商品的過程，為了既不超預算，又能省郵費，有時加有時減：

1.1.3 宣告式（declarative）

這是一種**“宣告式（declarative）”**的程式設計正規化。通過四個串起來的map

比如對於第一個map操作：

**宣告式程式設計正規化的威力在於以不變應萬變。**無論到來的元素是什麼，計算邏輯是不變的，從而形成了一種對計算邏輯的“繫結”。

總結來說，命令式是面向過程的，宣告式是面向結構的。

不過命令式和宣告式本身並無高低之分，只是宣告式比較適合基於流的處理方式。這是響應式的第三個核心特點：宣告式（declarative）。結合“變化傳遞”的特點，宣告式能夠讓基於資料流的開發更加友好。

1.1.4 總結

總結起來，響應式程式設計（reactive programming）是一種基於資料流（data stream）和變化傳遞（propagation of change）的宣告式（declarative）的程式設計正規化。

響應式程式設計的“變化傳遞”就相當於果汁流水線的管道；在入口放進橙子，出來的就是橙汁；放西瓜，出來的就是西瓜汁，橙子和西瓜、以及機器中的果肉果汁以及殘渣等，都是流動的“資料流”；管道的圖紙是用“宣告式”的語言表示的。

這種程式設計正規化如何讓Web應用更加“reactive”呢？

我們設想這樣一種場景，我們從底層資料庫驅動，經過持久層、服務層、MVC層中的model，到使用者的前端介面的元素，全部都採用宣告式的程式設計正規化，從而搭建一條能夠傳遞變化的管道，這樣我們只要更新一下資料庫中的資料，使用者的介面上就相應的發生變化，豈不美哉？尤其重要的是，一處發生變化，我們不需要各種命令式的呼叫來傳遞這種變化，而是由搭建好的“流水線”自動傳遞。

這種場景用在哪呢？比如一個日誌監控系統，我們的前端頁面將不再需要通過“命令式”的輪詢的方式不斷向伺服器請求資料然後進行更新，而是在建立好通道之後，資料流從系統源源不斷流向頁面，從而展現實時的指標變化曲線；再比如一個社交平臺，朋友的動態、點贊和留言不是手動刷出來的，而是當後臺資料變化的時候自動體現到介面上的。

轉：https://blog.51cto.com/liukang/2090170