什麼是多運行時架構？

服務化演進中的問題

自從數年前微服務的概念被提出，到現在基本成了技術架構的標配。微服務的場景下衍生出了對分佈式能力的大量需求：各服務之間需要相互協作和通信，以及共享狀態等等，因此就有了各種中間件來爲業務服務提供這種分佈式能力。

我們熟知的 “Spring Cloud 全家桶” 正是憑藉着對各種中間件優秀的集成與抽象能力，成爲了當時炙手可熱的項目。

然而隨着業務的快速發展，組織規模的不斷擴大，微服務越來越多，系統規模越來越大則是服務化體系架構演進的必然。這就帶來了兩方面複雜度的上升：

  1. 服務治理與接入的複雜度

服務治理代表了系統中服務資源的地圖及其獲取途徑，例如通過註冊發現服務提供圖譜能力，路由、網關、負載均衡服務提供獲取途徑。

服務接入則代表瞭如何使用系統中的服務能力，例如通過中間件提供的 API 協議或是封裝的 SDK 來接入該中間件。各種業務服務越多、中間件越複雜，整個系統服務治理與接入的複雜度就會急劇上升。

  1. 團隊協作的複雜度

該複雜度主要體現在團隊的認知負載上，複雜的依賴、溝通、協作將明顯拖慢交付進度。正如康威定律所述的，由於服務複雜度的上升，團隊之間的交互成本也隨之上升。

如下是複雜度上升問題的一個顯而易見的例子。

當系統中的中間件都通過 SDK 作爲其外化能力的控制方式，來封裝協議、數據結構與操作方法。隨着中間件數量和種類不斷增多，大量孤立的 SDK 被綁定在業務服務上，導致兩方面問題：

  1. 版本升級困難：SDK 與業務服務的強依賴性導致想要升級 SDK 版本變得異常複雜與緩慢

  2. 業務服務難以異構：SDK 所支持的語言反向限制了業務服務所能選擇的語言，例如 Spring Cloud 幾乎沒有官方的多語言支持

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

什麼是多運行時架構

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

暫時先拋開到底什麼是 “多運行時” 不談（因爲多運行時這個名字個人覺得起得可能不太妥當），先看看多運行時架構都包括了哪些內容。

分佈式應用四大類需求

上一節提到，爲了治理不斷上升的複雜度問題，歸一化是手段之一。歸一化的第一步就是對問題進行歸類。

Bilgin Ibryam 梳理了分佈式應用的各類需求後，將其劃分到了四個領域內：

（來源：Multi-Runtime Microservices Architecture）

分別是：

Bilgin Ibryam 認爲，應用之間對分佈式能力的需求，無外乎這四大類。且在 Kubernetes 成爲雲原生場景下運行時的事實標準後，對生命週期這部分的需求已經基本被覆蓋到了。

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

與單機應用的類比

單機應用一般大都是以用戶態進程的形式運行在操作系統上。顯然，與微服務類似，單機應用的核心關注點也是業務邏輯，與業務關係不大的支撐能力，都要依賴操作系統來完成。

因此上述由 Bilgin 歸納的分佈式應用四大類需求，其實我們很容易就可以和單機應用進行合理的類比：

HHh6S3

從上述類比來看我們發現，單單是 Kubernetes 可能還不足以稱爲是 “雲原生操作系統”，除非有一種解決方案，能在分佈式環境下，把其他幾項支撐能力也進行歸一化整合，才能理直氣壯的冠此大名。」

Service Mesh 的成功

Service Mesh 在近幾年的高速發展，讓我們認識到網絡相關的需求是如何被歸一化並與業務本身解耦的：

通過流量控制能力實現多變的發佈模式以及對服務韌性的靈活配置，通過安全能力實現的開箱即用的 mTLS 雙向認證來構建零信任網絡，通過可觀察性能力實現的網絡層 Metrics，Logging 和 Tracing 的無侵入式採集。

而上述服務治理能力，全部被代理到 Sidecar 進程中完成。這就實現了 codebase level 的解耦，網絡相關的分佈式能力完全拋棄 SDK。

伴隨着 Service Mesh 的成功，我們不禁會想到，是否可以將另外的兩種需求——狀態和綁定 ——也進行 Mesh 化改造呢？

分佈式能力 Mesh 化

基於對 Service Mesh 的拓展，我們大可以將其他的能力也進行 Mesh 化，每一類能力都以 Sidecar 的形式部署和運作：

在業界也有不少從某些能力角度切入的方案：

（來源：Multi-Runtime Microservices Architecture）

我們可以發現，各類方案都有自己的一套對某些能力需求的 Mesh 化方案，合理地選擇它們，的確滿足了分佈式能力 Mesh 化的要求，但卻引入了新的問題：

對業務複雜度上升的歸一化，現在變成了對 Mesh 複雜度上升的歸一化。

Multi-Runtime = Micrologic + Mecha

Bilgin Ibryam 在多運行時微服務架構中，對前述討論的各種問題點進行了整合，提出了 Micrologic + Mecha 的架構形態：

（來源：Multi-Runtime Microservices Architecture）

在 Micrologic 中只包含業務邏輯，儘可能的把分佈式系統層面的需求剝離出去，放到 Mecha 中。從 Mecha 的命名就可以明白它的功能：

由提供各種分佈式能力的 “機甲” 組成的 Sidecar 進程，與 “裸奔的” 業務邏輯一起部署。因爲是 Micrologic 進程和 Mecha 進程共同部署的這種多個 “運行時” 的架構，所以稱之爲 “多運行時架構”。

Mecha 不僅成功地將分佈式能力從耦合的業務進程中抽取出來，還整合了方案，避免了多種方案混合的額外成本。可以說 Mecha 在本質上提供了一個分佈式能力抽象層。

因此與其叫 “多運行時架構”，不如叫 “面向能力的架構”。

微軟的嘗試：Dapr

Dapr 是微軟主導開發並開源的一種 Mecha runtime，從宏觀上看它處在整個架構的中間層：

（來源：Dapr）

自上而下分別是業務層、Dapr Runtime 層、基礎設施層。Dapr 通過 Http 或 gRPC API 向業務層提供分佈式能力抽象，通過稱爲 “Component” 的接口定義，實現對具體基礎設施的插件式管理。

Building Blocks

作爲一個合格的 Mecha，最關鍵的就是如何定義分佈式能力抽象層。如何把各類中間件提供的分佈式能力定義清楚是一項挑戰。Dapr 中定義的分佈式能力抽象層，稱爲 Building Blocks。顧名思義，就是一系列的 “構建塊”，每一個塊定義了一種分佈式能力。

（來源：Dapr）

其中有一些 Blocks 的能力由 Dapr 自己就能實現，有一些則需要由實際的基礎設施或中間件來實現。選取幾個典型舉例說明：

Dapr 的限制與挑戰

Dapr 期望通過定義一個能容納所有需求的分佈式能力抽象層，來徹底解放業務邏輯。從歸一化的角度看，不得不說這是一種大膽而富有野心的嘗試，理想條件下的確能非常優雅地解決問題。但現實總是充斥着各種跳脫出理想的情況，Dapr 在推廣的過程中遇到了很多限制與挑戰。

與 Service Mesh 整合

作爲面向開發側提供的能力抽象層，Dapr 在網絡能力上包含了 mTLS、Observability 與 Resiliency（即超時重試熔斷等），但並沒有包含諸如負載均衡、動態切換、金絲雀發佈等運維側的流量管理能力。

（來源：Dapr）

因此對於不斷走向成熟的業務系統，可能既要 Service Mesh 在運維側的流量管理能力，又要 Dapr 在開發側的分佈式抽象能力，不管誰先誰後，都將面臨一個問題：怎樣搭配使用它們纔是正確的？某些場景下可以做適配，如：

但 Dapr 與 Service Mesh 配合使用中難以避免的是開銷的問題，包括資源開銷和性能開銷。

每個應用 Pod 攜帶兩種 sidecar，再加上 Dapr 和 Service Mesh 自己的控制面應用（高可用方案主備或多副本），這些資源開銷是無法忽略，甚至是非常可觀的。

而由於 Service Mesh 網絡代理的流量劫持，網絡調用需要先經過 Dapr sidecar，再經過網絡代理 sidecar，被代理兩次，也會造成一定的性能開銷。

下表是彙總的 Dapr 官方標註的 daprd 資源與性能消耗數據，以及 Istio v1.16（最新版未找到）官方標註的 envoy 資源與性能消耗數據：

tWkeMY

簡單計算一下就會發現，當擁有 1000 個業務實例時，dapr + istio 的 Sidecar 進程可能會消耗 800+ vCPU 和 60+ GiB 內存。

隨着分佈式能力抽象層的不斷擴展，到底哪些屬於開發側，哪些屬於運維側，也許不會像現在這樣涇渭分明瞭。因此已經有對 Multi-Runtime 與 Service Mesh 能力邊界越來越模糊的討論。

Sidecarless？

從上一節的表格我們發現，資源消耗以及性能的問題其實不只是 Dapr 下的場景，實際上它是 sidecar 模式自有的限制，因此在 Service Mesh 領域的討論中，已經有提出 Sidecarless 的概念了，即通過 DaemonSet 而不是 Sidecar 的形式來部署網絡代理。

對於網絡代理的 Sidecarless 化，支持方認爲它能帶來高性能、低資源消耗的優點，而反對方則認爲它會導致安全性與隔離性差、故障的爆炸半徑過大等缺點。

那麼，Mecha 是否也可能會走向 Sidecarless 呢？

與網絡代理的 Sidecarless 類似，如果將 Mecha 做成 Daemonset，其優劣勢也差不多。而 Daemonset 形式的 Mecha，由於只啓動一次，可能會在 Serverless 的場景下大幅縮短 Serverless 函數的執行時間。對此 Dapr 項目也有相關的討論。

就像今年 Cilium 發佈支持 Service Mesh 能力的辦法，通過 eBPF 在內核態實現 L3 L4 層能力，而對應的 L7 層能力則交給用戶態的 Envoy 處理這種將問題一分爲二的思想，也許多運行時架構的未來方案也可能是折中或是多種方式結合的。例如採用在 Node 上按 Service Account 或 Namespace 運行多實例，或是輕量級 Sidecar 做協議轉換＋DaemonSet 做流量管理和網絡調用。

當然 DaemonSet 也有其固有的缺陷，資源被共享從而降低消耗的同時，故障也被共享了，而且故障產生的傷害面也變大了，此外還會導致 DaemonSet 被應用使用的爭搶問題，以及應用之間的數據暴露風險。到底後續將會如何演進，我們拭目以待。

定義抽象能力的（API）的困境

分佈式能力抽象層，是對分佈式場景下需求的抽象性定義，抽象作爲一種共識，其要義就在於保留共性而排除個性。但實際當中會發現，同類型中間件的差異化恰恰體現在了一些高級的、細分的專有特性上，很多業務對中間件選型的原因也在於這些專有特性上。

這就引出了一個困境：抽象能力所覆蓋的需求，其豐富程度與可移植性成反比。

就如上圖所示，如果抽象能力範圍只覆蓋到紅色的部分，則組件 ABC 的專有特性都無法被引入，而如果抽象能力範圍覆蓋到綠色，那麼就無法遷移到組件 C。

Dapr 的 Building Blocks 中，State management 就存在這樣的一個例子：

State management 定義了基於事務操作的能力 /v1.0/state//transaction，支持 State management 能力的 Component 有很多，對於支持事務的中間件如 Redis 就一切正常，但有一些並不支持事務的如 DynamoDB，則這種能力就無法使用。

定義抽象能力的困境，本質上是一種對能力收斂的權衡，這種權衡可能是與具體的業務需要高度相關的。

關於如何降低專有特性對能力集合可移植性的衝擊，敖小劍在他的文章《死生之地不可不察：論 API 標準化對 Dapr 的重要性》中提到了四種解決思路：

  1. 在 Mecha 層彌補能力缺失 

如果缺失的能力支持用基礎能力來間接實現，就可以在 Mecha 內做處理。例如對於不支持批量寫入的基礎設施，在 Dapr 中通過 forloop 連續調用單次寫入也能間接地彌補這一能力（雖然無法做到性能一致）。 然而這樣也可能導致 Dapr 越來越臃腫，怎麼權衡見仁見智。

  1. 在 Component 層彌補能力缺失 

Component 作爲某種具體基礎設施與 Dapr 的適配器，可以將 1 中的方案下沉到 Component 裏面，避免 Dapr 本身的臃腫，然而這種辦法的缺陷在於每種基礎設施只要想彌補缺失的能力，就都要分別在自己的 Component 中實現一遍。

  1. 直接忽略某些缺失的能力 

例如在 State management 中對多副本強一致性的配置屬性 consistency，假如實際的存儲中間件是單副本架構，那麼就可以直接忽略掉該屬性。

  1. 其餘的情況，只能在業務側處理 

就像前文提到的事務能力，對於不支持的基礎設施必須要明確報錯，否則可能導致業務不正確。這種情況就只能在業務側做限制，本質上是侵入了業務層。

這四種解決思路從權衡與折中的角度，覆蓋了絕大多數能力缺失的場景，本質上這些思路屬於 “堅守 API 能力交集” 的辦法。假如跳出 “抽象共識” 這一限制，我們是否可以試圖構建出一套包含了所有分佈式能力的 “大全集” 呢？顯然只是理論可行，但不現實。

然而，在企業實際的場景下，這個 “全集” 的規模可能並不一定像我們想象的那麼龐大，因此就有可能提供額外的一種思路，即對分佈是抽象層進行擴展，將有限規模的 “個性” 全部包含進去，形成 “並集” 從而規避上述問題。

螞蟻 Layotto 的設計中體現了這種方案，詳見下文。

螞蟻金服的方案：layotto

螞蟻金服作爲 Dapr 的早起使用者，在落地的過程中結合遇到的問題及業務思考，在 2021 年年中推出了自研的 Mecha 方案：layotto。

Layotto 的架構

（來源：Layotto）

非常有趣的一點是，layotto 是以 MOSN 爲基座的。MOSN 是螞蟻金服自研的網絡代理，可用於 Service Mesh 數據面。因此 layotto 類似於是 MOSN 的一個特殊的插件，向業務側提供分佈式能力抽象層，並且仍然以 Component 的形式封裝各種中間件的訪問與操作，而在這之下的所有網絡層交互全部代理給 MOSN。

由於 layotto 在運行態上是與 MOSN 綁定在一個 Sidecar 內的，因此就減少了一部分前文提到的兩個 Sidecar 之間通信的開銷。當然 layotto 可以這樣做也有一部分原因在於 MOSN 本身已經在螞蟻內部大規模落地，同時螞蟻也有足夠的研發強度來支撐 layotto 的開發。

“私有協議” 與 “可信協議”

Layotto 的開發者，在討論多運行時架構以及 layotto 落地實踐的文章中，嘗試對可移植性的概念進行了擴展，將支撐分佈式能力的協議劃分爲 “可信協議” 與“私有協議”。

其中，可信協議指代的是一類影響力很大的協議如 Redis 協議、S3 協議、SQL 標準等。這一類協議由於用戶衆多，且被各類雲廠商所支持，因此可以認爲它們本身就具有可移植性。

私有協議則指代一些企業內部自研的、閉源或影響力小的開源軟件提供的協議。顯然這一類協議才更需要考慮抽象與可移植性。

因此實際上的所謂分佈式能力抽象層可能會是如下圖所示的樣子：

（來源：如何看待 Dapr、Layotto 這種多運行時架構？）

各類可信協議不再二次抽象，而是直接支持，對其餘的私有協議再進行抽象。這種直接支持開源協議的思路，部分緩解了定義抽象能力的困境問題。

靈活的擴展模型

前文提到的 API 擴展形成 “並集”，Layotto 通過提供 In-Tree 形式的私有 API 註冊點，實現了不修改 Layotto 代碼就能擴展 API 能力：

（來源：Layotto 官方文檔）

從代碼角度看，Layotto 是通過暴露 API 註冊鉤子，暴露啓動入口，來允許用戶自行擴展代碼，之後再調用啓動函數啓動進程。這樣擴展 API 代碼與 Layotto package 級隔離，但編譯後可形成同一個二進制文件。

另外，通過 MOSN 的 WASM 插件能力，Layotto 也支持通過 WASM 鏡像來擴展 API Filter。

未來展望

雖然多運行時架構這種理念從提出到現在只有兩年，但已經很少有人會否認它所帶來的價值，不論是 Dapr 還是 layotto 的快速發展，都明確了頭部企業對這一領域的投資邏輯。

當然目前從理論到實踐可能都不夠成熟，大家在落地實踐的過程中也都會或多或少遇到前文提到的一些侷限。但這些侷限所處的層次大都是工程化、技術選擇等具體的問題，相信隨着各方技術的不斷整合，實踐的不斷完善，問題都能解決。

對多運行時架構實踐的未來，結合當下的限制、挑戰以及趨勢，我們也許能勾勒出某種未來可能的架構形態：

在這一架構形態下：

總之，不管是架構形態怎麼變、能力怎麼抽象，讓業務邏輯不斷內聚，越來越面向接口、面向能力編程的趨勢不會改變，服務化體系的未來值得期待。

Reference

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/EKzQMSZByF3EaK6XUgm4Gw

猜你喜歡