深度思维者

永远年轻,永远热泪盈眶

Sidecar 模式

Sidecar

1.什么是Sidecar模式

Sidecar 模式是 Service Mesh 中习惯采用的模式

应用程序的功能划分为单独的进程可以被视为 Sidecar 模式。如图所示,Sidecar 模式允许您在应用程序旁边添加更多功能,而无需额外第三方组件配置或修改应用程序代码。

在软件架构中, Sidecar 连接到父应用并且为其添加扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。它可以屏蔽不同编程语言的差异,统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能

Istio与Envoy使用的模型 也是用的这种模型

2. Sidecar的使用

  • 使用 Sidecar 模式部署服务网格时,无需在节点上运行代理,但是集群中将运行多个相同的 Sidecar 副本

  • 在Sidecar部署方式中,会为每个应用的容器部署一个伴生的容器

  • 对于Service Mesh,Sidecar接管进出应用程序容器的所有网络流量

  • 在 Kubernetes 的 Pod 中,在原有的应用容器旁边注入一个 Sidecar 容器,两个容器共享存储、网络等资源,可以广义的将这个包含了 Sidecar 容器的 Pod 理解为一台主机,两个容器共享主机资源。

3. 一些思考

  1. 大多数(Kubernetes)集群每个节点上有多个pod(因此每个节点有多个sidecar),如果每个sidecar都需要知道“整个配置”,那么就需要更多的带宽来同步该配置(以及更多的内存来存储配置副本),不得不给每个Sidecar的配置范围加以限制,这很强,但从另一个角度看:必须花费更多精力为每个Sidecar减少配置(如Istio中的Pilot)。
  2. 通过Sidecar复制其他东西会带来类似的开销, 如果复制的内容完全相同并且使用了正确的驱动,容器运行时就会容器重用镜像一样, 因此磁盘损失就不重要了, 并且代码块也会在内存中共享。 但是每个Sidecar都是独一无二的, 要避免在每个sidecar上做一堆复制二十的Sidecar变重

4. Envoy 和 MOSN流量劫持

MOSN 兼容 Istio,使用 Go 语言开发的替换了 Envoy。

MOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时,需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社区使用 iptables 做流量透明劫持,MOSN 目前使用的是流量接管方案,并在积极探索适用于大规模流量下的透明劫持方案。

流量接管

MOSN 使用的流量接管的方案如下:

  1. 假设服务端运行在 1.2.3.4 这台机器上,监听 20880 端口,首先服务端会向自己的 Sidecar 发起服务注册请求,告知 Sidecar 需要注册的服务(比如充值服务Deposit)以及 IP + 端口(1.2.3.4:20880)

  2. 服务端的 Sidecar 会向服务注册中心(如 SOFA Registry)发起服务注册请求,告知需要注册的服务(Deposit)以及 IP + 端口,不过这里需要注意的是注册上去的并不是业务应用的端口(20880),而是 Sidecar 自己监听的一个端口(例如:20881)

  3. 调用端向自己的 Sidecar 发起服务订阅请求,告知需要订阅的服务信息

  4. 调用端的 Sidecar 向调用端推送服务地址,这里需要注意的是推送的 IP 是本机,端口是调用端的 Sidecar 监听的端口(例如 20882)

  5. 调用端的 Sidecar 会向服务注册中心(如 SOFA Registry)发起服务订阅请求,告知需要订阅的服务信息;

  6. 服务注册中心(如 SOFA Registry)向调用端的 Sidecar 推送服务地址(1.2.3.4:20881)

服务调用过程

经过上述的服务发现过程,流量转发过程就显得非常自然了:

  1. 调用端拿到的服务端地址是 127.0.0.1:20882,所以就会向这个地址发起服务调用

  2. 调用端的 Sidecar 接收到请求后,通过解析请求头,可以得知具体要调用的服务信息,然后获取之前从服务注册中心返回的地址后就可以发起真实的调用(1.2.3.4:20881

  3. 服务端的 Sidecar 接收到请求后,经过一系列处理,最终会把请求发送给服务端(127.0.0.1:20880

posted @ 2021-03-12 14:20  failymao  阅读(13843)  评论(0编辑  收藏  举报