什么是多運行時架構？
發(fā)布時間：2023-08-07 15:17:10
服務化演進中的問題
自從數(shù)年前微服務的概念被提出，到現(xiàn)在基本成了技術架構的標配。微服務的場景下衍生出了對分布式能力的大量需求：各服務之間需要相互協(xié)作和通信，以及共享狀態(tài)等等，因此就有了各種中間件來為業(yè)務服務提供這種分布式能力。
我們熟知的“Spring Cloud 全家桶”正是憑借著對各種中間件優(yōu)秀的集成與抽象能力，成為了當時炙手可熱的項目。
然而隨著業(yè)務的快速發(fā)展，組織規(guī)模的不斷擴大，微服務越來越多，系統(tǒng)規(guī)模越來越大則是服務化體系架構演進的必然。這就帶來了兩方面復雜度的上升：
1.服務治理與接入的復雜度
服務治理代表了系統(tǒng)中服務資源的地圖及其獲取途徑，例如通過注冊發(fā)現(xiàn)服務提供圖譜能力，路由、網(wǎng)關、負載均衡服務提供獲取途徑。
服務接入則代表了如何使用系統(tǒng)中的服務能力，例如通過中間件提供的 API 協(xié)議或是封裝的 SDK 來接入該中間件。各種業(yè)務服務越多、中間件越復雜，整個系統(tǒng)服務治理與接入的復雜度就會急劇上升。
2.團隊協(xié)作的復雜度
該復雜度主要體現(xiàn)在團隊的認知負載上，復雜的依賴、溝通、協(xié)作將明顯拖慢交付進度。正如康威定律所述的，由于服務復雜度的上升，團隊之間的交互成本也隨之上升。
如下是復雜度上升問題的一個顯而易見的例子。
當系統(tǒng)中的中間件都通過 SDK 作為其外化能力的控制方式，來封裝協(xié)議、數(shù)據(jù)結構與操作方法。隨著中間件數(shù)量和種類不斷增多，大量孤立的 SDK 被綁定在業(yè)務服務上，導致兩方面問題：
版本升級困難：SDK 與業(yè)務服務的強依賴性導致想要升級 SDK 版本變得異常復雜與緩慢
業(yè)務服務難以異構：SDK 所支持的語言反向限制了業(yè)務服務所能選擇的語言，例如 Spring Cloud 幾乎沒有官方的多語言支持
如何治理這種不斷上升的復雜度呢？復雜問題歸一化是一種不錯的手段。
什么是多運行時架構
多運行時微服務架構（Multi-Runtime Microservice Architecture）也被簡稱為多運行時架構，是由 Red Hat 的首席架構師 Bilgin Ibryam 在 2020 年初所提出的一種微服務架構形態(tài)，它相對完整地從理論和方法的角度闡述了多運行時架構的模型（實際上，在 2019 年末，微軟的 Dapr v0.1.0 就已經發(fā)布）。
暫時先拋開到底什么是“多運行時”不談（因為多運行時這個名字個人覺得起得可能不太妥當），先看看多運行時架構都包括了哪些內容。
分布式應用四大類需求
上一節(jié)提到，為了治理不斷上升的復雜度問題，歸一化是手段之一。歸一化的第一步就是對問題進行歸類。
Bilgin Ibryam 梳理了分布式應用的各類需求后，將其劃分到了四個領域內：
分別是：
生命周期：即應用從開發(fā)態(tài)到運行態(tài)之間進行打包、部署、擴縮容等需求。
網(wǎng)絡：分布式系統(tǒng)中各應用之間的服務發(fā)現(xiàn)、容錯、靈活的發(fā)布模式、跟蹤和遙測等需求。
狀態(tài)：我們期望服務是無狀態(tài)的，但業(yè)務本身一定需要有狀態(tài)，因此包含對緩存、編排調度、冪等、事務等需求。
綁定：與外部服務之間進行集成可能面臨的交互適配、協(xié)議轉換等需求。
Bilgin Ibryam 認為，應用之間對分布式能力的需求，無外乎這四大類。且在 Kubernetes 成為云原生場景下運行時的事實標準后，對生命周期這部分的需求已經基本被覆蓋到了。
因此實際上我們更關注的是如何歸一化其他三種需求。
與單機應用的類比
單機應用一般大都是以用戶態(tài)進程的形式運行在操作系統(tǒng)上。顯然，與微服務類似，單機應用的核心關注點也是業(yè)務邏輯，與業(yè)務關系不大的支撐能力，都要依賴操作系統(tǒng)來完成。
因此上述由 Bilgin 歸納的分布式應用四大類需求，其實我們很容易就可以和單機應用進行合理的類比：
從上述類比來看我們發(fā)現(xiàn)，單單是 Kubernetes 可能還不足以稱為是 “云原生操作系統(tǒng)”，除非有一種解決方案，能在分布式環(huán)境下，把其他幾項支撐能力也進行歸一化整合，才能理直氣壯的冠此大名。
Service Mesh 的成功
Service Mesh 在近幾年的高速發(fā)展，讓我們認識到網(wǎng)絡相關的需求是如何被歸一化并與業(yè)務本身解耦的：
通過流量控制能力實現(xiàn)多變的發(fā)布模式以及對服務韌性的靈活配置，通過安全能力實現(xiàn)的開箱即用的 mTLS 雙向認證來構建零信任網(wǎng)絡，通過可觀察性能力實現(xiàn)的網(wǎng)絡層 Metrics，Logging 和 Tracing 的無侵入式采集。
而上述服務治理能力，全部被代理到 Sidecar 進程中完成。這就實現(xiàn)了 codebase level 的解耦，網(wǎng)絡相關的分布式能力完全拋棄 SDK。
伴隨著 Service Mesh 的成功，我們不禁會想到，是否可以將另外的兩種需求——狀態(tài)和綁定 ——也進行 Mesh 化改造呢？
分布式能力 Mesh 化
基于對 Service Mesh 的拓展，我們大可以將其他的能力也進行 Mesh 化，每一類能力都以 Sidecar 的形式部署和運作：
在業(yè)界也有不少從某些能力角度切入的方案：
我們可以發(fā)現(xiàn)，各類方案都有自己的一套對某些能力需求的 Mesh 化方案，合理地選擇它們，的確滿足了分布式能力 Mesh 化的要求，但卻引入了新的問題：
復雜度從業(yè)務服務下沉到了 Mesh 層：多種 Mesh 化方案之間缺乏一致性，導致選型和運維的成本很高
多個 Sidecar 進程會帶來不小的資源開銷，很多解決方案還需要搭配控制面進程，資源消耗難以忽視
對業(yè)務復雜度上升的歸一化，現(xiàn)在變成了對 Mesh 復雜度上升的歸一化。
以上為本次所有分享內容
