本文由 Shaw 發表在 ScalaCool 團隊部落格。
原書
第一章：你是說「響應式」？
本章內容
響應式應用及其起源
為什麼響應式應用是必要的
Play 如何幫你構建響應式應用
概覽
在過去幾年，Web 應用開始在我們的生活中發揮越來越重要的作用，不論是像社交網路這樣的大型應用、電子銀行站點這樣的中型應用，還是一些小型應用，如線上賬戶系統以及一些小型企業的專案管理工具，它們對這些服務的依賴呈現出明顯增加的趨勢。而這一趨勢現在也轉向了物理裝置，根據資訊科技研究與諮詢公司 Gartner 的預測，到 2020 年物聯網裝置將增至260億臺。
這一快速演變對高可用性以及資源效率提出了更高的要求，而響應式應用就是為此而量身定做的。以前的 Web 程式開發一般都是利用一個應用程式嘗試解決各種問題，但隨著雲端計算的出現與雲服務的接踵而至，應用程式可以連線到雲服務，只需解決那些剩餘沒有很好解決的問題。
所以我們需要一套新的工具來有效地應對這一演變帶來的挑戰。Play! 框架是一套嶄新的方案，以便構建出能夠實時響應使用者行為的 Web 應用程式，即使在高負載和分散式的環境下也是如此。
在撰寫本文時，Play! 是 Java 虛擬機器上唯一真正的全棧響應式 Web 應用程式框架。作為一款免費且開源的軟體，Play! 已經被許多大公司所採用，比如 摩根士丹利（Morgan Stan-ley）、領英（LinkedIn）、衛報（The Guardian）等，當然還有許多小型的 Play! 玩家。Play! 隨時等著你去下載把玩呢！
在本章中，我們將探究：
- 響應式 Web 應用程式是什麼
- 為什麼要構建這樣的程式
- 以及為什麼 Play! 是構建這種程式的好工具。
我們將首先澄清「響應式」一詞的意思，並探討在新的硬體設計和軟體架構的趨勢下，如何重新考慮使用可計算資源。最後，還將探究為什麼失敗處理起著關鍵性的作用，以及如何去實現相應的邏輯。
1.1 特定場景下的「響應式」
如果你正在閱讀本書，你可能聽過諸如「響應式應用」、「響應式程式設計」、「響應式流」或「響應式宣言」等概念。這些詞加上「響應式」字首後感覺更加高大上了，但是你可能會去思考在這些不同場景下「響應式」的含義。那就讓我們去看看這個詞在計算機系統中的起源，從中尋求答案。
1.1.1 「響應式」的起源
「響應式系統」並不是一個新的概念。David Harel 和 Amir Pnueli 在《關於響應式系統的發展》（1985年出版）的論文中就收集整理了幾個二分法，以此來表徵複雜的計算機系統，並提出了一個新的二分法：轉換系統與響應式系統。轉換系統接受一組已知的輸入，然後轉換這些輸入，最終產生輸出。例如，轉換系統可以提示使用者進行一些輸入，然後再根據使用者提供的內容來提示使用者，並最終產出結果。
思考一下，比如，袖珍計算器，它接受數字並執行基本操作，以便在按下等號鍵時最終返回結果。另一方面，響應式系統由外部環境持續刺激，其作用是不斷響應這些刺激。例如，具有運動監測測功能的 WIFI 攝像機可以注意到小偷進入了房間，然後它會向攝像機主人的手機傳送警報，於是他們無助地目睹了小偷將其房間裡的貴重物品洗劫一空，以及不久之後警察到達現場的情景。
幾年後，Gérard Berry 通過介紹互動式程式和響應式程式之間的區別來改進了這一定義。 互動式程式與環境互動的速度由程式本身決定，而響應式程式則由外部環境決定。
因此，響應式程式能夠：
持續與它們的環境進行互動
互動速度由外部環境而不是程式本身決定
對外部的需求進行響應
讓我們再回到當下，響應式程式以前的操作，看起來很像是 Web 應用程式的執行方式，或者說是 Web 應用程式應該如何執行。儘管這在理論上很有吸引力，但是要實現這些標準難度很大，並且當系統的使用者量增加以及系統所需要的效能提高時，對硬體資源的要求也提出了一個很嚴峻的挑戰。因為缺乏廣泛的高效能硬體去實現大規模的實時互動，所以一直到最近幾年之前「響應式系統」都沒有經常被提及，直到「響應式宣言」 的出現，這份「宣言」闡明瞭響應式系統的一系列核心特徵。
1.1.2 「響應式」宣言
響應式宣言的第一個版本在 2013 年 6 月釋出，它描述了「響應式應用程式」的軟體架構體系。 「響應式應用程式」的定義中包含了許多特性，這些特性使得應用程式能夠像我們前面討論過的響應式程式那樣 —— 持續可用以及實時響應外部需求。雖然 響應式宣言 看上去似乎是在描述一種全新的架構模式，但其核心原則在一些需要 IT 系統能夠實時響應的行業中早已被廣泛接受，比如金融交易行業。
下面這四個特性組成了響應式應用程式：
響應式——響應使用者
可伸縮——響應負載
彈性化——響應失敗
事件驅動——響應事件
響應式應用程式要能滿足使用者對可用性以及實時響應行為的期望。所謂實時，或者說類實時，意味著應用程式能夠在短時間或者極短時間內作出響應。請求和響應之間的時間間隔我們稱為「延遲」，它是評估一個系統執行情況的關鍵測量之一。
為了能夠持續地與所在環境進行互動，響應式應用要能夠適應它們所面臨的負載。突然的流量爆發可能會對程式造成一定的影響；比如，一條帶有新聞外鏈的熱門推特可能會對外鏈指向的新聞網站造成衝擊。因此，應用程式必須是可擴充套件的，必要時，能夠增加其計算能力。這就意味著應用程式不僅要能在一臺機器上（可能具有一個或者多個CPU核心）有效地使用硬體資源，而且，當系統負載增加時，它還要能在多個計算機節點上執行。
- 注：我們使用術語「計算機節點」或簡稱為「節點」來指代執行 Web 應用程式的資源。 實際上，這可能指的是物理計算機，虛擬機器，甚至是服務提供商上的邏輯節點。
因為即使是最簡單的系統也容易出現故障（不論是與軟體相關還是與硬體相關），所以，要想讓系統持續可用，響應式應用程式必須能夠彈性化地處理失敗的情況。當涉及到可伸縮性系統時，應用程式面對問題之後的恢復能力將變得更加重要，因為這類系統在本質上以及分佈上面的複雜程度會導致其在硬體以及網路上面出現故障的機率增加。
基於非同步通訊的事件驅動應用程式能夠使我們的系統具有前面列舉出的那幾個特性。在這種設定下，系統（或子系統）能夠對諸如 HTTP 請求之類的離散事件發生反應，而不需要在等待事件發生時獨佔計算資源。與傳統的同步方法呼叫相比，這種自然級別的併發性帶來了更低的延遲。編寫事件驅動程式的另一個結果是元件鬆散耦合，長遠來看，這會使得軟體更加易於維護。