[譯] 響應式 Web 應用（一）

本文由 Shaw 發表在 ScalaCool 團隊博客。

原書

www.manning.com/books/react…

第一章：你是說「響應式」？

本章內容

• 響應式應用及其起源

• 爲何響應式應用是必要的

• 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 請求之類的離散事件發生反應，而不須要在等待事件發生時獨佔計算資源。與傳統的同步方法調用相比，這種天然級別的併發性帶來了更低的延遲。編寫事件驅動程序的另外一個結果是組件鬆散耦合，長遠來看，這會使得軟件更加易於維護。