這篇文章主要介紹了Reactive架構(gòu)的知識點有哪些的相關(guān)知識，內(nèi)容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Reactive架構(gòu)的知識點有哪些文章都會有所收獲，下面我們一起來看看吧。

創(chuàng)新互聯(lián)建站長期為成百上千家客戶提供的網(wǎng)站建設(shè)服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為蕉城企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、做網(wǎng)站，蕉城網(wǎng)站改版等技術(shù)服務。擁有十年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

Reactive 和 Reactive programming

Reactive 直接翻譯的意思式反應式，反應性。咋一看，似乎不太好懂。

舉個例子：在 Excel 里，C 單元格上設(shè)置函數(shù) Sum(A+B)，當你改變單元格 A 或者單元格 B 的數(shù)值時，單元格 C 的值同時也會發(fā)生變化。這種行為就是 Reactive。

在計算機編程領(lǐng)域，Reactive 一般指的是 Reactive programming。指的是一種面向數(shù)據(jù)流并傳播事件的異步編程范式（asynchronous programming paradigm）。

先舉個例子大家感受一下：

public static void main(String[] args) {
  FluxProcessor publisher = UnicastProcessor.create();
  publisher.doOnNext(event -> System.out.println("receive event: " + event)).subscribe();

  publisher.onNext(1); // print 'receive event: 1' publisher.onNext(2); // print 'receive event: 2' }

代碼 1

以上例代碼（使用 Reactor 類庫）為例，publisher 產(chǎn)生了數(shù)據(jù)流 (1,2)，并且傳播給了 OnNext 事件, 上例中 lambda 響應了該事件，輸出了相應的信息。上例代碼中生成數(shù)據(jù)流和注冊/執(zhí)行 lambda 是在同一線程中，但也可以在不同線程中。

注：如果上述代碼執(zhí)行邏輯有些疑惑，可以暫時將 lambda 理解成 callback 就可以了。

Reactive Manifesto

對于 Reactive 現(xiàn)在你應該大致有一點感覺了，但是 Reactive 有什么價值，有哪些設(shè)計原則，估計你還是有些模糊。這就是 Reactive Manifesto 要解決的疑問了。

使用 Reactive 方式構(gòu)建的系統(tǒng)具有以下特征：

即時響應性 (Responsive)

只要有可能， 系統(tǒng)就會及時地做出響應。即時響應是可用性和實用性的基石， 而更加重要的是，即時響應意味著可以快速地檢測到問題并且有效地對其進行處理。即時響應的系統(tǒng)專注于提供快速而一致的響應時間， 確立可靠的反饋上限， 以提供一致的服務質(zhì)量。這種一致的行為轉(zhuǎn)而將簡化錯誤處理、 建立最終用戶的信任并促使用戶與系統(tǒng)作進一步的互動。

回彈性 (Resilient)

系統(tǒng)在出現(xiàn)失敗時依然保持即時響應性。這不僅適用于高可用的、 任務關(guān)鍵型系統(tǒng)——任何不具備回彈性的系統(tǒng)都將會在發(fā)生失敗之后丟失即時響應性?；貜椥允峭ㄟ^復制、 遏制、 隔離以及委托來實現(xiàn)的。失敗的擴散被遏制在了每個組件內(nèi)部， 與其他組件相互隔離， 從而確保系統(tǒng)某部分的失敗不會危及整個系統(tǒng)，并能獨立恢復。每個組件的恢復都被委托給了另一個（外部的）組件， 此外，在必要時可以通過復制來保證高可用性。（因此）組件的客戶端不再承擔組件失敗的處理。

彈性 (Elastic)

系統(tǒng)在不斷變化的工作負載之下依然保持即時響應性。反應式系統(tǒng)可以對輸入（負載）的速率變化做出反應，比如通過增加或者減少被分配用于服務這些輸入（負載）的資源。這意味著設(shè)計上并沒有爭用點和中央瓶頸， 得以進行組件的分片或者復制， 并在它們之間分布輸入（負載）。通過提供相關(guān)的實時性能指標， 反應式系統(tǒng)能支持預測式以及反應式的伸縮算法。這些系統(tǒng)可以在常規(guī)的硬件以及軟件平臺上實現(xiàn)成本高效的彈性。

消息驅(qū)動 (Message Driven)

反應式系統(tǒng)依賴異步的消息傳遞，從而確保了松耦合、隔離、位置透明的組件之間有著明確邊界。這一邊界還提供了將失敗作為消息委托出去的手段。使用顯式的消息傳遞，可以通過在系統(tǒng)中塑造并監(jiān)視消息流隊列， 并在必要時應用回壓， 從而實現(xiàn)負載管理、 彈性以及流量控制。使用位置透明的消息傳遞作為通信的手段， 使得跨集群或者在單個主機中使用相同的結(jié)構(gòu)成分和語義來管理失敗成為了可能。非阻塞的通信使得接收者可以只在活動時才消耗資源， 從而減少系統(tǒng)開銷。

注：

• 上面描述有很多專有名詞，可能有些疑惑，可以看下相關(guān)名詞解釋。

• 為什么使用 Reactive 方式構(gòu)建的系統(tǒng)會具有以上價值, 我稍后在 Reactor 章節(jié)中介紹。

Reactive Stream

知道了 Reactive 的概念，特征和價值后，是否有相關(guān)的產(chǎn)品或者框架來幫助我們構(gòu)建 Reactive 式系統(tǒng)呢？在早些時候有一些類庫 (Rxjava 1.x, Rx.Net) 可以使用，但是規(guī)范并不統(tǒng)一，所以后來 Netfilx, Pivotal 等公司就制定了一套規(guī)范指導大家便于實現(xiàn)它（該規(guī)范也是受到早期產(chǎn)品的啟發(fā)），這就是 Reactive Stream 的作用。

Reactive Stream 是一個使用非阻塞 back pressure（回壓）實現(xiàn)異步流式數(shù)據(jù)處理的標準。目前已經(jīng)在 JVM 和 JavaScript 語言中實現(xiàn)同一套語意的規(guī)范；以及嘗試在各種涉及到序列化和反序列化的傳輸協(xié)議（TCP, UDP, HTTP and WebSockets）基礎(chǔ)上，定義傳輸 reactive 數(shù)據(jù)流的網(wǎng)絡協(xié)議。

The purpose of Reactive Streams is to provide a standard for asynchronous stream processing with non-blocking backpressure.

Reactive Streams 解決的問題場景

當遇到未預料數(shù)據(jù)流時，依然可以在可控資源消耗下保持系統(tǒng)的可用性。

Reactive Streams 的目標

控制在一個異步邊界的流式數(shù)據(jù)交換。例如傳遞一個數(shù)據(jù)到另外一個線程或者線程池，確保接收方?jīng)]有 buffer（緩存）任意數(shù)量的數(shù)據(jù)。而 back pressure（回壓）是解決這種場景的不可或缺的特性。

Reactive Streams 規(guī)范適用范圍

此標準只描述通過回壓來實現(xiàn)異步流式數(shù)據(jù)交換的必要的行為和實體，最小接口，例如下方的 Publisher, Subscriber。Reactive Streams 只關(guān)注在這些組件之間的流式數(shù)據(jù)中轉(zhuǎn)，并不關(guān)注流式數(shù)據(jù)本身的組裝，分割，轉(zhuǎn)換等行為, 例如 map, zip 等 operator。Reactive Streams 規(guī)范包括：

Publisher

產(chǎn)生一個數(shù)據(jù)流（可能包含無限數(shù)據(jù)）, Subscriber 們可以根據(jù)它們的需要消費這些數(shù)據(jù)。

public interface Publisher {    
  public void subscribe(Subscriber s);
}

Subscriber

Publisher 創(chuàng)建的元素的接收者。監(jiān)聽指定的事件，例如 OnNext, OnComplete, OnError 等。

publicinterface Subscriber { public void onSubscribe(Subscription s); public void onNext(T t); public void onError(Throwable t); public void onComplete();
}

Subscription

是 Publisher 和 Subscriber 一對一的協(xié)調(diào)對象。Subscriber 可以通過它來向 Publisher 取消數(shù)據(jù)發(fā)送或者 request 更多數(shù)據(jù)。

public interface Subscription { public void request(long n); public void cancel();
}

Processor

同時具備 Publisher 和 Subscriber 特征。代碼1中 FluxProcessor 既可以發(fā)送數(shù)據(jù)(OnNext)，也可以接收數(shù)據(jù) (doOnNext)。

public interface Processor extends Subscriber, Publisher {}

為什么規(guī)范強調(diào)使用非阻塞異步方式而不是阻塞同步方式?

• 同步方式一般通過多線程來提高性能，但系統(tǒng)可創(chuàng)建的線程數(shù)是有限的，且線程多以后造成線程切換開銷。

• 同步方式很難進一步提升資源利用率。

• 同步調(diào)用依賴的系統(tǒng)出現(xiàn)問題時，自身穩(wěn)定性也會受到影響。

實現(xiàn)非阻塞的方式有很多種，為什么規(guī)范會選擇上述的實現(xiàn)方式呢?

Thread

• thread 不是非常輕量（相比下面幾種實現(xiàn)方案）。

• thread 數(shù)量是有限的，最終可能會成為主要瓶頸。

• 有一些平臺可能不支持多線程。例如：JavaScript。

• 調(diào)試，實現(xiàn)上有一定復雜性。

Callback

• 多層嵌套 callback 比較復雜，容易形成"圣誕樹" (callback hell)。

• 錯誤處理比較復雜。

• 多用于 event loop 架構(gòu)的語言中，例如：JavaScript。

Future

• 無法邏輯組合各種行為，支持業(yè)務場景有限。

• 錯誤處理依然復雜。

Reactive Extensions (Rx)

• 和 Future 很相似。Future 可以認為返回一個獨立的元素，而 Rx 返回一個可以被訂閱的 Stream。

• 多平臺支持同一套規(guī)范。

• 同一套 API 同時支持異步、同步。

• 錯誤處理方便。

Coroutines

• kotlin coroutine 和 goroutine 在語法層面上提供異步支持, 而且比Rx更簡潔，但無法跨多個語言平臺形成統(tǒng)一的規(guī)范。

Reactive 的實現(xiàn)原理個人認為還是回調(diào)，kotlin 協(xié)程實現(xiàn)原理同樣也是回調(diào)。但實現(xiàn)回掉的方式不一樣。一個是通過事件傳播, 一個是通過狀態(tài)機。但 cooutine 編程的易用性明顯強于 Rx，后面有空我會專門寫篇文章介紹 kotlin coroutine 的實現(xiàn)原理。

Reactor

有了 Reactive Stream 這個規(guī)范，就會有相應實現(xiàn)該規(guī)范的類庫。Reactor 就是其中之一。

Reactor 是遵守 Reactive Stream 規(guī)范構(gòu)建非阻塞應用的 Java 語言 Reactive 類庫，已經(jīng)在 spring 5 中集成，與他相似的類庫有 RxJava2, RxJs, JDK9 Flow 等。

阿里內(nèi)部的 Faas 系統(tǒng)目前使用 Reactor 來構(gòu)建整個系統(tǒng)，包括函數(shù)應用和各種核心應用(邏輯架構(gòu))。根據(jù)我們壓測結(jié)果顯示，使用 Reactive 方式構(gòu)建的系統(tǒng)確實會有這些特點：

• 回彈性 (Resilient)：當函數(shù)出現(xiàn)嚴重超時時 (rt >= 10s)，函數(shù)上游的 broker, gateway 應用幾乎無任何影響。

• 及時響應性：不管是高并發(fā)場景（資源足夠），還是正常場景，RT 表現(xiàn)一致。

另外從原理上，我認為資源利用率和吞吐量也會高于非反應式的應用。

為什么 Reactive 的架構(gòu)系統(tǒng)有這些特點?

阿里內(nèi)部的 Faas 系統(tǒng)主要做了兩件事情：

涉及到 IO 的地方幾乎全異步化。例如中間件（HSF, MetaQ 等提供異步 API）調(diào)用。

IO 線程模型變化。使用較少（一般 CPU 核數(shù)）線程處理所有的請求。

傳統(tǒng) Java 應用 IO 線程模型

參考 Netty 中 Reactor IO (worker thread pool) 模型，下方偽代碼（kotlin）進行了簡化。

// 非阻塞讀取客戶端請求數(shù)據(jù)(in), 讀取成功后執(zhí)行l(wèi)ambda.
inChannel.read(in) {
    workerThreadPool.execute{
      // 阻塞處理業(yè)務邏輯(process), 業(yè)務邏輯在worker線程池中執(zhí)行，同步執(zhí)行完后，再向客戶端返回輸出(out)
      val out = process(in)
      outChannel.write(out)
    }  
}

Reactive 應用 IO 線程模型
IO 線程也可以執(zhí)行業(yè)務邏輯 (process)，可以不需要 worker 線程池。

// 非阻塞讀取客戶端請求數(shù)據(jù)(in), 讀取成功后執(zhí)行l(wèi)ambda inChannel.read(in) { // IO線程執(zhí)行業(yè)務邏輯(process),  然后向客戶端返回輸出(out). 這要求業(yè)務處理流程必須是非阻塞的. process(in){ out->
        outChannel.write(out) { // this lambda is executed when the writing completes ...
        }
    }
}

關(guān)于“Reactive架構(gòu)的知識點有哪些”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“Reactive架構(gòu)的知識點有哪些”知識都有一定的了解，大家如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。