反應式程式設計在微服務下的重生

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

反應式編宣言：

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

反應式程式設計概念簡化版

1. 設計思想

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

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

2. 組成

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

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

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

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

效能

---

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

總結

---

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

本文作者：

Andy Shi : 

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