反應(yīng)式編程在好幾年前就已經(jīng)出現(xiàn)了，它原理是基于反應(yīng)式編宣言。但是，由于反應(yīng)式編程推廣速度比較緩慢，導(dǎo)致很多人現(xiàn)在對其不是很了解。

反應(yīng)式編宣言：

https://www.reactivemanifesto.org

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

反應(yīng)式編程概念簡化版

---

1. 設(shè)計思想

反應(yīng)式編程的提出，是在分布式編程剛興起不久。當(dāng)時沒有各種 PaaS 平臺，而分布式系統(tǒng)中，常常出現(xiàn)一個節(jié)點出問題，導(dǎo)致整個系統(tǒng)癱瘓的情況。所以，反應(yīng)式編程的思想是：不等不靠，即當(dāng)有一個節(jié)點慢下來的時候，整個系統(tǒng)都放慢，以此來避免災(zāi)難性的后果。

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

2. 組成

反應(yīng)式編程的宣言是指導(dǎo)框架，具體的實現(xiàn)是有不同的版本。但是，它們都有兩個共同的特征。

• 異步編程，非阻塞流：這是實現(xiàn)反應(yīng)式編程的基礎(chǔ)。

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

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

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

所以，用不是很準(zhǔn)確的方式總結(jié)反應(yīng)式編程的主要部分，就是異步編程、非阻塞流和背壓。

?

微服務(wù)環(huán)境對分布式應(yīng)用架構(gòu)帶來的挑戰(zhàn)

---

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

微服務(wù)已經(jīng)算是很成熟的技術(shù)了，并且微服務(wù)是分布式系統(tǒng)的一員，所以很多人也會理所當(dāng)然的覺得分布式系統(tǒng)也應(yīng)該很成熟了。但是結(jié)果卻恰恰相反。

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

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

這個時候，反應(yīng)式編程的優(yōu)點就體現(xiàn)出來了。它不管什么原因，處理不了就不請求發(fā)送。而且是立刻的。

?

微服務(wù)環(huán)境對反應(yīng)式編程的新要求

---

不能以為反應(yīng)式編程好像就是可以在微服務(wù)環(huán)境下安枕無憂。其實，它也面臨改進的要求。

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

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

?

性能

---

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

?

總結(jié)

---

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

?

本文作者：

Andy Shi :?

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。