005 云原生之 Service Mesh(Istio+Envoy)

Service Mesh（服务网格）是专用的基础结构层，主要用于保障服务之间安全、快速和可靠的通信。构建云原生应用程序就需要一个 Service Mesh。

Service Mesh 是基础设施层，在某些场景中可能要与其他基础设施交互，如基础网络、PaaS 平台、运维系统等。如 ServiceMesh 产品 Istio 就非常依赖 Kubernetes 这一基础设施，当然 Istio 本身也是基础设施。

Service Mesh 主要包含三种模式：第一种 Sidecar 模式，典型解决方案如 Istio+Envoy，当然还有其他的实现方案，如 Linkerd 等；第二种是服务注册和发现模式(Service Registry & Discovery)，典型解决方案如 SpringCloud；第三种是中心化 Broker 模式，典型解决方案如 RSocketBroker。

Sidecar 模式最典型的方案是 Istio+Envoy 的结构，其中 Istio 主要负责控制面（Control Plane）的管控，而 Envoy 则负责数据面（Data Plane）的网络流量转发。两者的结合实现了 Istio 的 4 大目标：连接（Connect）、安全（Security）、控制（Control）和观测（Observe）。

Istio+Envoy 典型的点架构方案

服务路由和可靠性保证：有了代理人的介入，应用只需要与附近（127.0.0.1）的代理人创建连接，然后代理人与目标服务创建连接和路由等。有了代理人，应用就不用关心与网络相关的工作了。

隔离性和安全性：当发起网络 I/O 请求时，如果采用同步阻塞的方式，通常要设置连接池和请求超时，以保证应用的快速响应。代理人可以承担起这部分责任，处理连接池和超时等工作。由代理人来管理与服务提供者的连接，那么应用就不再需要保存这些用户名、密码和密钥等信息，安全性就会因此而得到提升。

为应用减负：采用代理人模式，我们只需要通过 HTTPREST/gRPC 这些通用 SDK 将请求发送给代理人，代理人就可以连接 Kafka 并完成消息的发送，这种协议转换能够很大程度地为应用减负。

服务调用的可观测性：代理人介入后，服务请求的转发都是通过代理人完成的，相当于有了统一的入口。在这里，我们可以进行可观测性数据埋点，如使用 Logging、Tracing 和 Metrics，使数据采集工作简单很多。数据采集将为后续的服务治理提供分析数据。

在 Istio+Envoy 的架构设计中，存在一个数据面和控制面的通信协议，即 xDS 协议（xDS Protocol）。该协议可以实现对 Envoy 代理的管控。

代理人应用部署在真实应用的旁侧，我们可以将真实应用和代理人应用理解为同一个虚拟主机或容器内的两个进程——一个为正式应用的进程，一个为 Envoy 代理进程。

对比传统的直连模式，Envoy 代理介入后增加了网络请求的跳数（Network Jump）。Envoy 代理同时也是一个独立进程，需要使用到内存和 CPU 等。