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. 一些思考
- 大多数（Kubernetes）集群每个节点上有多个pod（因此每个节点有多个sidecar），如果每个sidecar都需要知道“整个配置”，那么就需要更多的带宽来同步该配置（以及更多的内存来存储配置副本），不得不给每个Sidecar的配置范围加以限制，这很强，但从另一个角度看：必须花费更多精力为每个Sidecar减少配置（如
Istio中的Pilot）。 - 通过Sidecar复制其他东西会带来类似的开销, 如果复制的内容完全相同并且使用了正确的驱动，容器运行时就会容器重用镜像一样， 因此磁盘损失就不重要了， 并且代码块也会在内存中共享。 但是每个Sidecar都是独一无二的， 要避免在每个sidecar上做一堆复制二十的Sidecar变重。
4. Envoy 和 MOSN流量劫持
MOSN 兼容 Istio，使用 Go 语言开发的替换了 Envoy。
MOSN 作为 Sidecar 和业务容器部署在同一个 Pod 中时，需要使得业务应用的 Inbound 和 Outbound 服务请求都能够经过 Sidecar 处理。区别于 Istio 社区使用 iptables 做流量透明劫持，MOSN 目前使用的是流量接管方案，并在积极探索适用于大规模流量下的透明劫持方案。
流量接管
MOSN 使用的流量接管的方案如下：
-
假设
服务端运行在 1.2.3.4 这台机器上，监听 20880 端口，首先服务端会向自己的 Sidecar 发起服务注册请求，告知 Sidecar 需要注册的服务(比如充值服务Deposit)以及 IP + 端口（1.2.3.4:20880） -
服务端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务注册请求，告知需要注册的服务(
Deposit)以及 IP + 端口，不过这里需要注意的是注册上去的并不是业务应用的端口（20880），而是 Sidecar 自己监听的一个端口（例如：20881） -
调用端向自己的 Sidecar 发起服务订阅请求，告知需要订阅的服务信息
-
调用端的 Sidecar 向调用端推送服务地址，这里需要注意的是推送的 IP 是本机，端口是调用端的 Sidecar 监听的端口（例如 20882）
-
调用端的 Sidecar 会向服务注册中心（如 SOFA Registry）发起服务订阅请求，告知需要订阅的服务信息；
-
服务注册中心（如 SOFA Registry）向调用端的 Sidecar 推送服务地址（1.2.3.4:20881）
服务调用过程
经过上述的服务发现过程，流量转发过程就显得非常自然了：
-
调用端拿到的服务端地址是
127.0.0.1:20882，所以就会向这个地址发起服务调用 -
调用端的 Sidecar 接收到请求后，通过解析请求头，可以得知具体要调用的服务信息，然后获取之前从服务注册中心返回的地址后就可以发起真实的调用（
1.2.3.4:20881） -
服务端的 Sidecar 接收到请求后，经过一系列处理，最终会把请求发送给服务端（
127.0.0.1:20880）
