Kevin_T

### 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，也没有很好的解决这个问题。

### F、与云平台的顺滑集成 我之前看layotto社区是打算复用istio工具链，然后在k8s里面做layotto on istio是么。 那像已经在用aws appmesh和asm的用户（非原生istio），该如何顺滑集成呢。 比如appmesh，是通过helm安装的。 layotto有没有类似helm的方式，可以很方便的在k8s集群中进行安装/升级/卸载呢。

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

> 取线程上下文、塞header ，听起来是只能由sdk实现的功能；你们其他语言也会有类似需求么? 是的，这个应该是只能由sdk实现的。 其他语言也会有，不过opentelemetry提供了多语言sdk，这个可以复用它的sdk。 这种分布式追踪的功能，应该是普遍的应用场景，layotto-sdk打算怎么做呢？ > 如果有的话，确实只能在每个语言的 sdk里加，但这部分应该不复杂，不会经常修改、推业务升级 这部分我感觉是会经常修改的。例如最开始只需要传递trace-id，后面又逐渐添加trace-souce等字段。最终在每次rpc调用时，header中会有一大堆用于上下文传递的字段（已有的rpc框架，往往有很多的自定义header）

> 我调研下，你可以帮忙一起看看，因为我对这些云服务也不是很熟 > 感觉现在的主要矛盾是（在已有 sidecar 的情况下）怎么部署 :) > > 我们先确定大的方向，再讨论细节哈。几个可能的方向: > A. 最理想的方式是让 阿里云asm 也支持 layotto 能力（比如把蚂蚁的 moe 方案输出到 阿里云上） 要先找人聊下 > B. 另一种方案，既然是找小语种应用试点、切到 Layotto，那能否让小语种应用 从envoy 迁移到 mosn 上来？比如 阿里云也有...

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

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

> 本地 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~

> @kevinten10 可以周六聊下这事? 好啊 > “替换托管的镜像” 应该无法替换云厂商托管的镜像，除非使用hack的方式，所以可能还是在外面加一个吧

> layotto进程级别部署 Hi，这个有实际的落地实践吗~我不太清楚，这种方式有没有什么缺陷呢