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

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

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

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

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

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

Vert.x是模塊化的，里面有Core，web，Data access，Reactive，Microservices，MQTT，Authentication and Authorisation，Messaging，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ū)動(dòng)，觀察者模式，函數(shù)式編程，消息驅(qū)動(dòng)等，所有的一切都是為了讓現(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è)計(jì)，架構(gòu)還是程序編碼都發(fā)生了極大的變化。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

恢復(fù)性（Resilient）

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

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

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

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

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

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

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

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

有彈性（Elastic）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

以上就是淺談Java響應(yīng)式系統(tǒng)的詳細(xì)內(nèi)容，更多關(guān)于Java響應(yīng)式系統(tǒng)的資料請關(guān)注腳本之家其它相關(guān)文章！