这是一个创建于 1632 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前手里有三个中间件，一个是拉取配置的 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