[Proposal]Dynamic mecha:Let business logic sink to sidecar
seeflood opened this issue · comments
Dynamic mecha: Let business logic sink to sidecar
This is a feature discussion thread. I put it here to see if everyone thinks this feature is worth doing.
The motivation for this feature is that the multi-tenant system that I was responsible for has always had the pain point of lack of isolation. So I am wondering whether it can be solved through the wasm in Layotto.
1. What problem to solve and what is the value
1.1. Reloadable SDK
The business application also has its own SDK, and there are also problems in sdk upgrades and version fragmentation:
For example, a platform system developed an SDK in the form of a jar package for use by other business systems. Their features are not universal to the entire company, so they cannot persuade the middleware team to develop them into the company's unified sidecar.
And if it becomes like this:
If developers no longer develop sdk (jar package), and develop .wasm files instead, they can upgrade and deploy these files independently, and there will be no pain to push other systems to upgrade their sdk. When you want to upgrade your wasm files, you just do some operation in the PaaS console. There is no need to restart the app and sidecar any more.
1.2. Sandbox as a Service
For example, a multi-tenant system written in Java supports developers from different department to write groovy in it. If memory leak happens, it may cause the entire jvm oom. This is dangerous, and the memory isolation problem in jvm cannot be solved.
If we let the business guys change from writing groovy in jvm to writing rust/assemblyscript/cpp and automatically compiling to .wasm,the sidecar can reload these .wasm during runtime and isolate each function with memory and cpu limit.With this architecture,the isolation problem can be solved.
Dynamic mecha:让业务逻辑也能下沉到sidecar
这是一个需求讨论帖，发出来看看大家觉得这件事值不值得做。
起因是我之前负责的一个多租户系统一直有缺少隔离性的痛点，做Layotto的时候就在想能否通过Layotto内的wasm解决这种痛点
1. 解决什么问题，价值是什么
1.1. Reloadable SDK
业务系统也有自己的sdk，也会有推动升级难、版本碎片的问题：
比如某中台系统以jar包形式开发了sdk，供上层业务系统使用。他们的feature不算全公司通用，因此没法说服中间件团队、开发到公司统一的sidecar里。
而如果变成这样：
如果开发者不再开发sdk(jar包），改成开发.wasm文件、支持独立升级部署，就没有推动业务方升级的痛苦了,想要升级的时候在运维平台上操作发布即可，不需要app和sidecar重启
1.2. Sandbox as a Service
比如某中台java系统是多租户架构，支持不同业务方写groovy。如果一个业务方写的代码内存泄漏，可能导致整个jvm oom。这是稳定性隐患，而jvm内的内存隔离问题是没法解决的。
如果让业务方从写groovy、跑在jvm上，改成写rust/assemblyscript/cpp、构建时自动编译成.wasm，sidecar加载这些.wasm、对每个功能做内存和cpu隔离，就能避免这种稳定性隐患:
补充一种场景，最近有遇到用户需求想在Sidecar逻辑里做一些扩展，比如RPC路由逻辑想要做一些定制
按当前架构，用户想扩展的话，需要sidecar通过grpc callback回调，如果钩子少还好，钩子多的话这种方式不scale，不可行。
这其实是个通用的问题：以前中间件在sdk里、支持用户扩展，现在中间件下沉到sidecar了，还怎么扩展？
个人觉得这种需求适合通过WASM做扩展
1.3. Layotto Extension
Sidecar监听.wasm变更、加载进内存，runtime可以在任意地方预留扩展点，app用户需要hook做定制逻辑的时候，只需要按照SPI实现.wasm扩展点
2. 总体架构
综合上述场景，我们可以将内部架构设计成：
sidecar监听.wasm文件变化，如果有变化就加载进内存；每个wasm模块有唯一服务名，内部有个服务注册表，以及路由机制。
支持多种方式调用wasm服务：
- FaaS场景，调用wasm function
- APP调用wasm模块，例如上述Reloadable Sdk，或者Sandbox as a Service场景
- Layotto Extension. Layotto预留若干扩展点，允许用户在运行时扩展
扩展能力所有基础设施都需要，但是是否当下就能这么笃定选择 WASM 目前还存在很多讨论。WASM 本身的标准其实还在讨论中，什么时间能够定下来也存在不确定性，并且每种语言能转换到 WASM 的能力还是差异很大的。
我看 apisix 也有类似的能力，我记得他们有曾经考虑选型 WASM，但是目前还是没有使用，而是独立进程的 RPC 方案实现扩展 https://apisix.apache.org/zh/docs/apisix/external-plugin/
@fengmk2 是的，其实现在Layotto的WASM相关功能还属于探索性功能，暂时还没在生产直接用，毕竟从一些公司的历史中我们也都看到了，如果在基础设施中贸然选择一项技术、最终这技术没有在社区推广开，带来的损失是巨大的。
目前对WASM相关的探索除了这种动态扩展外，主要精力在尝试拿WASM当FaaS的运行时，@zhenjunMa大佬一直在做，不过也属于探索性，暂时不会在生产直接用。
如果只是做动态扩展，有很多种方案、不一定非得用WASM，比如支持通过脚本语言动态扩展（缺点是隔离性不好），比如再加一个sidecar进程跑扩展（缺点是进程通信损耗），比如一个进程里跑多个go runtime
这个提案属于“既然MOSN已经有WASM运行时了，既然Layotto跑在MOSN上、能沾沾光，那我们能拿MOSN的WASM runtime做点什么呢？”的讨论
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.
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.
mark