Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layotto是直接复用了mosn的全部能力包括可观测这块嘛 #384

Closed
jingb opened this issue Feb 8, 2022 · 7 comments
Closed

Layotto是直接复用了mosn的全部能力包括可观测这块嘛 #384

jingb opened this issue Feb 8, 2022 · 7 comments

Comments

@jingb
Copy link

jingb commented Feb 8, 2022

为了方便点我就直接中文描述了
基本上阅读了一遍layotto的文档,我理解Layotto是直接复用了mosn的所有能力
但我在 新手任务计划 里面又看到了有可观测性的任务如下
image
对这块有点疑惑,如果复用了mosn按理这些应该是都有的?
还没有仔细看mosn的文档和layotto的代码

背景
当前我这边的是在做FaaS相关的事情,函数间的调用及函数调用其他中间件都是需要一些治理能力的
想通过引入serviceMesh的方式把通用逻辑沉到sidecar减少不同语言支持的工作量
在istio及linkerd间选型,考虑到mosn是可以作为istio的另外一种数据面选择及layotto在Runtime Api这块的前瞻性,当前是比较想使用istio+layotto 引入到这边做的FaaS平台

@seeflood
Copy link
Member

seeflood commented Feb 8, 2022

hi @jingb ,欢迎!

Layotto是直接复用了mosn的所有能力

是的

但我在 #108 里面又看到了有可观测性的任务如下
对这块有点疑惑,如果复用了mosn按理这些应该是都有的?

现在想用layotto对接skywalking的话,还需要做一些集成工作的。因为现状是:

  1. mosn通过skywalking上报trace数据 只支持http1协议的流量 。也就是说,如果用mosn处理别的协议的流量,相关trace数据还不支持上报到skywalking。
    image
  2. layotto现在的trace功能是复用了mosn的trace框架,但是写死了用"SOFATracer"这个driver

因此需要做一些集成工作,实现”用户改一下配置,就能改成用skywalking上报数据“

@seeflood
Copy link
Member

seeflood commented Feb 8, 2022

背景
当前我这边的是在做FaaS相关的事情,函数间的调用及函数调用其他中间件都是需要一些治理能力的
想通过引入serviceMesh的方式把通用逻辑沉到sidecar减少不同语言支持的工作量
在istio及linkerd间选型,考虑到mosn是可以作为istio的另外一种数据面选择及layotto在Runtime Api这块的前瞻性,当前是比较想使用istio+layotto 引入到这边做的FaaS平台

哈哈,我们也在落地 layotto支持faas,你们的架构是啥样的,可以交流下~

@jingb
Copy link
Author

jingb commented Feb 9, 2022

嗯,看过文档和相关的issue
我这边是基于开源框架fission做faas服务,不过已经改得面目全非了。fission是基于k8s的,函数跑在pod里面,单pod单函数做隔离,利用k8s的能力(比方调度)。当前业界大部分的开源faas产品都是基于k8s做,而公有云的产品好像基本都不是基于k8s,至少我了解的企鹅和aws都不是。
像aws底层函数是跑在firecracker上面,我理解你们探索用wasm跑函数,是想利用wasm的隔离性和多语言支持,算faas平台里面的一部分

@zhenjunMa
Copy link
Contributor

@jingb
我们调研wasm,除了隔离性跟多语言支持外,还有一点是调度的速度,我了解基于k8s的话,创建一个pod出来耗时已经不低了(当然这里应该可以优化,不知道你们有没有做这方面的事情),要是再加上函数本身的启动时间(资源初始化之类),很难达到用时启动的目标,比如请求可能都超时了,结果函数还没启动,甚至pod还没创建出来。

@jingb
Copy link
Author

jingb commented Feb 9, 2022

@zhenjunMa 是的,少说了这个冷启动的事情
一开始选用fission就是因为fission实现了热pod池的能力,能够很大程度上降低冷启动的耗时。

所谓热pod池就是一组已经调度完运行起来的pod,函数请求来的时候实例数从0->1,随机选一个可用的pod,然后把函数代码(先忽略编译)从存储里下载到pod里面,利用各种语言的动态加载机制加载进去,然后就可以开始提供服务了。

因为是提前调度好的pod,所以是没有调度、拉镜像这些耗时大头的步骤的,一个空间换时间的解法。
当前这里面是有一些问题的,比方

  1. 这组pod规格都是一样的,数量多了浪费少了可能不够,怎么弹起来
  2. 函数的代码不能太大,不然拉代码的时间太长
  3. 针对问题2我们看细一些,用户的需求是不可控的,比方用户需要个A三方包,要么是我这个pod镜像里已经有了,要么是用户自己把三方包打进代码里面,这样不可避免代码包的大小是失控的(这块我是想着看dapr这种统一API的模式解决,此外就是我理解FaaS是做了很多框架及功能下沉的事情,最好给开发者的就是API,比方kv存储的就是一个 xx.get("key值"),甚至开发者都不要关心底层是存redis还是什么存储,也不要在客户端这侧关心连接池这些东西……)

这里我就简单描述下,有机会的话可以线上开个zoom一起交流下啥的

@seeflood
Copy link
Member

seeflood commented Feb 9, 2022

@jingb 好呀好呀可以详聊,因为我们除了在内部落地faas之外,也在做调研、想着和各种开源serverless生态做集成,方便开源用户落地serverless。可以聊聊您有啥需求,我们帮着共建
要不加群聊?钉钉群 31912621 或者微信群
image

@seeflood
Copy link
Member

更新:对接skywalking的pr在review, #310 可以一起看下

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants