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 的方方面面，但语言较为晦涩，内容组织也不适合初学者。今天这本《Istio实战指南》恰好满足了初学者的需求。

Istio实战指南

01 什么是服务网格

什么是服务网格？简单来说，就是在微服务架构下管理服务间网络通信的基础设施。为了让大家更容易理解，我们用现实中的社交网络来进行类比。

把时间退回到现代科技出现之前。那时候人和人之间如果需要沟通和交流，可能就只能亲自登门拜访了，以面对面的方式建立联系。后来出现了书信，这是通讯的一大进步，至少为了说几句话，我不用亲自跑一趟了。但书信的时效性还是太低，于是就出现了电话。这下沟通的时效性问题也解决了，只要有电话网络覆盖的地方，随时都可以通过电话进行交流。但是电话仍然有局限性，就是它只能是点对点的沟通，如果我想和三五个好友一起聊天，就没法实现了。最终，社交网络的出现解决了这个问题。

无论是以前IM工具的群组功能，还是Facebook、人人网这样的SNS网站，再到现在的朋友圈，都可以认为是不同形态的社交网络。我们可以随时随地不受限制的和联系人进行一对一、多对多的沟通。那么社交网络和服务网格有哪些相似性呢？

首先，社交网络中出现的主体是联系人，这就好像服务网格中的主体是一个个的微服务。联系人之间是通过注册在社交网络的账号进行交互的，包括消息的发送和接收。这个账号的载体可以是电脑或者手机。这就好像网格里的Sidecar代理，服务间的通信都由它们完成。它们就像是微服务的账号和手机一样，负责与不同的联系人（微服务）进行沟通。

如果说服务网格是Sidecar代理组成的网络拓扑，那么人际关系就是社交网络的拓扑。最后，社交网络的最终效果是使得人与人之间无阻碍的沟通，使人和地域、时间解耦；类似的，服务网格最终的目的是使得微服务（即业务）和网络通信功能解耦。

相信现在你已经大致了解了服务网格的基本概念，本质上它将网络通信下沉到基础设施层，让微服务只需要关注业务本身；就好像社交网络将人际关系的网络拓扑抽取出来，你只需要关注沟通的内容本身，而不需要关心沟通的方式。

02 什么是Istio

作为服务网格的实现产品，Istio一经推出就备受瞩目，成为各大厂商和开发者争相追逐的“香馍馍”。我个人认为Istio会成为继Kubernetes之后的又一个明星级产品。Istio的官方网站这样定义自己。

它是一个完全开源的服务网格，以透明层的方式构建在现有分布式应用中。它也是一个提供了各种API的平台，可以与任何日志平台、监控系统或策略系统集成。Istio的多样化特性可以让你高效地运行分布式微服务架构，并提供一种统一的方式来保护、连接和监控微服务。

从上面的定义中可以了解到，Istio为微服务应用提供了一个完整的解决方案，可以以统一的方式去检测和管理微服务。同时，它还提供了管理流量、实施访问策略、收集数据等功能，而所有这些功能都对业务代码透明，即不需要修改业务代码就能实现。

有了Istio，就几乎可以不需要其他的微服务框架，也不需要自己去实现服务治理等功能，只要把网络层委托给Istio，它就能帮助完成这一系列的功能。简单来说，Istio就是一个提供了服务治理能力的服务网格。

03 Istio的架构

对服务网格来讲，业务代码无侵入和网络层的全权代理是其重要的优势。我们来了解一下Istio的架构，看一看它是如何做到这两点的，并了解架构中的各个组件是如何协同工作并完成网络层功能的。

Istio的架构从逻辑上分成数据平面（Data Plane）和控制平面（Control Plane）。是否觉得似曾相识？没错，Kubernetes的架构也具有相似的结构，分为控制节点和计算节点。毫无疑问，这样的设计可以很好地解耦各个功能组件。

• 数据平面：由一组和业务服务成对出现的Sidecar代理（Envoy）构成，它的主要功能是接管服务的进出流量，传递并控制服务和Mixer组件的所有网络通信（Mixer是一个策略和遥测数据的收集器，稍后会介绍）。
• 控制平面：主要包括了Pilot、Mixer、Citadel和Galley共4个组件，主要功能是通过配置和管理Sidecar代理来进行流量控制，并配置Mixer去执行策略和收集遥测数据（Telemetry）。

图1展示了由这些组件组成的Istio架构。

从Istio的架构中可以看出，Istio追求尽可能的透明，通过各种解耦设计让系统对内对外都没有依赖。同时，它还提供了高度的扩展性。Istio认为随着应用的增长和服务的增多，扩展策略系统是最主要的需求，因此它被设计为以增量的方式进行扩展。可移植也是Istio在设计中充分考虑的因素，它被设计为支持多种平台，以便服务可以被方便地迁移到不同的云环境中（在撰写本书的过程中，Istio仍然深度依赖于Kubernetes平台）。

通过数据平面和控制平面的分离，各个组件都成为插件，这种开放和包容的设计思路相当具有前瞻性，我想这也就是其他服务网格产品都放弃了和它竞争而选择合作的重要原因。

下面对架构中的各组件做进一步介绍。

图1　Istio架构

04 Istio的核心控件

4.1 Envoy  

从架构图可以看出，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的数据平面并提供集成。

4.2  Pilot 

Pilot 是Istio实现流量管理的核心组件，它主要的作用是配置和管理Envoy代理。比如可以为代理之间设置特定的流量规则，或者配置超时、重试、熔断这样的弹性能力。Pilot会将控制流量行为的路由规则转换为Envoy的配置，并在运行时将它们广播到Envoy。另外，Pilot还能够把服务发现机制抽象出来并转换成API分发给Envoy，使得后者具有服务发现的能力。

简单来说，Pilot的主要任务有两个。

• 从平台（如Kubernetes）获取服务信息，完成服务发现。
• 获取Istio的各项配置，转换成Envoy代理可读的格式并分发。

图2展示了Pilot架构。Pilot维护了一套独立于平台的服务规则，并提供了

图2　Pilot架构

一个平台适配器，以便接入各种不同的平台。Rules API对运维人员开放，使得他们可以设置想要的流量规则，Pilot会把这些配置好的规则通过Envoy API分发给Envoy代理，以使其执行指定的规则。

Pilot还公开了用于服务发现并且可以动态更新负载均衡和路由表的API。

4.3  Mixer  

Mixer的主要功能是提供策略控制，并从Envoy代理收集遥测数据。每次网络通信时Envoy代理都会向Mixer发出预检要求，用来检测调用者的合法性。调用之后Envoy代理会发送遥测数据供Mixer收集。一般情况下Sidecar代理可以缓存这些数据，不需要频繁地调用Mixer。

适配器是Mixer的重要组成部分，它本质上是一个插件模型，每个插件叫作适配器。这项特性使得Mixer可以接入几乎任意的（只要定义好接口）后端基础设施。比如可以选择接入不同的日志收集器、监控工具和授权工具等；可以在运行时切换不同的适配器或者是打开（关闭）它们；还可以自定义适配器以满足特定需求。适配器极大地提高了Mixer的扩展性，它让Istio的功能拥有了更多可能性。图3展示了Mixer的架构图并展示了它和Envoy的交互方式。

图3　Mixer架构

4.4  Citadel  

Citadel是与安全相关的组件，主要负责密钥和证书的管理。它可以提供服务间和终端用户的身份认证，还可以加密服务网格中的流量。在后面介绍安全主题的第8章中，我们会详细说明它是如何和其他组件协同工作的。

4.5  Galley 

在2019年3月份发布的1.1版本中，Galley作为一个独立的组件被添加到了架构当中（在此之前的版本中Galley并未独立出现），它现在是Istio主要的配置管理组件，负责配置的获取、处理和分发。Galley使用了一种叫作MCP（Mesh Configuration Protocol，网格配置协议）的协议与其他组件进行通信。

05 Istio的主要功能

下面详细地介绍一下Istio的4个主要功能和实现原理。

5.1 流量管理 

第1章介绍过，微服务应用最大的痛点就是处理服务间的通信，而这一问题的核心其实就是流量管理。首先来看一看传统的微服务应用在没有服务网格介入的情况下，如何完成诸如金丝雀发布这样的动态路由。假设不借助任何现成的第三方框架，一个简单的实现方法是，在服务间添加一个负载均衡（如Nginx）做代理，通过修改配置的权重来分配流量。这种方式将对流量的管理和基础设施（云服务器、虚拟机、实体机等）绑定在了一起，难以维护。

而使用Istio就可以轻松地实现各种维度的流量控制。图4展示了两种不同的金丝雀发布策略。第一种是根据权重把5%的流量路由给新版本；第二种是根据请求的头信息User-Agent把使用iPhone的用户流量路由到新版本。

图4　Istio的流量管理

Istio的流量管理是通过Pilot和Envoy这两个组件实现的，将流量和基础设施进行了解耦。Pilot负责配置规则，并把规则分发到Envoy代理去实施；而Envoy按照规则执行各种流量管理的功能，比如动态请求路由，超时、重试和熔断，还可以通过故障注入来测试服务之间的容错能力。下面对这些具体的功能进行逐一介绍。

1．请求路由

Istio为了控制服务请求，引入了服务版本（Version）的概念，可以通过版本这一标签将服务进行区分。版本的设置是非常灵活的，可以根据服务的迭代编号进行定义（如v1、v2版本）；也可以根据部署环境进行定义（如Dev、Staging和Production）；或者是自定义任何用于区分服务的标记。通过版本标签，Istio就可以定义灵活的路由规则以控制流量，上面提到的金丝雀发布这类应用场景就很容易实现了。

图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版本的预生产环境。

图5　服务版本控制

2．入口网关（Ingress）和出口网关（Egress）

服务间通信是通过Envoy代理进行的。同样，我们也可以在整个系统的入口和出口处部署代理，使得所有流入和流出的流量都由代理进行转发，而这两个负责入口和出口的代理就叫作入口网关和出口网关。它们相当于整个微服务应用的边界代理，把守着进入和流出服务网格的流量。图6展示了Ingress和Egress在请求流中的位置，通过设置Envoy代理，出入服务网格的流量也得到了控制。

图6　请求流中的Ingress和Egress

3．服务发现和负载均衡

服务发现的前提条件是具有服务注册的能力。目前Kubernetes这类容器编排平台也提供了服务注册的能力。Istio基于平台实现服务发现和负载均衡时，需要通过Pilot和Envoy协作完成，如图7所示。Pilot组件会从平台获取服务的注册信息，并提供服务发现的接口，Envoy获得这些信息并更新到自己的负载均衡池。Envoy会定期地对池中的实例进行健康检查，剔除离线的实例，保证服务信息的实时性。

图7　服务发现和负载均衡

4．故障处理

Istio的故障处理都由Envoy代理完成。Envoy提供了一整套现成的故障处理机制，比如超时、重试、限流和熔断等。这些功能都能够以规则的形式进行动态配置，并且执行运行时修改。这使得服务具有更好的容错能力和弹性，并保证服务的稳定性。

5．故障注入

简单来说，故障注入就是在系统中人为地设置一些故障，来测试系统的稳定性和系统恢复的能力。比如为某服务设置一个延迟，使其长时间无响应，然后检测调用方是否能处理这种超时问题而自身不受影响（如及时终止对故障发生方的调用，避免自己受到影响且使故障扩展）。

Isito支持注入两种类型的故障：延迟和中断。延迟是模拟网络延迟或服务过载的情况；中断是模拟上游服务崩溃的情况，表现为HTTP的错误码和TCP连接失败。

5.2  策略和遥测 

1．策略

在微服务应用中，除了流量管理以外，常常还需要进行一些额外的控制，比如限流（对调用频率、速率进行限制）、设置白名单和黑名单等。

Istio中的策略控制是依靠Mixer完成的。Envoy代理在每次网络请求时，都会调用Mixer进行预先检查，确定是否满足对应的策略。同时，Mixer又可以根据这些来自流量的数据，进行指标数据的采集和汇总，这就是遥测功能。

2．遥测（Telemetry）

遥测是工业上常用的一种技术，它是指从远程设备中收集数据，并传输到接收设备进行监测。在软件开发中，遥测的含义引申为对各种指标（metric）数据进行收集，并监控、分析这些指标，比如我们经常听到的BI数据分析。

Mixer的一大主要功能就是遥测。前面已经说过，Envoy代理会发送数据给Mixer，这就使得Mixer具有了数据收集的能力。在本章对Mixer的介绍中读者已经了解到Mixer的插件模型，也就是适配器。Mixer可以接入不同的后端设施作为适配器，来处理收集到的指标数据，比如日志分析系统、监控系统等。

5.3  可视化  

在微服务应用越来越复杂的情况下，对整个系统的状态进行监控和追踪变得尤为重要。试想如果一个包含上百个服务的系统发生了故障却无法准确定位问题的根源，或者系统压力已经到了承受的临界值而运维人员却浑然不知，这是多么可怕的事情。没有完备的、可观察的监控系统就无法保障系统的稳定性。

Istio可以很方便地和各种监控、追踪工具集成，以便我们以可视化的方式（网页）直观地查看整个系统的运行状态。比如可以集成Prometheus来进行指标数据的收集，然后将收集的数据放在Grafana监控工具中展示；还可以集成Jaeger作为追踪系统，帮助我们对请求的调用链进行跟踪，在故障发生时分析出现问题的根源；或者将请求日志记录到Kibana系统，以图表的方式进行数据分析。

以上提到的这些可视化工具都会在第7章被集成到Istio，并得到详细的介绍。

5.4  安全 　

Istio 中的安全架构是由多个组件协同完成的。Citadel是负责安全的主要组件，用于密钥和证书的管理；Pilot会将授权策略等信息分发给Envoy代理；Envoy根据策略实现服务间的安全通信；Mixer负责管理授权等工作。图8展示了Istio的安全架构和运作流程。

图8　Istio安全架构

1．认证

Istio提供如下两种类型的身份认证。

• 传输认证：也叫作服务到服务认证。这种方式的认证是通过双向TLS（mTLS）来实现的，即客户端和服务端（或者是调用者和被调用者）都要验证彼此的合法性。
• 来源认证：也叫作最终用户认证，用于验证终端用户或设备。Istio使用目前业界流行的JWT（JSON Web Token）作为实现方案（在配置项上Istio提供了扩展性，但在撰写本书时仍然只支持JWT）。

这两种认证的工作原理类似，都是将来自平台的认证策略存储起来，然后通过Pilot分发给Envoy代理，如图9所示。

图9　认证架构

2．授权

Istio的授权功能沿用了Kubernetes中的授权方式：RBAC（Role-Based Access Control，基于角色的访问控制）。它可以为网格中的服务提供不同级别的访问控制。比如命名空间级别、服务级别和方法级别。

图10显示了授权的工作方式。运维人员编写授权策略的清单文件并将其部署到平台（Kubernetes）。Pilot组件会获取策略信息并将其保存到自己的配置存储中，同时监听授权策略的变更情况，以便及时更新。然后Pilot会把授权信息分发给Envoy代理。Envoy在请求到达的时候，评估当前的请求是否合法并作出相应的返回。

图10　授权架构

与安全相关的配置涉及很多细节，我们会在后面的练习章节有针对性地进行具体介绍，以便读者可以通过演练加深理解。

06 小     结

本章主要介绍了Istio的理论知识。Istio作为一个开源的服务网格产品，提供了统一的方式去管理流量、设置安全和监控等服务治理的能力。

Istio的架构分为数据平面和控制平面，这种优雅的设计使得各个组件充分解耦，各司其职，这就是很多人将它称为第二代服务网格产品的原因。数据平面即Envoy代理，负责流量的接管；控制平面包含了Pilot、Mixer、Citadel和Galley，它们分别负责流量控制、策略控制、安全加固和数据收集。通过这些组件的协同工作，Istio顺利地完成了流量管理、策略和遥测、可视化和安全这4大功能。

第3章将进入实践阶段，搭建Istio的开发环境并完成它的安装和部署。

Istio实战指南

作者：马若飞

推荐理由：

• Service Mesher社区成员，作为Service Mesh的布道者； 
• 该社区成员对于Istio的了解和认知都具备一定的权威性。 。

本书是Istio服务网格技术的入门图书。全书共分为10章，深入浅出地介绍了Istio的相关知识，结合大量的示例，清晰而详细的阐述了Istio的4大特性：连接、策略、可视化和安全。本书的第1章介绍了服务网格的起源和发展，第2~4章介绍了Istio的基本概念和安装。从第5章起通过实例练习的方式介绍了Istio的流量管理等内容，并把Istio应用到真实的项目开发中，帮助读者进一步理解概念。

- END -