聊聊Multi-Runtime架构 ，以及 Dapr 、Layotto 等Runtime系统当下需要解决的问题，抛砖引玉，欢迎讨论
Q: 什么是Multi-runtime？什么是Dapr?
A: Multi-runtime是一种服务端架构思路(让我们技术人聊技术，避免使用“云原生架构”之类不明觉厉的buzzword)，简单来说就是把所有中间件下沉到sidecar里，Dapr是一个实现这种架构的项目。可以看看敖小剑老师写的介绍《Mecha：将Mesh进行到底》
Q: 什么是Layotto?
A: 笔者在做的一个实现multi-runtime架构的项目，可以看看https://github.com/mosn/layotto
1. API标准建设
现状：可移植性的理想与现实
Dapr是个非常优秀的项目，但是他还年轻，需要时间来迭代。Dapr API目前还处在早期阶段，我们在生产落地的时候会发现，已有的API满足不了需求。 于是，为了满足生产需求，开发者要大量使用非结构化字段(使用每个API里的metadata字段，这个字段是个map，用户把API不支持的东西全塞map里传给Runtime），或者非结构化API（比如binding API）。这两种使用方式其实都有毒，用了会导致你的app不具有可移植性，和Runtime的设计初衷相悖。
如果你冲着跨云可移植这个目标使用Dapr，又大量使用metadata，那当你想要移植的时候可能会感到失望。
那么，作为工程师，2022年怎么解决这个问题呢？ 作为抛砖引玉，这里列一下我个人的想法：
想法1：建设更多的API标准
这也是我们在做的，根据落地用户的生产需求继续建设API标准、提交给Dapr社区共建。比如：
- 分布式锁API
- 配置API
- 延迟消息API
想法2：可扩展API架构
参考OS领域当年是怎么定API的，我们可以把Runtime API设计成多层：
- 社区标准API
- 企业内部的私有API
- 基础设施特定API
分别对应OS领域的：
- POSIX API
- 各种Unix-like系统自己的System Call
- 特殊硬件提供的特殊功能
基于这种思想，最近在尝试让Layotto支持API插件，让用户自己实现自己的私有API
想法3：移植时开发适配层，让业务无感移植
想要“跨云移植时，一行代码都不用改”太过理想，其实可以把目标定义成“跨云移植时，业务应用不用改代码，基础设施团队开发一些简单的适配层”。
比如应用原先使用Dapr Redis组件，往map里塞一些定制的key，如果换成Dapr Memcached组件，没法直接换，因为Memcached组件不认识map里面这些key。
解决方案是：基础设施团队开发一个Dapr Redis-Memcached的适配层，把map里面的东西翻译成Memcached认识的key就行了。这样一来业务应用依然不用改代码。
想法4：直接支持行业标准协议吧
直接支持行业标准协议>>>>>自己重新发明API。比如支持AWS S3，比如支持SQL。SQL这个有点特殊，想做的话会让Runtime变的特别大，不一定值得。
想法5：别用binding API了
：)
2. 生态建设
2.1. 怎么解决Service Mesh用户的问题？
如何让已经落地Service Mesh的用户平滑迁移到Multi-Runtime？
目前Dapr的方案是把Dapr和Service mesh的sidecar部署成两个sidecar进程 ，互相通信；Layotto目前是跑在MOSN进程里，现在在做的一件事是Layotto on Envoy，让Layotto跑在Envoy之上，和Envoy跑在一个进程里。
2.2. 能否让Runtime API更好的融入K8S生态？
sidecar这种东西更适合被云厂商关心，最好能对用户透明。能否让Runtime API更好的融入K8S生态，让用户不操心sidecar之类的事情？
目前Layotto需要做的事是把Layotto集成进k8s生态;
微软在搞 Azure Container Apps ，提供容器+Dapr的托管服务。
2.3. 想要把Runtime集成进微服务生态
比如集成进java的Spring boot/Spring cloud生态；
比如集成进Node js生态；
比如给 eggjs 做个egg-layotto插件，开发者敲 npm i --save egg-layotto 就能安装插件、写代码调layotto 。
@fengmk2 老师设想的nodejs开发体验是：开发者在WebIDE上写几行nodejs代码、调用Layotto API读写缓存，然后在IDE上点一点或者执行几个命令就能把这几行代码部署成一个带Layotto的eggjs应用，这个应用能够和缓存交互。当然，这其中有很多nodejs相关问题要解决。
3. 上生产环境要解决的问题
想在生产环境铺开，有些问题必须要解决。观察早期生产用户，目前面临以下问题：
3.1. 可扩展性不好
能否让整个项目可扩展，比如某个公司想用layotto但是又想扩展一些自己的功能，要么能自己起一个项目、import开源layotto后通过钩子做一些扩展，要么能通过动态连接库之类的办法去扩展layotto二进制文件。目前这两种办法,dapr和layotto都没法做到，想扩展只能fork出来改代码
再比如用户开发了自己的Dapr组件，编译进Dapr、部署到生产，后来发现Dapr升级了，得重新升级组件、升级Dapr、重新编译部署
3.2. 稳定性风险
可恶的panic
import开源Layotto或Dapr之后，panic风险巨大,因为依赖了Dapr所有组件，这些组件用的库五花八门，可能起自己的协程、在新协程内panic，可能依赖冲突。能否通过按需编译、隔离性设计来减少panic风险？
怎么提高开源Runtime系统的稳定性？
Dapr和Layotto都太年轻了，之前光是看代码都能看到几个bug。目前开源项目的测试投入相对于公司里的测试流程来说少太多了，怎么建设开源测试体系，提高开源Runtime系统的稳定性？
3.3. 可观测性不好
怎么让查问题简单些？
以前没service mesh的时候，有问题我能自己查；后来有了service mesh，遇到问题我只能找别人来查了
——某测试同学
在生产环境落地Service Mesh会导致排查问题变难，而 Multi-Runtime 下沉的功能多了，排查起来更难。
怎么建设 Multi-Runtime 的可观测性，让生产用户查问题简单些？
集成更多可观测性相关的开源系统
翻一翻CNCF的全景图，里面和可观测性相关的系统，都可以做集成
4. Runtime支持新研发模式(FaaS)
目前我们在探索使用sidecar作为FaaS的运行时，支持 serverless 落地。
存在以下问题：
4.1. 想拿WASM跑FaaS，但是WASM的科技树还不完善
几年前wasm刚出来我们就有这个想法，尤其对serverless场景。
但，几年过去了，没太大变化的感觉
——某位行业大佬
WASM非常适合跑FaaS，但可惜相关科技树还不完善。比如缺少资源调度的生态工具，比如wasm 运行时能力参差不齐。
这方面社区有一些有意思的尝试，比如@zhenjunMa 老师做的 Layotto 用Dockerhub做镜像分发、集成K8s做函数调度 ，再比如WasmEdge社区的 Manage WebAssembly Apps in WasmEdge Using Docker Tools
4.2. 做Serverless开源，产品形态应该是什么样的？怎么解决社区的问题？
做Serverless开源，有个难题：你是要解决公司的问题，还是社区的问题？
为什么这么说呢，因为serverless牵扯到整个公司的运维基础设施和研发流程，没法全开源；但是只开源一部分好像又没有意义，只解决公司的问题，没法解决社区用户的问题。这方面可以看 天猪的知乎讨论
那么Serverless开源产品的产品形态应该是什么样的呢？怎么做一个 能解决社区用户问题的 Serverless产品？
5. 一些来自社区的声音：Dapr很棒，但我不想用grpc+sidecar的模式
一些社区用户和公司不选择Dapr的原因之一是，他们不想用grpc+sidecar模式。我们已经能看到一些开源项目，试图在sdk层实现跨平台Runtime，而不是把Runtime做成sidecar。比如 Capa 比如鹅厂的 Femas (如果我没理解错的话)
再比如字节跳动也落地了sidecar ，但是他们对app和sidecar通信有极高的performance追求(因为文章被锁定了，好像不能用一些特殊字，改成英文试试），做了很多通信上的优化，比如基于共享内存的IPC，比如改内核加API，相比之下普通的通过grpc调sidecar的通信方式自然满足不了他们的performance requirement。
个人觉得这个问题倒是好解决，后面可以再开个帖子聊
6. 巨石应用的研发效率
当所有中间件团队都给runtime这一个应用提交代码的时候，这个应用就变成了巨石应用，会带来很多协作成本。如何控制协作成本，保证研发效率和质量？