这是一个创建于 1954 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前手里有三个中间件，一个是拉取配置的 sdk 、redis 的 sdk 、数据库连接池的 sdk，目前有两个问题
1 、版本升级太难，老版本就像毒瘤一样，永远无法下掉
2 、新功能做完一个，需要为每个语言都开发一遍，开发成本大。
所以在这种情况下，使用 sidecar 模式是否是一个好的选择
======================================================================================
sidecar 模式:将 sdk 的重逻辑全部抽到 sidecar 中去做了，sdk 只是一层皮，但是额外增加了一层成本，这个成本至少包含：网络通信成本+sidecar 运行中对内存 /cpu 消耗的成本。
优点是：
1 、由于重 sdk 的逻辑都在 sidecar 中去做，所以 sidecar 升级，业务基本是无感的。
2 、sdk 无需在提供各个语言的版本，直接与 sidecar 通信即可
小弟的这个念想只是一时所想，或者能解决 sdk 的困难，大佬们有什么好的解决方案，大家一起讨论下。
1 、版本升级太难，老版本就像毒瘤一样，永远无法下掉
2 、新功能做完一个，需要为每个语言都开发一遍，开发成本大。
所以在这种情况下，使用 sidecar 模式是否是一个好的选择
======================================================================================
sidecar 模式:将 sdk 的重逻辑全部抽到 sidecar 中去做了，sdk 只是一层皮，但是额外增加了一层成本，这个成本至少包含：网络通信成本+sidecar 运行中对内存 /cpu 消耗的成本。
优点是：
1 、由于重 sdk 的逻辑都在 sidecar 中去做，所以 sidecar 升级，业务基本是无感的。
2 、sdk 无需在提供各个语言的版本，直接与 sidecar 通信即可
小弟的这个念想只是一时所想，或者能解决 sdk 的困难，大佬们有什么好的解决方案，大家一起讨论下。
 | 1 hantsy 2020-06-04 11:24:56 +08:00 你这是 Gateway 了，不是 Sidecar 了。 |
 | 2 lsk569937453 OP @hantsy sidecar 是和用户进程跑在一起的，用户使用 redis 的时候原先的方法是 ip:port，使用了 sidecar 后变为直接和本地的 sidecar 通信 |
 | 3 mazhan465 2020-06-04 11:32:42 +08:00 你这和直接把你的 sdk 写成命令行工具，用的时候直接命令行用差不多 |
 | 4 chendy 2020-06-04 11:36:25 +08:00 拉配置，连 redis，数据库连接池…每种语言开发一遍？？？手撸一切？ |
 | 5 Foralrec 2020-06-04 11:36:26 +08:00 你的想法没有任何问题,不用理会质疑. 所谓的`multi-runtime`就是这个意思. https://www.infoq.com/articles/multi-runtime-microservice-architecture/ |
| 6 lsk569937453 OP |
| 7 lsk569937453 OP @chendy 有些和业务场景绑定的，必须手撸啊。 最近在做双中心 redis 集群的建设，涉及到 redis 的双写双读策略，必须要在 sdk 层面做啊。 |
 | 8 kaneg 2020-06-04 12:34:55 +08:00 via iPhone 你的这种改造方式从设计来说是值得的：既可以保持兼容：对使用 sdk 的应用是透明的，又可以降低开发成本。 |
 | 9 wu181184 2020-06-04 14:30:55 +08:00 想法完全没问题，我司已经落地了。 |
 | 10 julyclyde 2020-06-04 15:02:10 +08:00 感觉不是去解决本质问题而有点糊弄的意思 |
 | 11 index90 2020-06-04 15:20:22 +08:00 不就是把进程内调用改成 RPC 吗？ |
 | 12 psx2019 2020-06-04 15:31:04 +08:00 这不就是现在逐步推广的服务网格么(server mesh)？这种是可以的，问题是只有弱业务耦合的好放到 sidecar 中，单个业务强耦合的并不太适合。 |
| 13 chendy 2020-06-04 15:36:45 +08:00 @lsk569937453 #7 所以，应用和 sidecar 之间通信的 api 是固定的，api 固定了直接放到外面跑就也行了吧… |
| 14 lsk569937453 OP @wu181184 你们的 service mesh 是微服务调用的时候做的吗？我现在想要把各个 sdk 放到里面，不知道会不会有影响。毕竟微服务调用的量和访问 redis 的量比起来，应该差好几个数量级 |
| 15 lsk569937453 OP @index90 对的，就是这个意思 |
| 16 index90 2020-06-04 16:18:24 +08:00 @lsk569937453 这个跟 service mesh 中的 sidecar 不是一回事，你这个操作是把包组件（ sdk 组件）封装成服务。如果你只是把 redis，数据的 tcp 协议封装成 http 协议，意义不大。 |
 | 17 fdingiit 2020-06-04 16:25:21 +08:00 istio |
| 18 lsk569937453 OP @index90 包装的 sdk 还是走自己的协议，包装的 redis 还是走 redis 协议，mysql 连接池还是走 mysql 协议 |
| 19 lsk569937453 OP @index90 其实就是想各个语言的使用方，可以使用官方的 sdk 来和 sidecar 通信。 |
 | 20 joesonw 2020-06-04 17:10:06 +08:00 service mesh 主要是解决可观察性的问题. 之前是要把 lb, tracing, filtering, mtls 放在 sdk 层面, 每个语言都需要. 所以才弄成 sidecar, 因为本来就是与业务无关的. 业务相关的为什么要抽出来. |
| 21 index90 2020-06-04 18:40:32 +08:00 @lsk569937453 所以你是希望研发都用官方的 SDK，然后你截获官方 SDK 发出的请求，做了一些 hack 的事情（例如染色？数据抽取？路由？），再转发出去？ 这里 tcp 栈的消耗相对于你的 hack 的消耗可能不值一提？ 如果只是做数据抽取，抓包会不会更好 如果是改数据包，你的序列化的操作可能才是瓶颈 如果是路由，有很多现成的中间件啊 |
 | 22 asAnotherJack 2020-06-04 18:41:04 +08:00 我觉得可以，我记得 proxysql 是不是就是这样用的啊 |
 | 23 lazyfighter 2020-06-04 19:00:18 +08:00 可行 同时还可以做一些鉴权，命令限制等等 |
Select Language