2015/9/7

The Reactive Manifesto 響應式宣言

作者 Matin Thompson 在 InfoQ 談到 為什麼要有 Reactive Manifesto 2.0 ,對於我們來說,透過這樣的宣言,讓我們意識到系統架構以及程式語言,必須因應時代的更迭,提出新的架構與設計,也可以說是一種 Reactive System/Architecture。

The Reactive Manifesto 響應式宣言

The Reactive Manifesto, September 16 2014 (v2.0)

響應式宣言 中文版

現在的系統以大量的 muticore 處理器處理,使用者預期的是數毫秒的反應時間,以及永不中斷的線上服務,資料量達到 PB 的規模。我們需要一個協調一致的 Reactive System,這樣的系統有 flexible 彈性、lossely-coupled 鬆耦合與 scalable 可擴展性的表現,並具有以下四個特性:

  1. Responsive 響應式
    系統在任何情況下,都能及時響應,在可靠的時間內提供訊息且有穩定品質的服務。

  2. Resillient 韌性、堅固
    系統在失敗時,仍然保有 Responsive 特性。這是由 replication 複製, containment 容忍, isolation 隔離以及 delegation 委託的方式達成的。系統的任何組件發生問題時,可以隔離此部份,並獨立恢復,過程中不會影響整個系統。

  3. Elastic 彈性
    系統能即時量測效能,可透過演算法增加或減少服務的資源分配,滿足不同工作負載量的系統要求。

  4. Message Driven 訊息驅動
    組件之間透過非同步訊息傳遞方式互相溝通,用以確保 loose coupling 鬆耦合, isolation 隔離, location transparency 與區域無關的特性。還能提供錯誤訊息的委託處理機制。



由圖片可得知,這四個特性是以 Message Driven 為基礎,並以 Responsive 為終極目標,Elastic 跟 Resilient 像是天平的兩端,需要架構師權衡架構,在提供更多彈性的系統要求下,還能讓系統保持穩定。

Enterprise Application Integration Patterns: Messaging Patterns

Messaging Patterns Overview

因為企業內部有很多樣化的資訊系統,但通常系統之間會缺乏資料傳遞與整合的溝通管道,就算有了傳遞的管道,每一個系統的效能瓶頸以及運算時間不同,也會影響到應用整體的表現。

EAI (Enterprise Application Intergartion) Patterns 專門討論在企業內部該用什麼方法來整合不同的資訊系統,而其中所有 Pattern 的核心就是使用 Message Queue 系統。

Message Queue 的用意在於協調兩端的處理速度,道理就像是健康檢查,檢查時會區分不同的專業檢查診間,每個診間的處理速度不同,因此會有不同長度的排隊序列,每一個參加健康檢查的人,最終的目的就是要到最後一關醫生問診的地方,結束整個健康檢查的流程。

Reactive System 跟 EAI 的背後的概念是相同的,就是要將整個 end-to-end 的需求,依照不同的應用特性切割成特定的應用模組,然後在模組之間,以 MQ 來協調並同步處理的結果,然後一次將結果輸出給前端使用者。

Message Queue 的應用已經不單只是以獨立的 MQ System 存在,現在的趨勢,也有內建在程式語言中的趨勢,過去熱門的程式語言都是以 Multithread 以及共享記憶體的方式,進行多工處理,現在的趨勢也轉換成 Actor Concurrency Model,以訊息佇列來區隔不同的內部模組,以因應不同模組的處理速度。

設計 -> 切割 + 分析 -> 實作

京東技術架構(一)構建億級前端讀服務

京東技術架構(二)構建需求響應式億級商品詳情頁

這兩篇文章,可看成 Reactive System Architecture 的一個實際例子,京東商城 是中國一家 B2C 的購物網站,就跟一般購物的網站一樣,它必須因應中國的節日產生的大量購物流量,不斷地更新自己的系統架構,達到 Reactive System 的基本要求:反應速度快,系統不斷線,客戶是不會等人的。

從文章中可以看到,他們的整個商品頁面先有設計之後,再將頁面的功能,進行分析並切割成多個部份,根據商業應用的要求,決定該怎麼實作。

系統實作的過程,歷經了三個版本的更新,一樣是以 MQ 為核心,將頁面的工作拆散後,丟給多個商業邏輯集群,在最後進行頁面整合,丟給前端的使用者查看頁面。