概述

这篇文章是我在 2019 年 5 月份编撰的，但是一直没有写完，放在草稿箱里，今天突然被我翻出来了，所以顺手编辑了一下。其实没有写完的原因就是因为之前翻译了不少内容，觉得直接打着翻译的名号又辜负了自己的一些理解，所以就堆着了，后面就逐渐地加上了自己的体会和理解，今天顺便整理一下。

什么是 Service Mesh

Service Mesh 是一种工具，通过在平台层而不是应用层插入可观察性、安全性和可靠性功能来为应用程序添加这些功能。

Service Mesh 通常被实现为一组可扩展的网络代理，与应用程序代码一起部署（这种模式有时被称为 sidecar）。这些代理处理微服务之间的通信，同时也作为一个点，可以引入服务网状结构的功能。代理包括服务网状结构的数据平面，并作为一个整体由其控制平面控制。例如现在最为流行的 Service Mesh 框架之一 Istio，就是典型的这种架构，默认地，Istio 就在客户端和服务器之间各安插一个 Sidecar：Envoy，客户端和服务端的流量都走 Envoy，从而屏蔽了中间的平台细节，让客户端和服务器都感觉自己就是和对方直接连接。

服务网格特点

• 轻量级的网络代理
• 应用无感知
• 应用之间的流量由服务网格接管
• 把服务间调用可能出现的超时/重试/监控/追踪等工作下沉到服务网格层处理

服务网格结构

现在（2021）的 Service Mesh（Isito 和 Linkerd，包括我们公司自己开发的）都由数据平面和控制平面组成：

• 数据平面：应用数据真正的请求路径
  • 主要负责流量转发，策略实施和遥测数据上报；
  • 核心组件：Envoy，Linkerd-proxy
• 控制平面：控制数据平面如何处理数据
  • 主要是将用户的配置转成具体的路由规则，并且交给数据平面（Envoy、Linkerd-Proxy），然后收集遥测数据用于指导控制策略
  • 核心组件：
    • 以前 Istio 有好几个：
      • Mixer：遥测管理
      • Pilot：流量管理
      • Citadel：认证管理
    • 现在 Istio 将这些都合并成一个了，这也是现在的一个趋势，尽量简化部署模型，能一个进程跑就不跑多个；

图 1：旧版本 Istio 示意图

图 2：新版本 Istio 示意图

Istio 支持的特性

• Istio 支持不同协议流量的负载均衡：HTTP、gRPC、WebSocket 和 TCP；
• 通过 Vritual Service 和 Destionation Rule 两个概念，提供丰富的路由规则、重试、故障转移和故障注入等流量行为的细粒度控制；
• 提供可插入的策略层和配置 API，支持访问控制、速率限制和配额；
• 通过 Ingress 和 Outgress 集群流量的入口和出口进行控制，跟踪和监控；
• 通过基于身份的认证和授权，实现服务间的安全通信。

Reference

• What’s a service mesh? And why do I need one?
• Istio Document