Deploy layotto on AWS and Alibaba Cloud, together with native sidecar

[seeflood]

@kevinten10 目前遇到了多语言维护成本高的痛点，在调研 sidecar 模式

但是遇到了问题:

1. 已经在 AWS 和 阿里云上用了原生 sidecar （AWS app mesh 和 阿里云 ASM，其实都是 envoy)，在开启了透明流量劫持的情况下, 再部署个 layotto sidecar 会不会冲突?
2. 已经有了原生 sidecar (envoy), 再部个 mosn 比较冗余。能否部署一个 layotto 独立sidecar，但是里面不带mosn？

需求细节：

• rpc 需要走 layotto sidecar，因为有一些 tracing、可观测性相关逻辑要自己写；
• 云上的 mesh 不好做扩展、不考虑把扩展逻辑做在 envoy 里（AWS envoy 想扩展得自己打镜像、再交给 AWS 托管，有额外的运维成本，不想这么做）
• 考虑私有云采用 sdk（因为要复用已有中间件，不可能换个语言重写一遍）云上用 sidecar 模式。值得学习

action:

• 把 layotto 拆个独立包，以不带 mosn 的方式启动 @seeflood
• 找个 AWS 环境，二进制运行，看看流量冲突问题 @kevinten10

[kevinten10]

A、目前Capa SDK模式在落地中的痛点：

1. 多语言问题：

我们目前主要有java/nodejs两种语言，后续可能拓展到python/golang语言，同一个逻辑需要在多种语言中实现，开发维护成本高。

2. 版本迭代问题：

在公有云落地初期，需要定制/兼容的逻辑比较多，经常改一行代码然后就要升级sdk版本，再去推业务方升级，业务方频繁升级导致推进困难。

3. Java依赖冲突：

由于CapaSDK需要和第三方sdk一起运行，有时会涉及到多个云的sdk。虽然借助maven做了依赖隔离管理，但有时还是会遇到依赖冲突的问题，在解决依赖冲突上花费了比较大的精力。

4. 发包链路长：

由于Capa分成了好几个层次（api层/spi实现层等），相互之间通过maven发布的jar包进行引用。导致修改一个功能，需要依次升级多个包，开发效率较低。

---

B、Capa run on multi-runtime调研：

1. 在私有云，继续使用sdk模式。

私有云功能由专门的中间件sdk提供，直接复用，不需要做很多自定义逻辑。

2. 在公有云，java大部分功能继续使用sdk模式，调研sidecar模式可行性，并尝试逐渐将功能下沉到sidecar中。

Capa run on multi-runtime模式。

3. 在公有云，golang/python等语言可以直接尝试使用layotto-sdk，并使用sidecar模式。

如果sidecar模式可行，后续Capa不必再为其他语言开发一套sdk，可以直接复用layotto-sdk。

[kevinten10]

C、功能下沉到sidecar

1. configuration

configuration对性能要求比较低，容错度比较高。所以会先考虑下沉到sidecar中。

Capa目前在aliyun上使用MSE Nacos-Client，在aws上使用appconfig client。

目前，Capa做了一些自定义逻辑在里面：

1. 定时轮询，根据某个配置文件中的自定义时间，定时轮询获取最新的版本信息（appconfig sdk不支持服务端推送模式，只能通过get方法获取更新）。
2. 主要使用了get/subscribe方式，目前未使用到save/delete方法

---

2. RPC Client

目前，在aws/aliyun的Capa SDK中链路如下：

业务代码通过Capa-Adaptor SDK发起RPC调用 -> invokeMethod API -> Capa SDK ① -> Java HTTP client -> 流量劫持 -> Appmesh/ASM envoy -> 服务端

Capa在SDK中（①中）做了一些自定义逻辑：

1. 基于configuration配置添加了一些header
2. 获取当前上下文的traceid等上下文字段，放到http header中

(1)

对于(1)这种场景，能否下沉到sidecar中呢。

如果将该部分逻辑加入到envoy当中，就如上所述，可能要自运维镜像，并且不好修改。

能否先走layotto，将自定义逻辑写在layotto当中呢（用golang或者wasm）。layotto再将流量转发给appmesh/asm envoy。

但这样会不会带来性能损耗。

(2)

对于(2)中获取trace上下文字段的功能，我觉得可能没有办法下沉到sidecar中，因为trace上下文跟线程上下文有关。

这个可能也是layotto-sdk需要考虑的问题吧？layotto-sdk该如何做trace-id上下文追踪呢？

Capa目前是基于 [OpenTelemetry] 定义了一套 Trace/Metric Runtime API，并且在RPC Client中通过这套API获取当前的trace-id等字段，然后放入http header中。

(3)

在使用aws appmesh时，发现它原生的 熔断/限流/预热 等功能并不完善。

如果引入layotto，是否可以在layotto中实现这些能力呢，我理解可能要引入mosn是吧

---

3. RPC Server

目前，在aws/aliyun的Capa SDK中链路如下：

流量到达本机 -> 流量劫持 -> Appmesh/ASM envoy -> Tomcat/SpringMVC -> Capa SDK ①  -> 业务代码的服务端接口方法

Capa在SDK中（①中）做了一些自定义逻辑：

1. 基于configuration配置添加了一些header（与私有云的header做兼容）
2. 获取http header中的一些字段，放入到当前上下文的traceid等字段中

(1)

同上，envoy中无法植入逻辑，如果请求直接到 Tomcat/SpringMVC，那还是需要每种语言SDK都要写一遍Server端的自定义逻辑。

能否实现：

流量到达本机 -> 流量劫持 -> Appmesh/ASM envoy -> Layotto Sidecar ② -> Tomcat/SpringMVC -> Capa SDK -> 业务代码的服务端接口方法

这样可以在（②）中植入服务端的一些自定义逻辑。

(2)

同上，这个还是需要在SDK内做的，将header中的字段放入线程上下文（trace）。

---

4. Mysql、Redis

如果layotto的redis component性能比较好，可以考虑redis下沉到sidecar。

如果性能不稳定的话，暂不考虑下沉到sidecar中，可能在未来考虑使用database mesh、redis mesh等。

---

4. mq pub/sub

主要是producer/consumer。

目前在aliyun/aws上目前使用kafka，可以考虑下沉到sidecar。

---

5. log、trace、metric

Capa目前在使用的API，可能无法下沉到sidecar中。

log：不同云上，打印日志的方式不同。例如私有云上直接打到私有云log sdk中（通过网络传输日志）；公有云上直接打到磁盘上。都不经过sidecar。

trace/metric：基于opentelemetry sdk实现，跟线程上下文有关，无法下沉到sidecar中。

---

6. Capa 正在做的功能

file/s3: 可以考虑下沉到sidecar，和社区默认实现可能也有一些自定义逻辑上的不同

dislock: 可以考虑下沉到sidecar

ratelimit：后续给社区提案

[kevinten10]

D、sidecar部署模式的讨论

如果要部署sidecar，讨论一下哪种部署方式会更好一些呢。

1. sidecar模式

经典模式，不过在已经部署了appmesh/asm的情况下，需要再部署一个容器。

最终一个pod中会有3个容器，主要问题是成本问题：部署成本和运维成本。

可能调试起来不太方便，见（E）。

2. 独立部署模式

比如将layotto独立部署为中心化节点。

然后像configuration这类非性能敏感的场景，是否可以由业务pod通过grpc直连中心化节点来提供。

好处是：

1. 主要是成本问题，降低了pod中增加容器的部署成本和运维成本。
2. 有利于本地debug，本地可以通过grpc直连远程的中心化节点，来提供各项能力。

但这么搞的项目比较少，比如中心化瓶颈、单点故障等问题？

---

E、sidecar模式的本地调试问题

这应该是一个社区常见的问题，就是如何在开发环境进行debug，无论是envoy/istio/dapr我似乎都没有找到很好的解决方案。

如果Capa由SDK模式切换到sidecar模式，有办法进行方便的本地debug吗（网络是通的）。

不过Capa目前正在使用的Appmesh和ASM，也没有很好的解决这个问题。

[kevinten10]

F、与云平台的顺滑集成

我之前看layotto社区是打算复用istio工具链，然后在k8s里面做layotto on istio是么。

那像已经在用aws appmesh和asm的用户（非原生istio），该如何顺滑集成呢。

比如appmesh，是通过helm安装的。

layotto有没有类似helm的方式，可以很方便的在k8s集群中进行安装/升级/卸载呢。

[kevinten10]

以上是对该issue的补充说明~

[seeflood]

关于RPC Client:

2. 获取当前上下文的traceid等上下文字段，放到http header中
   (2)
   对于(2)中获取trace上下文字段的功能，我觉得可能没有办法下沉到sidecar中，因为trace上下文跟线程上下文有关。

这个可能也是layotto-sdk需要考虑的问题吧？layotto-sdk该如何做trace-id上下文追踪呢？

Capa目前是基于 [OpenTelemetry] 定义了一套 Trace/Metric Runtime API，并且在RPC Client中通过这套API获取当前的trace-id等字段，然后放入http header中。

取线程上下文、塞header ，听起来是只能由sdk实现的功能；你们其他语言也会有类似需求么?
如果有的话，确实只能在每个语言的 sdk里加，但这部分应该不复杂，不会经常修改、推业务升级

[seeflood]

我之前看layotto社区是打算复用istio工具链，然后在k8s里面做layotto on istio是么。

是的

那像已经在用aws appmesh和asm的用户（非原生istio），该如何顺滑集成呢。

我调研下，你可以帮忙一起看看，因为我对这些云服务也不是很熟
感觉现在的主要矛盾是（在已有 sidecar 的情况下）怎么部署 :)

我们先确定大的方向，再讨论细节哈。几个可能的方向:
A. 最理想的方式是让 阿里云asm 也支持 layotto 能力（比如把蚂蚁的 moe 方案输出到 阿里云上） 要先找人聊下
B. 另一种方案，既然是找小语种应用试点、切到 Layotto，那能否让小语种应用 从envoy 迁移到 mosn 上来？比如 阿里云也有 mosn服务；或者不买他的服务，自己运维 layotto sidecar
C. 都不行的话，就新加一个 sidecar，看需求只用给小语种应用加，java 不需要

我感觉 B 更合适些， @kevinten10 先评估下?

[kevinten10]

取线程上下文、塞header ，听起来是只能由sdk实现的功能；你们其他语言也会有类似需求么?

是的，这个应该是只能由sdk实现的。

其他语言也会有，不过opentelemetry提供了多语言sdk，这个可以复用它的sdk。

这种分布式追踪的功能，应该是普遍的应用场景，layotto-sdk打算怎么做呢？

如果有的话，确实只能在每个语言的 sdk里加，但这部分应该不复杂，不会经常修改、推业务升级

这部分我感觉是会经常修改的。例如最开始只需要传递trace-id，后面又逐渐添加trace-souce等字段。最终在每次rpc调用时，header中会有一大堆用于上下文传递的字段（已有的rpc框架，往往有很多的自定义header）

[kevinten10]

我调研下，你可以帮忙一起看看，因为我对这些云服务也不是很熟
感觉现在的主要矛盾是（在已有 sidecar 的情况下）怎么部署 :)

我们先确定大的方向，再讨论细节哈。几个可能的方向:
A. 最理想的方式是让 阿里云asm 也支持 layotto 能力（比如把蚂蚁的 moe 方案输出到 阿里云上） 要先找人聊下
B. 另一种方案，既然是找小语种应用试点、切到 Layotto，那能否让小语种应用 从envoy 迁移到 mosn 上来？比如 阿里云也有 mosn服务；或者不买他的服务，自己运维 layotto sidecar
C. 都不行的话，就新加一个 sidecar，看需求只用给小语种应用加，java 不需要

我感觉 B 更合适些， @kevinten10 先评估下?

A

这样感觉对阿里云会很好啊，应用迁移到阿里云的成本会变低。不过还是会面临混合云的问题呢：在阿里云用托管layotto，在azure用托管dapr，在aws/gcp自己搞？

以及，托管服务如何让用户写自定义逻辑呢，生产用户很难100%复用公共逻辑，能用wasm写hook逻辑吗。

B

我们很难迁移到mosn上面来，主要是：

1. 小语种和java都部署在一套k8s中，使用同一namespace，服务之间会互相调用。
2. 对外提供api的服务，使用了aws appmesh gateway，必须和它的appmesh sidecar一起使用。如果切换到mosn，我们需要自行部署gateway。
3. appmesh是托管的，有任何运维问题可以寻求厂商支持。如果自运维，可能要自己解决。我们这边更多是云原生的，运维的资源会很少。
4. 技术投资，已经为appmesh调优等投入了比较多的资源，再切换到mosn要从头开始。

C

可能是小语种就直接用sidecar了，java的话功能逐步下沉到sidecar，期望是未来全部放到sidecar里面呢

[seeflood]

这部分我感觉是会经常修改的。例如最开始只需要传递trace-id，后面又逐渐添加trace-souce等字段。最终在每次rpc调用时，header中会有一大堆用于上下文传递的字段（已有的rpc框架，往往有很多的自定义header）

我确认下需求，是说：可能时不时的想在 app 调sidecar的 请求header 里，加一些字段？

加字段的话，layotto sdk 不用改，毕竟对上层暴露的是个map，上层想塞啥字段都行；但是既然上层框架想加字段，那确实没办法，只能升级（上层框架的）sdk

[seeflood]

• 关于部署:
  A方案推不动，看来B 方案满足不了需求，那先按 C方案搞吧（在原生sidecar 之外，再加个sidecar）

后续可以考虑： 基于 Mosn-on-Envoy 做 Layotto on envoy，社区做一些工具链，让”用户自己构建 envoy 镜像”这件事变的更简单一些。不知道这条路有市场么。

[kevinten10]

我确认下需求，是说：可能时不时的想在 app 调sidecar的 请求header 里，加一些字段？

是的，不想在sdk里面加，想在sidecar里面加。

[seeflood]

• 关于 layotto 去掉 mosn、减少冗余
  社区可以搞个不带 mosn 的'轻量版layotto"，不难的，但是相应的 mosn 那些 tracing 、metrics 功能也没了。
  这个属于性能优化的事情了，可以往后放一放，咱们先把流程跑通再看性能优化；
  @kevinten10 先搞个带 asm或者appmesh 的测试环境跑layotto试试吧（主要我这没环境试不了，难受

[kevinten10]

我这边有可以操作的appmesh环境，我先尝试一下把layotto跑起来试试

[seeflood]

E、sidecar模式的本地调试问题

对于 “app 开发者如何调试 app”，一般有以下几种方案:

• 本地 docker/docker-compose 启动个 layotto sidecar
• 公司提供远端 layotto sidecar
• 如果公司有类似于 github codespace的云端研发环境，那在研发环境自带sidecar

对于 “layotto 开发者如何调试 layotto”:
本地编译运行 layotto 即可

我补个文档吧

[kevinten10]

本地 docker/docker-compose 启动个 layotto sidecar

本地搞个docker，对于业务同学不太友好，有点geek style。

公司提供远端 layotto sidecar

我对这个方案比较感兴趣，意思是否为：

比如我在远端测试环境，自己拉起一个pod，在里面跑layotto sidecar，然后把pod的ip设为本地可访问。

这样我在本地调试时，把localhost修改为以上ip，即可实现本地进程连接到layotto sidecar是么。

good idea！

如果公司有类似于 github codespace的云端研发环境，那在研发环境自带sidecar

一般不会在云端进行编码，还是本地ide居多。

对于 “layotto 开发者如何调试 layotto”:

enough~

[seeflood]

比如我在远端测试环境，自己拉起一个pod，在里面跑layotto sidecar，然后把pod的ip设为本地可访问。
这样我在本地调试时，把localhost修改为以上ip，即可实现本地进程连接到layotto sidecar是么。

是的
更进一步，可以由公司里负责研发环境的团队把上述操作自动化，提供"一键申请远端 sidecar" 功能。

[seeflood]

• 关于部署:
  方案 D. 从 envoy 切到 Layotto-on-envoy 上。
  基于 Mosn-on-Envoy 做 Layotto on envoy，社区做一些工具链、构建好镜像，这样用户把托管的 envoy 镜像 换成 layotto-on-envoy 镜像即可。

刚去聊了下，Mosn-on-Envoy 预计8月开源

好处:

1. 其实新加个 sidecar 也有运维成本的，可能“替换托管的镜像”带来的运维成本更小些
2. 更好的性能

@kevinten10 可以周六聊下这事?

[kevinten10]

@kevinten10 可以周六聊下这事?

好啊

“替换托管的镜像”

应该无法替换云厂商托管的镜像，除非使用hack的方式，所以可能还是在外面加一个吧

[wenxuwan]

可以试一下layotto进程级别部署，把layotto和业务容器做到一个container中，而不是作为sidecar存在。如果内存和cpu有负担，layotto这边也可以尝试阉割一部分用不到的能力。以此减少性能的影响。

[kevinten10]

layotto进程级别部署

Hi，这个有实际的落地实践吗~我不太清楚，这种方式有没有什么缺陷呢

[seeflood]

@kevinten10 这种方式还没落地实践过
好处: 目的是让你没有新增运维成本，原先是部署app镜像，现在替换下 app 镜像、往镜像里塞个layotto进程进去
缺点: sidecar 版本升级后，要重新打 app镜像

[seeflood]

会议结论

关于 app mesh 的情况

没法把 envoy 镜像替换成 Layotto-on-envoy
因为 aws 里的 appmesh(envoy) 没有官方的手段去替换 envoy 镜像（除非 hack)；且闭源；

其他缺点：

• 每个服务要在 CI/CD 里做配置，声明要依赖哪些服务
  （很难梳理）

• 功能支持少（没有熔断限流，只有连接池粒度的熔断）

方向:

• 还是用 appmesh

优化

• 在弥补缺少的feature。考虑用 mosn 做限流、熔断，流量转给 envoy，因此需要支持 filter 配置的动态下发

关于部署方式

加个 sidecar 容器。只在公有云玩 sidecar 模式

关于动态配置下发

通过配置中心（qconfig, app config, nacos)
不止需要下发 layotto 组件配置，还需要下发 filter 配置

目标

希望在9月 跑起来 demo

action

• @kevinten10 测试下 部署app 容器+sidecar 容器，测试会不会和 envoy 有冲突（理论上没有）
• 社区要支持动态配置下发
  • 组件的动态配置下发 配置下发通道与配置热加载 #500
  • filter @kevinten10

demo 包括功能:

• configuration

  • appConfig @kevinten10
    - [ ] nacos

• pubsub

  • kafka

• oss

  • 阿里云 和 aws s3 feat: implement oss interface #556

• lock API

  • redis

• secret API

  • AWS Secrets Manager

• demo 就用java 写个，或者直接用现成的 @kevinten10

• 演示可扩展性

  • API 插件. 见 https://mosn.io/layotto/#/zh/design/api_plugin/design
  • 组件扩展 @kevinten10

• 其他：讲清楚未来演进方向

  • SQL
  • 可观测性

• 性能优化先不考虑

[seeflood]

@kevinten10 问下，改 layotto配置的时候，用 configmap挂载新的config.json、重启，能满足需求对吧？
我感觉上来就搞动态下发、热重载不好搞，先把静态方案搞好之后，再往动态演进

[kevinten10]

@kevinten10 问下，改 layotto配置的时候，用 configmap挂载新的config.json、重启，能满足需求对吧？

满足的。以及，configmap有热更新吧，不知道layotto能监听到config.json的变更吗

[seeflood]

@kevinten10 问下，改 layotto配置的时候，用 configmap挂载新的config.json、重启，能满足需求对吧？

满足的。以及，configmap有热更新吧，不知道layotto能监听到config.json的变更吗

现在还没监听变更，不过这个好弄，实在不行写个脚本，有变更就 kill layotto、重启

[seeflood]

@kevinten10 目前调研到的差异:

• AWS envoy 不支持自定义逻辑（比如加一些 trace 数据，改一些请求头），阿里云支持、但是要写 wasm，不敢在生产用 wasm，因此决定继续用加一个sidecar的方案
• AWS envoy 没有熔断限流等能力
• AWS envoy 需要手动配置服务之间的依赖关系，不现实；阿里云 asm 是全量下发 XDS，但是能在后端算依赖关系

解决方案:

1. 在 app 边上再加个 Layotto sidecar，和 envoy 共存，rpc 先经过 layotto，做熔断限流、加 trace 改请求头之类的逻辑，layotto 再转给 envoy。需要决策做不做“layotto 去 mosn”，因为现在熔断限流是基于 mosn 做的
2. 配置服务之间依赖关系的问题，暂时没方案
   

关于“这种模式用 dapr 还是 layotto”：
用 dapr 的话运维复杂度较高，layotto 更省事一些，而且方便扩展私有 api

[seeflood]

@kevinten10 hi 我确认下，上次说 Poc 跑通了 是指哪些能力跑通啦？
我想了下，感觉需要跑下 rpc 的 poc，即 app-> layotto -> envoy -> 调出去
这个你们有跑 poc 么

[kevinten10]

@kevinten10 hi 我确认下，上次说 Poc 跑通了 是指哪些能力跑通啦？

部署通了：

pod内有4个container：

1. init (aws appmesh)
2. bussiness
3. envoy (aws appmesh)
4. layotto runtime

在这种情况下，bussiness container可以正常运行并提供服务

我想了下，感觉需要跑下 rpc 的 poc，即 app-> layotto -> envoy -> 调出去
这个你们有跑 poc 么

如果要跑这个poc，比如A服务rpc调用testservice服务，我理解是这样的：

A app --(grpc: invoke api)--> layotto --(http://testservice.prod:8080/api1)--> envoy

在这里我需要layotto的invoke组件，能够"重写url"并发起新的http请求。
我不清楚layotto目前已经支持了这样的能力吗？

我在这里提到过类似的想法：#705

[seeflood]

在这里我需要layotto的invoke组件，能够"重写url"并发起新的http请求。
我不清楚layotto目前已经支持了这样的能力吗？

@wenxuwan 写了这个功能，在 #739
但是因为是短连接、设计上有些争议，这个 PR 还没合并；感觉可以先把他这个PR合并，供你跑poc?

另外，感觉其他 api 也可以跑下 poc，比如 oss, redis ，不知道你们方便么？

[kevinten10]

但是因为是短连接、设计上有些争议，这个 PR 还没合并；感觉可以先把他这个PR合并，供你跑poc?

我看了一下 #739 ，确实可以供我们跑poc。未来跑生产之前再解决短链接问题

另外，感觉其他 api 也可以跑下 poc，比如 oss, redis ，不知道你们方便么？

方便的，我会都尝试跑一下，然后整理一下结果

[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.