1、sidecar 是什么

所谓 sidecar 模式，翻译过来就是边车模式，是一种分布式和微服务架构的设计模式，目的是实现了控制和逻辑的分离与解耦。因为其非常类似于生活中的三轮摩托车而得名。边车加装在摩托车旁起拓展功能，比如行驶更稳定，可以拉更多的人和货物，坐在边车上的人可以给驾驶员指路。

软件设计中的 sidecar 模式通过给应用服务加装一个“边车”达到控制和逻辑分离的目的。该设计模式通过给应用程序加上一个“边车”的方式拓展应用程序现有的功能，例如日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断等在业务服务中不需要实现的控制面功能，可以交给“边车”，业务服务只需要专注于实现业务逻辑即可。

边车模式出现得很早，实现的方式也多种多样。这个模式随着 Service Mesh 的逐渐成熟进入人们的视野。

sidecar 模式一般有两种实现方式：

通过 SDK 的形式，在开发时引入该软件包依赖，使其与业务服务集成起来。这种方法可以与应用密切集成，提高资源利用率并且提高应用性能，但也对代码有侵入，受到编程语言和软件开发人员水平的限制；
agent 形式。服务所有的通信都是通过这个 agent 代理的，这个 agent 同服务一起部署，和服务一起有着相同的生命周期创建。这种方式对应用服务没有侵入性，不受编程语言和开发人员水平的限制，做到了控制与逻辑分开部署。但是会增加应用延迟，并且管理和部署的复杂度会增加。

2、service mesh 和 sidecar

Service Mesh 作为 sidecar 运行时，对应用程序来说是透明的，所有应用程序间的流量都会通过 sidecar，然后由 sidecar 转发给应用程序。由于 sidecar 劫持了流量，所以对应用程序流量的控制都可以在 sidecar 中实现。

sidecar 模式在概念上比较简单，我们为什么要在 Service Mesh 中使用 sidecar 模式呢？

解决服务之间调用越来越复杂的问题。随着分布式架构越来越复杂和微服务越拆越细，我们越来越迫切地希望有一个统一的控制面来管理我们的微服务，帮助我们维护和管理所有微服务，这时传统开发层面上的控制就远远不够了，而边 sidecar 模式可以很好地解决这个问题；
控制与逻辑分离的问题。sidecar 模式基于将控制与逻辑分离和解耦的思想。通俗地讲就是，让专业的人做专业的事，业务代码只需要关心其复杂的业务逻辑，其他的事情 sidecar 会帮其处理。例如，日志记录、监控、流量控制、服务注册、服务发现、服务限流、服务熔断、鉴权、访问控制和服务调用可视化等功能本质上讲和业务服务的关系并不大，完全可以交给 sidecar。

这就是 Service Mesh 诞生的契机，它是 CNCF 主推的新一代微服务架构。William Morgan 在 What's a service mesh？And why do I need one文章中指出 Service Mesh 有以下几个特点：

应用程序间通信的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现

3、k8s service 和 service mesh

Kubernetes 集群的每个节点都部署了一个 Kube-proxy 组件，该组件会与 Kubernetes API Server 通信，获取集群中的 Service 信息，然后设置 iptables/ipvs 规则，直接将对某个 Service 的请求发送到对应的后端 Pod 上。 Kube-proxy 实现了流量在 Kubernetes Service 的负载均衡，但是没法对流量做细粒度的控制，例如灰度发布和蓝绿发布（按照百分比划分流量到不同的应用版本）等。

Istio Service Mesh 把 Kubernetes 看作服务注册机构，通过控制平面生成数据平面的配置，数据平面的透明代理以 sidecar 容器的方式部署在每个应用服务的 Pod 中。之所以说是透明代理，是因为应用程序容器完全无感知代理的存在。区别在于 Kube-proxy 拦截的是进出 Kubernetes 节点的流量，而 Istio sidecar 拦截的是进出该 Pod 的流量。