ServiceMesh实战：用Istio软负载实现服务网格 pdf下载

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

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

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

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

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

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

蒋江伟 阿里巴巴研究员
周遥（玄胤）在阿里巴巴中间件团队的时候，负责和参与了软负载体系的建设，并且为整个阿里巴巴分布式架构的演进贡献了大量创新想法。玄胤有非常丰富的分布式系统经验，本书是理论和实践的结合，值得细读。

刘清富 挖财CTO
服务网格作为Kubernetes的有力补充，能很好地扩充容器的功能范围，在简化服务架构的同时让运维更高效，是服务架构发展方向之一。服务网格使每个Service实例之间的通信更加流畅、可靠和迅速，开发工程师可以在服务中专注于开发、支持以及维护，系统运维工程师可以专心维护服务网格并运行App。本书是感兴趣的工程师拥抱服务网格的很好选择，从基础到实践都有细致讲解，极具指导意义。

罗毅 Dubbo开源框架总负责人
有幸和周遥（玄胤）在阿里巴巴中间件团队共事三年。他是软负载领域重要产品VIPServer的原创者及主力开发人员。迄今为止，VIPServer仍然是阿里巴巴电商系统中P0级别的系统，为百万级别的集群提供地址解析服务。本书从概念、使用、设计再到实现，抽丝剥茧、层层推进，适于不同程度读者快速掌握时下十分流行的服务网格。作者在本书最后部分敏锐指出软负载演进的过程其实就是一部“抽象、隔离与自动化的发展史”，未来将会在“硬件、云计算、虚拟化、通信协议及人工智能技术上看到更多的亮点"。可见本书不仅停留在Service Mesh具体技术上，而且是在深挖其背后的设计理念，洞察其未来的发展方向。

许令波 《大型网站技术架构演进与性能优化》作者
作者有多年在阿里巴巴中间件团队工作的经验，尤其在服务网关、地址路由及Service Mesh，有很丰富的实践。阅读本书，读者可以了解和掌握Service Mesh的核心概念和工作原理，在开发中更加合理、高效地解决和排查Service Mesh的各种问题，建议反复细读。

第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

推荐序1

CNCF 所提出的云原生概念在相当短的时间内得到了来自Alibaba、Google、IBM、Pivotal等公司的支持与参与，背后的核心驱动力在于通过打造“事实标准”的软件去解决云厂商对客户的锁定问题。云原生的本质，是解决应用的弹性（resiliency）、易用性（usability）和可移植性（portability）。当这“三性”得到妥善的解决后，客户所开发的（分布式）应用可以方便、高效地同时部署于多个云厂商所提供的云服务之上，这不仅解决客户所担心的技术锁定问题，还使得应用能很好地满足法规（指要求某些影响国计民生的应用必须同时部署于多个云厂商的云上）、全球多活等严苛的要求。

在解决“三性”的道路上，Service Mesh 被视为新一代分布式应用架构的软件基础设施，并被明确地写入了云原生概念的定义中。Service Mesh 可以理解为是微服务软件架构（microservices）的进一步延伸，用于解决大规模微服务应用所面临的多语言支持、服务全局最优治理、服务（全球）发现与路由、安全保障等挑战的关键技术手段。

开源软件Istio 的出现，有望成为云原生中Service Mesh 的软件事实标准。Istio 所提出的“数据平面”（Istio 中的Pilot-discovery、Mixer 等组件）和“控制平面”（Envoy）通过很好的概念切分践行着软件行业解决复杂问题的终级范式——分而治之，这两个“平面”外加“运维平面”（Service Mesh 中并没有定义）将能很好地助力解决云原生所致力于解决的“三性”问题。

Service Mesh 的最高境界在于让分布式应用无须关注服务（全球）发现与路由、限流、降级、熔断、安全等通用问题，但达到这一目标并非一蹴而就，这就需要同仁们在各自的岗位上共同学习、运用和成就这一技术。本书的出现能帮助读者更好地理解以Istio 为代表的Service Mesh 技术背后的设计思路和了解阶段性的探索成果。

李云 阿里巴巴中间件高级技术专家

推荐序2

近几年，随着 Kubernetes 的兴起，云原生的理念得到了大规模的推广。在整个业界，我们看到了云原生的理念正在重新塑造整个技术栈，从应用编排到服务化，再到Serverless，等等。Linkerd 背后的公司 Bouyant 首先提出了 Service Mesh 的概念，随后 Google、IBM、Lyft 共同推出了 Istio。目前来看，它有成为 Service Mesh 事实标准的趋势。因此，想要了解云原生时代下微服务架构应该如何设计和实现，学习 Istio 是一条逃不开的路径。

那么怎么学习 Istio ，就成了摆在 Istio 爱好者面前的一大难题——Istio 组件繁多，功能也非常强大，要搞清楚这些组件的功能，仅凭翻阅 Istio 官方文档当然远远不够。难上加难的是，市场上讲述 Istio 的书屈指可数。

好在，周遥的这本《Service Mesh 实战：用Istio 软负载实现服务网格》适时问世了，它详细剖析 Istio 的各个核心功能，完整弥补了这方面的资料缺失，并且介绍了国内部分互联网企业在 Service Mesh 上的实践，可谓针对这一热门技术不可多得的好书。对于想要快速了解 Istio功能，进而准备上手实践的朋友来说，这本书是有限的选择中最不会让你后悔的一个。

黄挺 蚂蚁金服中间件技术专家

……

序

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

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

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

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

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

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

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

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

（以下排名不分先后）

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

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