天天看點

Reactive Programming 響應式程式設計

Scala Reactive Programming 響應式程式設計

Functional Reactive Programming (FRP), we will first understand the meaning of Reactive and Reactive programming

in this section.

什麼是響應?

反應意味着及時對變化作出反應或及時響應變化。

在這裡,在Reactive World中,我們可以将變化表示為事件。是以,我們還可以将Reactive定義為及時響應事件。此更改可能發生在資料或資料元素上。

每當我們的系統發生變化時,系統應立即對這些變化做出及時的反應。在目前世界中,使用者期望快速且及時地響應來自應用程式(網站,Web應用程式,移動應用程式等)的響應。如果系統或應用程式沒有及時響應使用者(或客戶),使用者将尋找其他選項,我們的應用程式将失去其使用者。

什麼是反應式程式設計?

與指令式程式設計(IP)或(面向對象程式設計)OOP不同,我們根據行或語句的順序編寫代碼,在反應式程式設計(RP)中,我們根據事件編寫代碼或程式。

簡單來說,RP意味着使用事件編寫程式,或RP意味着編寫定義如何對事件做出反應的程式。 正如我們所讨論的,事件是程式或應用程式狀态的變化。 是以我們也可以如下定義RP:反應式程式設計是一種傳播變化的程式設計範式。

讓我們讨論一個重要且經常使用的RP示例(幾乎所有書籍或教程都使用相同的場景)。 考慮以下電子表格應用程式的示例:觀察A3單元格具有公式= A1 A2,即A3是單元格A1和A2的值的總和。最初,A3的值為0.當我們更改單元格A1或A2或兩者的值時,電子表格會更新A3的值:

什麼是資料流或流?

在反應式程式設計中,我們編寫程式來處理一系列事件。例如,在電子表格中,我們可以按順序觀察以下事件:

Reactive Programming 響應式程式設計

1。使用者在單元格A1中輸入值1。當使用者将資料輸入到單元格A1中時,單元格A3中的值更新為1。

2. 使用者在單元格A2中輸入值2。當使用者将資料輸入到單元格A2時,A3被更新為3。

在Reactive World中,随時間發生的這一系列事件稱為流,事件流或資料流。下圖顯示了事件序列如何形成事件流。它還顯示了釋出伺服器如何将事件發送到事件流以及訂閱伺服器如何從該事件流接收事件:流或資料流是按時排序的一系列正在進行的事件。

在RP中,釋出者将事件發送到Stream,訂閱者從Stream中使用這些事件。

為了對事件做出反應,我們應該監控它們。在RP中,監視事件的過程稱為偵聽事件或訂閱事件。

我們還可以使用此資料流定義RP:RP是使用異步資料流進行程式設計的程式設計範例。

事件流=一系列事件

RP與Reactive系統與Reactive架構的對比

反應系統是一組反應性互相通信的元件。通過将這些單獨的元件合二為一,我們可以形成一個現代的分布式系統。我們可以通過遵循一系列架構設計原則來開發Reactive系統。

反應系統元件作為單個系統工作,它們及時對變化做出反應。

反應系統或反應應用程式具有以下功能:

響應能力:他們及時對使用者做出反應

彈性:它們對負載做出反應 Elasticity: They react to load

恢複性:他們對失敗做出反應Resilience: They react to failures

消息驅動:它們對事件或消息做出反應

反應式架構是一種設計反應式系統的技術或過程。

我們可以使用許多技術開發反應系統。但是,RP或FRP是建構Reactive系統的最佳工具。

Reactive系統的核心原則是使用消息驅動方法開發其元件,而RP則是使用事件編寫程式,這意味着它遵循事件驅動方法。

正如我們所說,反應系統是一組元件。我們在元件級别使用RP,這意味着我們使用RP開發每個元件。

我們在系統級使用Reactive系統。

事件驅動與MessageDriven。

RP的核心原則是事件驅動方法,而Reactive系統的核心原則是消息驅動方法。

RP僅在元件級别提供優勢,因為事件是在本地發出和處理的。 它們無法在分布式系統中跨網絡工作。

反應系統為我們提供了系統級的好處,因為消息在分布式系統中通過網絡進行處理和通信。

我們無法通過RP獲得全部好處; 我們應該使用RP和Reactive系統的組合。

在具有RP的反應系統中,生成的事件在引擎蓋下表示為消息,并将它們作為消息處理。

RP反應系統的優點

當我們使用RP作為程式設計範例來開發Reactive系統的元件時,我們将獲得更多的好處。 RP和Reactive系統的組合為我們帶來以下好處:

自我修複:根據Reactive Streams規範,RP應該

支援彈性。這意味着我們可以在一個中編寫Reactive系統

他們有一些技術可以從失敗中恢複的方式

繼續努力回應客戶。這被稱為

自愈。客戶不會知道這一點,他們永遠不會看到

那些失敗。

高度可用的系統:根據Reactive Streams規範,

RP應支援彈性(向上/向下擴充和向外擴充/向内擴充)。這個

意味着我們可以以始終可用的方式編寫反應系統。他們支援100%的正常運作時間。

高度可擴充,可支援重載。

松耦合。

有效利用系統資源(包括硬體和軟體)。

提供更好的響應能力。

提供實時行為或資料流。

易于執行分布式資料處理。

支援位置透明度。

低延遲。

更好的性能。

易于維護。

不需要使用匿名回調(是以沒有更多的回調地獄)。

易于解決和處理故障。

容易理由失敗。

我們還應該了解迫使我們開發和使用Reactive系統的事情:

物聯網(物聯網)

雲環境或服務

大資料系統

實時快速資料流

移動架構

異構系統之間的通信

多核硬體架構

在這裡,Reactive系統意味着Reactive Web Applications,

反應性應用程式和反應式微服務。在我看來,所有人都有相同的含義。