什么是服务网格和 Istio？

 

服务网格是一个专用的基础设施层，目的在于使得服务与服务之间的通信变得安全、快速和可靠。

 

服务网格通常以轻量级网络代理的形式实现并且会与服务代码部署在一起，它会拦截服务所有进站/出站的网络流量。

 

Istio是一个适用于 Kubernetes 的开源服务网格实现。Istio 采用的策略是集成一个网络流量代理到 Kubernetes Pod 中，而这个过程是借助sidecar容器实现的。
sidecar 容器与服务容器运行在同一个 Pod 中。因为它们运行在系统的 Pod 之中，所以两个容器会共享 IP、生命周期、资源、网络和存储。

 

 

Istio 使用Envoy Proxy作为 sidecar 容器中的网络代理，并且会配置 Pod 通过 Envoy 代理（sidecar 容器）发送所有的入站/出站流量。

 

在使用 Istio 的时候，服务之间的通信并不是直接进行的，而是通过 sidecar 容器（即 Envoy）进行的，当服务 A 请求服务 B 的时候，请求会通过服务 A 的 DNS 发送到它的代理容器上。随后，服务 A 的代理容器会发送请求至服务 B 的代理容器，代理容器最终会调用真正的服务 B。响应过程则会遵循完全相反的路径。

 

 

Envoy 代理的 sidecar 容器实现了如下的特性：

• 智能路由和跨服务的负载均衡。

• 故障注入。

• 回弹性：重试和断路器。

• 可观察性和遥测：指标与跟踪。

• 安全性：加密和授权。

• 全局范围（fleet-wide）的策略执行。

通过下图我们可以看出，sidecar 容器实现的特性能够非常好地匹配五个微服务特性：服务发现、回弹性、认证、监控和跟踪。

在容器中实现微服务特性的逻辑有如下几个好处：

• 业务代码与微服务特性完全隔离。

• 所有的服务会使用完全相同的实现，因为它们使用的是同一个容器。

• 它的代码是独立的。服务可以使用任意语言实现，但是这些横切性的关注点始终是相同的。

• 所有服务的配置过程和参数是相同的。

但是，Istio 内部是如何运行的，我们为什么需要 Istio，而不是直接使用 Envoy 代理呢？

架构

Envoy 代理是一个轻量级的网络代理，它可以单独使用，但是如果有十个服务要部署的话，我们就需要配置十个 Envoy 代理。这个过程会变得有一些复杂和繁琐。Istio 简化了这一过程。

从架构上来讲，Istio 服务网格是由数据平面（data plane）和控制平面（control plane）组成的。

数据平面是由以 sidecar 形式部署的 Envoy 代理组成的。这个代理会拦截所有网络之间的通信。它还会收集和报告所有网格流量的遥测数据。

控制平面负责管理和配置 Envoy 代理。

下图描述了这两个组件：

 https://www.infoq.cn/article/MAdzPKPBJBDibipO9daS