search

timzaak / blog

8 stars 1 forks source link

现阶段的 Service Mesh #87

Closed timzaak closed 2 years ago

timzaak commented 2 years ago

网络 Sidecar 目前遇到的问题：重复序列化+数据多次转运。 要解决这个问题，目前获知的最好方案（来源于字节）是：尽量少的 memory copy + data transfer，也就是主机共享内存。这个方案实际是个工程优化问题，在以 Sidecar 为载体的方案中可拆分为三方面：

RPC to IPC（SharedMemory） 改造

服务和Sidecar` 通信，Sidecar之间通信，从基于 tcp/udp/ipc 协议 改成 IPC 内存共享。这个有巨量的代码需要编写，每个运行时都要fork出来实现 Shared Memory，而且可能存在内存泄漏的风险。每个协议解析都要集成在Sidecar中，方便Debug。

智能通信Switcher

根据目标 Sidecar 是否在同一台机器和目标Sidecar负载情况，选择 IPC 或者 TCP/UDP 通信。

Pod 亲密性 Scheduler

相互调用量大的 Pod 尽量往单一机器上部署。虽然会带来稳定性问题，但可以通过增加横向实例来解决。

估计三年内，会有开源版的 Sidecar 实现。 要做的内容包含：

  1. gRPC/Thrift/HTTP 改造
  2. 现有Sidecar改造，envoy/linkerd-proxy
  3. 实现新 K8S Scheduler Inejector

从版本迭代角度来看，最小 MVP 应该是： 服务 和 Sidecar 实现IPC 内存共享通信。也就是

  1. gRPC 改造
  2. linkerd-proxy 支持 IPC inbounds

然后再根据社区反馈，做二次调整。 至于上述的 gRPC 改造，目前已知最多支持 process communication。

timzaak commented 2 years ago

不仅是难度问题， Istio/linkerd 等都已经有成熟的 sidecar。目前没有 sidecar 标准，做出来后大概率会被缝合进现有sidecar，很难独立出来。而且很多调用服务是 N:M 的关系，proxy 之前的通信大概率会跨机器，LB 比较麻烦。

这两天又看到了 bRPC， 这个产品是直接将 RPC 做到可替代 Sidecar 的程度（集成服务发现、API注册、遥测、多协议支持等）。

那么，若是服务所用技术有RPC框架，便用该框架，没有，再补上以此RPC框架写的Sidecar。这种解决方案，是否会更符合实际情况呢？

timzaak commented 2 years ago

gRPC 已经暴露了 interface 来做 LB、Service Discovery, 至于具体实现，还要依靠第三方。也就是走 SDK 路线还是要花费很多精力写代码去缝合现有的组件。

SMI(Service Mesh Interface) 正要做成 k8s 内的一个标准，让 Service Mesh Provider 变成一个标准实现提供方（Istio 通过 adapter 来搞）。

研究了一番，本以为蓝海的地方早已是红海。