论 sidecar 模式的可行性

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

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