作者：马若飞
出版社：人民邮电出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Istio实战指南试读：
前言
写作初衷2017年年初，我所在的公司开始对整个业务系统进行重构和微服务化，替换掉因业务发展而不堪重负的、运行了10年的庞大的单体应用。我有幸作为小组技术负责人，负责部分业务的微服务架构的设计和开发工作。
随着微服务迁移工作的深入，服务化过程中遇到的问题越来越多，痛点也越加明显。当我们的业务被拆分成若干个服务时，不可避免地要进行服务之间的交互，很多时候需要多个服务共同协作才能完成一个完整的业务流程。在这种情况下，服务间的通信问题也暴露得更加明显。我开始思考如何实现分布式系统的弹性设计，以及解决容错、监控等问题。
我偶然通过阅读“What's a service mesh? And why do I need one?”这篇文章接触到服务网格概念，并了解到它是解决微服务通信问题的好帮手。与此同时，Istio也发布了1.0版本。在仔细了解了Istio的整体技术架构后，我深深地被这种优雅的设计所折服，各组件职责清晰、松散耦合，数据平面可替换，Mixer的适配器模式又提供了强大的可扩展性。加之Google、IBM和Lyft的支持，我预感Istio会和Kubernetes一样，成为又一个明星级的产品。
服务网格是一个新颖的概念，Istio作为它的一个实现产品，诞生也不到两年的时间，网络上很难找到相关的学习资源，主要的学习资料就是Istio官方提供的文档。这份文档虽然十分详尽地介绍了Istio的方方面面，但语言较为晦涩，内容组织也不适合初学者。加之市面上有关这方面的图书很少，我个人又有写技术博客的习惯，这让我萌生了自己整理一份服务网格学习笔记的想法。
很巧，本书的责任编辑陈聪聪在ServiceMesher社区看到了我翻译的一些文章，于是联系到我，询问是否有兴趣出版一本有关服务网格的图书。在她的鼓励下，我毅然决然地把大部分业余时间都投入到了写作中，并经历了一个漫长而艰苦的创作过程。我乐于分享技术并从中体会分享的喜悦；然而图书写作和博客写作最大的不同就是收获喜悦的过程太过漫长了，好在经过不懈努力，在编辑的帮助下终于促成了本书的出版。
本书的定位是一本Istio入门图书，主要面向那些想了解服务网格，并通过学习把Istio服务网格集成在自己的微服务应用里的开发人员和运维人员。若读者对Kubernetes有一定的了解，会方便理解书中相关的概念。内容组织
本书的内容编排以实践为主，涵盖了Istio的主要特性。通过由浅入深的方式让读者能够循序渐进地掌握Istio的理论知识并付诸实践。
第1章和第2章是理论知识，通过分析微服务架构存在的问题来引出服务网格的起源，让读者能够很自然地理解其概念。接着对Istio的架构、功能特性等做了较为详细的介绍，为后续的实践打下基础。
第3章和第4章聚焦在开发环境的准备上。为了后续进行练习，需要安装Istio以及官方的示例应用。为照顾到初学者，详细地介绍了如何从零开始搭建Istio的开发环境，包括Go语言环境、Docker、Kubernetes等必要的开发工具。
第5～8章是全书的重点，也是实战演练的部分。读者可通过多种多样的实例来学习Istio的绝大多数功能，并体会Istio的架构设计特点。在每一章节的实例内容之前，特意添加了对实例中出现的各种理论、关键词、工具等概念的解释，方便初学者弥补可能缺失的知识点，更好地完成实例的练习。
第9章编排了一部分进阶内容，包括云平台的集成、高级流量控制以及调试和故障排除，方便有需要的读者更深入地了解这些知识。最后的附录介绍了安装选项、属性词汇表、表达式语言、适配器列表和istioctl命令，可作为手册参考。版本及配套资源
本书成稿时Istio官方推出了1.1版本，因此示例也基于1.1版本进行编写。本书的所有示例代码可以直接在Istio的安装包内找到，也可以从本书的配套资源中获取。感谢
写作是一个漫长而枯燥的过程，需要查阅大量的资料，反复地修改、推敲，没有毅力很难坚持下来。非常有幸能遇到出版本书的责任编辑陈聪聪，在她的鼓励和帮助下才促成了本书的出版，并且她在文字、内容编排等多个方面给予了我非常宝贵的建议。
感谢在写作过程中帮助过我的同事、朋友，特别感谢ServiceMesher社区，作为活跃的服务网格技术中文社区，在和创始人宋净超以及其他成员的交流中我获益良多。
最后要感谢我的家人，感谢我的妻子一直在默默地支持我的创作；感谢我的两个可爱的孩子——Mina和函宝。写作的过程中很少能陪伴在你们身边，以后我会弥补之前错过的时光。我爱你们。作者简介
马若飞，FreeWheel 主任软件工程师，ServiceMesher社区成员、译者。近15年的软件、互联网行业从业生涯，对分布式系统、微服务的设计和开发具有丰富的经验和深刻的理解。目前在FreeWheel负责微服务相关的架构设计和开发工作，热衷于技术的探索与分享。资源与支持
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。配套资源
本书提供如下资源：● 本书配套资源请到异步社区本书购买页处下载。
要获得以上配套资源，请在异步社区本书页面中点击，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。提交勘误
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。与我们联系
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。关于异步社区和异步图书“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。异步社区微信服务号第1章 服务网格
随着科技和互联网的发展，企业应用的规模不断扩大，系统的架构也从早期的单体应用逐渐演进到现在的微服务模式。随着微服务架构的普及和广泛应用，它已经成为分布式环境下非常流行的架构解决方案。然而，软件行业从来就没有“银弹”，微服务虽然解决了业务耦合、扩展性和灵活性等问题，但同时也引入了新的问题：服务间通信成为困扰开发人员的新难题。
在此背景下，服务网格（Service Mesh）技术诞生了。它的出现就是为了解决微服务架构中网络通信的难题，因此有些人把它称为下一代微服务。本章将简要地回溯软件架构的发展过程，并对微服务架构中面临的痛点做深入剖析，以便读者能体会到服务网格出现的背景和意义。然后本章会重点介绍服务网格的概念及其主要功能，并对目前市面上主流的服务网格产品做一个简要说明。1.1 服务端架构的发展——从单体应用到微服务1.1.1 单体应用
通常，一个应用的服务端的主要工作是执行业务逻辑，获取或更新数据并返回到客户端显示。在互联网发展的早期阶段，因为访问量小，业务也相对单一，所以Web应用的服务端通常把所有功能都打包在一起部署以节约成本，比如一个基于Java语言开发的应用，以war包形式部署在Web容器里，这就是常说的单体应用（Monolithic Application）。从软件工程的角度来看，单体应用是一个单一的软件结构，用户接口和数据访问代码都被整合在单一的程序单元里。而作为一个软件架构，单体应用被认为是非模块化的，这也是它的突出特点。
单体应用具有如下优点。● 开发简单。一般开发工具或IDE是为开发单体应用而设计的，开
发完即可使用，没有额外工作。● 易于测试。不需要额外的环境、配置等，本地就可以进行测试。● 易于部署。因为是单一的整体，所以直接将程序包部署在运行环
境即可。
图1-1展示了一个典型的单体应用，展示层（HTML+JavaScript）、业务逻辑和数据访问都耦合在一起。我们不得不承认，单体应用在软件架构的发展史上占有重要的地位。即便是今天，在简单的业务场景下它依然是一种不错的选择。然而，随着业务规模逐渐变大，单体应用的弊端便突显出来。图1-1 单体应用架构● 各个业务模块耦合严重，很难保证某一个模块的修改不影响其他
模块。● 部署问题。应用变得臃肿后部署本身就成为一种困难。另外，改
动任何一部分，都不得不重新构建和部署整个应用，这可能会中
断与改动无关的后台任务或者是数据库事务。● 扩展方式单一，只能通过水平扩展来提高整体的计算能力。但实
际上各业务模块对资源的需求并不平均，不能按需独立扩展会造
成资源的浪费。● 开发效率不高。因业务和前后端代码的耦合，开发团队可能需要
花费很多时间协调和集成。1.1.2 多层结构
为解决上面列举的单体应用架构的问题，以分而治之思想为基础的解决方案产生了，这就是多层结构（Multi-Tier Architecture）。一个应用常被分为3层：接口层、业务逻辑层和数据访问层。● 接口层。为客户端提供对应的访问接口。● 业务逻辑层。系统的主要功能和业务逻辑部分，对输入和输出的
数据进行业务处理。● 数据访问层。为业务层提供底层数据库的访问能力。
图1-2展示了一个多层结构的数据流图。用户发送请求，依次传递给接口层、业务层再到数据访问层，获取数据后再依次返回。多层结构的体系利用了高内聚、低耦合的思想，解决了单体应用混沌的形态，具有以下优点。● 降低了层与层之间的依赖关系，使原本的强依赖变成了松散耦
合。● 结构更加明确，也更易于复用。● 降低了开发难度，开发人员可以只关注其中的一层。● 当解决方案变更时，可以比较容易地替换某一层的实现，而不会
影响其他层。比如数据库由MySQL变成MongoDB后，只需要修
改数据访问层，其他层不受影响。图1-2 多层结构的数据流
在这一时期，解耦是多层结构要解决的主要任务，比如我们很熟悉的MVC模式。然而，分层也必然带来其他的缺点，比如性能损失（原本可以直接访问数据库的操作现在需要通过中间层执行）或者涉及多层的级联修改等。1.1.3 面向服务的架构
随着垂直应用（或子系统）越来越多，不同的应用之间不可避免地需要交互，于是面向服务的架构产生了，这就是我们通常所说的SOA（Service-Oriented Architecture）。它是指在分布式环境下，系统或者其组件可以在网络上通过通用协议调用另一个系统，使得多个系统彼此协作，它是令被调用系统成为调用者的服务。面向服务的架构被认为是一种演化，而不是革命。它延续了之前系统架构设计的最佳实践，把原本是数据孤岛的各个单体应用封装成服务，并通过标准的网络协议连接在一起，组成了更大的系统。
SOA架构中的各个子系统通过企业服务总线（Enterprise Service Bus，ESB）实现了松散耦合。ESB是构建SOA时所使用的关键技术，可以简单地理解为它是一个通信系统，为各个应用提供交互能力。在SOA体系中，它能够通过多种通信协议（如HTTP、RPC和SOAP等）连接并集成不同组件将其映射成服务。
SOA将不同系统模块封装成服务，以集中管理的方式提供系统之间的交互能力。通常具有如下特点。● 将子系统或者大块业务逻辑作为服务。● 服务之间松散耦合。● 服务可重用、可组合。● 中心化管理（ESB）。
图1-3展示了一个简单的SOA体系结构，不同的服务或者子系统通过ESB进行通信。图1-3 SOA体系结构1.1.4 微服务架构
有人认为微服务（Microservice）就是SOA的一种表现形式。如果从面向服务这个角度来讲，的确如此。两者在理念上有一些非常相似的特点，但它们之间依然有较大的不同。在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，它们共同构成了较大的应用。每个组件都被称为一个微服务，而每个微服务都在整体架构中执行着单独的任务或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，共同协作来完成一个完整、复杂的业务逻辑。
图1-4展示了一个简单的微服务应用。整个业务被拆分成几个不同的服务，客户端通过API网关发送请求，业务数据被拆分到不同的数据库，只能由对应的服务进行访问。图1-4 微服务架构
微服务架构具有如下特点。● 服务的粒度较小，一个大型复杂的系统由多个微服务组成。● 采用UNIX的设计哲学，某个服务只做一件事，是一种可以独立
开发和部署的无状态服务。● 通过服务实现组件化。不使用库（Library）而用服务来构建组件
以便于独立部署。● 微服务的开发团队小而内聚，可独立开发自己的业务，团队之间
没有依赖。● 去中心化的数据管理。每个服务有自己的数据存储。● 不受语言、平台的限制（现实中一个大型的微服务应用往往是一
个多语言开发的异构系统）。1.2 微服务架构的痛点
微服务相对于单体应用而言是一个巨大的进步，它将系统切分成若干个服务，使系统的复杂度降低，不同业务之间解耦并提高了可扩展性。另外，单个服务的复杂度大幅降低，这些服务由各自的团队负责开发和维护，高度内聚互不干涉，使得开发过程也变得更轻松。图1-5展示了单体应用和微服务应用的对比。图1-5 单体应用和微服务应用
但是，软件开发中从来就没有银弹。微服务在带来了一系列便利的同时，也伴随着新问题的出现。当一个大型的系统被拆分为几十个、上百个甚至更多的服务时，如何有效地管理服务，以及保证服务间的通信稳定可靠成为开发人员需要关注的新问题。
原本业务模块之间函数级别的调用方式变成了远程调用，单一的系统演变成了分布式系统。L Peter Deutsch等人提出的著名理论——分布式环境下的8个谬论，很好地总结了以微服务为代表的分布式系统在网络层面面临的问题。● 网络是可靠的。● 网络延迟是0。● 带宽是无限的。● 网络是安全的。● 网络拓扑结构从不改变。● 只有一个管理员。● 传输成本是0。● 网络是均匀而稳定的。
这些问题被定义为“谬论”，其本质是要告诫开发人员，在构建分布式系统的过程中不要忽视它们，应该想办法去解决问题。因此，稳定可靠的网络通信成为构建微服务系统的一大难题。试想一个大型的业务系统，需要对成百上千个微服务进行版本控制、监控和故障转移等一系列操作，并实现A/B测试、灰度发布、限流、熔断和访问控制等一系列与网络相关的功能，这是多么复杂的一件事情。开发和运维人员在转型到微服务架构时不得不面对这一新的挑战。1.3 服务网格的发展
为了解决微服务之间网络通信的问题，以应对这一全新的挑战，系统架构也进一步演化，最终催生了服务网格的出现。我们来回顾一下这一演进过程，以便读者能更好地理解服务网格的概念和存在的意义。1.3.1 耦合阶段
在微服务架构中，服务发现、熔断这样的弹性能力是架构重要的组成部分。在单体应用中，可以使用一个公共的组件统一实现或是嵌入业务逻辑中。而在微服务架构下，因为服务的分散粒度更小，所以它变得更加复杂。起初开发人员将诸如熔断（Circuit Breaker）这样的网络层功能和业务代码封装在一起，使服务具备了网络控制能力，如图1-6所示。图1-6 将网络功能和业务逻辑耦合在一起
这种方案虽然易于实现，但从设计角度来讲缺点也很明显。● 网络功能和业务逻辑耦合。● 每个服务都需要重复封装和实现这样的代码。● 管理困难。如果某个服务的负载均衡发生了变化，则调用它的相
关服务都需要更新变化。● 开发人员不能专注在业务逻辑上。1.3.2 封装公用库
一定有人会想，为什么不把服务发现处理、负载均衡、分布式追踪和安全通信等网络功能设计为一个公用库呢？这可以让应用与这些网络功能降低耦合，且更加灵活，提高了利用率及运维性，更重要的是开发人员只需要关注公用库，而不必自己实现这些功能，从而降低了开发人员的负担。图1-7展示了网络功能封装的情况。图1-7 网络功能被封装在库里
实际上，一些大的软件公司（如Twitter和Facebook）都提供了这样的控件来解决这一问题。但即便如此，它仍然有一些不足之处。● 这些库有较为陡峭的学习成本曲线，需要耗费一定的时间和人力
与现有系统集成，甚至需要修改现有代码去进行整合。● 通常这种库是通过特定语言实现的，缺乏多语言的支持，和现有
系统整合时会受到限制。● 公共库的管理和维护依然牵扯了开发人员的大量精力。
显然，把这些网络功能从服务中独立出来并单独部署才是更好的做法。它可以让工程师关注业务逻辑本身，而不必浪费时间在编写基础架构层的代码或者是管理三方库和框架上，如图1-8所示。图1-8 把网络库从业务服务中独立出来1.3.3 Sidecar模式
然而，这样的方案仍然不完美，它会导致很多问题的出现，比如跨语言问题、更新后的发布和维护等。许多实践者发现，更好的解决方案是把它作为一个代理——服务不会直接访问它的下游依赖方，而是通过这个透明的代理来处理所有的流量。
这就是Sidecar代理模式，也被翻译为边车代理，如图1-9所示。它是一个伴随服务的辅助进程，为服务提供额外的网络特性。可以理解为Sidecar就是服务的网络代理，服务所有的对外通信都由这个代理完成。Sidecar的出现要追溯到几年前，2013年，Airbnb开发了Synapse和Nerve，这是对Sidecar的一种开源实现。2014年，Netflix推出了Prana，这使得由不同语言实现的服务进行通信成为可能。图1-9 Sidecar和业务服务
以Sidecar的方式进行网络代理，对应用服务没有侵入性，不会受到应用服务的语言和技术限制，而且可以做到控制层和业务逻辑的分开升级和部署。Sidecar在逻辑上和应用服务部署在同一个结点（如Pod）中，它们拥有相同的生命周期。每个服务都配备了一个Sidecar代理。Sidecar可以迅速方便地为应用服务提供扩展，而不需要应用服务的改造。它的主要功能如下。● Sidecar可以帮助服务注册到相应的服务发现系统，并对服务做
相关的健康检查。如果服务不健康，则可以从服务发现系统中移
除服务实例。● 当应用服务要调用外部服务时，Sidecar可以帮助从服务发现中
找到相应外部服务的地址，然后进行服务路由。● Sidecar接管了进出的流量，这样我们就可以进行相应的日志监
视、调用链跟踪、流控熔断等操作，这些都可以在Sidecar中实
现。● 服务控制系统可以通过Sidecar来控制应用服务，如流控、下线
等。
于是，应用服务终于可以做到专注于业务逻辑。1.3.4 服务网格出现
如果把Sidecar代理应用于一个大型的系统，其中包括多个相互通信的服务，那么每个服务都将有一个配套的Sidecar代理，服务之间通过Sidecar代理进行通信，最终得到一个如图1-10所示的网络拓扑结构，这就是服务网格。图1-10 服务网格
最后，总结一下微服务网络通信功能的演进过程。（1）最初，服务进行通信时，因为接收速度不一致，所以需要加入流量控制等功能（服务发现和熔断）。（2）流控功能和业务耦合需要被标准化和复用，它们被封装在公共库里。（3）多语言多平台下，为避免浪费时间来开发和管理这些公共库，应将网络功能下沉并独立出来，和业务服务分离。（4）分离的通信服务发展成为Sidecar模式。（5）Sidecar模式应用于多服务的系统，服务之间相互连接形成了网状拓扑结构，最终演变成了服务网格。1.4 什么是服务网格1.4.1 基本概念
服务网格（Service Mesh）这一名词在2016年9月由Buoyant公司的CEO William Morgan首先提出，并对其做了如下定义。
服务网格是一个处理服务通信的专门的基础设施层。它的职责是为构建复杂的云原生应用传递可靠的网络请求。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。
这段话有点晦涩难懂，但只要抓住下面几个关键点就能理解：基础设施、服务间通信、请求分发、云原生应用、网络代理和对应用服务透明。这些关键词清楚地对服务网格做出了解释。● 服务网格是什么（基础架构、网络代理）。● 主要功能（请求分发、发送）。● 应用的场景（云原生应用）。● 特点（透明）。
我个人对服务网格的定义是，服务网格是用来处理服务间通信的基础设施。可以说，服务网格就是Sidecar的网络拓扑形态，Mesh这个词也由此而来。
服务网格的出现解决了微服务框架中的痛点，使开发人员专注于业务本身。同时，将服务通信及相关管控功能从业务程序中分离到基础设施层。在云原生应用中，面对数百个甚至更多的服务，单个请求经由服务拓扑的路径可能会非常复杂，单独进行网络通信处理非常有必要，否则很难对整个应用的通信情况进行管理、监控和追踪。而这正是服务网格的意义所在。1.4.2 服务网格的功能
那么服务网格到底能做什么呢？可以不夸张地说，作为微服务架构中负责网络通信的基础设施，服务网格具有网络处理的大多数功能。下面列举了一些主要的功能。● 动态路由，可以通过配置路由规则来动态确定要请求的服务。请
求需要被路由到生产环境还是预演（Staging）环境？路由到本
地还是云？是测试版本还是运行版本？所有这些路由规则都是可
以动态配置的，而且能够应用到全部请求或者仅仅针对一部分请
求。● 故障注入。Netflix有一个非常著名的故障测试系统Chaos Monkey，
它会故意切断不同范围的网络环境来测试服务的容错能力。在服
务网格中我们可以通过故障注入特性模拟基本的网络传输问题来
验证系统的健壮性。● 熔断。生产环境中经常会有各种问题导致服务中断，这就需要系
统有检测服务并且快速移除问题服务的能力。熔断可以通过服务
降级来终止潜在的关联性错误。● 安全。微服务环境中，服务间通信变得更加复杂，如何保证这些
通信是在安全、授权的情况下进行的就非常重要了。通过在服务
网格上实现安全机制（如TLS加解密和授权），不但可以在不同
的服务上对其进行重用，而且很容易在整个基础设施层更新安全
机制，甚至无须对系统做任何操作。● 多语言支持。作为独立运行的透明代理，服务网格支持多语言的
异构系统。● 多协议支持。同多语言支持一样，实现多协议支持也非常容易。● 指标和分布式追踪。服务网格对整个基础设施层的可见性使得它
有能力对网络通信进行全面的检测，还可以收集指标和日志，并
交由后端设施进行可视化展示。
概括起来，服务网格主要具有如下4个主要的特性。● 可见性（Visibility）：运行时指标遥测、分布式跟踪。● 可管理性（Manage Ability）：服务发现、负载均衡、运行时动态
路由。● 健壮性（Resilience）：超时、重试、熔断等弹性能力。● 安全性（Security）：服务间访问控制、TLS加密通信。1.5 服务网格产品介绍1.5.1 Linkerd
2016年初，前Twitter的两位工程师William Morgan和Oliver Gould组建了一个小的创业公司Buoyant，开发出了Linkerd并在GitHub上发布了0.0.7版本。这是业界公认的第一个Service Mesh。2017年年初Linkerd加入CNCF，同年4月1.0版本发布。同时，那篇著名的博客“What’s a service mesh? And why do I need one?”在Buoyant网站发布。
Linkerd使用Scala语言编写，底层基于Twitter的Finagle库。官方对Linkerd的定义是，一个开源的网络代理以服务网格的方式进行部署，专注于微服务通信的管理、控制和监控。它的功能特性有负载均衡、熔断、服务发现、动态路由、重试和超时等。1.5.2 Envoy
2016年9月，Lyft公司的Matt Klein宣布Envoy在GitHub开源并发布了1.0.0版本。2017年Envoy加入CNCF成为第二个服务网格项目，并于2018年底孵化毕业。Envoy是一个高性能的C++语言实现的分布式代理，它也是一个通信总线。Envoy基于对Nginx、HAProxy、硬件负载均衡器和云负载均衡器等解决方案的了解，与每个应用服务一起运行，并以与平台无关的方式提供公共的网络特性。
Envoy具有以下功能特性。● 过程外架构：Envoy是一个自包含的高性能服务器，内存占用很
小，可以与任何应用程序语言或框架一起运行。● HTTP/2和gRPC支持：Envoy对HTTP/2和gRPC的传入和传出连
接都提供支持，它是一个透明的HTTP/1.1到HTTP/2的代理。● 负载均衡：支持先进的负载均衡能力，包括自动重试、断流、速
率限制、请求镜像和区域本地负载均衡等。● API配置管理：Envoy为动态管理其配置提供了健壮的API。● 可视化：L7 流量的深度可观测性，分布式跟踪的本地支持，
MongoDB 和DynamoDB数据层面的支持。
Envoy已经被印证性能优秀而稳定，既可作为独立的代理运行，也可以作为服务网格中的Sidecar代理和业务服务一起运行，负责网络通信。大量的厂商都在自己的生产环境中使用了Envoy，比如腾讯、Airbnb、Booking、DigitalOcean和eBay等。目前Envoy已经从CNCF项目中毕业，作为数据平面，以Sidecar代理的形式存在于Istio架构体系中。1.5.3 Istio
2017年5月Istio的0.1版本发布，这标志着服务网格第二代产品的诞生，2018年7月Istio又发布了1.0版本。Istio是Google、IBM和Lyft联合发布的产品，靠着这3家公司的强大支持，它很可能成为继Kubernetes之后的另一个重量级产品。在0.1版本发布的时候各个厂商就开始积极响应，Envoy成为Istio默认的数据平面，Linkerd、Nginmesh也放弃了竞争，选择与其集成。
可以把Istio理解为一个微服务的开放平台，它提供了统一的方式去连接、管理和保护微服务。它为微服务之间提供了管理流量、实施访问策略、收集数据等方面的功能，而所有这些功能都不需要修改原有的业务服务就能实现。有了Istio，就几乎可以再需要其他的微服务框架，也不需要自己去实现服务治理，只要客户端和服务端互联互通，把网络层委托给Istio，它就能帮助完成这一系列的功能。下面列举了Istio的一些主要的功能。● 对HTTP、gRPC、WebSocket和TCP流量的自动负载均衡。● 通过路由规则、重试、故障转移和故障注入等功能实现细粒度的
流量控制。● 插件式的策略层以及配置API支持访问控制、速率限制和配额请
求。● 对集群的所有进出流量进行测量、记录并追踪。● 身份验证和授权保证服务间通信的安全。1.5.4 其他1．Conduit
2017年底，Buoyant公司又发布了一款更加轻量级的服务网格产品——Conduit，它基于Rust语言实现。Conduit的整体架构和Istio类似，借鉴了Istio数据平面 + 控制平面的设计。选择Rust 编程语言来实现数据平面是为达成Conduit宣称的更轻、更快和超低的资源占用。目前Conduit已经合并入了Linkerd 2.0产品线，它的特点就是支持Kubernetes，并且超级轻量化。2．NginMesh
顾名思义，NginMesh是Nginx开发的服务网格产品，2017年9月宣布加入Istio网络工作组，作为Istio平台中的负载平衡和服务代理，并部署为Sidecar代理与Istio集成，以便通过标准、可靠和安全的方式促进服务之间的通信。
Nginx提供了一个占用空间小且高性能的代理，具有先进的负载平衡算法、缓存、SSL终止和API网关可扩展性、Lua和nginScript的可写性，以及带有粒度访问控制的各种安全特性。但从目前的情况看，这个项目处于不活跃的状态，应该是趋于流产。3．SOFAMesh
SOFAMesh由蚂蚁金服发起，控制面板克隆了Istio的开源库并进行了符合自身要求的改进，MOSN是基于Golang开发的全新数据面板，用以替换Envoy。
SOFAMesh除了具有服务网格的基本功能外，还有一些自身的特色。● 多协议支持：由于公司内部服务和协议的多样化，因此MOSN实
现了多协议支持，同时提供了自定义协议以方便扩展。● 性能：为满足大流量的需要，MOSN在I/O、协议、内存、协
程、网络处理等多方面进行了优化，保证了生产环境的需求。● 安全性：支持mTLS、双向链路加密等。
除上面提到的这些产品外，还有一些相对小众的项目，就不一一介绍了。1.6 小结
本章主要讲述了服务网格的基本概念。我们简单回溯了服务端架构的发展，阐述了微服务相对单体应用的巨大进步和优势。但同时也了解到，随着服务的拆分和细化，服务间网络通信成为新的痛点，而这也正是服务网格要解决的主要问题和存在的意义。
服务网格是一个负责微服务之间网络通信的基础设施层，提供了管理、控制和监控网络通信的功能，本质上是Sidecar模式的网络拓扑形态。
最后对目前市面上几款主要的服务网格产品进行了简要介绍。第 2 章将正式开始介绍本书的主角Istio。第2章 Istio入门2.1 什么是Istio
通过第1章的介绍，相信读者对服务网格已经有了初步的认识。作为服务网格的实现产品，Istio一经推出就备受瞩目，成为各大厂商和开发者争相追逐的“香馍馍”。我个人认为Istio会成为继Kubernetes之后的又一个明星级产品。Istio的官方网站这样定义自己。
它是一个完全开源的服务网格，以透明层的方式构建在现有分布式应用中。它也是一个提供了各种API的平台，可以与任何日志平台、监控系统或策略系统集成。Istio的多样化特性可以让你高效地运行分布式微服务架构，并提供一种统一的方式来保护、连接和监控微服务。
从上面的定义中可以了解到，Istio为微服务应用提供了一个完整的解决方案，可以以统一的方式去检测和管理微服务。同时，它还提供了管理流量、实施访问策略、收集数据等功能，而所有这些功能都对业务代码透明，即不需要修改业务代码就能实现。
有了Istio，就几乎可以不需要其他的微服务框架，也不需要自己去实现服务治理等功能，只要把网络层委托给Istio，它就能帮助完成这一系列的功能。简单来说，Istio就是一个提供了服务治理能力的服务网格。2.2 Istio的架构
对服务网格来讲，业务代码无侵入和网络层的全权代理是其重要的优势。我们来了解一下Istio的架构，看一看它是如何做到这两点的，并了解架构中的各个组件是如何协同工作并完成网络层功能的。
Istio的架构从逻辑上分成数据平面（Data Plane）和控制平面（Control Plane）。是否觉得似曾相识？没错，Kubernetes的架构也具有相似的结构，分为控制节点和计算节点。毫无疑问，这样的设计可以很好地解耦各个功能组件。● 数据平面：由一组和业务服务成对出现的Sidecar代理（Envoy）
构成，它的主要功能是接管服务的进出流量，传递并控制服务和
Mixer组件的所有网络通信（Mixer是一个策略和遥测数据的收集
器，稍后会介绍）。● 控制平面：主要包括了Pilot、Mixer、Citadel和Galley共4个组件，
主要功能是通过配置和管理Sidecar代理来进行流量控制，并配
置Mixer去执行策略和收集遥测数据（Telemetry）。
图2-1展示了由这些组件组成的Istio架构。图2-1 Istio架构
从Istio的架构中可以看出，Istio追求尽可能的透明，通过各种解耦设计让系统对内对外都没有依赖。同时，它还提供了高度的扩展性。Istio认为随着应用的增长和服务的增多，扩展策略系统是最主要的需求，因此它被设计为以增量的方式进行扩展。可移植也是Istio在设计中充分考虑的因素，它被设计为支持多种平台，以便服务可以被方便地迁移到不同的云环境中（在撰写本书的过程中，Istio仍然深度依赖于Kubernetes平台）。
通过数据平面和控制平面的分离，各个组件都成为插件，这种开放和包容的设计思路相当具有前瞻性，我想这也就是其他服务网格产品都放弃了和它竞争而选择合作的重要原因。
下面对架构中的各组件做进一步介绍。2.3 Istio的核心控件2.3.1 Envoy
从2.2节的架构图可以看出，Istio的数据平面就是指代理。Istio选择Envoy作为Sidecar代理，Envoy本质上是一个为面向服务的架构而设计的7层代理和通信总线。Envoy基于C++11开发而成，性能出色。除了具有强大的网络控制能力外，Envoy还可以将流量行为和数据提取出来发送给Mixer组件，用以进行监控。
Envoy在网络控制方面的主要功能如下。● HTTP 7层路由。● 支持gRPC、HTTP/2。● 服务发现和动态配置。● 健康检查。● 高级负载均衡。
我们知道，在Kubernetes环境中，同一个Pod内的不同容器间共享网络栈，这一特性使得Sidecar可以接管进出这些容器的网络流量，这就是Sidecar模式的实现基础。Envoy是目前Istio默认的数据平面，实际上因为Istio灵活的架构，完全可以选择其他兼容的产品作为Sidecar。目前很多服务网格产品都可以作为Istio的数据平面并提供集成。2.3.2 Pilot
Pilot 是Istio实现流量管理的核心组件，它主要的作用是配置和管理Envoy代理。比如可以为代理之间设置特定的流量规则，或者配置超时、重试、熔断这样的弹性能力。Pilot会将控制流量行为的路由规则转换为Envoy的配置，并在运行时将它们广播到Envoy。另外，Pilot还能够把服务发现机制抽象出来并转换成API分发给Envoy，使得后者具有服务发现的能力。
简单来说，Pilot的主要任务有两个。● 从平台（如Kubernetes）获取服务信息，完成服务发现。● 获取Istio的各项配置，转换成Envoy代理可读的格式并分发。
图2-2展示了Pilot架构。Pilot维护了一套独立于平台的服务规则，并提供了一个平台适配器，以便接入各种不同的平台。Rules API对运维人员开放，使得他们可以设置想要的流量规则，Pilot会把这些配置好的规则通过Envoy API分发给Envoy代理，以使其执行指定的规则。图2-2 Pilot架构
Pilot还公开了用于服务发现并且可以动态更新负载均衡和路由表的API。2.3.3 Mixer
Mixer的主要功能是提供策略控制，并从Envoy代理收集遥测数据。每次网络通信时Envoy代理都会向Mixer发出预检要求，用来检测调用者的合法性。调用之后Envoy代理会发送遥测数据供Mixer收集。一般情况下Sidecar代理可以缓存这些数据，不需要频繁地调用Mixer。
适配器是Mixer的重要组成部分，它本质上是一个插件模型，每个插件叫作适配器。这项特性使得Mixer可以接入几乎任意的（只要定义好接口）后端基础设施。比如可以选择接入不同的日志收集器、监控工具和授权工具等；可以在运行时切换不同的适配器或者是打开（关闭）它们；还可以自定义适配器以满足特定需求。适配器极大地提高了Mixer的扩展性，它让Istio的功能拥有了更多可能性。图2-3展示了Mixer的架构图并展示了它和Envoy的交互方式。图2-3 Mixer架构2.3.4 Citadel
Citadel是与安全相关的组件，主要负责密钥和证书的管理。它可以提供服务间和终端用户的身份认证，还可以加密服务网格中的流量。在后面介绍安全主题的第8章中，我们会详细说明它是如何和其他组件协同工作的。2.3.5 Galley
在2019年3月份发布的1.1版本中，Galley作为一个独立的组件被添加到了架构当中（在此之前的版本中Galley并未独立出现），它现在是Istio主要的配置管理组件，负责配置的获取、处理和分发。Galley使用了一种叫作MCP（Mesh Configuration Protocol，网格配置协议）的协议与其他组件进行通信。2.4 Istio的主要功能
下面详细地介绍一下Istio的4个主要功能和实现原理。2.4.1 流量管理
第1章介绍过，微服务应用最大的痛点就是处理服务间的通信，而这一问题的核心其实就是流量管理。首先来看一看传统的微服务应用在没有服务网格介入的情况下，如何完成诸如金丝雀发布这样的动态路由。假设不借助任何现成的第三方框架，一个简单的实现方法是，在服务间添加一个负载均衡（如Nginx）做代理，通过修改配置的权重来分配流量。这种方式将对流量的管理和基础设施（云服务器、虚拟机、实体机等）绑定在了一起，难以维护。
而使用Istio就可以轻松地实现各种维度的流量控制。图2-4展示了两种不同的金丝雀发布策略。第一种是根据权重把5%的流量路由给新版本；第二种是根据请求的头信息User-Agent把使用iPhone的用户流量路由到新版本。图2-4 Istio的流量管理
Istio的流量管理是通过Pilot和Envoy这两个组件实现的，将流量和基础设施进行了解耦。Pilot负责配置规则，并把规则分发到Envoy代理去实施；而Envoy按照规则执行各种流量管理的功能，比如动态请求路由，超时、重试和熔断，还可以通过故障注入来测试服务之间的容错能力。下面对这些具体的功能进行逐一介绍。1．请求路由
Istio为了控制服务请求，引入了服务版本（Version）的概念，可以通过版本这一标签将服务进行区分。版本的设置是非常灵活的，可以根据服务的迭代编号进行定义（如v1、v2版本）；也可以根据部署环境进行定义（如Dev、Staging和Production）；或者是自定义任何用于区分服务的标记。通过版本标签，Istio就可以定义灵活的路由规则以控制流量，上面提到的金丝雀发布这类应用场景就很容易实现了。
图2-5展示了使用服务版本实现路由分配的例子。服务版本定义了版本号（v1.5、v2.0-alpha）和环境（us-prod、us-staging）两种信息。服务B包含了4个Pod，其中3个是部署在生产环境的v1.5版本，而Pod4是部署在预生产环境的v2.0-alpha版本。运维人员根据服务版本指定路由规则，通过Pilot同步给Envoy代理，使得99%的流量流向v1.5版本的生产环境，而1%的流量进入v2.0-alpha版本的预生产环境。图2-5 服务版本控制2．入口网关（Ingress）和出口网关（Egress）
服务间通信是通过Envoy代理进行的。同样，我们也可以在整个系统的入口和出口处部署代理，使得所有流入和流出的流量都由代理进行转发，而这两个负责入口和出口的代理就叫作入口网关和出口网关。它们相当于整个微服务应用的边界代理，把守着进入和流出服务网格的流量。图2-6展示了Ingress和Egress在请求流中的位置，通过设置Envoy代理，出入服务网格的流量也得到了控制。图2-6 请求流中的Ingress和Egress3．服务发现和负载均衡
服务发现的前提条件是具有服务注册的能力。目前Kubernetes这类容器编排平台也提供了服务注册的能力。Istio基于平台实现服务发现和负载均衡时，需要通过Pilot和Envoy协作完成，如图2-7所示。Pilot组件会从平台获取服务的注册信息，并提供服务发现的接口，Envoy获得这些信息并更新到自己的负载均衡池。Envoy会定期地对池中的实例进行健康检查，剔除离线的实例，保证服务信息的实时性。图2-7 服务发现和负载均衡4．故障处理
Istio的故障处理都由Envoy代理完成。Envoy提供了一整套现成的故障处理机制，比如超时、重试、限流和熔断等。这些功能都能够以规则的形式进行动态配置，并且执行运行时修改。这使得服务具有更好的容错能力和弹性，并保证服务的稳定性。5．故障注入
简单来说，故障注入就是在系统中人为地设置一些故障，来测试系统的稳定性和系统恢复的能力。比如为某服务设置一个延迟，使其长时间无响应，然后检测调用方是否能处理这种超时问题而自身不受影响（如及时终止对故障发生方的调用，避免自己受到影响且使故障扩展）。
Isito支持注入两种类型的故障：延迟和中断。延迟是模拟网络延迟或服务过载的情况；中断是模拟上游服务崩溃的情况，表现为HTTP的错误码和TCP连接失败。2.4.2 策略和遥测1．策略
在微服务应用中，除了流量管理以外，常常还需要进行一些额外的控制，比如限流（对调用频率、速率进行限制）、设置白名单和黑名单等。
Istio中的策略控制是依靠Mixer完成的。Envoy代理在每次网络请求时，都会调用Mixer进行预先检查，确定是否满足对应的策略。同时，Mixer又可以根据这些来自流量的数据，进行指标数据的采集和汇总，这就是遥测功能。2．遥测（Telemetry）
遥测是工业上常用的一种技术，它是指从远程设备中收集数据，并传输到接收设备进行监测。在软件开发中，遥测的含义引申为对各种指标（metric）数据进行收集，并监控、分析这些指标，比如我们经常听到的BI数据分析。
Mixer的一大主要功能就是遥测。前面已经说过，Envoy代理会发送数据给Mixer，这就使得Mixer具有了数据收集的能力。在本章2.3节对Mixer的介绍中读者已经了解到Mixer的插件模型，也就是适配器。Mixer可以接入不同的后端设施作为适配器，来处理收集到的指标数据，比如日志分析系统、监控系统等。2.4.3 可视化
在微服务应用越来越复杂的情况下，对整个系统的状态进行监控和追踪变得尤为重要。试想如果一个包含上百个服务的系统发生了故障却无法准确定位问题的根源，或者系统压力已经到了承受的临界值而运维人员却浑然不知，这是多么可怕的事情。没有完备的、可观察的监控系统就无法保障系统的稳定性。
Istio可以很方便地和各种监控、追踪工具集成，以便我们以可视化的方式（网页）直观地查看整个系统的运行状态。比如可以集成Prometheus来进行指标数据的收集，然后将收集的数据放在Grafana监控工具中展示；还可以集成Jaeger作为追踪系统，帮助我们对请求的调用链进行跟踪，在故障发生时分析出现问题的根源；或者将请求日志记录到Kibana系统，以图表的方式进行数据分析。
以上提到的这些可视化工具都会在第7章被集成到Istio，并得到详细的介绍。2.4.4 安全
Istio 中的安全架构是由多个组件协同完成的。Citadel是负责安全的主要组件，用于密钥和证书的管理；Pilot会将授权策略等信息分发给Envoy代理；Envoy根据策略实现服务间的安全通信；Mixer负责管理授权等工作。图2-8展示了Istio的安全架构和运作流程。图2-8 Istio安全架构1．认证
Istio提供如下两种类型的身份认证。● 传输认证：也叫作服务到服务认证。这种方式的认证是通过双向
TLS（mTLS）来实现的，即客户端和服务端（或者是调用者和
被调用者）都要验证彼此的合法性。● 来源认证：也叫作最终用户认证，用于验证终端用户或设备。
Istio使用目前业界流行的JWT（JSON Web Token）作为实现方
案（在配置项上Istio提供了扩展性，但在撰写本书时仍然只支持
JWT）。
这两种认证的工作原理类似，都是将来自平台的认证策略存储起来，然后通过Pilot分发给Envoy代理，如图2-9所示。图2-9 认证架构2．授权
Istio的授权功能沿用了Kubernetes中的授权方式：RBAC（Role-Based Access Control，基于角色的访问控制）。它可以为网格中的服务提供不同级别的访问控制。比如命名空间级别、服务级别和方法级别。
图2-10显示了授权的工作方式。运维人员编写授权策略的清单文件并将其部署到平台（Kubernetes）。Pilot组件会获取策略信息并将其保存到自己的配置存储中，同时监听授权策略的变更情况，以便及时更新。然后Pilot会把授权信息分发给Envoy代理。Envoy在请求到达的时候，评估当前的请求是否合法并作出相应的返回。图2-10 授权架构
与安全相关的配置涉及很多细节，我们会在后面的练习章节有针对性地进行具体介绍，以便读者可以通过演练加深理解。2.5 小结
本章主要介绍了Istio的理论知识。Istio作为一个开源的服务网格产品，提供了统一的方式去管理流量、设置安全和监控等服务治理的能力。
Istio的架构分为数据平面和控制平面，这种优雅的设计使得各个组件充分解耦，各司其职，这就是很多人将它称为第二代服务网格产品的原因。数据平面即Envoy代理，负责流量的接管；控制平面包含了Pilot、Mixer、Citadel和Galley，它们分别负责流量控制、策略控制、安全加固和数据收集。通过这些组件的协同工作，Istio顺利地完成了流量管理、策略和遥测、可视化和安全这4大功能。
第3章将进入实践阶段，搭建Istio的开发环境并完成它的安装和部署。第3章 Istio的安装和部署3.1 准备工作
在正式安装Istio之前，需要先做一些准备工作。本章将介绍如何从零开始搭建一个必要的开发环境。如果读者的环境已经搭建完成了，可以跳过这一章。3.1.1 安装Go语言
Istio是使用Go语言实现的，因此为构建它我们需要一个Go语言开发环境。可以按照下面的步骤去安装。在编写本书期间，Go语言的版本已经到了1.11.x，Istio的最新版本也是基于1.11版本编译的。1．系统要求
Go语言对系统的要求如表3-1所示。在撰写本书时最新的稳定版本为1.11.4，我们就以它作为安装版本。表3-1 Go语言系统版本要求系统版本要求LinuxLinux 2.6.23或更高MacmacOS 10.10或更高WindowsWindows 7或更高
注意，因Windows系统在环境搭建和开发中局限性比较大，本书不做介绍，只针对Linux和Mac系统进行讲解。Windows用户可使用虚拟机进行学习。2．Linux系统下的安装
Linux用户可以下载安装压缩包（如无特殊要求，选择最新的稳定版本）。图3-1是Go语言安装包的下载页面。图3-1 Go语言安装包下载页面
下载后可以通过下面的命令解压安装。$ tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz
如果是Ubuntu系统，也可以直接通过apt-get来安装。$ sudo apt-get install golang-go3．macOS系统下的安装
和Linux类似，Mac用户也可以从上面的下载链接中选择适合macOS的pkg包，比如当前的最新稳定版本go1.11.5.darwin-
试读结束[说明：试读内容隐藏了图片]