如何看待 Dapr、Layotto 這種多執行時架構？

文｜周群力（花名：儀式 )

Layotto PMC
Layotto 和 SOFAStack 開源社群的建設，Dapr 貢獻者，Dapr sig-api 的 Co-chair

本文 10963 字閱讀 20 分鐘

2019 年，微軟開源了 Dapr 專案。2021 年，螞蟻參照 Dapr 思想開源了 Layotto 專案。如今，螞蟻已落地 Layotto，服務了很多應用。從理想落地到現實的過程中，我們遇到了不少問題，也對專案做了很多改變。回過頭再看，如何看待 Dapr、Layotto 這種多執行時架構？我們能從中學到什麼？

本次我將從以下幾個方面，分享螞蟻在落地多執行時架構之後的思考：

1. 如何看待“可移植性”

2. 多執行時架構能帶來哪些價值

3. 與 Service Mesh、Event Mesh 的區別

4. 如何看待不同的部署形態

PART. 1 快速回顧

如果你熟悉 Multi-Runtime、Dapr 和 Layotto 的概念，可以跳過這一章節，直接進入下一章節。

快速回顧：什麼是 Multi-Runtime 架構？

Multi-Runtime 是一種服務端架構思路，如果用一句話來概括，就是把應用裡的所有中介軟體挪到 Sidecar 裡，使得“業務執行時”和“技術執行時”分離開。

更詳細的解釋如下：首先來看 Service Mesh，和傳統 RPC 框架相比，Service Mesh 的創新之處在於引入了 Sidecar 模式。Service Mesh 只解決了服務間通訊的需求，而現實中的分散式應用存在更多需求，比如“協議轉換”、“狀態管理”等。Multi-Runtime 架構提出將各種各樣的分散式能力外移到獨立 Runtime，最後和應用 Runtime 共同組成微服務，形成所謂的“Multi-Runtime” （多執行時） 架構。

具體細節可以詳閱《Multi-Runtime Microservices Architecture》和《Mecha：將 Mesh 進行到底》。

哪些專案實現了 Multi-Runtime 架構？

Dapr

Dapr 的全稱是“Distributed Application Runtime”，即“分散式應用執行時”，是一個由微軟發起的開源專案。

Dapr 專案是業界第一個 Multi-Runtime 實踐專案，Dapr 的 Sidecar，除了可以和 Service Mesh 一樣支援服務間通訊，還可以支援更多的功能，如 state （狀態管理） 、pub-sub （訊息通訊） ，resource binding （資源繫結，包括輸入和輸出） 。Dapr 將每種功能抽象出標準化的 API （如 state API） ，每個 API 都有多種實現，比如使用者可以面向 state API 程式設計，但是可以隨意切換儲存元件，今年用 Redis，明年改成用 MongoDB，業務程式碼不用改。

如果之前沒有接觸過 Dapr，更詳細的介紹可以閱讀《Dapr v1.0 展望：從 Service Mesh 到雲原生》這篇文章。

Layotto

Layotto 是由螞蟻集團 2021 年開源的一個實現 Multi-Runtime 架構的專案，核心思想是在 Service Mesh 的資料面 （MOSN） 裡支援 Dapr API 和 WebAssembly 執行時，實現一個 Sidecar 同時作為 Service Mesh 資料面、多執行時 Runtime、FaaS 執行時。專案地址為：https://github.com/mosn/layotto

以上是本文背景，接下來是本次主題分享。

PART. 2 你真的需要這種“可移植性”嗎？

社群比較關注 Dapr API 的“可移植性”，但在落地過程中，我們不禁反思：你真的需要這種“可移植性”嗎？

標準化 API 能滿足所有需求嗎？

資料庫領域曾出現過一個有趣的討論：同一個資料庫能否適用於所有場景，滿足所有需求？ 比如，一個資料庫能否同時支援 OLAP+OLTP+ACID 等等需求？

今天，我們在建設 Dapr API 的過程中也遇到了有趣的問題：在某個產品領域 （比如訊息佇列） ，能否定義一套“標準 API”同時適用於所有的訊息佇列？

當然，這兩個問題不能混為一談：即使是兩種不同型別的資料庫，比如兩個資料庫，一個只做 OLAP，另一個只做 OLTP，它們都可以支援 SQL 協議。兩個差距那麼大的資料庫都能用同樣的協議，我們有理由相信：在特定領域，設計一個適用於所有產品的“標準 API”是可行的。

可行，但現在還不完全行。

現在的 Dapr API 還比較簡單，簡單場景足以勝任，但在複雜的業務場景下，做不到“幫助應用 Write once,run on any cloud”。對這個問題，敖小劍老師的文章《死生之地不可不察：論 API 標準化對 Dapr 的重要性》有過詳細描述，大意是說：

現在的 Dapr API 比較簡單，在生產落地的時候滿足不了複雜需求，於是開發者只能新增很多自定義的擴充套件欄位，在 Sidecar 的元件裡做特殊處理。比如下面是用 State API 時候的一些自定義擴充套件欄位：

（圖片摘自敖小劍老師的文章）

這些自定義的擴充套件欄位會破壞可移植性：如果你換一個元件，新元件肯定不認識這些欄位，所以你得改程式碼。

之所以出現這個問題，背後的根本原因是 Dapr API 的設計哲學。

社群在設計 Dapr API 時，為了可移植性，設計出的 API 傾向於 “功能交集” 。比如在設計 Configuration API 時，會考察各種配置中心 A、B、C，如果 A、B、C 都有同一個功能，那麼這個功能才會出現在 Dapr API 中：

然而，在現實世界中，人們的需求可能是 A 和 B 的交集，B 和 C 的交集 （如下圖紅色部分） ，而不是 A、B、C 的交集：

或者更常見，使用者的需求是“B 的所有功能”，其中必然包括一些 B 獨有的功能，Dapr API 無法覆蓋：

Dapr 提供“標準 API”、“語言 SDK”和“Runtime”，需要應用進行適配 （這意味著老應用需要進行改造） ，侵入性比較大。

因此 Dapr 更適合新應用開發 （所謂 Green Field） ，對於現有的老應用 （所謂 Brown Field） 則需要付出較高的改造代價。但在付出這些代價之後，Dapr 就可以提供跨雲跨平臺的可移植性，這是 Dapr 的核心價值之一。

這些聽起來是解決不了的問題。那怎麼辦？

跨雲部署時，你真的需要從 Redis 換成 Memcached 嗎？

在設計 API 時，常常出現類似的討論：

A：嘿，這個功能只有 Redis 和 xxx 有，但是 Memcached 和其他儲存系統沒有。我們該怎麼辦，要不要把這個功能納入 API 規範裡？

B：如果我們把這個功能納入 API 裡，會有什麼問題？

A：那樣的話，使用我們 API 的使用者就沒法從 Redis 遷移到 Memcached 了，這破壞了可移植性！

等一等……你真的需要從 Redis 換成 Memcached 嗎？

你真的需要這種“可移植性”嗎？

不需要吧！如果你的應用是面向 Redis 程式設計的，那它天生就能部署到不同的雲上，因為每個雲環境都有託管 Redis 服務。如果沒有這種服務，你可以自己部署一個 Redis，讓它有。

而且不止是 Redis，其他開源產品也可以類似操作。

舔狗定理 .

曾經聽過一個很有意思的觀點 （不是我說的） ：商業公司們就像舔狗，哪個開源產品有商業機會，商業公司很快就會去跟進，那個產品就會在各種雲上出現託管服務。話雖糙，但揭示了一個道理：開源產品的協議天生具有可移植性。

標準化 API 的價值是限制私有協議

為了讓討論更具體，讓我們把應用依賴的基礎設施協議劃分成兩類：可信協議與私有協議。

可信協議

指在某個領域影響力比較大的協議，衡量標準是：有託管服務的雲環境 >=k （k 是某個讓你有安全感的數字，比如 3，5）

比如 Redis 的協議，基本可以認為是和 SQL 一樣的事實標準了，各個雲廠商都提供了 Redis 託管服務；再比如 MySQL 協議，各個雲廠商都會提供相容 MySQL 協議的資料庫託管服務。

觀點 1： 可信協議天生具有可移植性。

沒必要擔心“萬一我以後想換雲部署時，沒法從 Redis 切換到 Memcached 怎麼辦”。因為每個雲上都有相容 Redis 的託管服務。

擔心要從 Redis 換成別的快取產品，就像是擔心“假如我今天引入了 Sidecar，如果以後 Sidecar 架構不流行了，我要去掉 Sidecar 怎麼辦”，或者“假如我今天引入了 Spring Cloud，以後其他框架火了，我要換成別的框架怎麼辦”。那一天當然會出現，但是大部分業務都活不到那一天，如果能，恭喜你，到那時你會有足夠的資源做重構。

私有協議

比如閉源產品的協議，或者影響力小的開源產品的協議，衡量標準是：有託管服務的雲環境<k。

舉個例子，螞蟻內部的 MQ 是自建 MQ，使用私有協議，業務程式碼依賴了這種私有協議就不好部署到別的雲環境了，所以適合用標準化 API 包一層。

再比如，你在調研接入某個阿里雲提供的 MQ，但是發現這個 MQ 的 API 是阿里雲獨有的，別的雲廠商不提供這種服務，如果你害怕被阿里雲繫結，最好用標準化 API 把這個私有 MQ API 包一層。

讀到這，你應該明白我想說的了：

觀點 2：

Dapr 標準化 API 的價值是限制私有協議。

題外話 Sky Computing，2021 年，UC Berkeley 發了篇論文，預言云計算的未來是 Sky Computing，大意是說：回看網際網路的歷史，網際網路連線了各種異構網路，對使用者暴露出一個統一的網路，使用者面向這個網路程式設計不需要關心具體每個異構網路的細節；今天不同雲廠商的環境有差異，像極了網際網路出現之前“各立山頭”的狀態，為了讓使用者更方便，我們可以設計一個“互聯雲”，連線各種異構雲環境，遮蔽差異，只對使用者暴露統一的抽象。連線不同雲，可以叫“空計算”。

那怎麼實現呢？

作者提出了 3 層概念模型，最基礎的第一層是“相容層”，負責抽象不同雲服務，讓應用能夠不改程式碼部署在不同雲上。作者認為，開源軟體在各個雲上都有託管服務，所以可以把不同開源軟體整合成一個平臺，形成“相容層”，並且現在已經有專案在這麼做了，比如 Cloud Foundry。

在“相容層”之上，作者認為應該還有“Intercloud 層”和“Peering 層”，感興趣的可以閱讀原文。

我們需要什麼樣的“可移植性”

題外話，電腦科學中有一種思想：如果一個問題太難了解決不了，那就放寬假設，弱化需求。用大白話講就是：如果一個問題太難了解決不了，那就先解決一些更簡單的問題。這樣的例子很多，比如實現資料庫事務的“隔離性”會導致效能很差，只能在實驗室環境使用，無法用在現實世界，於是人們提出“弱隔離性”，羅列出“讀提交”，“可重複讀”之類的“弱隔離級別”，越弱的問題越好解決。

比如在現實世界中，求解 NP-Hard 問題的最優解太慢了，不可行，於是人們提出，放棄追求最優解，只要能保證演算法給出的結果在“可以承受的範圍內”就行，於是有了“近似演算法”；如果這也太難了，那就用玄學演算法——“啟發式演算法”；

比如想實現“對業務透明”的分散式事務比較難，要付出很多代價，於是人們就提出放棄“對業務透明”，於是就有了 TCC 和 Saga；……

既然“可移植性”這個問題太難了，那就讓我們弱化一下需求，先解決一些更簡單的問題：“弱移植性”。

可移植性分級

“可移植性”這個需求太模糊了，我們先明確下需求。我們可以把可移植性分成多個等級：

level 0：業務系統換雲平臺部署時，需要改業務程式碼 （比如換一套基礎設施 SDK， 然後重構業務程式碼） 。

這是常見狀態，比如某公司內部有一套自研訊息佇列系統“XX MQ”，有一個“xx-mq-java-sdk”供業務系統引入。當業務系統想要上雲 / 換雲部署時，由於雲上沒有“XX MQ”，需要換一個 MQ （比如換成 RocketMQ） ，業務系統需要做重構。

level 1：換雲平臺部署時，業務程式碼不用改，但是需要換一套 SDK，重新編譯。

社群有一些通過 SDK 做跨平臺的方案，屬於這個級別。比如攜程開源的 Capa 專案，比如騰訊開源的 Femas 專案。

level 2：換雲平臺部署時，業務系統不需要改程式碼，不需要重新編譯，但是 Sidecar 要改程式碼。

level 3： 換雲平臺部署時，業務系統和 Sidecar 都不需要改程式碼，不需要重新編譯，只需要改配置。

level 4： 換依賴的開源產品時 （比如原先使用 Redis，現在要換成別的分散式快取） ，業務系統和 Sidecar 都不需要改程式碼。

社群的最終目標是 level 4，但是上文已述，現在還沒法完美實現，存在種種問題。對於需要快速落地，解決業務問題的商業公司，現在能實現的目標是：追求 level 2 的可移植性，部分場景可以達到 level 3，這就足夠解決業務問題了。

比如分散式快取場景，螞蟻在 MOSN 裡自建了一套分散式快取中介軟體支援 Redis 協議訪問，如果你相信 Redis 協議是具有可移植性的，那麼應用通過 Redis 協議和 MOSN 通訊即可，沒必要強行遷移到 Dapr 的“State API”上。在這種情況下，標準化 API 只是作為補充。

題外話，Sky Computing 的“相容層”需要哪種可移植性？ 按照這種分級方式，Sky Computing 提出的“相容層”需要 level 3 及以上的可移植性。

如何實現 level 3 可移植？

如果我們把目標定為 level 3，那麼 Runtime 對外暴露的“相容層”協議應該是多種多樣的，包括各種領域的可信協議 （比如 Redis 協議、MySQL 協議、AWS S3 協議等） ，以及 Dapr 風格的標準化 API。

由此，我們可以得出兩個觀點：

觀點 3：

擁抱可信協議：Dapr 標準化 API 的定位應該是作為可信協議的補充，而不是試圖讓使用者放棄可信協議，遷移到 Dapr API 上。

觀點 4：

設計 Dapr 標準化 API 時，要專注於那些還沒有形成可信協議的領域，為這些領域設計標準化 API，而不是花精力設計“Another SQL”，或者糾結“如何從 Redis 遷移到 Memcached”。比如，不同雲廠商的配置中心提高的 API 不一樣，還沒形成事實標準，那麼設計一套跨平臺的 Configuration API 就能填補這個空缺。

演進路線

現在我們回答最開始提出的問題：現在的 Dapr API 有很多問題，比如自定義擴充套件欄位太多，破壞可移植性，比如面向“交集”做設計，功能太弱難以演進，比如侵入性強等等，該怎麼辦？

答案是：逐漸演進，先考慮從 level 2 演進到 level 3。

為了實現 level 3，我們需要：放棄面向“功能交集”的設計，改為面向“功能並集”做設計；在 Sidecar 直接支援各種“可信協議”。

而為了實現最終的 level 4，我們需要：標準化 API 是完備的“功能並集”，保證覆蓋到所有的業務場景；有一套“feature 發現機制”，應用在部署時和基礎設施協商“我需要哪些 feature”，基礎設施根據應用的需求自動繫結元件。

PART. 3 Runtime 架構帶來的價值

除了標準化 API，實踐中 Runtime 架構更大的價值在於以下幾個方面：

一、可能是最重要的價值：讓“下沉”合理化

一個有趣的觀察是：以前 Mesh 的概念強調“代理”，因此一些基礎設施產品想把自己的程式碼邏輯也“下沉”進 Sidecar 時可能會遭到 Mesh 團隊的拒絕，或者能“下沉”進去，但是實現的比較 hack，並不規範；而有了 Runtime 的概念後，各種產品把程式碼邏輯挪到 Sidecar 行為就合理化了。

這裡說的“下沉”，是指“把應用依賴的公共元件從應用裡挪到 Sidecar 裡”，分離核心業務邏輯和技術部分。好處就太多了，比如：

1.多語言複用中介軟體

Service Mesh 宣傳的好處之一是讓多語言應用複用流量治理類的中介軟體，現在 Runtime 強調把更多的中介軟體放進 Sidecar，意味著有更多的中介軟體能夠被多語言應用複用。比如，以前的中介軟體都是為 Java 開發的，C++ 用不了，現在可以讓 Node.js/Python/C++ 語言的應用通過 gRPC 調 Sidecar，複用中介軟體。

2.微服務啟動加速、FaaS 冷啟加速

原先微服務應用的框架比較重，比如有和配置中心建連、初始化、快取預熱之類的邏輯，現在這些啟動邏輯都挪到 Runtime 裡。當應用或者函式需要擴容時，可以複用原有 Runtime，不需要再做一遍類似的建連預熱動作，從而達到啟動加速的效果。

3.不用推動使用者升級 SDK 了

這個就是 Mesh 一直講的好處：有了 Sidecar 後，不需要天天催促各個業務方升級 SDK，提高了基礎設施的迭代效率。

4.讓業務邏輯也能下沉

除了基礎設施，一些業務邏輯也有放進 Sidecar 的訴求，例如處理使用者資訊等邏輯。

讓業務邏輯放進 Sidecar 需要保證隔離性，去年嘗試了用 WebAssembly 來做，但是不太成熟，不敢在生產中使用，今年會嘗試其他方案。

二、讓“下沉”規範化：約束“私有協議”，保證能實現 level 2 可移植

在“下沉”的過程中，標準化 API 更多起到約束“私有協議”的作用，比如：

- 限制私有協議的通訊模型

設計私有協議時 （Layotto 支援“API 外掛”功能，允許擴充套件私有的 gRPC API） ，需要證明“這個私有協議在其他雲上部署時，存在一個能切換的元件”

- 作為設計私有協議的指導

參照著標準化 API 去設計私有協議，有理由相信設計出來的協議在換雲部署時，能達到 level 2 可移植性

三、RPC 協議轉換、微服務互通

Dapr 的 InvokeService （用來做 RPC 呼叫的 API） 設計的比較簡單，也有一些不足，在實際 RPC 場景中，Layotto 調整了它的定位，作為 Service Mesh 的輔助：

已有的 Java 微服務的 RPC 流量還是通過 Service Mesh （MOSN） 進行轉發，而對於其他語言的微服務，或者其他協議棧的微服務，可以通過 gRPC 呼叫 Sidecar，由 Sidecar 幫忙做協議轉換，然後把流量接入已有服務體系。

比如很多語言沒有 Hessian 庫，可以通過 gRPC 調 Layotto，Layotto 幫忙做 Hessian 序列化，然後將流量接入 MOSN。

業界也有一些做多語言微服務打通的專案，比如 dubbogo-pixiu 專案，區別是通過閘道器的形式部署。

PART. 4

如何劃分 Serivce Mesh、Event Mesh 和 Multi-Runtime 的邊界？Serivce Mesh 和 Event Mesh 的區別是什麼？

網上的說法是 Event Mesh 處理非同步呼叫的流量，Service Mesh 處理同步呼叫。

Service Mesh 和 Dapr 的區別是什麼？網上的說法是 Service Mesh 是代理，Dapr 是執行時，要抽象 API，做協議轉換。

但是，隨著落地演進，我們漸漸發現這些技術概念的邊界變得很模糊。

如下圖，Layotto 這個 Sidecar 支援了各種協議，好像已經“非驢非馬”了：不只是 Dapr 式的對外暴露標準化 http/gRPC API，抽象分散式能力，也包括 Service Mesh 式的流量攔截、代理轉發，能處理同步呼叫、非同步呼叫，能處理 Redis 等開源協議的請求，好像把 Event Mesh 的事情也做了，已經變成了一種混合模式的 Sidecar：

所以，如何劃分 Serivce Mesh，Event Mesh 和 Multi-Runtime 的邊界？

個人觀點是，可以把 Dapr 的“標準化 API”看做“Sidecar 增強” 。比如“InvokeService API”可以看成“Service Mesh 增強”，“Pubsub API”可以看成是“Event Mesh 增強”，“State API”可以看成“資料中介軟體增強”，這裡說的資料中介軟體包括快取流量轉發和 DB Mesh。

從這種角度看，Layotto 更像是 Sidecar 裡的“API 閘道器”。

PART. 5 部署形態之爭

一、目前的架構有什麼問題？

目前的架構存在一個問題：Runtime 是個巨石應用。

不管是 Dapr 還是 Layotto，都傾向於承載所有和業務無關的功能。

如果你把 Runtime 類比成作業系統的核心，那麼 API 這層就是系統呼叫，負責抽象基礎設施，簡化程式設計，而不同的元件類似於驅動，負責把系統呼叫翻譯成不同基礎設施的協議。

Runtime 把所有元件都放在一個程式裡，類似於“單核心”的作業系統把所有子模組都塞在一起，變成了巨石應用。

巨石應用有什麼問題？模組間互相耦合，隔離性不好，穩定性降低。比如之前就有研究指出 Linux 中大部分的程式碼是驅動，而且很多驅動是“業餘玩家”寫的，穩定性不好，驅動寫的有問題是 kernel 崩潰的主要原因。

同樣的，如果 Dapr 或者 Layotto 的一個元件出現 bug，會影響整個 Sidecar。

怎麼解決巨石應用的問題呢？拆！一個思路是把 Runtime 按模組拆分，每個模組是一個 Container，整個 Runtime 以 DaemonSet 的形式部署：

這種方案就像作業系統的“微核心”，不同子模組之間有一定的隔離性，但相互通訊的效能損耗會高一些。比如 Event Mesh 容器想要讀取配置中心的配置時，就需要通過網路呼叫 Configuration 容器；如果呼叫頻率過高，就要考慮在 Event Mesh 容器裡做一些配置快取，可能最後每個容器都要做一套快取。

那麼應該選擇單容器 Runtime 還是多容器 Runtime 呢？這就像作業系統選擇“單核心”還是“微核心”架構，全看取捨。巨石應用的好處是子模組之間互相通訊效能好，缺點是緊耦合，隔離性不好；如果把 Runtime 拆成多個 Sidecar 則剛好相反。

目前，Dapr 和 Layotto 都是單容器 Runtime。

一個可能的拆分方案是：將 Runtime 按能力“垂直拆分”成多個容器，比如一個容器負責狀態儲存，一個容器負責非同步通訊等等，容器間通訊通過 eBPF 做優化。不過目前還沒看到這樣做的專案。

二、目前的架構還可以做哪些優化？

優化點 1：啟動應用時，需要先啟動 Sidecar 容器，再啟動應用容器。能否讓應用啟動加速？

直覺上想，如果能讓新啟動的應用 （或函式） 複用已有的 Runtime，就能省掉一些初始化動作，加速啟動。

優化點 2：能否減少 Runtime 的資源佔用？

每個 Pod 都有一個 Sidecar 容器，假如一個節點有 20 個 Pod，就得有 20 個 Sidecar，在大規模叢集裡光是 Sidecar 就要佔用很多記憶體。

能否減少 Runtime 的資源佔用？

直覺上想，如果能讓多個容器共享同一個代理 （而不是每個容器獨享一個代理） ，就能減少資源佔用。

上述兩點看起來都可以通過“讓多個容器共享同一個代理”來做優化。但事情真有那麼簡單嗎？

Service Mesh 社群關於“共享代理”的討論

其實 Service Mesh 社群有過很多關於資料面部署形態的爭論，大致有以下幾種方案：

Sidecar 模式，每個應用獨享一個代理

圖片來自 <eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>

節點上所有 Pod 共享同一個代理

圖片來自<eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>

不需要代理程式，用 eBPF 處理流量

很優雅，但功能有限，滿足不了所有需求。

節點上每個 Service Account 共享一個代理

圖片來自<eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>

混合模式：輕量 Sidecar+ 遠端代理

圖片來自<eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>

Runtime 社群還需要共享代理嗎？

上面幾種方案看起來都行，只是取捨問題，但是到了 Runtime 這裡，情況就變了！

情況 1：叢集裡有各種各樣的中介軟體，各種各樣的基礎設施

如果叢集裡有各種各樣的中介軟體，各種各樣的基礎設施，那還是別用“節點上所有 Pod 共享同一個代理”的模型了。

舉個例子，某叢集裡有各種各樣的 MQ，如果節點上所有 Pod 共享同一個 Runtime，Runtime 事先不知道 Pod 會用什麼 MQ，所以它必須在編譯時帶上所有 MQ 元件。每次新建一個 Pod 時，這個 Pod 要動態把配置傳給 Runtime，告訴 Runtime 它要用哪個 MQ，然後 Runtime 再根據配置去和相應的 MQ 建立連線。

比如下圖，某個節點上，Pod 1、Pod 2、Pod 3 分別使用 RocketMQ、Kafka、ActiveMQ，這時新啟動了一個 Pod 4，Pod 4 告訴 Runtime 它很有個性，它要用 Pulsar！於是 Runtime 就得去和 Pulsar 建連，做一些初始化動作。所以，Pod 4 啟動並沒有“加速”，因為它沒能複用之前已有的連線。

這種情況下，共享 Runtime 並不能幫助應用啟動加速，無法複用和後端伺服器的連線數，雖然能省一些記憶體，但帶來了一些缺點：增加了複雜度，降低了隔離性等等。

如果強行把 Sidecar 模型的 Runtime 改成共享代理，有用，但投入產出比不高。

情況 2：叢集裡基礎設施的技術棧比較統一

在這種情況下，共享代理模型可能有一定價值。

比如，某叢集只用一種 MQ，RocketMQ。假如使用共享代理模型，某個節點上 Pod 1、Pod 2、Pod 3 已啟動，這時新啟動一個 Pod 4 也要用 RocketMQ，此時就可以複用已有的一些後設資料，甚至有可能複用和 MQ 伺服器的連線。

這種情況下，共享代理模型的好處有：應用啟動加速，複用和後端伺服器的連線。

不過，所謂“啟動加速”也是要看情況的，比如通過優化讓 Runtime 啟動快了 2 秒，但是應用啟動卻要 2 分鐘，那麼優化 2 秒其實並沒有多大用處。尤其是有很多 Java 應用的叢集，大部分 Java 應用啟動不快，這點優化價值有限。所以，啟動加速在 FaaS 場景會比較有用。如果函式本身啟動、載入速度較快，優化幾秒還是很有價值的。提高資源利用率，不用部署那麼多 Sidecar 了。