论 sidecar 模式的可行性

[lsk569937453]

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

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

[index90]

@lsk569937453 所以你是希望研发都用官方的 SDK，然后你截获官方 SDK 发出的请求，做了一些 hack 的事情（例如染色？数据抽取？路由？），再转发出去？
这里 tcp 栈的消耗相对于你的 hack 的消耗可能不值一提？
如果只是做数据抽取，抓包会不会更好
如果是改数据包，你的序列化的操作可能才是瓶颈
如果是路由，有很多现成的中间件啊

[asAnotherJack]

我觉得可以，我记得 proxysql 是不是就是这样用的啊

[lazyfighter]

可行 同时还可以做一些鉴权，命令限制等等