论 sidecar 模式的可行性

[lsk569937453]

目前手里有三个中间件，一个是拉取配置的 sdk 、redis 的 sdk 、数据库连接池的 sdk，目前有两个问题
1 、版本升级太难，老版本就像毒瘤一样，永远无法下掉
2 、新功能做完一个，需要为每个语言都开发一遍，开发成本大。
所以在这种情况下，使用 sidecar 模式是否是一个好的选择
======================================================================================
sidecar 模式:将 sdk 的重逻辑全部抽到 sidecar 中去做了，sdk 只是一层皮，但是额外增加了一层成本，这个成本至少包含：网络通信成本+sidecar 运行中对内存 /cpu 消耗的成本。
优点是：
1 、由于重 sdk 的逻辑都在 sidecar 中去做，所以 sidecar 升级，业务基本是无感的。
2 、sdk 无需在提供各个语言的版本，直接与 sidecar 通信即可

小弟的这个念想只是一时所想，或者能解决 sdk 的困难，大佬们有什么好的解决方案，大家一起讨论下。

[hantsy]

你这是 Gateway 了，不是 Sidecar 了。

[lsk569937453]

@hantsy sidecar 是和用户进程跑在一起的，用户使用 redis 的时候原先的方法是 ip:port，使用了 sidecar 后变为直接和本地的 sidecar 通信

[mazhan465]

你这和直接把你的 sdk 写成命令行工具，用的时候直接命令行用差不多

[chendy]

拉配置，连 redis，数据库连接池…每种语言开发一遍？？？手撸一切？

[Foralrec]

你的想法没有任何问题,不用理会质疑.
所谓的`multi-runtime`就是这个意思.
https://www.infoq.com/articles/multi-runtime-microservice-architecture/

[lsk569937453]

@mazhan465
命令行优点和缺点很明显
优点：不会一直占用 cpu,内存
坏处：每次调用的时候，sidecar 会重新建连接，会影响指令的执行速度

[lsk569937453]

@chendy 有些和业务场景绑定的，必须手撸啊。
最近在做双中心 redis 集群的建设，涉及到 redis 的双写双读策略，必须要在 sdk 层面做啊。

[kaneg]

你的这种改造方式从设计来说是值得的：既可以保持兼容：对使用 sdk 的应用是透明的，又可以降低开发成本。

[wu181184]

想法完全没问题，我司已经落地了。

[julyclyde]

感觉不是去解决本质问题而有点糊弄的意思

[index90]

不就是把进程内调用改成 RPC 吗？

[psx2019]

这不就是现在逐步推广的服务网格么(server mesh)？这种是可以的，问题是只有弱业务耦合的好放到 sidecar 中，单个业务强耦合的并不太适合。

[chendy]

@lsk569937453 #7 所以，应用和 sidecar 之间通信的 api 是固定的，api 固定了直接放到外面跑就也行了吧…

[lsk569937453]

@wu181184 你们的 service mesh 是微服务调用的时候做的吗？我现在想要把各个 sdk 放到里面，不知道会不会有影响。毕竟微服务调用的量和访问 redis 的量比起来，应该差好几个数量级

[lsk569937453]

@index90 对的，就是这个意思

[index90]

@lsk569937453 这个跟 service mesh 中的 sidecar 不是一回事，你这个操作是把包组件（ sdk 组件）封装成服务。如果你只是把 redis，数据的 tcp 协议封装成 http 协议，意义不大。

[fdingiit]

istio

[lsk569937453]

@index90 包装的 sdk 还是走自己的协议，包装的 redis 还是走 redis 协议，mysql 连接池还是走 mysql 协议

[lsk569937453]

@index90 其实就是想各个语言的使用方，可以使用官方的 sdk 来和 sidecar 通信。

[joesonw]

service mesh 主要是解决可观察性的问题. 之前是要把 lb, tracing, filtering, mtls 放在 sdk 层面, 每个语言都需要. 所以才弄成 sidecar, 因为本来就是与业务无关的. 业务相关的为什么要抽出来.