顯示具有 Reactive Programming 標籤的文章。 顯示所有文章
顯示具有 Reactive Programming 標籤的文章。 顯示所有文章

2015/09/07

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 為核心,將頁面的工作拆散後,丟給多個商業邏輯集群,在最後進行頁面整合,丟給前端的使用者查看頁面。

2015/08/31

Reactive Programming 響應式程式設計方法

Reactive Programming 是以 data flow 以及傳遞資料改變這兩點為核心,提出的一種 programming paradigm,尤其在 GUI Programming 的領域中,簡易的 Reactive Programming Model,讓 Programmer 能用更直覺的方式,取得資料的串流,並能跟著時間的流動,改變整個畫面的呈現結果。

Imperative vs Reactive Programming

在程式中,如果寫下

b:=2;
c:=3;
a:=b+c
// a 為 5

這個 statement,這時候 a 的結果就會等於 b+c 的運算結果,也就是 5。

然而如果在後面 b 或 c 改變了自己的數值

b:=3;
// a 為 5 或 6?

程式並 "沒有" 再寫一次 a:=b+c,如果 a 還是一樣保持不變,還是等於 5,這就是 imerative programming。

但是如果 a 自動跟著 b 的數值改變,自動再次運算了 b+c,a 自動變成了 6,這就是 reactive programming。

Excel, Spreadsheet

Reactive Programming 乍看起來有點奇怪,這跟我們學習過的程式語言 C 或是 Java 根本都不一樣,變數不應該隨著另一個變數自動改變自己。

但其實有用過 Office Excel 或是其他 Spreadsheet 試算表軟體的使用者,就已經是在做 Reactive Programming了。

在下面的例子中,C1 設定為 A1 + B1 這兩個儲存格的總和,當 A1 的數值改變時,C1 也會自動改變結果。

Office Excel 是辦公室的試算軟體,換句話說,Reactive Programming 其實是比較人性化的程式設計方法,而 Imperative Programming 是為了避免程式設計師撰寫程式時出錯,而刻意將自己簡化的結果。

畢竟當我們撰寫程式時,寫下這樣的 statements 的時候,沒有一個人會直覺地認為 a 的結果會是 6,因為大腦線性運算的結果,只會記得 a 是 5。

b:=2;
c:=3;
a:=b+c
b:=3;

那為什麼又討論起 Reactive Programming 呢?這跟最近幾年流行起來的 Functional Programming 有關係。

Functional Reactive Programming

回到剛剛的 Excel 範例,其實 C1 儲存格隱藏著一個意義,就是 C1 := SUM(A1 + B1),C1 永遠會等於後面這個 function 的運算結果。

在不支援 Reactive Programming 中,要實作出 Reactive 的功能,必須要用 Observer Design Pattern,程式中向原始資料,註冊 Observer,當原始資料異動時,就會呼叫 Observer 的 Lisener Function,主動進行對應的資料異動處理。

也許有人會想,Functional Programming 的基本原則,變數應該都是 immutable value,為什麼會有 Functional Reactive Programming 呢?

Functional Programming 將 Function 視為 first class citizens,而 Function Reactive Programming 並不是單純地將 Reactive 的概念用在變數上,而是將資料視為一個 time-varying values,依照時間變動的數值。

這個互動模式最常見於 GUI 的實作上,FRP 定義了兩種會跟著時間改變的資料:events 與 behaviors。

  • events 代表一個特定時間的數值,例如使用者在鍵盤上敲了一個鍵,就產生了一個 Event Char,並以 (t, 'a') 來表示這個 event。實際上的程式並不直接處理 event,而是處理 event stream,因為時間的連續性,讓鍵盤輸入資料也變成了一個無限的資料串流。

  • behaviors 代表跟著時間持續變動的數值,例如滑鼠游標的位置,因為滑鼠的位置是永遠存在的,而且永遠一直在改變,所以我們可隨著時間的流動,持續取得滑鼠的位置串流。

針對跟著時間流動產生的數值串流寫的程式,其實不需要 Functional Language 也可以撰寫,將 Functional 結合 Reactive Programming 的優勢在於,Functional Language 能夠直接 function 來進行運算,而這個 function 恰好可以表示有著無限資料的 stream,這可簡化大量的程式語法。

ELM Programming Language

網頁是目前最常見的 GUI,以往我們需要了解 html, css, javascript,還要知道怎麼操作 DOM Tree,讀了一堆東西,才算是知道怎麼撰寫網頁程式。

ELM 程式語言,是針對網頁 UI 設計的一種 Functional Reactive Programming Language,他可以即時編譯成 html 與 javascript,因此可以打包放到網頁上運作。

我們可以直接看一下 Mouse Example,簡單的一個 statement: Mouse.position 就可以持續取得滑鼠的位置。

為什麼要提到 Game 呢?因為網頁的遊戲開發,如果使用 javascript,將會耗費 programmer 相當多的時間,也許可以採用某個 javascript framework簡化開發,而 ELM 是直接用另一種程式語言的方式,取代掉繁瑣的 javascript。

看看這兩個實際的例子,就能實際感受到,簡潔的語法帶來的開發優勢:
Mario
Elmtris

References

也談響應式編程

遊戲編程的未來——FRP(函數式反應型編程)

Reactive Programming wiki

Reactive programming - 響應式編程

關於 Elm 的分享, 底稿

使用函數式編程語言 ELM 開發遊戲

FRP與函數式

The introduction to Reactive Programming you've been missing

Functional Reactive Programming (FRP)

Quora: What is Functional Reactive Programming

An Introduction to Functional Reactive Programming