淺談Java響應式系統
ReactiveX的本質就是Observer+Iterator+函數編程+異步。是一個事件驅動的，異步的，可觀察的序列。
使用RxJava可以將異步的回調改寫成為鏈式調用。在代碼上看起來非常簡潔明了。當然JDK也提供了CompletionStage提供了類似的解決回調的功能。
Rxjava只是一個java的基本庫，如果我們想要構建響應式的服務器，響應式的web,響應式的數據訪問，甚至是響應式的微服務，又該如何處理呢？
這個時候我了解到了Vert.x。Vert.x就是用來構建Reactive的應用程序的。
Vert.x是Eclipse基金會旗下的產品，基于事件驅動和非阻塞編程。
Vert.x是模塊化的，里面有Core，web，Data access，Reactive，Microservices，MQTT，Authentication and Authorisation，Messaging，Event bus Bridge,Devops,Testing,Clustering,Services和Cloud等模塊。可謂是應有盡有。
其實java界一直都在向reactive靠近，除了JDK本身的api新特性意外，比如業界有名的Spring也在spring 5中添加了webflux框架，這就是一款reactive的web框架。
什么是響應式系統在上一節我們提到了Rxjava和Vert.x,里面有一些共同的關鍵字，比如異步，事件驅動，觀察者模式，函數式編程，消息驅動等，所有的一切都是為了讓現代系統更加健壯，運行的更快，更加富有彈性，從而更好。
系統從很久之前的單一服務器，到現在的多服務器架構，從秒級響應到現在的毫秒級響應。從90%可用都現在的99.999%可用。不論從系統設計，架構還是程序編碼都發生了極大的變化。
我們迫切的需要一個能夠滿足以上需求的通用的系統架構解決方案。
那么什么是響應式系統呢？
響應式系統需要具備這些特征：及時響應性（Responsive）、恢復性（Resilient）、有彈性（Elastic）以及消息驅動（Message Driven）。我們把具有上面四個特性的系統就叫做響應式系統。
上面的四個特性中，及時響應性（Responsive）是系統最終要達到的目標，恢復性（Resilient）和有彈性（Elastic）是系統的表現形式，而消息驅動（Message Driven）則是系統構建的手段。
于是我們得到了響應式系統的終極架構圖：
使用響應式系統的架構，可以保證系統的可維護性，和可擴展性，并且在系統出現問題的時候能夠有更好的可容忍性。
響應式系統的四大特點在定義響應式系統的時候，我們提到了及時響應性（Responsive）、恢復性（Resilient）、有彈性（Elastic）以及消息驅動（Message Driven）這四大特點。
接下來我們將會具體描述這四大特點到底有什么奧秘。
及時響應性（Responsive）Responsive就是系統能夠立刻響應請求，這應該包含兩個方面的含義。
第一，響應請求的時間要夠短，如果用戶請求一個頁面，等待2秒鐘估計已經是極限了。再長的時間估計就要失去這個用戶了。
時代在變，技術也在變，十幾年前下載一個幾百K的文件要一分鐘估計就算是很快了，現在沒有個幾M每秒，肯定會讓人抓狂不已。
在現代CPU，服務集群和光纖傳輸的飛速發展和頁面承載信息的巨大變化，一個普通的頁面可能就要包含十幾二十個請求。每個請求的時間已經提升到了毫秒甚至是微妙級。同時在頁面展示方面也產生了很多新的變化，比如異步加載和預加載等技術。
最終是為了創建一個能夠及時響應的系統。而系統背后的各種技術和新的請求方式都是為這個目標來服務的。
第二，對于錯誤的響應時間要短。
一方面對于用戶來說，要及時的提醒用戶可能出現的錯誤。不管是系統本身的錯誤亦或是用戶的使用錯誤，都需要在一個有限的時間內進行響應。
另一方面，對于系統本身來說，要能夠快速的定位和響應問題。這是提升系統本身的穩定性和安全性的基本要求。
如何發現和響應系統本身的問題呢？第一要有完善的錯誤記錄系統，讓一切都有章可循。第二就是要有相應的監控措施，讓系統出現的任何問題都能夠及時的進行通知和報警。
恢復性（Resilient）可恢復性是指系統在遇到失敗或者錯誤時仍然能夠對外提供服務。
首先，要求我們的系統足夠穩健，能夠抗住正常的訪問，并且能夠可預見的應對熱點訪問。
其次，現代系統的功能是各種各樣的，一個簡單的APP的后臺可能有多達幾十種服務。所以我們需要區分出來哪些是關鍵的服務，哪些是非關鍵的服務。對于關鍵的服務我們一定要確保其的穩定性，對于非關鍵性的服務，我們可以在首先保障關鍵服務的前提下再進行考慮。
比如說一個訂單系統，下單肯定就是關鍵服務了，而商品的點贊數，評論等則就沒有那么重要。
區分好了關鍵服務和非關鍵服務，就要對他們進行區分和隔離。非關鍵服務的任何錯誤或者異常都不能夠影響到關鍵服務。
再次，如果服務發送了錯誤，我們應該盡可能的縮小影響范圍，不要一點小錯誤影響所有的服務。
最后，對于失敗要有恢復措施，并且這個恢復措施不能夠影響其他的系統服務。比如我們可以對現有的系統做一個復制，在某個服務失敗的時候，可以用備用的服務進行替代。
只有這樣，才能夠保證系統的可靠性。
有彈性（Elastic）彈性的意思就是在需要的時候服務可以動態擴展，在不需要的時候可以停用服務以節約資源。
現在很多云服務都提供了動態擴展的功能，如果系統是我們自己實現的，那就需要區分出熱點問題和非熱點問題。
只有熱點問題才需要考慮彈性，系統不能有瓶頸，并且能夠進行分片或者復制，從而實現分布式的動態負載功能。
負載均衡技術可能是我們最常用的彈性功能，但是如何動態的自動的進行負載的均衡可能是一個非常有意義的話題。
彈性可以通過軟件或者硬件的方式來實現，當然我們需要在成本和效果之間達成一個平衡。
消息驅動（Message Driven）消息驅動的本質就是發送消息，接收消息然后進行處理。現在大型系統很少有不使用消息中間件的。使用這些消息中間件的好處就是可以解耦和異步驅動。
異步的好處這里就不多講了，大概就是不用一直傻傻的等待，而是充分利用時間去做更有效率的事情。
解耦的作用就更大了，現代系統基本上都是由很多個服務組成的。要想保證這么多系統的平穩運行，肯定要做解耦操作，否則一個服務的失敗就會導致所有服務的不可用，想想都覺得害怕。
而消息驅動，就是這些不同的服務組件之間溝通的橋梁。告訴他們要做什么，等待他們的反饋消息。
或者我們可以把這些服務看做一個一個的人，多人之間的溝通就是通過語言。語言驅動或者也可以叫做消息驅動。
這里再講一個消息驅動中常見的一個概念：back-pressure。
我們知道發送消息和接收消息的服務其處理速度是有限的，當發送消息的速度快過與接收消息的速度時候，就會發送消息阻塞，當消息阻塞過多的時候，就有可能發送消息丟失或者服務崩潰的情況。并且如果太多消息一直都沒有被處理，沒有得到響應的話，對于用戶體驗也是非常不好的。
這里就需要使用到back-pressure的概念，如果消息接收方消息處理不過來，則可以通知消息發送方，告知其正在承受壓力，需要降低負載。back-pressure是一種消息反饋機制，從而使系統得以優雅地響應負載， 而不是在負載下崩潰。
總結reactive是近幾年非常流行的一個概念，如何通過reactive來設計出滿足我們需要的系統，是我們需要考慮的問題。
以上就是淺談Java響應式系統的詳細內容，更多關于Java響應式系統的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備