Service Mesh实战：用Istio软负载实现服务网格

《Service Mesh实战：用Istio软负载实现服务网格》为网格服务技术的实战详解图书。作者以初学者角度展示软负载在分布式架构中承担的角色，引入容器时代主角Kubernetes；再从路由层面全面展开对Service Mesh 与Istio 的系统介绍和深入剖析，包括其功能与特色；最后通过源码剖析从实现细节上分析Istio 的几大关键设计。不论你是刚开始接触软负载的初学者，还是有一定经验的架构师，都可以在这本细致入微的图书中找到想要的实用内容。

周遥：挖财中间件架构师，原阿里巴巴中间件团队技术专家，8年分布式架构经验，三项国家发明专利，在软负载领域拥有相当丰富的经验，阿里软负载核心产品VIPServer原作者。

√ 阿里巴巴分布式架构与软负载体系核心骨干执笔

√ 阿里P0 |百万集群级|电商系统缔造者实践精华

√ 从容器到Kubernetes，再到服务网格，全线实战贯通

√ 侧重“排坑”，解决|排查Service Mesh常见问题是亮点

序

早在2013 年，我供职的阿里巴巴集团（以下简称阿里）中间件软负载团队就受运维部门之托，开始着手研究新一代的内部服务调度与治理系统。那个时候微服务概念还没有提出，但阿里在服务化方式上已经走在前列了——强壮的业务由拥有数量庞大的服务群及复杂的调用关系支撑着。运维的需求集中于希望能提供一种“更加灵活、响应更快速且更低成本”的方案来连接、控制、配置整套线上服务系统；因为在当时的LVS 负载体系下，由于硬件的限制，是不可能做到快速响应的，而独立部署的LVS 集群在配置与多环境下都又略显得有心无力。

当时我的领导蒋江伟（花名小邪）将这一重任交予了我并预示了SDN（Software Defined Network，即软件定义的网络）的发展方向，我很荣幸能拥有这样的机会，当然也没有辜负他的期望。一年后，VIPServer 系统诞生，第一次在阿里内部以纯软路由的形式调度各大系统间的请求，并在两年内完全主宰了内部的服务调用需求。

软路由的好处在于“软”，不与实体布线、交换机配置或硬件绑定，对于不同的流量流向什么样的地方可以任意且随时地变更，此即灵活。例如我们可以将来自Android 客户端的流量指定到链路中拥有Test 标记的服务器，这样可以实现诸如灰度发布的功能。分布式系统发布至今，系统数量空前爆炸，业务的关系与配置越来越复杂，因此对环境治理与隔离的要求也越来越高。回顾应用容器的发展，从纯硬件到硬件虚拟化、容器化再到弹性编排，无不都是走向“软件定义”这个方向，因此软负载领域也应该如此。

2017 年我加入挖财，发现对较大型企业而言，中小规模企业更加饱受服务环境治理之苦，因为中小规模的企业通常没有过多精力自行研发属于自己的软负载体系，大多通过修改开源的组件来实现目的。这样的问题在于无法组成一个平台体系，虽然基本功能（如配置、服务发现）能够满足，一旦涉及多级协调功能（如链路压测、故障注入体系）的时候，便捉襟见肘了。虽然阿里早些年已经拥有这样的能力了，但想要将其直接复制到外部的企业却是一项几乎不可能完成的任务。阿里的关键技术都是定制的（如RPC 服务HSF），设计所针对的场景不一定适合中小企业，即关注的点不同；所以对于中小企业而言，需要的就是一个能够连接各软负载开源产品的平面，而且这个平面应该与主流的服务编排、RPC、配置及服务发现完美兼容，并最大限度地支持链路功能扩展。

带着上述问题，我一直在思考这个产品的存在形式；而在Istio 问世以后，我便相信这就是它的最佳形态。我个人看好服务网格（Service Mesh）在服务架构上的影响力，并且相信这是微服务架构的下一个阶段，因为对多数企业而言架构本身的复杂度已经开始超越业务逻辑本身，如果不加以统一管理与规划，那么只是维护成本就已经很高了。

服务网格的思想就像是分布式服务本身下沉到技术栈中，只对业务提供接口供其调用。Istio很巧妙地将其分成了“控制平面”与“数据平面”两部分，使得接口本身更加清晰。接口清晰的好处在于更加容易地定义边界与职能，例如“数据平面”部分，Istio 便可以直接依托于开源Envoy 来实现，而且这并不是唯一的选择；而“控制平面”则为运维人员提供了统一的接口来操作整个链路，相较之前的零散的配置，仅这一点就可以节省不少的人力成本。

2018 年，阿里顺势推出了自己的Nacos1来争夺这一领域，蚂蚁金服也公布了SOFAMesh项目。这说明软负载仍然是大型分布式系统基础的重点，只有将环境与调用梳理清楚、高效利用起来，上层的业务及周边的扩展基础才能快速地推进。未来的分布式架构只会愈加专注，职能划分愈加精细，计算愈加弹性灵活。

虽然在本书编写过程中已经尽力反复去论证、实践每一处，但难免遗误，希望大家积极批评指正。最后我要感谢下面这些在编写本书时一直支持我的朋友们，无论是帮忙订正还是写序，感谢你们！同时本书第6 章得到了蚂蚁金服团队的大力支持，特别感谢你们！当然还有在背后一直支持我的家人们，谢谢！

（以下排名不分先后）

孙 虹 陈霞光 谭建南 吕献军 徐伟杰 李华刚 周文瑾

杨卓荦 马连志 宋月月 王 伟 杨 凯

第1 章 分布式发展史 1

1.1 单机小型机时期 1

1.1.1 互联网的诞生 2

1.1.2 复杂应用拆分 3

1.1.3 遭遇性能问题 3

1.2 集群化时期 4

1.2.1 从高端设备到普通PC 4

1.2.2 硬件负载均衡设备 5

1.2.3 资源配置问题 5

1.2.4 积少成多的优势 6

1.2.5 集群化架构 6

1.2.6 软件负载设备 7

1.3 服务化时期 8

1.3.1 应用到服务 8

1.3.2 远程调用 8

1.3.3 虚拟IP 地址 9

1.3.4 复杂的调用关系 10

1.3.5 服务治理 11

1.3.6 旁路负载 12

1.4 微服务时期 13

1.4.1 服务细化 13

1.4.2 架构轻量化 14

1.5 服务网格（Service Mesh）新时期 15

1.5.1 多语言的困难 15

1.5.2 指数级增加的系统复杂度 15

1.5.3 Linkerd 诞生 16

1.5.4 第一代服务网格架构 17

1.5.5 第二代服务网格架构 18

1.5.6 生产应用情况 19

1.6 本章小结 20

第2 章 Service Mesh：以Istio 为例 21

2.1 Istio 的设计理念 21

2.1.1 Istio 的诞生背景 22

2.1.2 控制一切的两个平面 23

2.1.3 接口与平台化 24

2.1.4 中心化与分散化的抉择 25

2.2 数据平面 27

2.2.1 xDS-API 27

2.2.2 服务负载及流量控制 28

2.2.3 入口与出口网关 31

2.2.4 故障应急机制 32

2.2.5 故障注入 32

2.3 控制平面 33

2.3.1 Pilot 结构及功能 33

2.3.2 Mixer 结构及功能 34

2.3.3 稳定性与容灾能力 37

2.3.4 请求属性（Attribute） 37

2.3.5 操作配置（Operator Config） 38

2.4 安全控制 40

2.4.1 Citadel 结构及功能 42

2.4.2 Istio 身份（Identity） 42

2.4.3 认证（Authentication） 43

2.4.4 鉴权（Authorization） 44

2.5 Hello, Istio! 45

2.5.1 安装 Docker 45

2.5.2 安装 Kubernetes 47

2.5.3 初始化 Master 节点 48

2.5.4 配置 weave 网络插件 49

2.5.5 安装 Istio 49

2.5.6 向 Istio 部署第一个应用 50

2.5.7 部署 BookInfo 系统 51

2.6 动手体验Istio 53

2.6.1 几个基本概念 53

2.6.2 体验1：按版本路由 55

2.6.3 体验2：按权重分流 56

2.7 BookInfo 示例分析 57

2.7.1 IngressGateway 57

2.7.2 IngressGateway 配置 58

2.7.3 Sidecar 路由配置 59

2.8 本章小结 62

第3 章 理解Istio 服务网格 65

3.1 Kubernetes 服务组网原理 65

3.1.1 四层服务部署结构 66

3.1.2 Node 内部流量路由 67

3.1.3 Pause 容器 69

3.1.4 节点间通信接口CNI 72

3.1.5 服务发现与 DNS 74

3.2 Sidecar 流量接管原理 76

3.2.1 Sidecar 注入方式 76

3.2.2 优雅的容器调试方式 78

3.2.3 Sidecar 流量劫持配置 79

3.3 Istio 服务组网 81

3.3.1 链路优势总结 81

3.3.2 服务传输路径全览 82

3.4 组建零信任安全网络（Zero Trust Network） 83

3.4.1 点对点的安全传输 84

3.4.2 身份认证（Authentication） 86

3.4.3 安全命名（Secure Naming） 89

3.4.4 服务鉴权（Authorization） 89

3.4.5 启用Istio 服务网格安全 91

3.5 Istio 的扩展设计 96

3.5.1 Sidecar 对接适配 96

3.5.2 平台适配 100

3.5.3 扩展模板（Template） 104

3.6 本章小结 108

第4 章 Istio 周边生态一览 109

4.1 链路跟踪 Jaeger/Zipkin 110

4.1.1 链路跟踪诞生的前因后果 110

4.1.2 Jaeger 能做什么 110

4.1.3 如何在 Istio 中使用 Jaeger 112

4.1.4 使用 Trace ID 来查询跟踪信息 115

4.2 分布式监控 Prometheus 117

4.2.1 监控需求的由来及现状 117

4.2.2 Prometheus 的功能及特点 118

4.2.3 Prometheus 架构简介 118

4.2.4 如何在 Istio 中使用 Prometheus 120

4.2.5 配置监控报警来实时掌握应用状态 124

4.3 监控大盘 Grafana 129

4.3.1 什么是 Grafana 129

4.3.2 如何在 Istio 中使用 Grafana 130

4.3.3 生成新的 Grafana 仪表盘 132

4.3.4 配置 Grafana 报警通道 135

4.4 分布式日志 Fluentd 137

4.4.1 什么是 Fluentd 137

4.4.2 如何在 Istio 中使用 Fluentd 139

4.4.3 在 Kibana 中查看日志 147

4.4.4 Elasticsearch 映射配置 149

4.5 服务图谱 156

4.6 本章小结 157

第5 章 Istio 部分源码剖析 159

5.1 Sidecar（Envoy）源码分析 160

5.1.1 准备编辑器 160

5.1.2 编译Envoy 调试版本 161

5.1.3 配置 Envoy 调试环境 162

5.1.4 整体架构 168

5.1.5 过滤链与 HTTP 代理 171

5.1.6 xDS 相关逻辑 182

5.2 Pilot 源码分析 187

5.2.1 Go 语言简介 187

5.2.2 编译 Istio 调试版本 188

5.2.3 配置 Istio 调试环境 192

5.2.4 用单元测试快速调试 195

5.2.5 如何进行启动调试 196

5.2.6 Pilot 初始化与平台对接 198

5.2.7 模型数据映射及CRD 监听 203

5.2.8 Envoy xDS 对接服务 206

5.3 Mixer 源码分析 211

5.3.1 Mixer 初始化逻辑 213

5.3.2 前置检查逻辑详解 217

5.3.3 适配器数据流及模板原理 223

5.3.4 缓存原理与实现 233

5.4 本章小结 244

第6 章 服务网格企业实践 245

6.1 升级，值得吗 246

6.1.1 升级服务网格的基本要求 246

6.1.2 如何评估是否需要升级 247

6.2 从架构上考虑的问题 248

6.2.1 当前系统所处的状态 248

6.2.2 迁移中需要考虑的几点 249

6.3 蚂蚁金服SOFAMesh 简介 251

6.3.1 项目组成 251

6.3.2 特色功能 252

6.4 蚂蚁金服渐近式迁移最佳实践 253

6.4.1 制定总体路线 253

6.4.2 保证迁移前后服务网络互通 256

6.4.3 透明拦截带来的弹性升级 256

6.4.4 遗留架构在迁移过程中的问题 257

6.5 本章小结 260

第7 章 结语及附录 261

7.1 服务网格在整体架构中的定位 261

7.1.1 现代软负载应具备的功能 261

7.1.2 服务网格在系统技术栈中的定位 262

7.2 软负载发展方向与未来 263

7.2.1 技术发展的本质 263

7.2.2 再谈软负载的发展 264

7.3 附录——A-Mixer 所有的支持属性值 266

7.4 引用目录 266