下载掌阅APP，畅读海量书库
立即打开
上一节笔者介绍了 Istio 的总体架构，分“数据平面”与“控制平面”两部分。数据平面的职责是流量承载、服务路由及数据管控，是与链路对接的前端；而“控制平面”则是集中化地配置、遥测、监控及调配台面，“数据平面”在需要时将其承载的请求发送至中心，以进行管理员预配置的操作。
由此可见，“数据平面”最主要的就是形成这个面的节点，即之前提到的 Sidecar。在Kubernetes 生态里，Sidecar 会被自动注入 Pod （当然也可以手动注册），将其后面的服务纳入Service Mesh 生态。
第2章谈到对于 Sidecar 的具体实现有很多选择，比如早期的 Linkerd，后来的 Envoy 或者经典反向代理 Nginx 衍生出的 Nginmesh 等。然而 Istio 选择的却是 Envoy，笔者个人认为Nginx 作为之前服务架构中广泛使用的网关，却没有得到 Istio 的青睐，很大程度上是因为没有像 Envoy 那样优秀的配置扩展 API。虽然 Nginx 也支持 Lua 扩展脚本，但却是静态级别的，与 Envoy 的实时配置相差甚远，与 Istio 的透明配置设计相违背。
接下来看看 Envoy 的xDS接口是如何得到 Google 巨人青睐的吧。
在 Envoy 中，xDS-API 中的 xDS 其实是一类发现服务的统称，包括如下几类。
○ SDS/EDS（Service/Endpoint（v2） Discovery Service）：节点发现服务，针对的就是提供服务的节点，让节点可以以聚合成服务的方式提供给调用方。在 Envoy v2 API 中，Service Discovery Service 已经更名为 Endpoint Discovery Service，因此这两个描述本质上是一个概念。
○ CDS（Cluster Discovery Service）：集群发现服务，集群指 Envoy 接管的服务集群，例如三台机器组成了一个服务集群提供 reviews 服务；Istio 可以使用这个接口创建虚拟集群，例如一个应用可以划分出不同版本号的部署结构。
○ RDS（Route Discovery Service）：路由规则发现服务，路由规则的作用是动态转发，例如上面 BookInfo 中的指定流量只流向 v3 版本的 reviews 服务，基于此可以实现比如请求漂移、蓝绿发布等功能。
○ LDS（Listener Discovery Service）：监听器发现服务，监听器主要作用于Envoy 的链接状态，例如像 downstreamcxtotal____（连接总数）、downstreamcxactive（活动的连接总数）等。
可见 Envoy 的动态转发/代理功能是相当强大的，几乎可以动态配置一切路由、转发及监听规则。Istio 正是利用了这点，对所有注入的 Sidecar 进行全局管控，将系统管理集中配置的路由及服务信息分发给各节点的 Envoy。
这一点非常重要，结合之前对 Istio 架构的理解，Istio 想要做到的是业务透明、低维护成本与高可用性。假设 Istio 采用类似 Nginx 的静态脚本配置，那么每次在路由规则发生变化或者模块加强的情况下，都需要重启服务。这显然会对业务造成影响，达不到其设计初衷。
在上面的各类配置中，Istio 中使用得较多的主要是 CDS 与 RDS，其作用是对服务及路由信息进行配置，例如之前 BookInfo 示例项目中，要将 reivews 的流量都分配到 v3 版本中，则需配置如下规则：
这里的配置是针对 Istio 模块 Pilot 的配置。这些配置会被 Pilot 翻译成 Envoy 理解的格式，并通过之前提到的 xDS-API 分发给它们（就是 Sidecar）。在第57页“2.7 BookInfo 示例分析”中，笔者将演示如何通过 istioctl 命令查看分发至 Envoy 中的原生配置，对此有兴趣的读者可以去看一下。下发至 Envoy 中的配置都是按照官方的配置要求
来转换的。
使用 Istio 的核心优势在于完全将业务逻辑、分布式调用以及基础组件设施解耦。运维人员只需要简单地向 Pilot 中发送一些配置，就可以轻松掌控全局。在正常情况下，Envoy 会对下游流量做负载均衡，这里主要有“轮询（Round Robin）”与“最少连接（Least Connection）”两种。除此之外还可以做特殊的定制，例如可以向指定的下游分配 5% 的流量；或为链路添加链路跟踪功能；抑或针对某个版本做特定的转发规则。
一切都是那么简单，如图2.4所示：
图2.4 “Envoy 服务负载逻辑示意图”
这样解耦的最大好处是，Istio 可以提供多种链路功能，例如 A/B 测试、多版本转发及链路压测功能，同时还支持故障注入（Fault Injection）等非常实用的功能。这些都是依赖分布在各端前的 Sidecar 来实现的。
Istio 中所有的服务关系都是维护在 Pilot 中的，但需要特别注意的是 Pilot 本身并不做服务发现，而是提供接口与标准让三方扩展来实现，其是完全平台独立的（这也是 Istio 的设计原则，不绑定平台，其计划支持 Kubernetes、Mesos、Cloud Foundry 等平台）。除了服务本身，前面提到的链路功能也是通过 Pilot 配置的。同样，这些配置都是平台无关的。虽然 Istio 目前使用的是 Envoy，但也不排除之后会使用其他数据平面实现。这对 Istio 都是很简单的事，其在架构层面上已经做到了完全接口化，如果真的需要变更数据平面，只需要将 Envoy 的配置翻译器替换成其他的即可，非常简单有效，如图2.5所示。
图2.5 “Istio 的服务发现并不依
除了流量负载，每个 Envoy（即 Sidecar）还向其挂载的服务发起周期性的健康检测。这样新服务在启动时便能自动接入网格：即在健康检测失败时及时排除无效的服务；而当检测成功达到一定的次数后，又可以将其加回服务列表中。有些时候服务需要主动下线（例如发布的时候），这个时候只需在健康检测时返回 503 （Service Unavailable），就不会多次确认，服务会立即下线。
当然，其实很多容器平台，例如 Kubernetes，已经提供了类似的服务，之所以还需要是因为 Istio 设计目的是提供一个通用解决方案，不能依赖平台的功能特性。
在服务网格中，Istio 默认使用的 RPC 调用协议是 HTTP。在第1章也提到过，HTTP 在具有非常明显的轻量优势，并且容易解码与转发，所以是首选；不过在实际生产环境，特别是国内环境，HTTP 被很多大厂，如蚂蚁金服、华为以及腾讯
等不看好，原因是其过于弱类型
，在故障排查、性能调优以及链路分析上都有很多不足
。
Istio 提倡所有进入与离开服务网格的流量都经过一个特殊的网关（见图2.6），这样才能比较轻松地管理内部的网格，在安全、单元封闭、接口扩展层面上都有好处。
图2.6 “Istio 的流量入口与出口网关”
换一种角度来讲，网关除了对入口进行管控，还能够提供对外接口兼容以及流量统一跳转功能，这一点对于多单元部署特别有作用。
所谓的多单元部署就是将全局的应用以单元的形式部署，每个单元都是完全的整套服务，而调用链路是自封闭的，可以提供以下几个功能：
○
服务能力扩展
：当一个单元的服务能力不能满足要求时，可以快速甚至自动地扩展一个单元，由于所有单元的请求都是自封闭的，所以整个扩展只需要将单元的入口网关接入全局的CDN
即可，非常简单。
○ 数据容灾能力 ：当系统单元化后，多个单元间的数据是实时全量同步的，这样以后就将数据冗余到了多地，除非整个地球遭遇灾难，否则数据都是安全的。
○ 就近访问能力 ：单元化的具体落地是机房，由于其自身的完备性，工程师可以把用户定向到离其最近的单元，减少延时，以提供优质的服务访问质量。
由此可见，单元流量的调度都基于统一的入口，否则，例如当一个单元出现问题需要迁移至另一个的时候，还需要逐一地通知各业务方，显然这是不合适的。单元网关为整个服务网格确立了边界，犹如城墙与城门一样重要。
Envoy 提供一系列容灾解决方案，主要由以下部分组成。
○ 超时机制 ：在服务请求总时间超过一个阈值时直接返回错误，避免卡死。
○ 重试机制 ：采用不确定重试时间间隔，并限制重试次数，最大程度保障服务调用的顺畅性。
○ 并行连接控制 ：对下游的并行连接数量进行控制，以避免过载的情况。
○ 健康检测 ：对挂载服务进行健康检测，支持主动与被动（即平台提供的健康检测结果）两种方式，以及时剔除不健康的节点，当其恢复时又及时加入。
○ 断路器支持 ：同样，对服务过载进行保护。
Envoy之所以会结合主动与被动两种健康检测方式，是为了避免将不可用的服务纳入网格。当与平台提供的健康检测结果相结合时，应用能够最大限度地保证故障节点及时被移除，最大限度地减少因为检测延时而导致的错误调用。
以上功能都是可以通过 Istio 的配置规则进行动态设置的。这些功能的结合，为 Istio 中的服务提供了健康保障，能有效避免因过载导致的各类链路故障。
有时候为了测试链路的健壮性，需要模拟一些故障。通常来说，故障模拟都是通过杀掉服务进程或者发送一个错误的 TCP 包来模拟的，显然这种方式非常低效。Istio 从架构设计上就考虑到了这一因素，其支持协议层面上的故障注入，对应用来说结果都一样。相对于之前的方案，这种方式不仅益于问题观察，还能根据请求匹配定向注入问题，最为关键的是对自动化友好，可以随时进行回归测试。
Istio 支持两种形式的错误注入：延时（delays）与丢包（aborts）。延时，顾名思义就是增加网络的传输延时以模拟服务过载时出现的问题；丢包则是模拟上行服务故障，这种故障一般是利用 HTTP 错误码来实现的。
故障注入是现在大型企业保障业务稳定性的重要手段之一。一般来说，大的故障不常见，一见便是灾难；所以时常对自己的系统进行容灾演练是非常好的预防手段，而故障注入便是这其中很好的工具。