Reactive Programming

Reactive的表現
Reactive 規範是 JVM Reactive 擴展規範 Reactive Streams JVM，而 Reactive 實現框架則是最典型的實現：

Reactive Streams /Java 9
一個很是底層的約定，提供了Publisher和Subscriber接口。 Java 9 提供了Flow API 的支持

Spring Framework 5.0 / Reactor
Spring 5，以 Reactive 爲基礎的Reactor框架 ，逐步構建一套完整的 Reactive 技術棧，例如 WebFlux，相似於Spring MVC的功能

RxJava
Netflix開源的技術

爲何會出現
這些實現都是怎麼說的
reactor
http://projectreactor.io/docs/core/release/reference/#_blocking_can_be_wasteful
3.1. Blocking Can Be Wasteful
阻塞致使性能瓶頸和浪費資源
增長線程可能會引發資源競爭和併發問題
並行的方式不是銀彈（不能解決全部問題）

理解阻塞的弊端

理解並行的複雜

異步
3.2. Asynchronicity to the Rescue?
Callbacks 是解決非阻塞的方案，然而他們之間很難組合，而且快速地將代碼引導至 "Callback Hell" 的不歸路
Futures 相對於 Callbacks 好一點，不過仍是沒法組合，不過 CompletableFuture 可以提高這方面的不足

理解 "Callback Hell"

Future 的限制
阻塞 鏈式
CompletableFuture 不只能夠支持 Future 鏈式操做，並且提供三種生命週期回調，即執行回調（Action）、完成時回調（Complete）、和異常回調（Exception），相似於 Spring 4 ListenableFuture 以及 Guava ListenableFuture。

Reactive Streams JVM . http://www.reactive-streams.org/

認爲異步系統和資源消費須要特殊處理
流式數據容量難以預判
異步編程複雜
數據源和消費端之間資源消費難以平衡

 

什麼是 Reactive Programming
關於什麼是 Reactive Programming，下面給出六種渠道的定義，嘗試從不一樣的角度，瞭解 Reactive Programming 的意涵。首先了解的是「The Reactive Manifesto」 中的定義

The Reactive Manifesto 中的定義
Reactive Systems are: Responsive, Resilient, Elastic and Message Driven.

https://www.reactivemanifesto.org/

該組織對 Reactive 的定義很是簡單，其特色體如今如下關鍵字：

響應的（Responsive）
適應性強的（Resilient）
彈性的（Elastic）
消息驅動的（Message Driven）
不過這樣的定義側重於 Reactive 系統，或者說是設計 Reactive 系統的原則。

維基百科中的定義
維基百科做爲全世界的權威知識庫，其定義的公允性可以獲得保證：

Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm it is possible to express static (e.g. arrays) or dynamic (e.g. event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow.

參考地址：https://en.wikipedia.org/wiki/Reactive_programming

維基百科認爲 Reactive programming 是一種聲明式的編程範式，其核心要素是數據流（data streams ）與其傳播變化（ propagation of change），前者是關於數據結構的描述，包括靜態的數組（arrays）和動態的事件發射器（event emitters）。由此描述，在小馬哥腦海中浮現出如下技術視圖：

數據流：Java 8 Stream
傳播變化：Java Observable/Observer
事件/監聽：Java EventObject/EventListener
這些技術可以很好地知足維基百科對於 Reactive 的定義，那麼， Reactive 框架和規範的存在乎義又在何方？或許以上定義過於抽象，還沒法詮釋 Reactive 的全貌。因而乎，小馬哥想到了去 Spring 官方找尋答案，正如所願，在 Spring Framework 5 官方參考文檔中找到其中定義。

Spring 5 中的定義
The term "reactive" refers to programming models that are built around reacting to change — network component reacting to I/O events, UI controller reacting to mouse events, etc. In that sense non-blocking is reactive because instead of being blocked we are now in the mode of reacting to notifications as operations complete or data becomes available.

參考地址：https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-why-reactive

相對於維基百科的定義，Spring 5 WebFlux 章節一樣也提到了變化響應（reacting to change ） ，而且還說明非阻塞（non-blocking）就是 Reactive。同時，其定義的側重點在響應通知方面，包括操做完成（operations complete）和數據可用（data becomes available）。Spring WebFlux 做爲 Reactive Web 框架，自然支持非阻塞，不過早在 Servlet 3.1 規範時代皆以實現以上需求，其中包括 Servlet 3.1 非阻塞 API ReadListener 和WriteListener，以及 Servlet 3.0 所提供的異步上下文 AsyncContext 和事件監聽 AsyncListener。這些 Servlet 特性正是爲 Spring WebFlux 提供適配的以及，因此 Spring WebFlux 能徹底兼容 Servlet 3.1 容器。小馬哥不由要懷疑，難道 Reactive 僅是新包裝的概念嗎？或許就此下結論還爲時尚早，不妨在瞭解一下 ReactiveX 的定義。

ReactiveX 中的定義
普遍使用的 RxJava 做爲 ReactiveX 的 Java 實現，對於 Reactive 的定義，ReactiveX 具有至關的權威性：

ReactiveX extends the observer pattern to support sequences of data and/or events and adds operators that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O.

參考地址：http://reactivex.io/intro.html

不過，ReactiveX 並無直接給 Reactive 下定義，而是經過技術實現手段說明如何實現 Reactive。ReactiveX 做爲觀察者模式的擴展，經過操做符（Opeators）對數據/事件序列（Sequences of data and/or events )進行操做，而且屏蔽併發細節（abstracting away…），如線程 API（Exectuor 、Future、Runnable）、同步、線程安全、併發數據結構以及非阻塞 I/O。該定義的側重點主要關注於實現，包括設計模式、數據結構、數據操做以及併發模型。除設計模式以外，Java 8 Stream API 具有很多的操做符，包括迭代操做 for-each、map/reduce 以及集合操做 Collector等，同時，經過 parallel() 和 sequential() 方法實現並行和串行操做間的切換，一樣屏蔽併發的細節。至於數據結構，Stream 和數據流或集合序列能夠畫上等號。惟獨在設計模式上，Stream 是迭代器（Iterator）模式實現，而 ReactiveX 則屬於觀察者（Observer）模式的實現。 對此，Reactor 作了進一步地解釋。

Reactor 中的定義
The reactive programming paradigm is often presented in object-oriented languages as an extension of the Observer design pattern. One can also compare the main reactive streams pattern with the familiar Iterator design pattern, as there is a duality to the Iterable-Iterator pair in all of these libraries. One major difference is that, while an Iterator is pull-based, reactive streams are push-based.

http://projectreactor.io/docs/core/release/reference/#intro-reactive

一樣地，Reactor 也提到了觀察者模式（Observer pattern ）和迭代器模式（Iterator pattern）。不過它將 Reactive 定義爲響應流模式（Reactive streams pattern ），並解釋了該模式和迭代器模式在數據讀取上的差別，即前者屬於推模式（push-based），後者屬於拉模式（pull-based）。難道就由於這因素，就要使用 Reactive 嗎？這或許有些牽強。我的認爲，以上組織均沒有坦誠或者簡單地向用戶表達，都採用一種模糊的描述，多少不免讓人以爲故弄玄虛。幸運地是，我從 ReactiveX 官方找到一位前端牛人 André Staltz，他在學習 Reactive 過程當中與小馬哥同樣，吃了很多的苦頭，在他博文《The introduction to Reactive Programming you've been missing》中，他給出了中肯的解釋。

André Staltz 給出的定義
Reactive programming is programming with asynchronous data streams.

In a way, this isn't anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events. Streams are cheap and ubiquitous, anything can be a stream: variables, user inputs, properties, caches, data structures, etc.

"What is Reactive Programming?"

他在文章指出，Reactive Programming 並非新東西，而是司空見慣的混合物，好比事件總監、鼠標點擊事件等。同時，文中也提到異步（asynchronous ）以及數據流（data streams）等關鍵字。若是說由於 Java 8 Stream 是迭代器模式的緣故，它不屬於Reactive Programming 範式的話，那麼，Java GUI 事件/監聽則就是 Reactive。
那麼，Java 開發人員學習 RxJava、Reactor、或者 Java 9 Flow API 的必要性又在哪裏呢？所以，很是有必要深刻探討 Reactive Programming 的使用場景。

 

性能如何/使用場景
Reactive Programming 使用場景
正如同 Reactive Programming 的定義那樣，各個組織各執一詞，下面仍採用多方引證的方式，尋求 Reactive Programming 使用場景的「最大公約數」。

Reactive Streams JVM 認爲的使用場景
The main goal of Reactive Streams is to govern the exchange of stream data across an asynchronous boundary.

https://github.com/reactive-streams/reactive-streams-jvm

Reactive Streams JVM 認爲 Reactive Streams 用於在異步邊界（asynchronous boundary）管理流式數據交換（ govern the exchange of stream data）。異步說明其併發模型，流式數據則體現數據結構，管理則強調它們的它們之間的協調。

Spring 5 認爲的使用場景
Reactive and non-blocking generally do not make applications run faster. They can, in some cases, for example if using the WebClient to execute remote calls in parallel. On the whole it requires more work to do things the non-blocking way and that can increase slightly the required processing time.

The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory. That makes applications more resilient under load because they scale in a more predictable way.

Spring 認爲 Reactive 和非阻塞一般並不是讓應用運行更快速（generally do not make applications run faster），甚至會增長少許的處理時間，所以，它的使用場景則利用較少的資源，提高應用的伸縮性（scale with a small, fixed number of threads and less memory）。

ReactiveX 認爲的使用場景
The ReactiveX Observable model allows you to treat streams of asynchronous events with the same sort of simple, composable operations that you use for collections of data items like arrays. It frees you from tangled webs of callbacks, and thereby makes your code more readable and less prone to bugs.

ReactiveX 所描述的使用場景與 Spring 的不一樣，它沒有從性能入手，而是代碼可讀性和減小 Bugs 的角度出發，解釋了 Reactive Programming 的價值。同時，強調其框架的核心特性：異步（asynchronous）、同順序（same sort）和組合操做（composable operations）。它也間接地說明了，Java 8 Stream 在組合操做的限制，以及操做符的不足。

Reactor 認爲的使用場景
Composability and readability

Data as a flow manipulated with a rich vocabulary of operators

Nothing happens until you subscribe

Backpressure or the ability for the consumer to signal the producer that the rate of emission is too high

High level but high value abstraction that is concurrency-agnostic

Reactor 一樣強調結構性和可讀性（Composability and readability）和高層次併發抽象（High level abstraction），並明確地表示它提供豐富的數據操做符（ rich vocabulary of operators）彌補 Stream API 的短板，還支持背壓（Backpressure）操做，提供數據生產者和消費者的消息機制，協調它們之間的產銷失衡的狀況。同時，Reactor 採用訂閱式數據消費（Nothing happens until you subscribe）的機制，實現 Stream 所不具有的數據推送機制。

 

WebFlux 使用場景

長期異步執行，一旦提交，慢慢操做。是否適合 RPC 操做？

任務型的，少許線程，多個任務長時間運做，達到伸縮性。

Mono：單數據 Optional 0:1, RxJava : Single

Flux : 多數據集合，Collection 0:N , RxJava : Observable

函數式編程
非阻塞（同步/異步）
遠離 Servlet API

API
Servlet
HttpServletRequest

再也不強烈依賴 Servlet 容器（兼容）

容器
Tomcat
Jetty

 

Spring Cloud Gateway -> Reactor

Spring WebFlux -> Reactor

Zuul2 -> Netty Reactive

Reactive Programming 做爲觀察者模式（Observer） 的延伸，不一樣於傳統的命令編程方式（ Imperative programming）同步拉取數據的方式，如迭代器模式（Iterator） 。

而是採用數據發佈者同步或異步地推送到數據流（Data Streams）的方案。當該數據流（Data Steams）訂閱者監聽到傳播變化時，當即做出響應動做。

在實現層面上，Reactive Programming 可結合函數式編程簡化面嚮對象語言語法的臃腫性，屏蔽併發實現的複雜細節，提供數據流的有序操做，從而達到提高代碼的可讀性，以及減小 Bugs 出現的目的。

同時，Reactive Programming 結合背壓（Backpressure）的技術解決發佈端生成數據的速率高於訂閱端消費的問題。