Reactive宣言的思考

banq發表於2014-04-18


這篇博文是關於著名的Rective宣言的再思考,或者可以認為是簡單總結擴充。

Reactive反應式程式設計是軟體發展的一個新趨勢,在過去幾年中聚集了很多的技術鑑賞家的熱情。按照Reactice宣言,有下面Reactvie之道:

1. 反應到事件react to events – 事件驅動event-driven的自然特性啟用了其隨後的各種特性。

2.反應到載入react to load – 透過避免金多執行緒對共享資源的競爭鎖爭奪實現可擴充套件性

2.反應到失敗react to failure – 彈性系統能夠在任何級別滿血復活。

3.反應到使用者react to users – 無論負載多高,都有傲人的響應時間。

事件驅動
事件驅動的應用程式由傳送和接收事件進行通訊的元件組成。事件是非同步傳遞,通常使用一個基於推送的通訊模型,事件不會發生阻塞。一個關鍵目標是要能夠有效地利用系統資源,不能佔用不必要的資源,最大限度地提高資源共享。

反應的應用是建立在分散式架構中,訊息傳遞提供了節點間通訊層和元件位置透明性。這也使部件和子系統之間的介面是基於松耦合的設計,從而使系統更容易隨時間的變化。

系統設計依賴於共享可變狀態,資料訪問和操作是透過使用併發控制機制,以避免資料完整性發生問題。併發控制機制是並行系統某種限制版。 Amdahl定律制定明確降低程式程式碼的並行會限制系統的可擴充套件性。避免共享可變狀態允許更高的並行度,從而達到更高程度的可擴充套件性和資源共享(如資料庫資源等)。


Scala可擴充套件性
系統架構需要小心地設計成橫向擴充套件或者向上擴充套件,以便能夠利用節點的並行的硬體趨勢(CPU和nb的數目增加。nb是一個CPU內的物理和邏輯核心)和系統級並行(節點的數目)。垂直和水平縮放應該是雙向的,所以彈性系統也能夠在雙向擴充套件,從而最佳化運營成本。

彈性構建的關鍵是透過由訊息傳遞提供的分散式架構和節點到節點的通訊機制,允許子系統進行配置,無需修改程式碼在同一個節點上或在不同的節點上執行(也就是位置透明性實現)。


彈性Resilient
一個彈性系統在系統的一個或多個部分發生故障的情況下將繼續發揮作用,包括不可預測的的條件(如意外的負載)。該系統需要精心設計,包含明確和安全的封裝故障,防止故障進一步升級和級聯失控。

響應Responsive
響應由韋氏定義為“快速回應或作出適當的反應。”
應用程式使用可觀察的模型,事件流和有態客戶端。
當狀態變化,觀察的模型讓其他系統接收事件。
..


評論
如果你在過去幾年能積極瞭解軟體的發展趨勢,那麼該宣言說的想法似乎很熟悉。這是因為宣言總結了軟體開發社群在建設網路規模的系統見解。

很多教訓源於分散式系統進行集中儲存狀態。在分散式系統中的一致性模型權衡已經被CAP定理解釋。CAP的見解讓開發人員在一致性、可用性和分割槽容忍性之間進行權衡考慮。近年來寬鬆的一致性模型已經得到普及,特別是NoSQL資料庫不同的品種。

而相對資料庫,應用程式的一致性模型對系統的可伸縮性和可用性同樣產生重大影響,宣言更明確地解決了這一問題。一致性模型應該是一個縱向方面,應該在系統的所有的層面都必須被考慮設計。

事件驅動是一種廣泛使用在程式設計中的術語,有許多不同的含義,並有多種變化。可以用不同的非同步通訊方法來實現。在反應宣言“非同步通訊”是使用訊息傳遞,如在訊息系統或Actor模型,而不是非同步函式或非同步方法呼叫。

反應宣言中採用並結合的思想從CAP理論, NoSQL,事件驅動的多種架構。它總結了開發社群在建設網路規模應用的經驗教訓。該宣言有很大的意義,但是該宣言可能比較晦澀。如果沒有在可擴充套件性問題方面擁有豐富經驗的開發人員可能難以理解,這樣就可能錯過或誤解這一偉大思想。

相關參考:

使用Akka實現Reactive DDD

相關文章