Non-client-server mesh sidecar

网络服务一般分为client和server端, server端负责监听一个地址, 等待client的连接

在他们中间如果需要做七层的流量治理与转发, 通常会引入一个像下图的proxy(以envoy为例)

proxy进程内包含两部分: Listeners负责监听来自client的连接, Upstream Clusters负责主动dial server, 并将数据转发给server

这样的模式很容易拓展到多级的proxy

但我司的Service mesh产品却是不一样的做法: 无论是client应用还是server应用, 都统一去dial proxy

Listners:

• App Listener: 负责监听来自app(client/server)的连接
• Proxy Listner: 负责监听来自client端proxy的连接

Clusters:

• Proxy Clusters: 负责将来自client app的数据转发到server proxy
• Upstream Cluseters: 负责将来自client proxy的数据转发到server app, 其中server app是通过app listener注册到Upstream Clusters上来的

这样有几个显而易见的坏处

• 代码结构冗余, 需要存在两套不一样的Listener和upstream逻辑, 给代码理解和日常维护带来了一定的障碍
• 多级的拓展变得非常费劲

但其实也仔细挖掘也是有好处的

• app视角里模糊了client/server的界限, 可以用同一个conn执行client和server的操作
• server连接是app主动连接注册到proxy, 所以proxy就不需要再执行类似连接预热的操作了
• mesh产品覆盖率直线上升, 传染法则 (LOL)