什么是多運(yùn)行時架構(gòu)？

發(fā)布時間：2023-08-07 15:17:10

服務(wù)化演進(jìn)中的問題

自從數(shù)年前微服務(wù)的概念被提出，到現(xiàn)在基本成了技術(shù)架構(gòu)的標(biāo)配。微服務(wù)的場景下衍生出了對分布式能力的大量需求：各服務(wù)之間需要相互協(xié)作和通信，以及共享狀態(tài)等等，因此就有了各種中間件來為業(yè)務(wù)服務(wù)提供這種分布式能力。

我們熟知的“Spring Cloud 全家桶”正是憑借著對各種中間件優(yōu)秀的集成與抽象能力，成為了當(dāng)時炙手可熱的項目。

然而隨著業(yè)務(wù)的快速發(fā)展，組織規(guī)模的不斷擴(kuò)大，微服務(wù)越來越多，系統(tǒng)規(guī)模越來越大則是服務(wù)化體系架構(gòu)演進(jìn)的必然。這就帶來了兩方面復(fù)雜度的上升：

1.服務(wù)治理與接入的復(fù)雜度

服務(wù)治理代表了系統(tǒng)中服務(wù)資源的地圖及其獲取途徑，例如通過注冊發(fā)現(xiàn)服務(wù)提供圖譜能力，路由、網(wǎng)關(guān)、負(fù)載均衡服務(wù)提供獲取途徑。

服務(wù)接入則代表了如何使用系統(tǒng)中的服務(wù)能力，例如通過中間件提供的 API 協(xié)議或是封裝的 SDK 來接入該中間件。各種業(yè)務(wù)服務(wù)越多、中間件越復(fù)雜，整個系統(tǒng)服務(wù)治理與接入的復(fù)雜度就會急劇上升。

2.團(tuán)隊協(xié)作的復(fù)雜度

該復(fù)雜度主要體現(xiàn)在團(tuán)隊的認(rèn)知負(fù)載上，復(fù)雜的依賴、溝通、協(xié)作將明顯拖慢交付進(jìn)度。正如康威定律所述的，由于服務(wù)復(fù)雜度的上升，團(tuán)隊之間的交互成本也隨之上升。

如下是復(fù)雜度上升問題的一個顯而易見的例子。

當(dāng)系統(tǒng)中的中間件都通過 SDK 作為其外化能力的控制方式，來封裝協(xié)議、數(shù)據(jù)結(jié)構(gòu)與操作方法。隨著中間件數(shù)量和種類不斷增多，大量孤立的 SDK 被綁定在業(yè)務(wù)服務(wù)上，導(dǎo)致兩方面問題：

版本升級困難：SDK 與業(yè)務(wù)服務(wù)的強(qiáng)依賴性導(dǎo)致想要升級 SDK 版本變得異常復(fù)雜與緩慢
業(yè)務(wù)服務(wù)難以異構(gòu)：SDK 所支持的語言反向限制了業(yè)務(wù)服務(wù)所能選擇的語言，例如 Spring Cloud 幾乎沒有官方的多語言支持

如何治理這種不斷上升的復(fù)雜度呢？復(fù)雜問題歸一化是一種不錯的手段。

什么是多運(yùn)行時架構(gòu)

多運(yùn)行時微服務(wù)架構(gòu)（Multi-Runtime Microservice Architecture）也被簡稱為多運(yùn)行時架構(gòu)，是由 Red Hat 的首席架構(gòu)師 Bilgin Ibryam 在 2020 年初所提出的一種微服務(wù)架構(gòu)形態(tài)，它相對完整地從理論和方法的角度闡述了多運(yùn)行時架構(gòu)的模型（實際上，在 2019 年末，微軟的 Dapr v0.1.0 就已經(jīng)發(fā)布）。

暫時先拋開到底什么是“多運(yùn)行時”不談（因為多運(yùn)行時這個名字個人覺得起得可能不太妥當(dāng)），先看看多運(yùn)行時架構(gòu)都包括了哪些內(nèi)容。

分布式應(yīng)用四大類需求

上一節(jié)提到，為了治理不斷上升的復(fù)雜度問題，歸一化是手段之一。歸一化的第一步就是對問題進(jìn)行歸類。

Bilgin Ibryam 梳理了分布式應(yīng)用的各類需求后，將其劃分到了四個領(lǐng)域內(nèi)：

分別是：

生命周期：即應(yīng)用從開發(fā)態(tài)到運(yùn)行態(tài)之間進(jìn)行打包、部署、擴(kuò)縮容等需求。
網(wǎng)絡(luò)：分布式系統(tǒng)中各應(yīng)用之間的服務(wù)發(fā)現(xiàn)、容錯、靈活的發(fā)布模式、跟蹤和遙測等需求。
狀態(tài)：我們期望服務(wù)是無狀態(tài)的，但業(yè)務(wù)本身一定需要有狀態(tài)，因此包含對緩存、編排調(diào)度、冪等、事務(wù)等需求。
綁定：與外部服務(wù)之間進(jìn)行集成可能面臨的交互適配、協(xié)議轉(zhuǎn)換等需求。

Bilgin Ibryam 認(rèn)為，應(yīng)用之間對分布式能力的需求，無外乎這四大類。且在 Kubernetes 成為云原生場景下運(yùn)行時的事實標(biāo)準(zhǔn)后，對生命周期這部分的需求已經(jīng)基本被覆蓋到了。

因此實際上我們更關(guān)注的是如何歸一化其他三種需求。

與單機(jī)應(yīng)用的類比

單機(jī)應(yīng)用一般大都是以用戶態(tài)進(jìn)程的形式運(yùn)行在操作系統(tǒng)上。顯然，與微服務(wù)類似，單機(jī)應(yīng)用的核心關(guān)注點也是業(yè)務(wù)邏輯，與業(yè)務(wù)關(guān)系不大的支撐能力，都要依賴操作系統(tǒng)來完成。

因此上述由 Bilgin 歸納的分布式應(yīng)用四大類需求，其實我們很容易就可以和單機(jī)應(yīng)用進(jìn)行合理的類比：

從上述類比來看我們發(fā)現(xiàn)，單單是 Kubernetes 可能還不足以稱為是 “云原生操作系統(tǒng)”，除非有一種解決方案，能在分布式環(huán)境下，把其他幾項支撐能力也進(jìn)行歸一化整合，才能理直氣壯的冠此大名。

Service Mesh 的成功

Service Mesh 在近幾年的高速發(fā)展，讓我們認(rèn)識到網(wǎng)絡(luò)相關(guān)的需求是如何被歸一化并與業(yè)務(wù)本身解耦的：

通過流量控制能力實現(xiàn)多變的發(fā)布模式以及對服務(wù)韌性的靈活配置，通過安全能力實現(xiàn)的開箱即用的 mTLS 雙向認(rèn)證來構(gòu)建零信任網(wǎng)絡(luò)，通過可觀察性能力實現(xiàn)的網(wǎng)絡(luò)層 Metrics，Logging 和 Tracing 的無侵入式采集。

而上述服務(wù)治理能力，全部被代理到 Sidecar 進(jìn)程中完成。這就實現(xiàn)了 codebase level 的解耦，網(wǎng)絡(luò)相關(guān)的分布式能力完全拋棄 SDK。