共计 10929 个字符，预计需要花费 28 分钟才能阅读完成。
文|周群力（花名：典礼 )
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 了。
PART. 6 总结
本文探讨了 Layotto 落地之后，对于 Multi-Runtime 架构“可移植性”、落地价值以及部署状态等方面的思考。且本文的探讨不限定于某个具体我的项目。
【参考链接】
《Multi-Runtime Microservices Architecture》：https://www.infoq.com/articles/multi-runtime-microservice-architecture/
《Mecha：将 Mesh 进行到底》：https://mp.weixin.qq.com/s/sLnfZoVimiieCbhtYMMi1A
《从 Service Mesh 到云原生》：https://mp.weixin.qq.com/s/KSln4MPWQHICIDeHiY-nWg
Dapr 我的项目地址：https://github.com/dapr/dapr
Layotto 我的项目地址：https://github.com/mosn/layotto
Capa 我的项目地址：https://github.com/capa-cloud/cloud-runtimes-jvm
Femas 我的项目地址：https://github.com/polarismesh/femas
【本周举荐浏览】
蚂蚁团体 Service Mesh 停顿回顾与瞻望
利用运行时 Layotto 进入 CNCF 云原生全景图
云原生运行时的下一个五年
MOSN 文档使用指南