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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（來源：Multi-Runtime Microservices Architecture）

分別是：

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

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

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

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

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

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

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

Service Mesh 的成功?

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

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

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

伴隨著 Service Mesh 的成功，我們不禁會(huì)想到，是否可以將另外的兩種需求——狀態(tài)和綁定 ——也進(jìn)行 Mesh 化改造呢？

分布式能力 Mesh 化

基于對(duì) Service Mesh 的拓展，我們大可以將其他的能力也進(jìn)行 Mesh 化，每一類能力都以 Sidecar 的形式部署和運(yùn)作：

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

（來源：Multi-Runtime Microservices Architecture）

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

• 復(fù)雜度從業(yè)務(wù)服務(wù)下沉到了 Mesh 層：多種 Mesh 化方案之間缺乏一致性，導(dǎo)致選型和運(yùn)維的成本很高
• 多個(gè) Sidecar 進(jìn)程會(huì)帶來不小的資源開銷，很多解決方案還需要搭配控制面進(jìn)程，資源消耗難以忽視

對(duì)業(yè)務(wù)復(fù)雜度上升的歸一化，現(xiàn)在變成了對(duì) Mesh 復(fù)雜度上升的歸一化。

Multi-Runtime = Micrologic + Mecha

Bilgin Ibryam 在多運(yùn)行時(shí)微服務(wù)架構(gòu)中，對(duì)前述討論的各種問題點(diǎn)進(jìn)行了整合，提出了 Micrologic + Mecha 的架構(gòu)形態(tài)：

（來源：Multi-Runtime Microservices Architecture）

在 Micrologic 中只包含業(yè)務(wù)邏輯，盡可能的把分布式系統(tǒng)層面的需求剝離出去，放到 Mecha 中。從 Mecha 的命名就可以明白它的功能：

由提供各種分布式能力的 “機(jī)甲” 組成的 Sidecar 進(jìn)程，與 “裸奔的” 業(yè)務(wù)邏輯一起部署。因?yàn)槭?Micrologic 進(jìn)程和 Mecha 進(jìn)程共同部署的這種多個(gè) “運(yùn)行時(shí)” 的架構(gòu)，所以稱之為 “多運(yùn)行時(shí)架構(gòu)”。

Mecha 不僅成功地將分布式能力從耦合的業(yè)務(wù)進(jìn)程中抽取出來，還整合了方案，避免了多種方案混合的額外成本?？梢哉f Mecha 在本質(zhì)上提供了一個(gè)分布式能力抽象層。

因此與其叫 “多運(yùn)行時(shí)架構(gòu)”，不如叫 “面向能力的架構(gòu)”。

微軟的嘗試：Dapr

Dapr 是微軟主導(dǎo)開發(fā)并開源的一種 Mecha runtime，從宏觀上看它處在整個(gè)架構(gòu)的中間層：

（來源：Dapr）

自上而下分別是業(yè)務(wù)層、Dapr Runtime層、基礎(chǔ)設(shè)施層。Dapr 通過 Http 或 gRPC API 向業(yè)務(wù)層提供分布式能力抽象，通過稱為 “Component” 的接口定義，實(shí)現(xiàn)對(duì)具體基礎(chǔ)設(shè)施的插件式管理。

Building Blocks

作為一個(gè)合格的 Mecha，最關(guān)鍵的就是如何定義分布式能力抽象層。如何把各類中間件提供的分布式能力定義清楚是一項(xiàng)挑戰(zhàn)。Dapr 中定義的分布式能力抽象層，稱為 Building Blocks。顧名思義，就是一系列的 “構(gòu)建塊”，每一個(gè)塊定義了一種分布式能力。

（來源：Dapr）

其中有一些 Blocks 的能力由 Dapr 自己就能實(shí)現(xiàn)，有一些則需要由實(shí)際的基礎(chǔ)設(shè)施或中間件來實(shí)現(xiàn)。選取幾個(gè)典型舉例說明：

• Service-to-service Invocation：提供服務(wù)間調(diào)用的能力，其中也隱含了服務(wù)的注冊(cè)與發(fā)現(xiàn)。該 Block 的能力由 Dapr 直接實(shí)現(xiàn)。
• State management：提供狀態(tài)管理能力，最簡單的就是存取狀態(tài)。該 Block 需要其他基礎(chǔ)設(shè)施通過 Component 的形式實(shí)現(xiàn)，例如定義一個(gè) Redis Component。
• Publish and subscribe：提供消息發(fā)布和訂閱的能力，這是非常典型的一種分布式能力。也需要通過基礎(chǔ)設(shè)施來實(shí)現(xiàn)，如定義一個(gè) Kafka Component。

Dapr 的限制與挑戰(zhàn)

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

與 Service Mesh 整合

作為面向開發(fā)側(cè)提供的能力抽象層，Dapr 在網(wǎng)絡(luò)能力上包含了 mTLS、Observability 與 Resiliency（即超時(shí)重試熔斷等），但并沒有包含諸如負(fù)載均衡、動(dòng)態(tài)切換、金絲雀發(fā)布等運(yùn)維側(cè)的流量管理能力。

（來源：Dapr）

因此對(duì)于不斷走向成熟的業(yè)務(wù)系統(tǒng)，可能既要 Service Mesh 在運(yùn)維側(cè)的流量管理能力，又要 Dapr 在開發(fā)側(cè)的分布式抽象能力，不管誰先誰后，都將面臨一個(gè)問題：怎樣搭配使用它們才是正確的？某些場景下可以做適配，如：

• 對(duì)于 distributed tracing 的能力，如果采用 Service Mesh 來實(shí)現(xiàn)，則需要考慮將原本 Dapr 直連的中間件也加入 mesh 網(wǎng)絡(luò)，否則會(huì) trace 不到。但從 distributed tracing 本身功能角度講，更應(yīng)該使用 Dapr。
• mTLS 應(yīng)該只在 Dapr 或者 Service Mesh 中開啟，而不應(yīng)該都開啟。

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

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

而由于 Service Mesh 網(wǎng)絡(luò)代理的流量劫持，網(wǎng)絡(luò)調(diào)用需要先經(jīng)過 Dapr sidecar，再經(jīng)過網(wǎng)絡(luò)代理 sidecar，被代理兩次，也會(huì)造成一定的性能開銷。

下表是匯總的 Dapr 官方標(biāo)注的 daprd 資源與性能消耗數(shù)據(jù)，以及 Istio v1.16（最新版未找到）官方標(biāo)注的 envoy 資源與性能消耗數(shù)據(jù)：

簡單計(jì)算一下就會(huì)發(fā)現(xiàn)，當(dāng)擁有 1000 個(gè)業(yè)務(wù)實(shí)例時(shí)，dapr + istio 的 Sidecar 進(jìn)程可能會(huì)消耗 800+ vCPU 和 60+ GiB 內(nèi)存。

隨著分布式能力抽象層的不斷擴(kuò)展，到底哪些屬于開發(fā)側(cè)，哪些屬于運(yùn)維側(cè)，也許不會(huì)像現(xiàn)在這樣涇渭分明了。因此已經(jīng)有對(duì) Multi-Runtime 與 Service Mesh 能力邊界越來越模糊的討論。

Sidecarless？

從上一節(jié)的表格我們發(fā)現(xiàn)，資源消耗以及性能的問題其實(shí)不只是 Dapr 下的場景，實(shí)際上它是 sidecar 模式自有的限制，因此在 Service Mesh 領(lǐng)域的討論中，已經(jīng)有提出 Sidecarless 的概念了，即通過 DaemonSet 而不是 Sidecar 的形式來部署網(wǎng)絡(luò)代理。

對(duì)于網(wǎng)絡(luò)代理的 Sidecarless 化，支持方認(rèn)為它能帶來高性能、低資源消耗的優(yōu)點(diǎn)，而反對(duì)方則認(rèn)為它會(huì)導(dǎo)致安全性與隔離性差、故障的爆炸半徑過大等缺點(diǎn)。

那么，Mecha 是否也可能會(huì)走向 Sidecarless 呢？

與網(wǎng)絡(luò)代理的 Sidecarless 類似，如果將 Mecha 做成 Daemonset，其優(yōu)劣勢也差不多。而 Daemonset 形式的 Mecha，由于只啟動(dòng)一次，可能會(huì)在 Serverless 的場景下大幅縮短 Serverless 函數(shù)的執(zhí)行時(shí)間。對(duì)此 Dapr 項(xiàng)目也有相關(guān)的討論。

就像今年 Cilium 發(fā)布支持 Service Mesh 能力的辦法，通過 eBPF 在內(nèi)核態(tài)實(shí)現(xiàn) L3 L4 層能力，而對(duì)應(yīng)的 L7 層能力則交給用戶態(tài)的 Envoy 處理這種將問題一分為二的思想，也許多運(yùn)行時(shí)架構(gòu)的未來方案也可能是折中或是多種方式結(jié)合的。例如采用在 Node 上按 Service Account 或 Namespace 運(yùn)行多實(shí)例，或是輕量級(jí) Sidecar 做協(xié)議轉(zhuǎn)換＋DaemonSet 做流量管理和網(wǎng)絡(luò)調(diào)用。

當(dāng)然 DaemonSet 也有其固有的缺陷，資源被共享從而降低消耗的同時(shí)，故障也被共享了，而且故障產(chǎn)生的傷害面也變大了，此外還會(huì)導(dǎo)致 DaemonSet 被應(yīng)用使用的爭搶問題，以及應(yīng)用之間的數(shù)據(jù)暴露風(fēng)險(xiǎn)。到底后續(xù)將會(huì)如何演進(jìn)，我們拭目以待。

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

分布式能力抽象層，是對(duì)分布式場景下需求的抽象性定義，抽象作為一種共識(shí)，其要義就在于保留共性而排除個(gè)性。但實(shí)際當(dāng)中會(huì)發(fā)現(xiàn)，同類型中間件的差異化恰恰體現(xiàn)在了一些高級(jí)的、細(xì)分的專有特性上，很多業(yè)務(wù)對(duì)中間件選型的原因也在于這些專有特性上。

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

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

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

State management 定義了基于事務(wù)操作的能力 /v1.0/state/<storename>/transaction，支持 State management 能力的 Component 有很多，對(duì)于支持事務(wù)的中間件如 Redis 就一切正常，但有一些并不支持事務(wù)的如 DynamoDB，則這種能力就無法使用。

定義抽象能力的困境，本質(zhì)上是一種對(duì)能力收斂的權(quán)衡，這種權(quán)衡可能是與具體的業(yè)務(wù)需要高度相關(guān)的。

關(guān)于如何降低專有特性對(duì)能力集合可移植性的沖擊，敖小劍在他的文章《死生之地不可不察：論API標(biāo)準(zhǔn)化對(duì)Dapr的重要性》中提到了四種解決思路：

(1) 在 Mecha 層彌補(bǔ)能力缺失?

如果缺失的能力支持用基礎(chǔ)能力來間接實(shí)現(xiàn)，就可以在 Mecha 內(nèi)做處理。例如對(duì)于不支持批量寫入的基礎(chǔ)設(shè)施，在 Dapr 中通過 forloop 連續(xù)調(diào)用單次寫入也能間接地彌補(bǔ)這一能力（雖然無法做到性能一致）。?然而這樣也可能導(dǎo)致 Dapr 越來越臃腫，怎么權(quán)衡見仁見智。

(2) 在 Component 層彌補(bǔ)能力缺失?

Component 作為某種具體基礎(chǔ)設(shè)施與 Dapr 的適配器，可以將 1 中的方案下沉到 Component 里面，避免 Dapr 本身的臃腫，然而這種辦法的缺陷在于每種基礎(chǔ)設(shè)施只要想彌補(bǔ)缺失的能力，就都要分別在自己的 Component 中實(shí)現(xiàn)一遍。

(3) 直接忽略某些缺失的能力?

例如在 State management 中對(duì)多副本強(qiáng)一致性的配置屬性 consistency，假如實(shí)際的存儲(chǔ)中間件是單副本架構(gòu)，那么就可以直接忽略掉該屬性。

(4) 其余的情況，只能在業(yè)務(wù)側(cè)處理?

就像前文提到的事務(wù)能力，對(duì)于不支持的基礎(chǔ)設(shè)施必須要明確報(bào)錯(cuò)，否則可能導(dǎo)致業(yè)務(wù)不正確。這種情況就只能在業(yè)務(wù)側(cè)做限制，本質(zhì)上是侵入了業(yè)務(wù)層。

這四種解決思路從權(quán)衡與折中的角度，覆蓋了絕大多數(shù)能力缺失的場景，本質(zhì)上這些思路屬于?“堅(jiān)守API 能力交集”?的辦法。假如跳出“抽象共識(shí)”這一限制，我們是否可以試圖構(gòu)建出一套包含了所有分布式能力的“大全集”呢？顯然只是理論可行，但不現(xiàn)實(shí)。

然而，在企業(yè)實(shí)際的場景下，這個(gè)“全集”的規(guī)?？赡懿⒉灰欢ㄏ裎覀兿胂蟮哪敲待嫶?#xff0c;因此就有可能提供額外的一種思路，即對(duì)分布是抽象層進(jìn)行擴(kuò)展，將有限規(guī)模的“個(gè)性”全部包含進(jìn)去，形成?“并集”?從而規(guī)避上述問題。

螞蟻 Layotto 的設(shè)計(jì)中體現(xiàn)了這種方案，詳見下文。

螞蟻金服的方案：layotto

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

Layotto 的架構(gòu)

（來源：Layotto）

非常有趣的一點(diǎn)是，layotto 是以 MOSN 為基座的。MOSN 是螞蟻金服自研的網(wǎng)絡(luò)代理，可用于 Service Mesh 數(shù)據(jù)面。因此 layotto 類似于是 MOSN 的一個(gè)特殊的插件，向業(yè)務(wù)側(cè)提供分布式能力抽象層，并且仍然以 Component 的形式封裝各種中間件的訪問與操作，而在這之下的所有網(wǎng)絡(luò)層交互全部代理給 MOSN。

由于 layotto 在運(yùn)行態(tài)上是與 MOSN 綁定在一個(gè) Sidecar 內(nèi)的，因此就減少了一部分前文提到的兩個(gè) Sidecar 之間通信的開銷。當(dāng)然 layotto 可以這樣做也有一部分原因在于 MOSN 本身已經(jīng)在螞蟻內(nèi)部大規(guī)模落地，同時(shí)螞蟻也有足夠的研發(fā)強(qiáng)度來支撐 layotto 的開發(fā)。

“私有協(xié)議”與“可信協(xié)議”

Layotto 的開發(fā)者，在討論多運(yùn)行時(shí)架構(gòu)以及 layotto 落地實(shí)踐的文章中，嘗試對(duì)可移植性的概念進(jìn)行了擴(kuò)展，將支撐分布式能力的協(xié)議劃分為“可信協(xié)議”與“私有協(xié)議”。

其中，可信協(xié)議指代的是一類影響力很大的協(xié)議如 Redis 協(xié)議、S3 協(xié)議、SQL 標(biāo)準(zhǔn)等。這一類協(xié)議由于用戶眾多，且被各類云廠商所支持，因此可以認(rèn)為它們本身就具有可移植性。

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

因此實(shí)際上的所謂分布式能力抽象層可能會(huì)是如下圖所示的樣子：

（來源：如何看待 Dapr、Layotto 這種多運(yùn)行時(shí)架構(gòu)？）

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

靈活的擴(kuò)展模型

前文提到的 API 擴(kuò)展形成 “并集”，Layotto 通過提供 In-Tree 形式的私有 API 注冊(cè)點(diǎn)，實(shí)現(xiàn)了不修改 Layotto 代碼就能擴(kuò)展 API 能力：

（來源：Layotto 官方文檔）

從代碼角度看，Layotto 是通過暴露 API 注冊(cè)鉤子，暴露啟動(dòng)入口，來允許用戶自行擴(kuò)展代碼，之后再調(diào)用啟動(dòng)函數(shù)啟動(dòng)進(jìn)程。這樣擴(kuò)展 API 代碼與 Layotto package 級(jí)隔離，但編譯后可形成同一個(gè)二進(jìn)制文件。

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

未來展望

雖然多運(yùn)行時(shí)架構(gòu)這種理念從提出到現(xiàn)在只有兩年，但已經(jīng)很少有人會(huì)否認(rèn)它所帶來的價(jià)值，不論是 Dapr 還是 layotto 的快速發(fā)展，都明確了頭部企業(yè)對(duì)這一領(lǐng)域的投資邏輯。

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

對(duì)多運(yùn)行時(shí)架構(gòu)實(shí)踐的未來，結(jié)合當(dāng)下的限制、挑戰(zhàn)以及趨勢，我們也許能勾勒出某種未來可能的架構(gòu)形態(tài)：

在這一架構(gòu)形態(tài)下：

• 分布式能力抽象層提供標(biāo)準(zhǔn)能力抽象，以及靈活擴(kuò)展的私有協(xié)議的能力
• 既成標(biāo)準(zhǔn)協(xié)議（對(duì)前文 "可信協(xié)議" 的另一種提法）作為 "既成的" 抽象能力，在Mecha 層只做協(xié)議轉(zhuǎn)換或直接透傳
• Mecha 與網(wǎng)絡(luò)代理層進(jìn)程級(jí)耦合，各類特性不再明確區(qū)分開發(fā)側(cè)與運(yùn)維側(cè)
• 進(jìn)程在 Node 上按租戶/namespace 以及高可用要求劃分多實(shí)例
• 接入現(xiàn)代化的可觀測性體系，提升對(duì)故障的洞察分析能力，降低由于架構(gòu)分層帶來的問題診斷困難

總之，不管是架構(gòu)形態(tài)怎么變、能力怎么抽象，讓業(yè)務(wù)邏輯不斷內(nèi)聚，越來越面向接口、面向能力編程的趨勢不會(huì)改變，服務(wù)化體系的未來值得期待。

Reference

• Multi-Runtime Microservices Architecture
• Dapr
• 死生之地不可不察：論API標(biāo)準(zhǔn)化對(duì)Dapr的重要性
• Layotto
• 如何看待 Dapr、Layotto 這種多運(yùn)行時(shí)架構(gòu)？