反應式編程在好幾年前就已經出現了，它原理是基于反應式編宣言。但是，由于反應式編程推廣速度比較緩慢，導致很多人現在對其不是很了解。

反應式編宣言：

https://www.reactivemanifesto.org

本文將從微服務角度闡述反應式編程，在深入解讀之前，先為大家簡單地介紹一些反應式編程的基本概念。

反應式編程概念簡化版

---

1. 設計思想

反應式編程的提出，是在分布式編程剛興起不久。當時沒有各種 PaaS 平臺，而分布式系統中，常常出現一個節點出問題，導致整個系統癱瘓的情況。所以，反應式編程的思想是：不等不靠，即當有一個節點慢下來的時候，整個系統都放慢，以此來避免災難性的后果。

這樣的想法，當然是有局限性的。一方面，雖然整個系統得到保全，但是系統的處理能力卻大大降低，作為這個系統之外的用戶或者其它應用還是受到影響的。另外，隨著 PaaS 相關技術的發展，現在如果出現一個節點放慢的問題，我們既可以用熔斷、限流，甚至擴容來處理，處理的選擇有多種。

2. 組成

反應式編程的宣言是指導框架，具體的實現是有不同的版本。但是，它們都有兩個共同的特征。

• 異步編程，非阻塞流：這是實現反應式編程的基礎。

但是，很多人把反應式編程和函數式編程混淆了。如 Java 這部分語言 ，選用函數式編程來實現非阻塞式的異步編程。但是，其它的語言，如 golang, goroutine 和 channel 已經是異步和非阻塞的，那么它們不用函數式編程也一樣可以實現反應式編程。

• 背壓：背壓是另一個自己把自己難倒的概念。

背壓就是處理數據的接收方指揮發送方何時發送信息和發多少信息，比如我們排隊過安檢，安檢的人招手了，我們才走過去。本來都是發送方有數據就發送，那么壓力就在接收方，因為處理不了就掛了。現在壓力反過來了，在發送方，就叫背壓。這個名字不好，如果我起，就叫“憋呀”，簡單易懂。發送方數據多了怎么辦？憋著。正是這個憋，是背壓形象直觀的解釋，而它保障了系統不會掛。

所以，用不是很準確的方式總結反應式編程的主要部分，就是異步編程、非阻塞流和背壓。

?

微服務環境對分布式應用架構帶來的挑戰

---

一直以來很多人都會對反應式編程有這樣的疑問：這樣的設計，真的有用嗎？

微服務已經算是很成熟的技術了，并且微服務是分布式系統的一員，所以很多人也會理所當然的覺得分布式系統也應該很成熟了。但是結果卻恰恰相反。

我個人的理解，并不是微服務走錯方向了，而正是由于微服務的普及，產生了許多以前沒有遇到過的新問題。

而其中最主要的問題，就是微服務之間的通信問題。首先，與單體應用不同，微服務之間誰也無法控制誰，是無法保障通訊的順序的， 這就要求是異步編程。同理也會要求通訊是采取非阻塞方式，不然一旦I/O被一個線程占了，其它線程就沒法用了。然后就是微服務之間如何協調通訊速度的問題。沒錯，現在有service mesh, 有熔斷，限流，也有擴容。但是，這些還不夠。因為這些手段都是要先觀察到異常，然后才能處置。而很多時候異常是很不容易察覺的。比如K8s的擴容，每30秒采集一次。還要算平均值。這些都很難及時反應。等到算出有問題，時間已經過了很久。而且很多的時候，故障就是小抖動，突然慢下來，但無法體現在平均值上。吞吐量的匹配，是一個棘手的問題。

這個時候，反應式編程的優點就體現出來了。它不管什么原因，處理不了就不請求發送。而且是立刻的。

?

微服務環境對反應式編程的新要求

---

不能以為反應式編程好像就是可以在微服務環境下安枕無憂。其實，它也面臨改進的要求。

端到端的背壓
過去的反應式編程一般只考慮兩個分布應用之間的通訊。但是隨著微服務架構的復雜化，從A到B也許中間要經過其他的環節。這個時候，怎么傳遞背壓的信息，而不是在中間環節丟失；怎么從端到端執行背壓，就顯得特別重要。這對很多現有的反應式編程框架都是挑戰。

與云原生環境的整合
一些早期反應式編程框架，有自己的集群管理功能。而且這些功能，是以胖SDK的方式捆綁在反應式編程基本功能上的。但是在強調云原生的今天，這似乎不是優勢而是缺點。相反，把基本的反應式編程功能與服務注冊，發現，以及負載均衡等功能分離，充分利用云原生的優勢，與之協調互補，則是未來的趨勢。

?

性能

---

最后我們談一下很重要的一環：性能。一直以來，很多人都有疑問：背壓的通訊方式真的好嗎？如果一切環境是可控的，網絡帶寬是無限的，那么傳統的阻塞通訊是有優勢的。這就是為什么JVM費那么大勁實現這些功能的原因。因為Linux其實是非阻塞的，而20多年前，應用大多是單體的。但是在現實的環境下，對于分布式應用，在數據量較大的時候，非阻塞通訊的優勢就體現出來了。特別當有合適的網絡通訊方式支持背壓的時候，這種優勢更加明顯。

?

總結

---

最近的趨勢告訴我們，在分布式應用架構變成熟的過程中，反應式編程的作用慢慢被重新認識。事實上，反應式編程自身也在發展中，特別是在網絡傳輸方面的進展，一定會在未來分布式應用架構中發揮更大的作用。

?

本文作者：

Andy Shi :?

GitHub ID szihai，阿里巴巴中間件高級技術專家，長期從事 Service Mesh 和微服務框架的技術推廣工作。

總結

以上是生活随笔為你收集整理的反应式编程在微服务下的重生的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。