ServiceMesh、SideCar和Istio

Service Mesh简介

Service Mesh直译过来就是服务网格，而他的架构就是一个个微服务组成的网络。

Sidecar简介

Service Mesh中的节点就是Sidecar节点。
sidecar直译过来就是这种摩托车，意为业务容器和非业务容器分离，如agent服务全部部署在非业务容器中。


sidecar proxy的作用和好处有很多：

• sidecar proxy能接管对应服务的入流量和出流量，所以sidecar proxy是有流量管理的功能，有了这个能力，可以做太多太多的事情了，如放火、熔断、限流、降级。
• 微服务架构中以前有公共库、sdk等部署在sidecar proxy容器中。
• 服务注册与发现可部署在sidecar proxy容器中。
• 与业务容器分离后，非业务容器中的程序不会影响到业务容器，资源能够隔离，监控系统也能部署在 sidecar proxy容器中。
• 与业务容器分离后，业务容器可以专注于业务，也无需让开发人员适配繁多的sdk、agent、中间件等。
• …

缺点：

• sidecar模式中，每个Pod都引入了一个新的容器，成本会上升。
• sidecar模式中，通信通过代理实现，所以会增加系统的开销。

一个个sidecar节点就组成了Service Mesh服务网格。

Istio简介

Service Mesh和Sidecar都是指导思想，下面介绍真正实践的Istio。

Envoy 是由Lyft公司 推出、基于C++ 11编写的ServiceMesh实现，但它专注于如何实现Proxy，并没有很好的控制面。所以 Google 和 IBM 两位巨人联合 Lyft 的合作开源项目，基于Envoy打造了Istio。

Istio中文社区：https://istio.cn/
K8s关于Istio的博客：https://www.kubernetes.org.cn/tags/istio

Istio架构如下图所示：

Envoy: 扮演sidecar的功能，协调服务网格中所有服务的出入站流量，并提供服务发现、负载均衡、限流熔断等能力，还可以收集大量与流量相关的性能指标。

Pilot: 负责部署在service mesh中的Envoy实例的生命周期管理。本质上是负责流量管理和控制，是将流量和基础设施扩展解耦，这是Istio的核心。感性上，可以把Pilot看做是管理sidecar的sidecar, 但是这个特殊的sidacar并不承载任何业务流量。Pilot让运维人员通过Pilot指定它们希望流量遵循什么规则，而不是哪些特定的pod/VM应该接收流量。比如 A/B 测试和金丝雀Canary测试。

Mixer: Mixer在应用程序代码和基础架构后端之间提供通用中介层。它的设计将策略决策移出应用层，用运维人员能够控制的配置取而代之。应用程序代码不再将应用程序代码与特定后端集成在一起，而是与Mixer进行相当简单的集成，然后Mixer负责与后端系统连接。也就是说，Mixer可以认为是其他后端基础设施（如数据库、监控、日志、配额等）的sidecar proxy。

Istio-Auth: 自动为服务之间的调用提供认证、授权和加密。

参考文档：

• https://istio.cn/
• https://www.kubernetes.org.cn/tags/istio
• https://blog.csdn.net/weixin_40274679/article/details/106232119
• https://blog.csdn.net/define_us/article/details/84812729