初識響應(yīng)式系統(tǒng)

第一次聽到reactive這個詞還是在幾年前，偶然了解到了Rxjava這個項(xiàng)目，仿佛為我打開了一扇新的大門，Rxjava是ReactiveX的java實(shí)現(xiàn)，ReactiveX家族除了Rxjava還有RxJS,Rx.NET,RxScala等等。

ReactiveX的本質(zhì)就是Observer+Iterator+函數(shù)編程+異步。是一個事件驅(qū)動的，異步的，可觀察的序列。

使用RxJava可以將異步的回調(diào)改寫成為鏈?zhǔn)秸{(diào)用。在代碼上看起來非常簡潔明了。當(dāng)然JDK也提供了CompletionStage提供了類似的解決回調(diào)的功能。

Rxjava只是一個java的基本庫，如果我們想要構(gòu)建響應(yīng)式的服務(wù)器，響應(yīng)式的web,響應(yīng)式的數(shù)據(jù)訪問，甚至是響應(yīng)式的微服務(wù)，又該如何處理呢？

這個時候我了解到了Vert.x。Vert.x就是用來構(gòu)建Reactive的應(yīng)用程序的。

Vert.x是Eclipse基金會旗下的產(chǎn)品，基于事件驅(qū)動和非阻塞編程。

Vert.x是模塊化的，里面有Core，web，Data access，Reactive，Microservices，MQTT，Authentication and Authorisation，Messagin，Event bus Bridge,Devops,Testing,Clustering,Services和Cloud等模塊?？芍^是應(yīng)有盡有。

其實(shí)java界一直都在向reactive靠近，除了JDK本身的api新特性意外，比如業(yè)界有名的Spring也在spring 5中添加了webflux框架，這就是一款reactive的web框架。

什么是響應(yīng)式系統(tǒng)

在上一節(jié)我們提到了Rxjava和Vert.x,里面有一些共同的關(guān)鍵字，比如異步，事件驅(qū)動，觀察者模式，函數(shù)式編程，消息驅(qū)動等，所有的一切都是為了讓現(xiàn)代系統(tǒng)更加健壯，運(yùn)行的更快，更加富有彈性，從而更好。

系統(tǒng)從很久之前的單一服務(wù)器，到現(xiàn)在的多服務(wù)器架構(gòu)，從秒級響應(yīng)到現(xiàn)在的毫秒級響應(yīng)。從90%可用都現(xiàn)在的99.999%可用。不論從系統(tǒng)設(shè)計，架構(gòu)還是程序編碼都發(fā)生了極大的變化。

我們迫切的需要一個能夠滿足以上需求的通用的系統(tǒng)架構(gòu)解決方案。

那么什么是響應(yīng)式系統(tǒng)呢？

響應(yīng)式系統(tǒng)需要具備這些特征：及時響應(yīng)性（Responsive）、恢復(fù)性（Resilient）、有彈性（Elastic）以及消息驅(qū)動（Message Driven）。我們把具有上面四個特性的系統(tǒng)就叫做響應(yīng)式系統(tǒng)。

上面的四個特性中，及時響應(yīng)性（Responsive）是系統(tǒng)最終要達(dá)到的目標(biāo)，恢復(fù)性（Resilient）和有彈性（Elastic）是系統(tǒng)的表現(xiàn)形式，而消息驅(qū)動（Message Driven）則是系統(tǒng)構(gòu)建的手段。

于是我們得到了響應(yīng)式系統(tǒng)的終極架構(gòu)圖：

圖1

使用響應(yīng)式系統(tǒng)的架構(gòu)，可以保證系統(tǒng)的可維護(hù)性，和可擴(kuò)展性，并且在系統(tǒng)出現(xiàn)問題的時候能夠有更好的可容忍性。

響應(yīng)式系統(tǒng)的四大特點(diǎn)

在定義響應(yīng)式系統(tǒng)的時候，我們提到了及時響應(yīng)性（Responsive）、恢復(fù)性（Resilient）、有彈性（Elastic）以及消息驅(qū)動（Message Driven）這四大特點(diǎn)。

接下來我們將會具體描述這四大特點(diǎn)到底有什么奧秘。

及時響應(yīng)性（Responsive）

Responsive就是系統(tǒng)能夠立刻響應(yīng)請求，這應(yīng)該包含兩個方面的含義。

第一，響應(yīng)請求的時間要夠短，如果用戶請求一個頁面，等待2秒鐘估計已經(jīng)是極限了。再長的時間估計就要失去這個用戶了。

時代在變，技術(shù)也在變，十幾年前下載一個幾百K的文件要一分鐘估計就算是很快了，現(xiàn)在沒有個幾M每秒，肯定會讓人抓狂不已。

在現(xiàn)代CPU，服務(wù)集群和光纖傳輸?shù)娘w速發(fā)展和頁面承載信息的巨大變化，一個普通的頁面可能就要包含十幾二十個請求。每個請求的時間已經(jīng)提升到了毫秒甚至是微妙級。同時在頁面展示方面也產(chǎn)生了很多新的變化，比如異步加載和預(yù)加載等技術(shù)。

最終是為了創(chuàng)建一個能夠及時響應(yīng)的系統(tǒng)。而系統(tǒng)背后的各種技術(shù)和新的請求方式都是為這個目標(biāo)來服務(wù)的。

第二，對于錯誤的響應(yīng)時間要短。

一方面對于用戶來說，要及時的提醒用戶可能出現(xiàn)的錯誤。不管是系統(tǒng)本身的錯誤亦或是用戶的使用錯誤，都需要在一個有限的時間內(nèi)進(jìn)行響應(yīng)。

另一方面，對于系統(tǒng)本身來說，要能夠快速的定位和響應(yīng)問題。這是提升系統(tǒng)本身的穩(wěn)定性和安全性的基本要求。

如何發(fā)現(xiàn)和響應(yīng)系統(tǒng)本身的問題呢？第一要有完善的錯誤記錄系統(tǒng)，讓一切都有章可循。第二就是要有相應(yīng)的監(jiān)控措施，讓系統(tǒng)出現(xiàn)的任何問題都能夠及時的進(jìn)行通知和報警。

恢復(fù)性（Resilient）

可恢復(fù)性是指系統(tǒng)在遇到失敗或者錯誤時仍然能夠?qū)ν馓峁┓?wù)。

首先，要求我們的系統(tǒng)足夠穩(wěn)健，能夠抗住正常的訪問，并且能夠可預(yù)見的應(yīng)對熱點(diǎn)訪問。

其次，現(xiàn)代系統(tǒng)的功能是各種各樣的，一個簡單的APP的后臺可能有多達(dá)幾十種服務(wù)。所以我們需要區(qū)分出來哪些是關(guān)鍵的服務(wù)，哪些是非關(guān)鍵的服務(wù)。對于關(guān)鍵的服務(wù)我們一定要確保其的穩(wěn)定性，對于非關(guān)鍵性的服務(wù)，我們可以在首先保障關(guān)鍵服務(wù)的前提下再進(jìn)行考慮。

比如說一個訂單系統(tǒng)，下單肯定就是關(guān)鍵服務(wù)了，而商品的點(diǎn)贊數(shù)，評論等則就沒有那么重要。

區(qū)分好了關(guān)鍵服務(wù)和非關(guān)鍵服務(wù)，就要對他們進(jìn)行區(qū)分和隔離。非關(guān)鍵服務(wù)的任何錯誤或者異常都不能夠影響到關(guān)鍵服務(wù)。

再次，如果服務(wù)發(fā)送了錯誤，我們應(yīng)該盡可能的縮小影響范圍，不要一點(diǎn)小錯誤影響所有的服務(wù)。

最后，對于失敗要有恢復(fù)措施，并且這個恢復(fù)措施不能夠影響其他的系統(tǒng)服務(wù)。比如我們可以對現(xiàn)有的系統(tǒng)做一個復(fù)制，在某個服務(wù)失敗的時候，可以用備用的服務(wù)進(jìn)行替代。

只有這樣，才能夠保證系統(tǒng)的可靠性。

有彈性（Elastic）

彈性的意思就是在需要的時候服務(wù)可以動態(tài)擴(kuò)展，在不需要的時候可以停用服務(wù)以節(jié)約資源。

現(xiàn)在很多云服務(wù)都提供了動態(tài)擴(kuò)展的功能，如果系統(tǒng)是我們自己實(shí)現(xiàn)的，那就需要區(qū)分出熱點(diǎn)問題和非熱點(diǎn)問題。

只有熱點(diǎn)問題才需要考慮彈性，系統(tǒng)不能有瓶頸，并且能夠進(jìn)行分片或者復(fù)制，從而實(shí)現(xiàn)分布式的動態(tài)負(fù)載功能。

負(fù)載均衡技術(shù)可能是我們最常用的彈性功能，但是如何動態(tài)的自動的進(jìn)行負(fù)載的均衡可能是一個非常有意義的話題。

彈性可以通過軟件或者硬件的方式來實(shí)現(xiàn)，當(dāng)然我們需要在成本和效果之間達(dá)成一個平衡。

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

消息驅(qū)動的本質(zhì)就是發(fā)送消息，接收消息然后進(jìn)行處理。現(xiàn)在大型系統(tǒng)很少有不使用消息中間件的。使用這些消息中間件的好處就是可以解耦和異步驅(qū)動。

異步的好處這里就不多講了，大概就是不用一直傻傻的等待，而是充分利用時間去做更有效率的事情。

解耦的作用就更大了，現(xiàn)代系統(tǒng)基本上都是由很多個服務(wù)組成的。要想保證這么多系統(tǒng)的平穩(wěn)運(yùn)行，肯定要做解耦操作，否則一個服務(wù)的失敗就會導(dǎo)致所有服務(wù)的不可用，想想都覺得害怕。

而消息驅(qū)動，就是這些不同的服務(wù)組件之間溝通的橋梁。告訴他們要做什么，等待他們的反饋消息。

或者我們可以把這些服務(wù)看做一個一個的人，多人之間的溝通就是通過語言。語言驅(qū)動或者也可以叫做消息驅(qū)動。

這里再講一個消息驅(qū)動中常見的一個概念：back-pressure。

我們知道發(fā)送消息和接收消息的服務(wù)其處理速度是有限的，當(dāng)發(fā)送消息的速度快過與接收消息的速度時候，就會發(fā)送消息阻塞，當(dāng)消息阻塞過多的時候，就有可能發(fā)送消息丟失或者服務(wù)崩潰的情況。并且如果太多消息一直都沒有被處理，沒有得到響應(yīng)的話，對于用戶體驗(yàn)也是非常不好的。

這里就需要使用到back-pressure的概念，如果消息接收方消息處理不過來，則可以通知消息發(fā)送方，告知其正在承受壓力，需要降低負(fù)載。back-pressure是一種消息反饋機(jī)制，從而使系統(tǒng)得以優(yōu)雅地響應(yīng)負(fù)載，而不是在負(fù)載下崩潰。

總結(jié)

reactive是近幾年非常流行的一個概念，如何通過reactive來設(shè)計出滿足我們需要的系統(tǒng)，是我們需要考慮的問題。

文章來源：flydean的博客

【數(shù)商云www.zhimaihui.cn】致力于提供企業(yè)級的電商平臺服務(wù)，長期為大中型企業(yè)打造數(shù)據(jù)化、商業(yè)化、智能化的電商網(wǎng)站建設(shè)解決方案，同時我們還提供B2B電商平臺、B2B2C多用戶商城系統(tǒng)、B2C網(wǎng)站建設(shè)、跨境進(jìn)口電商平臺、供應(yīng)商系統(tǒng)、SRM供應(yīng)商管理系統(tǒng)、SCM系統(tǒng)、渠道管理系統(tǒng)等一系列系統(tǒng)定制開發(fā)服務(wù)，通過大數(shù)據(jù)、云計算等新技術(shù)協(xié)助企業(yè)打造供應(yīng)端—渠道端—營銷端—數(shù)據(jù)端等全鏈數(shù)字化運(yùn)營體系，提升企業(yè)運(yùn)營效益與智慧數(shù)字化商業(yè)轉(zhuǎn)型。