作者：张超盟 等
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
云原生服务网格Istio：原理、实践、架构与源码解析试读：
前言
这是一本介绍“云原生”与“服务网格”技术的书籍。你或许对这两个词语感到陌生，或者耳熟却不明其意，其实，这两个术语分别与“云计算”与“微服务”的概念有着非常紧密的联系。
依据CNCF基金会（Cloud-Native Computing Foundation）的定义，云原生是对在现代的动态环境下（比如云计算的三大场景：公有云、私有云及混合云）可用来构建并运行可扩展应用的技术的总称；服务网格则是云原生技术的典型代表之一，其他技术还包括容器、微服务、不可变基础设施、声明式API等。
从技术发展的角度来看，我们可以把云原生理解为云计算所关注的重心从“资源”逐渐转向“应用”的必然结果。以“资源”为中心的上一代云计算技术关注物理设备如何虚拟化、池化、多租化，典型代表是计算、网络、存储三大基础设施的云化，以及相关硬件、操作系统、管控面等技术；而以“应用”为中心的云原生技术则关注应用如何更好地适应云环境，相对于传统应用通过迁移改造“上云”而言，云原生希望通过一系列的技术支撑，使用户能够在云环境下快速开发和交付云原生应用。
作为云原生技术栈的一部分，服务网格则指由云原生应用的服务化组件构成的一种网格。换句话说，我们可以将服务网格理解为一种应用网络，即为在应用内部或应用之间由服务访问、调用、负载均衡等服务连接关系构成的一种网络。你可能会注意到，这里并没有使用“微服务”这个术语。微服务更多地从设计、开发的视角来描述应用的一种架构或开发模式，而服务网格事实上更为关注运行时视角，因此，采用“服务”这个用于描述应用内外部调用关系的术语更为合适。服务网格与微服务在云原生技术栈中是相辅相成的两部分，前者更关注应用的交付与运行时，后者更关注应用的设计与开发。
本书的主角Istio，作为服务网格技术的事实标准，是一个比较年轻的开源项目。它在2017年5月由Google与IBM联合发布之后，经过一年多的快速发展，于2018年7月发布了1.0版本，并于2019年3月发布1.1这个大更新版本，该版本算是第一个生产可用的GA 版本（虽然官方宣称 1.0 版本“Production-Ready”，但从实践评估来看，1.1 作为 GA版本更合适一些）。
Istio体现了云原生领域核心项目Kubernetes的创建者Google对服务网格技术的思考，还包含了云计算先行者 IBM 对服务网格最早的实践经验，因此一经发布就得到云原生领域的广泛响应，它是继 Kubernetes之后云原生领域非常火爆的项目之一。截至 2019 年年初，国内外已经有超过百家公司的公开实践案例。
本书作者所在的华为公司作为云原生领域的早期实践者与社区领导者之一，在 Istio项目发展初期就参与了Istio社区，积极实践Istio并推动Istio项目的发展。目前，华为公司内部的多个产品线已经使用了Istio，部分实践已经进入生产环境，Istio的商业化产品也已经包含在华为公有云、私有云、混合云解决方案中，并面向华为云客户群进行推广。华为作为 Istio社区的当前领导者之一，会继续致力于 Istio项目及服务网格技术的推广与演进。
本书写作目的
本书作为华为云原生技术丛书的一员，面向云计算领域的从业者及感兴趣的技术人员，普及与推广 Istio 服务网格技术。本书作者来自华为云应用服务网格产品研发团队及华为云原生开源社区团队。本书结合作者在华为云及 Istio 社区的设计与开发实践，以及与服务网格强相关的Kubernetes容器、微服务和云原生领域的丰富经验，对服务网格技术、Istio开源项目的原理、实践，架构和源码进行了深入剖析，由浅入深地讲解Istio的功能、用法、设计与实现，帮助读者全面、立体地了解云原生服务网格 Istio 的每个技术细节。对于刚入门的读者，本书提供了从零开始的 Istio 上手实战指导；对于已经在产品中使用Istio的读者，本书也提供了丰富的案例与经验总结。
本书结构
本书分为原理篇、实践篇、架构篇和源码篇，总计24章，由浅入深地将Istio项目庖丁解牛并呈现给读者。
对于有不同需求的读者，我们建议这样使用本书。
◎ 对云原生技术感兴趣的读者，可阅读并理解原理篇。本篇介绍了服务网格技术与Istio 项目的技术背景、设计理念与功能原理，能够帮助读者了解服务网格这一云原生领域的标志性技术，掌握Istio流量治理、策略与遥测和安全功能的使用方法。
◎ Istio 一线实践者或动手能力较强的技术人员，通过实践篇可以从零开始搭建 Istio运行环境并完成一个真实应用的开发、交付、上线监控与治理的完整过程，能够熟悉Istio的功能并加深对Istio原理的理解。
◎ 关注Istio架构设计或者正在评估是否将Istio引入当前技术栈的技术人员，架构篇能够帮你剖析 Istio项目的三大核心子项目 Pilot、Mixer、Citadel的详细架构，熟悉Envoy、Galley、Pilot-agent等相关项目，并深入挖掘Istio代码背后的设计与实现思想。
◎ 对Istio源码感兴趣且希望更深入地了解Istio实现细节的读者，可以通过源码篇进入Istio源码世界。源码篇对Istio各个项目的代码结构、文件组织、核心流程、主要数据结构及各主要代码片段等关键内容都进行了详细介绍。读者只需具备一定的 Go 语言基础，便可快速掌握 Istio 各部分的实现原理，并根据自己的兴趣深入了解某一关键机制的完整实现，以期成为Istio高手，甚至作为贡献者参与到Istio项目开发中来。
本书篇章组织概述如下。
◎ 原理篇：介绍Istio概念、核心功能、原理和使用方式，为后续的实践提供理论基础。其中，第 1～2 章分别介绍 Istio 的背景知识、基本工作机制、主要组件及概念模型等；第 2～7 章分别介绍 Istio 的五大块功能集，即非侵入的流量治理、可扩展的策略和遥测、可插拔的服务安全、透明的Sidecar机制及多集群服务治理。
◎ 实践篇：通过实际操作介绍如何通过一个典型应用进行Istio实践。其中，第8章讲解环境准备，完成Kubernetes与Istio平台的基础设施准备工作；第9～13章分别介绍如何实际操作一个天气预报应用在Istio平台上实现流量监控、灰度发布、流量治理、服务安全、多集群管理等功能。
◎ 架构篇：从架构角度剖析Istio多个主要组件的设计原理、关键内部流程及数据结构等内容，为高级用户提供架构与设计层面的参考。其中，第14～19章分别介绍了Pilot、Mixer、Citadel、Envoy、Pilot-agent与Galley等6个Istio核心组件。
◎ 源码篇：本篇包括第20～24章，分别介绍Istio整体的代码组织情况，以及Pilot、Mixer、Citadel、Envoy与Galley的代码结构与关键代码片段。
源代码与官方参考
Istio是一个开源项目，本书也开源了实践篇示例应用的源代码，读者可通过如下链接获取本书源码及相关内容。
◎ Istio项目官网：https：//istio.io/。
◎ Istio源代码：https：//github.com/istio。
◎ 本书示例应用源代码：https：//github.com/cloudnativebooks/cloud-native-istio。
勘误和支持
若您在阅读本书的过程中有任何问题或者建议，则可以通过本书源码仓库提交 Issue或者 PR，也可以关注华为云原生官方微信公众号并加入微信群与我们交流。我们十分感谢并重视您的反馈，会对您提出的问题、建议进行梳理与反馈，并在本书后续版本中及时做出勘误与更新。
致谢
在本书的写作及成书过程中，本书作者团队得到了公司内外许多领导、同事及朋友的指导、鼓励和帮助。感谢华为云郑叶来、张宇昕、廖振钦、方璞等业务主管对华为云原生技术丛书及本书写作的大力支持；感谢华为云容器团队王泽锋、罗荣敏、毛杰、张琦等对本书的审阅与建议；感谢华为云应用服务网格团队陈冬冬、巩培尧、王少东、李汉辰、秦玉函、张云等为本书编写示例程序及分享实践经验；感谢电子工业出版社博文视点张国霞编辑一丝不苟地制订出版计划及组织工作；感谢华为云邢紫月对本书的出版建议与指导；最后，也感谢CNCF基金会及Istio、Kubernetes社区众多开源爱好者辛勤、无私的工作，使得我们在这个技术爆发的时代能够充分领略到技术的魅力并能够亲身参与到这份有激情、有挑战的事业中来。谢谢大家！刘赫伟 博士华为云原生技术丛书 总编华为云容器服务域 技术总监张超盟华为云应用服务网格 首席架构师原理篇
自本篇起，Istio 的学习之旅就正式开始了。本篇主要介绍 Istio 的功能特性及工作原理，呈现Istio丰富的流量治理、策略与遥测、访问安全等功能，以及Sidecar机制和多集群服务治理方面的内容。结合实践篇的内容，读者可以掌握 Istio 的使用方法，例如怎样使用 Istio 的流量规则、怎样配置安全策略、怎样使用 Istio 的 Adapter 来做策略控制和收集服务运行的遥测数据等。第1章 你好，Istio
本章简要介绍Istio的一些背景知识，包括Istio是什么、能干什么，以及Istio项目的诞生及发展历史，并尝试梳理Istio与微服务、服务网格、Kubernetes这几个云原生领域炙手可热的技术概念的关系。希望读者能通过本章对 Istio 有一个初步的认识，并带着问题与思考进入后续的学习中。1.1 Istio是什么
Istio是什么？我们试着用迭代方式来说明。
◎ Istio是一个用于服务治理的开放平台。
◎ Istio是一个Service Mesh形态的用于服务治理的开放平台。
◎ Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。
这里的关键字“治理”不局限于“微服务治理”的范畴，任何服务，只要服务间有访问，如果需要对服务间的访问进行管理，就可以使用 Istio。根据 Istio 官方的介绍，服务治理涉及连接（Connect）、安全（Secure）、策略执行（Control）和可观察性（Observe），如图1-1所示。
◎ 连接：Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能。
◎ 安全：Istio 提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性。
◎ 策略执行：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力。
◎ 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状况，发现并解决问题。图1-1 服务治理范畴
在 Istio 0.1 发布时，Istio 官方的第 1 篇声明（https：//istio.io/blog/2017/0.1-announcement/）强调了Istio提供的重要能力。
◎ 服务运行可观察性：监控应用及网络相关数据，将相关指标与日志记录发送至任意收集、聚合与查询系统中以实现功能扩展，追踪分析性能热点并对分布式故障模式进行诊断。
◎ 弹性与效率：提供了统一的方法配置重试、负载均衡、流量控制和断路器等来解决网络可靠性低所造成的各类常见故障，更轻松地运维高弹性服务网格。
◎ 研发人员生产力：确保研发人员专注于基于已选择的编程语言构建业务功能，不用在代码中处理分布式系统的问题，从而极大地提升生产能力。
◎ 策略驱动型运营：解耦开发和运维团队的工作，在无须更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够不依赖开发提供的能力精确控制生产流量。
◎ 默认安全：允许运营人员配置TLS双向认证并保护各服务之间的所有通信，并且开发人员和运维人员不用维护证书，以应对分布式计算中经常存在的大量网络安全问题。
◎ 增量适用：考虑到在网络内运行的各服务的透明性，允许团队按照自己的节奏和需求逐步使用各项功能，例如先观察服务运行情况再进行服务治理等。
1.3～1.5 节会分别结合服务治理、服务网格、Kubernetes 这几个关键字展开对“Istio是什么”的迭代，对 Istio进行立体介绍。在这之前，我们先通过一个示例来看看 Istio能做什么。1.2 通过示例看看Istio能做什么
首先看看 Istio 在服务访问的过程中都做了什么，简单起见，这里以一个天气预报应用中forecast服务对recommendation服务的访问为例，如图1-2所示。本书后面的大部分功能都会基于该应用来介绍。图1-2 Istio服务访问示例
这个示例对两个服务的业务代码没有任何要求，可以用任何语言开发。在这个示例中，forecast服务是用Node.js开发的，recommendation服务是用Java开发的。在forecast服务的代码中通过域名访问recommendation服务，在两个服务中都不用包含任何服务访问管理的逻辑。
我们看看Istio在其中都做了什么：
◎ 自动通过服务发现获取recommendation服务实例列表，并根据负载均衡策略选择一个服务实例；
◎ 对服务双方启用双向认证和通道加密；
◎ 如果某个服务实例连续访问出错，则可以将该实例隔离一段时间，以提高访问质量；
◎ 设置最大连接数、最大请求数、访问超时等对服务进行保护；
◎ 限流；
◎ 对请求进行重试；
◎ 修改请求中的内容；
◎ 将一定特征的服务重定向；
◎ 灰度发布；
◎ 自动记录服务访问信息；
◎ 记录调用链，进行分布式追踪；
◎ 根据访问数据形成完整的应用访问拓扑；
◎……
所有这些功能，都不需要用户修改代码，用户只需在 Istio 的控制面做些配置即可，并且动态生效。以灰度发现为例，在 Istio 中是通过简单配置实现灰度发布的，其核心工作是实现两个版本同时在线，并通过一定的流量策略将部分流量引到灰度版本上。我们无须修改代码，只要简单写一个配置就可以对任意一个服务进行灰度发布了：
Istio采用了与Kubernetes类似的语法风格，即使不了解语法细节，也很容易明白其功能大意：将 group是 dev的流量转发到 recommendation服务的 v2版本，其他用户还是访问 recommendation服务的 v1版本，从而达到从 v1版本中切分少部分流量到灰度版本 v2的效果。对Istio提供的功能都进行类似配置即可，无须修改代码，无须额外的组件支持，也无须其他前置和后置操作。1.3 Istio与服务治理
Istio是一个服务治理平台，治理的是服务间的访问，只要有访问就可以治理，不在乎这个服务是不是所谓的微服务，也不要求跑在其上的代码是微服务化的。单体应用不满足微服务的若干哲学，用Istio治理也是完全可以的。提起“服务治理”，大家最先想到的一定是“微服务的服务治理”，就让我们从微服务的服务治理说起。1.3.1 关于微服务
Martin Fowler对微服务的描述是“微服务是以一组小型服务来开发单个应用程序的方法，每个服务都运行在自己的进程中，服务间采用轻量级通信机制（通常用 HTTP 资源API）。这些服务围绕业务能力构建并可通过全自动部署机制独立部署，还共用一个最小型的集中式管理，可用不同的语言开发，并使用不同的数据存储技术”，参见 https：//martinfowler.com/articles/microservices.html。
可以看出，微服务在本质上还是分而治之、化繁为简的哲学智慧在计算机领域的一个体现。
如图1-3所示，微服务将复杂的单体应用分解成若干小的服务，服务间使用轻量级的协议进行通信。
这种方式带给我们很多好处：
◎ 从开发视角来看，每个微服务的功能更内聚，可以在微服务内设计和扩展功能，并且采用不同的开发语言及开发工具；
◎ 从运维视角来看，在微服务化后，每个微服务都在独立的进程里，可以自运维；更重要的是，微服务化是单一变更的基础，迭代速度更快，上线风险更小；
◎ 从组织管理视角来看，将团队按照微服务切分为小组代替服务大组也有利于敏捷开发。图1-3 微服务化
但是，微服务化也给开发和运维带来很大的挑战，因为微服务化仅仅是一种分而治之的方法，业务本身的规模和复杂度并没有变少，反而变多。如图1-4所示，在分布式系统中，网络可靠性、通信安全、网络时延、网络拓扑变化等都成了我们要关注的内容。另外，微服务机制带来了大量的工作，比如服务如何请求目标服务，需要引入服务发现和负载均衡等，以及对跨进程的分布式调用栈进行分布式调用链追踪，等等。总之，简单的事情突然变得复杂了。图1-4 微服务化带来的分布式问题
这就需要一些工具集来做一些通用的工作，包括服务注册、服务发现、负载均衡等。在原来未微服务化的时候，单体应用的多模块之间根本不需要进程间通信，也不需要服务发现。所以，我们将这些工具集理解为用于解决微服务化带来的新问题似乎更合理一些，但是这些工具集本身并没有带来更多的业务收益。1.3.2 服务治理的三种形态
服务治理的演变至少经过了以下三种形态。
第1种形态：在应用程序中包含治理逻辑
在微服务化的过程中，将服务拆分后会发现一堆麻烦事儿，连基本的业务连通都成了问题。如图1-5所示，在处理一些治理逻辑，比如怎么找到对端的服务实例，怎么选择一个对端实例发出请求等时，都需要自己写代码来实现。这种方式简单，对外部依赖少，但会导致存在大量的重复代码。所以，微服务越多，重复的代码越多，维护越难；而且，业务代码和治理逻辑耦合，不管是对治理逻辑的全局升级，还是对业务的升级，都要改同一段代码。图1-5 第1种形态：在应用程序中包含治理逻辑
第2种形态：治理逻辑独立的代码
在解决第1种形态的问题时，我们很容易想到把治理的公共逻辑抽象成一个公共库，让所有微服务都使用这个公共库。在将这些治理能力包含在开发框架中后，只要是用这种开发框架开发的代码，就包含这种能力，这就是如图 1-6 所示的 SDK 模式，非常典型的这种服务治理框架就是Spring Cloud。这种形态的治理工具集在过去一段时间里得到了非常广泛的应用。
SDK模式虽然在代码上解耦了业务和治理逻辑，但业务代码和 SDK还是要一起编译的，业务代码和治理逻辑还在一个进程内。这就导致几个问题：业务代码必须和 SDK 基于同一种语言，即语言绑定。例如，Spring Cloud等大部分治理框架都基于Java，因此也只适用于 Java 语言开发的服务。经常有客户抱怨自己基于其他语言编写的服务没有对应的治理框架；在治理逻辑升级时，还需要用户的整个服务升级，即使业务逻辑没有改变，这对用户来说是非常不方便的。图1-6 第2种形态：治理逻辑独立的代码
此外，SDK对开发人员来说有较高的学习门槛，虽然各种SDK都会讲如何开箱即用，但如果只是因为需要治理逻辑，就让开发人员放弃自己熟悉的内容去学习一套新的语言和开发框架，可能代价有点大。
第3种形态：治理逻辑独立的进程
SDK模式仍旧侵入了用户的代码，那就再解耦一层，把治理逻辑彻底从用户的业务代码中剥离出来，这就是如图1-7所示的Sidecar模式。图1-7 第3种形态：治理逻辑独立的进程
显然，在这种形态下，用户的业务代码和治理逻辑都以独立的进程存在，两者的代码和运行都无耦合，这样可以做到与开发语言无关，升级也相互独立。在对已存在的系统进行微服务治理时，只需搭配 Sidecar 即可，对原服务无须做任何修改，并且可以对老系统渐进式升级改造，先对部分服务进行微服务化。
比较以上三种服务治理形态，我们可以看到服务治理组件的位置在持续下沉，对应用的侵入逐渐减少，如表1-1所示。表1-1 三种服务治理形态的比较1.3.3 Istio不只解决了微服务问题
微服务作为一种架构风格，更是一种敏捷的软件工程实践，说到底是一套方法论；与之对应的 Istio 等服务网格则是一种完整的实践，Istio 更是一款设计良好的具有较好集成及可扩展能力的可落地的服务治理工具和平台。
所以，微服务是一套理论，Istio是一种实践。但是，Istio是用来解决问题的，并不是微服务理论的一种落地，在实际项目中拿着微服务的细节列表来硬套 Istio 的功能，比如要求Istio治理的服务必须实现微服务的服务注册的一些细节，就明显不太适当。
从场景来看，Istio管理的对象大部分是微服务化过的，但这不是必需的要求。对于一个或多个大的单体应用，只要存在服务间的访问要进行治理，Istio也适用。实际上，传统行业的用户业务需要在容器化后进行服务治理，Istio是用户非常喜欢的形态，因为不用因为服务治理而修改代码，只需将业务搬到 Istio 上即可，如果需要将业务微服务化，则可以渐进式进行。
从能力来看，Istio对服务的治理不只包含在微服务中强调的负载均衡、熔断、限流这些一般治理能力，还包含诸多其他能力，例如本书会重点讲到的提供可插拔的服务安全、可扩展的控制策略、服务运行可观察性等更广泛的治理能力。在 Istio 中提供的是用户管理运维服务需要的能力，而不是在微服务教科书中定义的能力。
所以，过多地谈论Istio和微服务的关系，倒不如多关注Istio和Kubernetes的结合关系。Kubernetes和云原生实际上已经改变或者重新定义了软件开发的很多方面，再想一想微服务世界正在发生的事情，我们也许会慢慢地习惯微服务回归本源，即用更加通用和松散的理论在新的形态下指导我们的工作。1.4 Istio与服务网格
业界比较认同的是William Morgan关于服务网格（Service Mesh）的一段定义，这里提取和解释该定义中的几个关键字来讲解服务网格的特点。
◎ 基础设施：服务网格是一种处理服务间通信的基础设施层。
◎ 云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求。
◎ 网络代理：在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。
◎ 对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。
经典的服务网格示意图如图1-8所示。图1-8 经典的服务网格示意图1.4.1 时代选择服务网格
笔者所在的团队曾经开发过一个微服务框架，该框架已经从 Apache 毕业。团队的老同事在聊起服务网格时，大家戏言它不就是个 Sidecar 嘛，其实我们为了支持多语言也构思过类似的东西，但那时还没有服务网格的概念。服务网格能这么快就产生如此大的影响，确实让人始料未及。那么，服务网格为什么会大行其道呢？
在云原生时代，随着采用各种语言开发的服务剧增，应用间的访问拓扑更加复杂，治理需求也越来越多。原来的那种嵌入在应用中的治理功能无论是从形态、动态性还是可扩展性来说都不能满足需求，迫切需要一种具备云原生动态、弹性特点的应用治理基础设施。
首先，从单个应用来看，Sidecar与应用进程的解耦带来的应用完全无侵入、开发语言无关等特点解除了开发语言的约束，从而极大降低了应用开发者的开发成本。这种方式也经常被称为一种应用的基础设施层，类比TCP/IP网络协议栈，应用程序像使用TCP/IP一样使用这个通用代理：TCP/IP 负责将字节码可靠地在网络节点间传递，Sidecar 则负责将请求可靠地在服务间进行传递。TCP/IP 面向的是底层的数据流，Sidecar 则可以支持多种高级协议（HTTP、gRPC、HTTPS 等），以及对服务运行时进行高级控制，使服务变得可监控、可管理。
然后，从全局来看，在多个服务间有复杂的互相访问时才有服务治理的需求。即我们关注的是这些 Sidecar 组成的网格，对网格内的服务间访问进行管理，应用还是按照本来的方式进行互相访问，每个应用程序的Inbound流量和Outbound流量都要经过Sidecar代理，并在Sidecar上执行治理动作。
最后，Sidecar是网格动作的执行体，全局的管理规则和网格内的元数据维护通过一个统一的控制面实现，如图 1-9 所示，只有数据面的 Sidecar 和控制面有联系，应用感知不到Sidecar，更不会和控制面有任何联系，用户的业务和控制面彻底解耦。图1-9 服务网格的统一控制面
当然，正所谓没有免费的午餐，这种形态在服务的访问链路上多引入的两跳也是不容回避的问题。
如图1-10所示，从forecast服务到recommendation服务的一个访问必须要经过forecast服务的 Sidecar拦截 Outbound流量执行治理动作；再经过 recommendation服务的 Sidecar拦截Inbound流量，执行治理动作。这就引入两个问题：
◎ 增加了两处延迟和可能的故障点；
◎ 多出来的这两跳对于访问性能、整体可靠性及整个系统的复杂度都带来了新的挑战。图1-10 服务网格访问路径变长
其中，后者本来就属于基础设施层面可维护性、可靠性的范畴，业界的几个产品都用各自的方式在保证。而前者引入的性能和资源损耗，网格提供商提供的方案一般是这样解决的：通过保证转发代理的轻量和高性能降低时延影响，尤其是考虑到后端实际使用的应用程序一般比代理更重，叠加代理并不会明显影响应用的访问性能；另外，对于这些高性能的代理，只要消耗足够的资源总能达到期望的性能，特别是云原生场景下服务的弹性特点使得服务实例的弹性扩展变得非常方便，通过扩展实例数量总是能得到期望的访问性能。
所以，对于考虑使用服务网格的用户来说，事情就会变成一个更简单的选择题：是否愿意花费额外的资源在这些基础设施上来换取开发、运维的灵活性、业务的非侵入性和扩展性等便利。相信，在这个计算资源越来越便宜、聪明的程序员越来越贵的时代，对于把程序员从机械的基础设施就可以搞定的繁杂事务中解放出来，使其专注于更能发挥聪明才智和产生巨大商业价值的业务开发上，我们很容易做出判断。
目前，华为、谷歌、亚马逊等云服务厂商将这种服务以云服务形态提供了出来，并和底层的基础设施相结合，提供了完整的服务治理解决方案。这对于广大应用开发者来说，更加方便和友好。1.4.2 服务网格选择Istio
在多种服务网格项目和产品中，最引人注目的是后来居上的 Istio，它有希望成为继Kubernetes之后的又一款重量级产品。
在本书码字快要完成时，Istio在 GitHub上已经收获了近两万个 Star（https：//timqian.com/star-history/＃istio/istio），这着实是个非常了不起的成绩，如图1-11所示。图1-11 Istio项目的Star进展
可以看到，Istio从2017年5月发布第1个版本0.1开始就被广泛关注。据Istio官方称，Istio 1.1解决了生产大规模集群的性能、资源利用率和可靠性问题，提供了众多生产中实际应用的新特性，已经达到企业级可用的标准。
首先，在控制面上，Istio作为一种全新的设计，在功能、形态、架构和扩展性上提供了远超服务网格的能力范围。它基于xDS协议提供了一套标准的控制面规范，向数据面传递服务信息和治理规则。Istio的早期版本使用Envoy V1版本的API，即Restful方式，其新版本使用Envoy V2版本的API，即gRPC协议。标准的控制面API解耦了控制面和数据面的绑定。Nginx的nginMesh、F5 Networks的Aspen Mesh等多种数据面代理支持Istio的控制面，甚至有些老牌微服务SDK也开始往Istio上集成，虽然其本身的功能定位和功能集合有些“不对齐”，但至少说明了Istio控制面的影响力和认同程度。
然后，在数据面的竞争上，Istio的标准数据面Envoy是由Lyft内部于2016年开发的，比 Linkerd更早。2016年9月，Envoy开源并发布了 1.0.0版本；2017年 9月，Envoy加入CNCF，成为第2个Service Mesh项目；2018年11月，Envoy从CNCF毕业，这标志着其趋于成熟。从开发语言上看，Envoy是使用C++开发的，其性能和资源占用比用Rust开发的 Linkerd Proxy 要更好，更能满足服务网格中对透明代理的轻量高性能要求；从能力上看，Envoy提供L3/L4过滤器、HTTP L7过滤器，支持HTTP/2、HTTP L7路由及gRPC、MongoDB、DynamoDB等协议，有服务发现、健康检查、高级LB、前端代理等能力，具有极好的可观察性、动态配置功能；从架构实现上看，Envoy是一个可高度定制化的程序，通过 Filter机制提供了高度扩展性，还支持热重启，其代码基于模块化编码，易于测试。除了在Istio中应用，Envoy在其他Service Mesh框架中也被广泛应用，渐渐成为Service Mesh的数据平面标准。
最后，在大厂的支持上，Istio 由谷歌和 IBM 共同推出，从应用场景的分析规划到本身的定位，从自身架构的设计到与周边生态的结合，都有着比较严密的论证。Istio项目在发起时已经确认了将云原生生态系统中的容器作为核心打包和运行时，将Kubernetes作为管理容器的编排系统，需要一个系统管理在容器平台上运行的服务之间的交互，包括控制访问、安全、运行数据收集等，而 Istio 正是为此而生的；另外，Istio 成为架构的默认部分，就像容器和Kubernetes已经成为云原生架构的默认部分一样。
云原生社区的定位与多个云厂商的规划也不谋而合。华为云已经在 2018 年 8 月率先在其容器服务CCE（Cloud Container Engine）中内置Istio；Google的GKE也在2018年12月宣布内置 Istio；越来越多的云厂商也已经选择将 Istio作为其容器平台的一部分提供给用户，即提供一套开箱即用的容器应用运行治理的全栈服务。正因为看到了 Istio 在技术和产品上的巨大潜力，各大厂商在社区的投入也在不断加大，其中包括Google、IBM、华为、VMware、思科、红帽等主流厂商。1.5 Istio与Kubernetes
Kubernetes是一款用于管理容器化工作负载和服务的可移植、可扩展的开源平台，拥有庞大、快速发展的生态系统，它面向基础设施，将计算、网络、存储等资源进行紧密整合，为容器提供最佳运行环境，并面向应用提供封装好的、易用的工作负载与服务编排接口，以及运维所需的资源规格、弹性、运行参数、调度等配置管理接口，是新一代的云原生基础设施平台。
从平台架构而言，Kubernetes的设计围绕平台化理念，强调插件化设计与易扩展性，这是它与其他同类系统的最大区别之一，保障了对各种不同客户应用场景的普遍适应性。另外，Kubernetes与其他容器编排系统的显著区别是Kubernetes并不把无状态化、微服务化等条件作为在其上可运行的工作负载的约束。
如今，容器技术已经进入产业落地期，而Kubernetes作为容器平台的标准已经得到了广泛应用。Kubernetes从2014年6月由Google宣布开源，到2015年7月发布1.0这个正式版本并进入CNCF基金会，再到2018年3月从CNCF基金会正式毕业，迅速成为容器编排领域的标准，是开源历史上发展最快的项目之一，如图1-12所示。图1-12 Kubernetes的发展历史1.5.1 Istio，Kubernetes的好帮手
从场景来看，Kubernetes已经提供了非常强大的应用负载的部署、升级、扩容等运行管理能力。Kubernetes 中的 Service 机制也已经可以做服务注册、服务发现和负载均衡，支持通过服务名访问到服务实例。
从微服务的工具集观点来看，Kubernetes本身是支持微服务的架构，在Pod中部署微服务很合适，也已经解决了微服务的互访互通问题，但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在Kubernetes的能力范围内。那么，如何提供一套从底层的负载部署运行到上层的服务访问治理端到端的解决方案？目前，最完美的答案就是在Kubernetes上叠加Istio这个好帮手，如图1-13所示。图1-13 在Kubernetes上叠加Istio这个好帮手
Kubernetes的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息，并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。但Kubernetes只提供了4层负载均衡能力，无法基于应用层的信息进行负载均衡，更不会提供应用层的流量管理，在服务运行管理上也只提供了基本的探针机制，并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。
Istio复用了Kubernetes Service的定义，在实现上进行了更细粒度的控制。Istio的服务发现就是从 Kube-apiserver中获取 Service和 Endpoint，然后将其转换成 Istio服务模型的 Service 和 ServiceInstance，但是其数据面组件不再是 Kube-proxy，而是在每个 Pod 里部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样，Proxy 的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理，如图 1-14 所示。通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。
总之，Istio和Kubernetes从设计理念、使用体验、系统架构甚至代码风格等小细节来看，关系都非常紧密，甚至有人认为 Istio 就是 Kubernetes团队开发的 Kubernetes可插拔的增强特性。图1-14 更细粒度的Proxy提供更多更细粒度的能力1.5.2 Kubernetes，Istio的好基座
Istio最大化地利用了Kubernetes这个基础设施，与之叠加在一起形成了一个更强大的用于进行服务运行和治理的基础设施，并提供了更透明的用户体验。
1.数据面
数据面Sidecar运行在Kubernetes的Pod里，作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时候感知不到Sidecar的存在。而基于Kubernetes的一个 Pod 多个容器的优秀设计使得部署运维对用户透明，用户甚至感知不到部署 Sidecar的过程。用户还是用原有的方式创建负载，通过 Istio 的自动注入服务，可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy，则不会有这样的便利。
2.统一服务发现
Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成，省去了再搭一个类似 Eureka 的注册中心的麻烦，更避免了在 Kubernetes 上运行时服务发现数据不一致的问题。
尽管 Istio 强调自己的可扩展性的重要性在于适配各种不同的平台，也可以对接其他服务发现机制，但在实际场景下，通过深入分析 Istio 几个版本的代码和设计，便可以发现其重要的能力都是基于Kubernetes进行构建的。
3.基于Kubernetes CRD描述规则
Istio的所有路由规则和控制策略都是通过 Kubernetes CRD实现的，因此各种规则策略对应的数据也被存储在 Kube-apiserver 中，不需要另外一个单独的 APIServer 和后端的配置管理。所以，可以说Istio的APIServer就是Kubernetes的APIServer，数据也自然地被存在了对应Kubernetes的etcd中。
Istio非常巧妙地应用了Kubernetes这个好基座，基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的，绝不再自己搞一套，避免了数据不一致和用户使用体验的问题。
如图1-15所示为Istio和Kubernetes架构的关系，可以看出，Istio不仅数据面Envoy跑在Kubernetes的Pod里，其控制面也运行在Kubernetes集群中，其控制面组件本身存在的形式也是Kubernetes Deployment和Service，基于Kubernetes扩展和构建。图1-15 Istio与Kubernetes架构的关系
如表1-2所示为Istio+Kubernetes的方案与将SDK开发的微服务部署在Kubernetes上的方案的比较。表1-2 两种方案的比较1.6 本章总结
如图1-16所示为Istio、微服务、容器与Kubernetes的关系。图1-16 Istio、微服务、容器与Kubernetes的关系
Kubernetes在容器编排领域已经成为无可争辩的事实标准；微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上匹配，这类服务在容器中的运行也正日益流行；随着Istio 的成熟和服务网格技术的流行，使用 Istio 进行服务治理的实践也越来越多，正成为服务治理的趋势；而 Istio 与 Kubernetes 的天然融合且基于 Kubernetes 构建，也补齐了Kubernetes的治理能力，提供了端到端的服务运行治理治理平台。这都使得Istio、微服务、容器及Kubernetes形成一个完美的闭环。
云原生应用采用 Kubernetes 构建应用编排能力，采用 Istio 构建服务治理能力，将逐渐成为企业技术转型的标准配置。第2章 Istio架构概述
前面的内容分别讲解了Istio是什么，以及Istio能做什么。本章将在此基础上进行Istio的架构概述，包括 Istio 的工作机制、服务模型和主要组件，为学习流量治理、策略与遥测、访问安全等内容做必要的知识储备。2.1 Istio的工作机制
图2-1展示了Istio的工作机制和架构，分为控制面和数据面两部分。可以看到，控制面主要包括Pilot、Mixer、Citadel等服务组件；数据面由伴随每个应用程序部署的代理程序Envoy组成，执行针对应用程序的治理逻辑。为了避免静态、刻板地描述组件，在介绍组件的功能前，我们先通过一个动态场景来了解图2-1中对象的工作机制，即观察frontend服务对 forecast 服务进行一次访问时，在 Istio 内部都发生了什么，以及 Istio 的各个组件是怎样参与其中的，分别做了哪些事情。
图2-1上带圆圈的数字代表在数据面上执行的若干重要动作。虽然从时序上来讲，控制面的配置在前，数据面执行在后，但为了便于理解，在下面介绍这些动作时以数据面上的数据流为入口，介绍数据面的功能，然后讲解涉及的控制面如何提供对应的支持，进而理解控制面上组件的对应功能。（1）自动注入：指在创建应用程序时自动注入 Sidecar代理。在 Kubernetes场景下创建 Pod时，Kube-apiserver调用管理面组件的 Sidecar-Injector服务，自动修改应用程序的描述信息并注入Sidecar。在真正创建Pod时，在创建业务容器的同时在Pod中创建Sidecar容器。图2-1 Istio的工作机制和架构（2）流量拦截：在 Pod 初始化时设置 iptables 规则，当有流量到来时，基于配置的iptables规则拦截业务容器的Inbound流量和Outbound流量到Sidecar上。应用程序感知不到Sidecar的存在，还以原本的方式进行互相访问。在图2-1中，流出frontend服务的流量会被 frontend服务侧的 Envoy拦截，而当流量到达forecast容器时，Inbound流量被forecast服务侧的Envoy拦截。（3）服务发现：服务发起方的 Envoy 调用管理面组件 Pilot 的服务发现接口获取目标服务的实例列表。在图 2-1 中，frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到forecast服务各个实例的地址，为访问做准备。（4）负载均衡：服务发起方的Envoy根据配置的负载均衡策略选择服务实例，并连接对应的实例地址。在图2-1中，数据面的各个Envoy从Pilot中获取forecast服务的负载均衡配置，并执行负载均衡动作。（5）流量治理：Envoy 从 Pilot 中获取配置的流量规则，在拦截到 Inbound 流量和Outbound 流量时执行治理逻辑。在图 2-1 中，frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则，并根据该流量治理规则将不同特征的流量分发到forecast服务的v1或v2版本。当然，这只是Istio流量治理的一个场景，更丰富的流量治理能力参照第3章。（6）访问安全：在服务间访问时通过双方的Envoy进行双向认证和通道加密，并基于服务的身份进行授权管理。在图2-1中，Pilot下发安全相关配置，在frontend服务和forecast服务的Envoy上自动加载证书和密钥来实现双向认证，其中的证书和密钥由另一个管理面组件Citadel维护。（7）服务遥测：在服务间通信时，通信双方的Envoy都会连接管
试读结束[说明：试读内容隐藏了图片]