什么是多运行时架构？( 五 ) _架构

蚂蚁 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 的快速发展，都明确了头部企业对这一领域的投资逻辑。
当然目前从理论到实践可能都不够成熟，大家在落地实践的过程中也都会或多或少遇到前文提到的一些局限。但这些局限所处的层次大都是工程化、技术选择等具体的问题，相信随着各方技术的不断整合，实践的不断完善，问题都能解决。
对多运行时架构实践的未来，结合当下的限制、挑战以及趋势，我们也许能勾勒出某种未来可能的架构形态：