程序員務必知悉:這五大關於反應式編程的關鍵點!
Reactive?反應式編程?在這篇文章中,我們將討論反應式編程,即圍繞非同步數據流構建的開發模型。
很多程序員編寫第一個反應式應用程序時都是極不耐煩的,但在做這些之前,有幾件事要清楚。使用反應式編程可改變設計和編寫代碼的方式,在這篇文章中,我們將解釋關於反應式編程的5件事情,看看對你有什麼意義。
1、反應式編程是用非同步數據流進行編程
使用反應式編程時,數據流將成為應用程序的脊柱。事件、消息、呼叫甚至故障都由數據流傳達。使用反應式編程,程序員可觀察這些數據流,並在值發生變化時作出反應。
所以,在代碼中,程序員可以創建任何數據流,包括點擊事件、HTTP請求、獲取消息、可用性通知、變數變化、緩存事件、感測器測量值等等......這對應用程序有一個有趣的副作用:它本質上是非同步的。
Reactive eXtension (http://reactivex.io,a.ka.RX)通過使用可觀察序列來組合非同步和基於事件的程序反應原理的實現。使用RX,代碼將會創建並訂閱名為Observables的數據流。RX同時提供了一個了不起的工具箱,程序員有一個功能集合來組合、合併、過濾、轉換和創建數據流。下圖說明了在Java中使用RX的情況(使用https://github.com/ReactiveX/RxJava)。
雖然RX不是唯一的反應式編程實現(例如我們可以引用BaconJS - http://baconjs.github.io),但它是今天最常用的。在這篇文章的其餘部分,我們將使用Rx Java。
2、Observables 數據流的冷熱很重要
程序員或許在嘗試查看將在程序中處理的不同流(或可觀測值)是什麼樣子的。但有兩類流:冷和熱。了解其差異是成功使用反應式編程的關鍵。
冷Observables數據流是懶惰的。除非有人開始使用它們,否則不會做任何事情(在RX中訂閱)。它們只在消耗時才開始運行,冷流用於表示非同步操作,例如,直到某人對結果感興趣才會執行它。另一個例子是文件下載,如果沒有人要對數據做某事,它不會開始提取位元組。冷流產生的數據在用戶之間不共享,訂閱之後將獲得所有的項目。
熱數據流在訂閱之前是活躍的,如股票行情,或感測器,或用戶發送的數據。數據獨立於單個用戶,當程序員訂閱熱Observables 時,它將獲得在訂閱之後發出的流中的所有值。這些值在所有用戶之間共享。例如,即使沒有人訂閱溫度計,它也會測量和發布當前的溫度。當用戶註冊流時,它會自動接收下一個值的數據。
為什麼要了解你的流是熱還是冷的呢?因為它會改變代碼消耗傳送項目的方式。如果沒有訂閱熱流,程序員將不會收到數據,並且此數據會丟失。
3、濫用非同步
反應式編程定義中有一個重要的單詞:非同步。當數據流以非同步方式發送時,程序員將被通知——獨立於主程序流。通過圍繞數據流構建程序,在流發出新項目時編寫調用的代碼。線程,代碼阻塞和副作用在這種情況下是非常重要的事情,我們從副作用開始吧。
沒有副作用的函數僅通過其參數和返回值與程序的其餘部分進行交互。副作用可能非常有用,在許多情況下是不可避免的,但也有陷阱。使用反應式編程時,應避免不必要的副作用,並在使用它們時有明確的意圖。雖然有些情況是合理的,但濫用副作用會引發線程安全問題。
第二個重點:線程。數據流一切正常,但程序員不知道功能被執行在哪個線程上了。建議避免在程序中使用太多線程,依賴於多個線程的非同步程序將成為一個艱難的同步難題,通常以死鎖結尾。
第三點:避免代碼阻塞。通過組合RX和非同步IO,程序員可以編寫非阻塞代碼所需的全部內容,如果需要更多內容,請查看Eclipse Vert.x,這是一個提高反應式和非同步反應式的工具包。例如,以下代碼顯示了Vert.x Web Client及其RX API,用於從伺服器檢索JSON文檔並顯示名稱條目:
注意在最後一個片段中的subscribe方法。當其中一個處理階段引發異常時,需要第二種方法。要學會捕捉異常,如果不這樣做,程序員可能會花幾個小時來弄清楚出了什麼問題。
4. 讓問題簡單化
RX提供了很多非常酷的功能, Chainingflapmap、重試......但是,永遠不要忘記,好的代碼需要具備可讀性。
我們來看一些代碼:
給出一個這樣的例子很難理解嗎?它鏈接了幾個非同步操作(flatmap),加入了另一組操作(zip)。 反應式編程代碼首先需要思考,通知非同步事件。然後,API可能很難掌握(只看運算符列表)。不濫用,寫注釋或繪製圖表。RX是強大的,濫用或不注釋會使你的同事脾氣暴躁。
5.反應式編程不等於反應式系統
這可能是最令人困惑的部分。使用反應式編程不會構建一個反應式系統。反應式定義的反應式系統是構建響應式分散式系統的架構風格。反應系統可以看作是正確的分散式系統,反應系統的特點是四個性質:
響應:反應式系統需要在合理的時間內處理請求(程序員要合理定義)。
彈性:反應式系統必須面對失敗保持響應(崩潰,超時,錯誤...),因此它必須設計在故障時適當地處理bug。
伸縮:反應式系統必須在各種負載下保持響應。因此,它必須擴展和縮小,並且能夠以最少的資源來處理負載。
消息驅動:來自反應式系統的組件使用非同步消息傳遞進行交互。
儘管這些反應系統的基本原理很簡單,但建立其中任何一個都是棘手的。通常,每個節點需要採用非同步非阻塞開發模型,基於任務的並發模型,並使用非阻塞I / O。如果不先考慮這些問題,那麼很快就會失敗。
反應式編程和反應擴展提供了一個馴服非同步的開發模型。明智地使用它,代碼將保持可讀性和可理解性。然而,使用反應式編程不會將系統轉變為反應系統,反應式系統是一個新的水平。
如果對反應式系統感興趣,可以查看Eclipse Vert.x,構建反應和分散式系統(http://vertx.io)的工具包,結合Vert.x和Reactive eXtension可以釋放反應式超能力。程序員不僅可以使用反應式編程,還可以構建反應式系統,並可以訪問一個令人興奮和不斷增長的生態系統。
Happy coding!
※別不服!Flash開源項目已獲5000餘人支持,Adobe還頂得住嗎?
※李彥宏和馬化騰的眼光不如馬雲 從七年前對雲計算的態度就能看出
※30台美國大選投票機成黑客「玩物」 90分鐘變自動點唱機
※自動分割歸檔管理 柯尼卡美能達掃描方案優化工作流程
※AMD進擊人工智慧:Project 47超級伺服器亮相
TAG:IT168企業級 |
※小程序自定義關鍵詞正式關閉
※應對程序員面試,你必須知道的8大數據結構
※程序員為什麼焦慮於編程語言和框架?
※程序員,你能真正掌握多少編程技術?
※關於程序設計的一些基本原則
※雙手無法敲代碼的程序員,該如何編程?
※關愛程序員,從產品經理做起!
※解讀有關小程序的十個問題,告訴你入局小程序的意義!
※互聯網協會理事:區塊鏈的關鍵應用將是把「利益」定義和程序化了
※技術面試時,程序員需要什麼樣的編程測試?
※趣圖說明程序員和測試之間的關係
※關於小程序的那些你不知道的事
※程序員嘗試理解一門新編程語言的時候
※編程測試,程序員過不去的坎?
※為什麼程序員下班後只關顯示器從不關電腦?
※程序員面試官何苦為難程序員!
※小程序生態的關鍵節點
※電腦應用程序常見的錯誤問題,應該這樣解決不行試試
※阿里的程序員們如何解決複雜數據的查詢優化問題?
※程序員如何解決線程中斷引發的那些問題?