定义
Service Mesh 直译为服务网格,分为两部分理解。
通讯组件
是应用系统微服务化的其中一种典型方案，重点在于Service Mesh是运行在请求/响应上层的通信层，专注于抽象应用系统之间的通讯模式和方案。通讯层的实现方式，有以下选择：
- 用库的形式在微服务应用程序中导入使用。
- 用节点代理或守护程序的形式为特定节点/计算机上的所有容器提供服务。
- 用Sidecar容器的形式运行，和应用容器一同运行。
以上三种方式，逐级降低了应用系统对于通讯组件的依赖程度。
通讯组件-库
软件中库引用的方式是个很自然的选择。它简单明了。在这种架构中，每个微服务应用程序包中都有实现Service Mesh功能的库。像Hystrix和Ribbon就是用库的方法。
如果一个团队仅使用一种语言开发并且还负责一个应用的运行，那么使用库引用就很容易，这种方式自然也是很合适的。库方法不需要与底层基础架构进行太多合作，如Kubernetes无需关心正在运行的一个应用是否包含Hystrix库。
要实现多语言支持，就必须用不同语言去重复实现多次，挑战在于实现的复杂性和一遍又一遍去实现同样概念的工作量。
我们的用户中对库模型的使用非常有限，因为大多数用户都会用许多不同语言编写应用程序，还会运行一些不是自己编写的应用程序，因此库引用是不可行的。
这种模型在工作审计方面具有优势：库的代码是在微服务内运行的。信任边界也很小，您只需要信任在自己进程中调用的库，而不像调用在网络的某个地方的远程服务。库的代码具有和库所在的微服务一样多的特权。代码的执行也是在微服务的环境中执行的，因此CPU时间片或内存等资源的分配可以很公平的由操作系统去完成。
通讯组件-节点代理
节点代理模型是下一个替代方案。在此架构中，每个节点上都运行一个单独的代理（通常是用户进程），为异构的服务提供负载。相比之下，该模型与库模型相反：它不关心应用程序的语言，可以为许多不同的微服务租户提供服务。
Linkerd在Kubernetes上的推荐部署就是这样的。和应用服务代理（ASP）F5一样，和Kubernetes默认的kube-proxy代理一样。
由于每个节点上都需要一个节点代理，因此需要与基础架构进行一些协作，如果没有协作的话此模型就无法工作。通过类比，大多数应用程序会把选择TCP堆栈，猜一个端口号，然后发送或接收TCP数据包的事委托给基础设施（也就是操作系统）。
相比工作审计来说，这个模型强调工作资源共享，如果节点代理用一些内存来缓存微服务的数据，那么服务就可能会在几秒钟内转向并使用该缓存区提供的数据。这可能非常有效，但容易被滥用。如果我的微服务请求所有缓存区空间，节点代理要先为你的微服务在缓存区提供一个快照。您需要更多代码来管理每个共享资源。
配置信息也受益于共享模式。因为将一个配置副本分发到每个节点，比把每个节点上的一个配置副本分发到每个节点要高效的多。
微服务容器化依赖的许多功能由节点代理或等效的组件提供。就像kubelet初始化pod，以及像flanneld这种CNI守护进程，或者再发散下，甚至操作系统内核本身就像节点代理模型一样。
通讯组件-Sidecar
Sidecar是社区的新生儿。这是Istio与Envoy使用的模型。 Conduit也使用了sidecar方法。在Sidecar部署方式中，你会为每个应用的容器部署一个伴生容器。对于Service Mesh，Sidecar接管进出应用程序容器的所有网络流量。
我到目前为止的讨论，这种方法介于库和节点代理模型之间。例如，您部署Sidecar服务网格时，无需在节点上运行代理（因此您不需要基础结构的协作），但是您将运行多个相同sidecar的副本。另外一个角度看：我可以为一组微服务安装一个Service Mesh，你也可以安装一个有特定实现的Service Mesh，我们不需要沟通协调。这在服务网格的早期是非常强大的，我们可能会共享同一个Kubernetes集群但用途不同，我们会用到不同的功能集，或者在可靠技术实现的基础上兼容前沿技术的尝试。
Sidecar有利于工作审计，特别是在一些与安全相关的方面。例如：假设我使用Service Mesh来提供零信任模式的安全性。我希望Service Mesh以加密方式去验证客户端和服务器。如果使用节点代理来实现：当我的pod想成为另一个服务器pod的客户端时，节点代理将代表我的pod进行身份验证。节点代理也在服务其他pod，因此必须确保另一个pod不能代表我的pod进行身份验证去欺骗他。如果我们用Sidecar来实现，我pod的Sidecar不会服务于其他pod。我们可以遵循最小特权原则，并在认证密钥，内存和网络功能方面满足这个pod最低限度的需求。
因此，从外部看，Sidecar与其附属的应用程序具有相同的权限。另一方面，sidecar需要介入应用程序和外部服务之间。这会产生一些安全顾虑：你即希望sidecar拥有尽可能少的权限，但你又需要给它足够的权限来控制进出应用程序的流量。例如，在Istio中，负责设置Sidecar的init容器要具有设置iptables规则NET_ADMIN权限。初始化方式是较好的安全实践，它用最少的权限运行后就消失，但NET_ADMIN的所有内容都代表了被攻击的点。 （已经有人在加强改进这一点）。
从安全角度来看，Sidecar和应用程序非常近。但没有在函数中调用（如库）那么近，但比调用节点代理更近。在Kubernetes中使用Istio时，您的应用容器通过pod中共享的网络命名空间内的loopback接口与Sidecar通讯，这对其他pod和节点代理是不可见的。
大多数Kubernetes集群每个节点上有多个pod（因此每个节点有多个sidecar）。如果每个sidecar都需要知道“整个配置”，那么你就需要更多的带宽来同步该配置（以及更多的内存来存储配置副本）。因此，你不得不给每个Sidecar的配置范围加以限制，这很强，但从另一个角度看：必须花费更多精力为每个Sidecar减少配置（如Istio中的Pilot）。
另一方面是通过Sidecar复制其他东西会带来类似的开销。好消息是如果复制的内容完全相同并且使用了正确的驱动，容器运行时就会容器重用镜像一样，因此磁盘损失就不重要了，并且代码块也会在内存中共享。但是每个Sidecar都是独一无二的，要避免在每个Sidecar上做一堆复制而使得Sidecar变重。
使用Sidecar的Service Mesh在功能完整性和轻量级之间找到了良好的平衡。
节点代理或Sidecar模型会占上风吗？
我想你可能会看到两者都存在。现在看来似乎Sidecar是Service Mesh的最佳实践：新技术、快速迭代和逐步替换。随着Service Mesh的成熟，我们将看到更多节点代理模型的应用。
随着Service Mesh实现的成熟和集群变得越来越大，节点代理模型的优势会更重要：
- 通过节点共享开销（尤其是内存）
- 更少、更容易扩展和分发配置信息
- 精心构建的节点代理可以有效地把服务一个应用程序的资源转移给另一个应用
Sidecar是一种向应用程序提供服务（如高级通信代理和服务网格）的方法。它特别适用于容器和Kubernetes。它的最大优势包括：
- 不需要中央协调，可以逐步的添加到现有集群
- 为应用程序做的工作就属于该应用程序
- App-to-sidecar通信比app-to-agent更安全
