反應式編程在好幾年前就已經出現了，它原理是基於反應式編宣言。可是，因爲反應式編程推廣速度比較緩慢，致使不少人如今對其不是很瞭解。react
反應式編宣言：golang
https://www.reactivemanifesto.orgweb
本文將從微服務角度闡述反應式編程，在深刻解讀以前，先爲你們簡單地介紹一些反應式編程的基本概念。編程
反應式編程概念簡化版
1. 設計思想
反應式編程的提出，是在分佈式編程剛興起不久。當時沒有各類 PaaS 平臺，而分佈式系統中，經常出現一個節點出問題，致使整個系統癱瘓的狀況。因此，反應式編程的思想是：不等不靠，即當有一個節點慢下來的時候，整個系統都放慢，以此來避免災難性的後果。微信
這樣的想法，固然是有侷限性的。一方面，雖然整個系統獲得保全，可是系統的處理能力卻大大下降，做爲這個系統以外的用戶或者其它應用仍是受到影響的。另外，隨着 PaaS 相關技術的發展，如今若是出現一個節點放慢的問題，咱們既能夠用熔斷、限流，甚至擴容來處理，處理的選擇有多種。網絡
2. 組成架構
反應式編程的宣言是指導框架，具體的實現是有不一樣的版本。可是，它們都有兩個共同的特徵。app
異步編程，非阻塞流：這是實現反應式編程的基礎。負載均衡
可是，不少人把反應式編程和函數式編程混淆了。如 Java 這部分語言 ，選用函數式編程來實現非阻塞式的異步編程。可是，其它的語言，如 golang, goroutine 和 channel 已是異步和非阻塞的，那麼它們不用函數式編程也同樣能夠實現反應式編程。
框架
背壓：背壓是另外一個本身把本身難倒的概念。
背壓就是處理數據的接收方指揮發送方什麼時候發送信息和發多少信息，好比咱們排隊過安檢，安檢的人招手了，咱們才走過去。原本都是發送方有數據就發送，那麼壓力就在接收方，由於處理不了就掛了。如今壓力反過來了，在發送方，就叫背壓。這個名字很差，若是我起，就叫「憋呀」，簡單易懂。發送方數據多了怎麼辦？憋着。正是這個憋，是背壓形象直觀的解釋，而它保障了系統不會掛。
因此，用不是很準確的方式總結反應式編程的主要部分，就是異步編程、非阻塞流和背壓。
微服務環境對分佈式應用架構帶來的挑戰
一直以來不少人都會對反應式編程有這樣的疑問：這樣的設計，真的有用嗎？
微服務已經算是很成熟的技術了，而且微服務是分佈式系統的一員，因此不少人也會理所固然的以爲分佈式系統也應該很成熟了。可是結果卻偏偏相反。
我我的的理解，並非微服務走錯方向了，而正是因爲微服務的普及，產生了許多之前沒有遇到過的新問題。
而其中最主要的問題，就是微服務之間的通訊問題。首先，與單體應用不一樣，微服務之間誰也沒法控制誰，是沒法保障通信的順序的， 這就要求是異步編程。同理也會要求通信是採起非阻塞方式，否則一旦I/O被一個線程佔了，其它線程就無法用了。而後就是微服務之間如何協調通信速度的問題。沒錯，如今有service mesh, 有熔斷，限流，也有擴容。可是，這些還不夠。由於這些手段都是要先觀察到異常，而後才能處置。而不少時候異常是很不容易察覺的。好比K8s的擴容，每30秒採集一次。還要算平均值。這些都很難及時反應。等到算出有問題，時間已通過了好久。並且不少的時候，故障就是小抖動，忽然慢下來，但沒法體如今平均值上。吞吐量的匹配，是一個棘手的問題。
這個時候，反應式編程的優勢就體現出來了。它無論什麼緣由，處理不了就不請求發送。並且是馬上的。
微服務環境對反應式編程的新要求
不能覺得反應式編程好像就是能夠在微服務環境下安枕無憂。其實，它也面臨改進的要求。
端到端的背壓
過去的反應式編程通常只考慮兩個分佈應用之間的通信。可是隨着微服務架構的複雜化，從A到B也許中間要通過其餘的環節。這個時候，怎麼傳遞背壓的信息，而不是在中間環節丟失；怎麼從端到端執行背壓，就顯得特別重要。這對不少現有的反應式編程框架都是挑戰。與雲原生環境的整合
一些早期反應式編程框架，有本身的集羣管理功能。並且這些功能，是以胖SDK的方式捆綁在反應式編程基本功能上的。可是在強調雲原生的今天，這彷佛不是優點而是缺點。相反，把基本的反應式編程功能與服務註冊，發現，以及負載均衡等功能分離，充分利用雲原生的優點，與之協調互補，則是將來的趨勢。
性能
最後咱們談一下很重要的一環：性能。一直以來，不少人都有疑問：背壓的通信方式真的好嗎？若是一切環境是可控的，網絡帶寬是無限的，那麼傳統的阻塞通信是有優點的。這就是爲何JVM費那麼大勁實現這些功能的緣由。由於Linux實際上是非阻塞的，而20多年前，應用大可能是單體的。可是在現實的環境下，對於分佈式應用，在數據量較大的時候，非阻塞通信的優點就體現出來了。特別當有合適的網絡通信方式支持背壓的時候，這種優點更加明顯。
總結
最近的趨勢告訴咱們，在分佈式應用架構變成熟的過程當中，反應式編程的做用慢慢被從新認識。事實上，反應式編程自身也在發展中，特別是在網絡傳輸方面的進展，必定會在將來分佈式應用架構中發揮更大的做用。
本文做者：
Andy Shi :
GitHub ID szihai，阿里巴巴中間件高級技術專家，長期從事 Service Mesh 和微服務框架的技術推廣工做。
若是你們以爲這篇文章對你有幫助，你的關注和轉發是對我最大的支持，O(∩_∩)O:
本文分享自微信公衆號 - 咖啡拿鐵（close_3092860495）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。