[Discussion] Multi-Runtime 2022：待解决的问题

[seeflood]

聊聊Multi-Runtime架构 ，以及 Dapr 、Layotto 等Runtime系统当下需要解决的问题，抛砖引玉，欢迎讨论

1. API标准建设

现状：可移植性的理想与现实

Dapr是个非常优秀的项目，但是他还年轻，需要时间来迭代。Dapr API目前还处在早期阶段，我们在生产落地的时候会发现，已有的API满足不了全部需求。
于是，为了满足生产需求，开发者要大量使用非结构化字段(使用每个API里的metadata字段，这个字段是个map，用户把API不支持的东西全塞map里传给Runtime，Runtime里的组件，比如Redis组件，从map里按照约定的key取东西），或者非结构化API（比如binding API）。这两种使用方式其实都有问题，用了会导致你的app不具有可移植性，和Runtime的设计初衷相悖。
如果你冲着跨云可移植这个目标使用Dapr，又大量使用metadata，那当你想要移植的时候可能会感到失望。
这并不是在否定Dapr，毕竟他刚出生没多久、需要时间变得成熟，而且他带来的价值可不只是跨云可移植这一点。这点问题不足以否定Dapr带来的价值。

那么，作为工程师，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、重新编译部署


目前Dapr和Layotto都有这问题 :(

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的全景图，里面和可观测性相关的系统，都想和Layotto做个集成。也欢迎共建 ：）

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通信有极高的性能追求，做了很多通信上的优化，比如基于共享内存的IPC，比如改内核加API，相比之下普通的通过grpc调sidecar的通信方式自然满足不了他们的性能追求。

个人觉得这个问题倒是好解决，后面可以再开个帖子聊

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue or help wanted. Thank you for your contributions.

[jingb]

mark

[yanggeorge]

写的太好了。真正实现落地，会有非常多的问题。
layotto目前只发布了3个版本。不敢用。只能以dapr作为切入点，试水了。

[seeflood]

@yanggeorge 哈哈，这个文章是去年写的，这周要发布v0.4 了，希望解决其中一部分问题
用 dapr 的过程中遇到问题也欢迎讨论哈
这周也会参与木兰社区的直播，分享 Layotto 落地体验，感兴趣也可以来看看

[yanggeorge]

@seeflood 好啊。能发一个直播的地址吗？

[seeflood]

@yanggeorge 晚点等我问到发你，我现在也不清楚 😆 时间是周五上午

[seeflood]

@yanggeorge B站预约直播地址：
https://t.bilibili.com/643279315254902791?share_medium=android&share_plat=android&share_session_id=0301ad7f-3846-4c07-9e27-d958f7134b96&share_source=COPY&share_tag=s_i&timestamp=1648614037&unique_k=QlWOAC1

[yanggeorge]

@seeflood thx.

[Mossaka]

你好👋，非常棒的一篇文章。关于4.1 Wasm里面的一个问题：“Wasm运行时如何设置某个函数所使用的最大资源限制“，如果使用的是wasmtime runtime的话，那么可以在engine config里设置consume_fuel flag，然后可以在Store里面add_fuel 来一定程度上控制instance的CPU的运行时间。内存的话可以使用limiter。

希望能帮到你！

[seeflood]

@Mossaka 感谢建议！ 社区正准备用 wasmtime, 见讨论:
#732
#607

不过感觉 add_fuel 比较 low level, 不太好控制占用的 cpu 资源，目前的想法是起个调度线程（协程）、定时给模块 add_fuel，但是这样有很多问题（比如：调度协程自己没被调度到，导致 wasm 模块没 fuel、没法继续运行）
这方面您有啥建议不~

[Mossaka]

@seeflood

不过感觉 add_fuel 比较 low level, 不太好控制占用的 cpu 资源

目前wasmtime确实没有一个API能够直接控制CPU资源。不过好像async + add fuel 可以做到，见这个issue:
bytecodealliance/wasmtime#2274 (comment)