The Reactive Manifesto（響應式宣言）

版本 2.0，2014 年 9 月 16 日發佈

在不一樣領域中深耕的組織都在不約而同地嘗試發現類似的軟件構建模式。 但願這些系統會更健壯、更具回彈性 、更靈活，也能更好地知足現代化的需求。

近年來，應用程序的需求已經發生了戲劇性的更改，模式變化也隨之而來。僅在幾年前， 一個大型應用程序一般擁有數十臺服務器、 秒級的響應時間、 數小時的維護時間以及GB級的數據。 而今，應用程序被部署到了形態萬千的載體上, 從移動設備到運行着數以千計的多核心處理器的雲端集羣。 用戶指望着毫秒級的響應時間，以及服務100%正常運行（隨時可用）。 而數據則以PB計量。 昨日的軟件架構已經根本沒法知足今天的需求。

咱們相信你們須要一套貫通整個系統的架構設計方案， 而設計中必須要關注的各個角度也已被理清： 咱們須要系統具有如下特質：即時響應性（Responsive）、回彈性（Resilient）、彈性（Elastic）以及消息驅動（Message Driven）。 對於這樣的系統，咱們稱之爲反應式系統（Reactive System）。

使用反應式方式構建的反應式系統會更加靈活、鬆耦合、可伸縮。 這使得它們的開發和調整更加容易。 它們對系統的失敗 也更加的包容， 而當失敗確實發生時， 它們的應對方案會是得體處理而非混亂無序。 反應式系統具備高度的即時響應性， 爲用戶提供了高效的互動反饋。

反應式系統的特質:

即時響應性: ：只要有可能， 系統就會及時地作出響應。 即時響應是可用性和實用性的基石， 而更加劇要的是，即時響應意味着能夠快速地檢測到問題而且有效地對其進行處理。 即時響應的系統專一於提供快速而一致的響應時間， 確立可靠的反饋上限， 以提供一致的服務質量。 這種一致的行爲轉而將簡化錯誤處理、 創建最終用戶的信任並促使用戶與系統做進一步的互動。

回彈性：系統在出現失敗時依然保持即時響應性。 這不只適用於高可用的、 任務關鍵型系統——任何不具有回彈性的系統都將會在發生失敗以後丟失即時響應性。 回彈性是經過複製、 遏制、 隔離以及委託來實現的。 失敗的擴散被遏制在了每一個[組件](/glossary.zh-cn.md#組件)內部， 與其餘組件相互隔離， 從而確保系統某部分的失敗不會危及整個系統，並能獨立恢復。 每一個組件的恢復都被委託給了另外一個（外部的）組件， 此外，在必要時能夠經過複製來保證高可用性。 （所以）組件的客戶端再也不承擔組件失敗的處理。

彈性： 系統在不斷變化的工做負載之下依然保持即時響應性。 反應式系統能夠對輸入（負載）的速率變化作出反應，好比經過增長或者減小被分配用於服務這些輸入（負載）的資源。 這意味着設計上並無爭用點和中央瓶頸， 得以進行組件的分片或者複製， 並在它們之間分佈輸入（負載）。 經過提供相關的實時性能指標， 反應式系統能支持預測式以及反應式的伸縮算法。 這些系統能夠在常規的硬件以及軟件平臺上實現成本高效的彈性。

消息驅動：反應式系統依賴異步的消息傳遞，從而確保了鬆耦合、隔離、位置透明的組件之間有着明確邊界。 這一邊界還提供了將失敗做爲消息委託出去的手段。 使用顯式的消息傳遞，能夠經過在系統中塑造並監視消息流隊列， 並在必要時應用回壓， 從而實現負載管理、 彈性以及流量控制。 使用位置透明的消息傳遞做爲通訊的手段， 使得跨集羣或者在單個主機中使用相同的結構成分和語義來管理失敗成爲了可能。 非阻塞的通訊使得接收者能夠只在活動時才消耗資源， 從而減小系統開銷。

大型系統由多個較小型的系統所構成， 所以總體效用取決於它們的構成部分的反應式屬性。 這意味着， 反應式系統應用着一些設計原則，使這些屬性能在全部級別的規模上生效，並且可組合。世界上各種最大型的系統所依賴的架構都基於這些屬性，並且天天都在服務於數十億人的需求。如今，是時候在系統設計一開始就有意識地應用這些設計原則了， 而不是每次都去從新發現它們。