作者 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 可擴展性的表現，並具有以下四個特性：
Responsive 響應式
系統在任何情況下，都能及時響應，在可靠的時間內提供訊息且有穩定品質的服務。Resillient 韌性、堅固
系統在失敗時，仍然保有 Responsive 特性。這是由 replication 複製, containment 容忍, isolation 隔離以及 delegation 委託的方式達成的。系統的任何組件發生問題時，可以隔離此部份，並獨立恢復，過程中不會影響整個系統。Elastic 彈性
系統能即時量測效能，可透過演算法增加或減少服務的資源分配，滿足不同工作負載量的系統要求。Message Driven 訊息驅動
組件之間透過非同步訊息傳遞方式互相溝通，用以確保 loose coupling 鬆耦合, isolation 隔離, location transparency 與區域無關的特性。還能提供錯誤訊息的委託處理機制。
由圖片可得知，這四個特性是以 Message Driven 為基礎，並以 Responsive 為終極目標，Elastic 跟 Resilient 像是天平的兩端，需要架構師權衡架構，在提供更多彈性的系統要求下，還能讓系統保持穩定。
Enterprise Application Integration Patterns: Messaging Patterns
因為企業內部有很多樣化的資訊系統，但通常系統之間會缺乏資料傳遞與整合的溝通管道，就算有了傳遞的管道，每一個系統的效能瓶頸以及運算時間不同，也會影響到應用整體的表現。
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 為核心，將頁面的工作拆散後，丟給多個商業邏輯集群，在最後進行頁面整合，丟給前端的使用者查看頁面。
沒有留言:
張貼留言