下载掌阅APP，畅读海量书库
立即打开
Istio 首先是服务网格（Service Mesh）的一个工程实践，说到服务网格首先想到的就是Sidecar，它独立存在于业务逻辑，这使得跨语言调用变简单——上层业务方完全无须感知复杂的分布式逻辑。同时由于 Sidecar 与业务部署在同一个资源单元上（如虚拟机或者容器），方便地实现了链路流量路由及安全控制。Istio的设计理念核心就是将所有链路管理都下沉至协议级别。这样做不仅能对业务方透明，还能将链路管理统一收拢在平台，可谓一举多得。
笔者认为，任何一个优秀的产品在开始设计时都需要有一个初心，即我的产品解决什么问题，在什么样的场景下发挥作用，其适用的用户群体是什么等，这样之后的功能才能紧密围绕初心而不断强化，否则就会慢慢地偏离自己预设的路线和起初的目标，功能虽然越来越多，优势却越来越不明显。
因此要理解 Istio 的设计理念，就得从其诞生的大环境说起，以了解在当时的场景下遇到的问题是什么，设计团队想解决的问题是哪些，这样就能慢慢理清楚了。
Istio 是 Google 于 2017 年 5 月推出的服务网格（Service Mesh）产品，已于 2018 年 8月推出1.0 正式版本。Istio 诞生之初，即 2017 年，正值微服务编排 Kubernetes 发展的繁盛时期，各大技术论坛都在讨论 Docker 及微服务弹性伸缩，微服务理念得到了空前的发展。微服务本身并不强调语言架构上的统一（使用的 RPC 都是基于 HTTP 的，具有很强的跨语言特性）。开发者可以根据需要选择（尽量一个进程一个服务），唯一需要注意的就是，在微服务中，任何一个服务都只具备单一的功能，因此会产生很多的独立服务部署。
那么随之而来的问题便是：这么多的微服务，这么多的调用及系统流量，如何才能有效地管理起来呢？而且同时还需要支持不同的语言及不同的部署平台。
经过综合考虑，Istio 的设计者们决定它应该是一个提供连接管理、安全控制、负载限流的统一微服务平台。Istio 不仅提供了服务之间的流量控制、访问控制策略，还集成了各种链路服务（例如链路跟踪 Zipkin）及相关的扩展接口，这一切都是无须上层业务感知的。
总之，Istio 能给用户带来：
○针对 HTTP、gRPC、WebSocket 及 TCP 等协议的自动负载均衡。
○精细的请求流量控制，支持众多路由、重试及容灾层面上的规则，支持故障模拟。
○模块化插件扩展支持，可通过 API 进行访问、频率限制及配额方面的控制。
○全自动化的请求遥测（Telemetry）、日志分析及全链路跟踪系统，所有请求都在掌控之内。
○全链路安全访问控制与身份认证。
Istio 的核心意义在于：适配多种Pass
平台，把调用链路相关工作从业务逻辑中彻底剥离出来。形成“数据平面”，再通过添加“控制平面”进行统一控制，把整个链路负载工作都下沉到了PaaS基础技术栈上层，从此业务开发工程师不再需要关心内部实现，就像使用云服务一样简单。简单来说，Istio提供了服务网络（Service Mesh）基础环境。
在Istio的控制平面中，管理员可以通过统一的配置下发给各节点，能非常轻松地对全局进行操控，这些功能以前也许需要几个甚至十几个系统，如今都被集成到了一起，1～2个工程师即可轻松维护，降低了整体运维成本。
因此，Istio的核心便是“数据平面”与“控制平面”两部分，外加“数据平面”衍生出的“安全控制”。接下来笔者便为大家一一介绍。
首先来看看 Istio 的全局模块，如图2.1所示。
图2.1 “Istio 官方给出的全局架构图”
从图2.1“Istio 官方给出的全局架构图”可以看出，所有的服务都加装了一个代理，系统间通信都通过这个代理来进行；如此一来，业务都不需要费力去搞清楚如何到达其他服务了，它们就像在一个应用里一样，不必去感受复杂的分布式拓扑。
对于这样功能奇特的代理网关，Istio 将之称为 Sidecar，直译过来就是“跨斗”。边斗源于一种特殊的摩托车，这种车的最大特点是侧边挂载有一个独轮小车，与主体可以是一体式的，也可以是挂载式的，如图2.2所示：
图2.2 “跨斗摩托车”
在 Istio 系统中，Sidecar 只是一个概念，它具体是由 Envoy 这个开源产品实现的。
图2.1最为明显的特点便是 Istio 的所有模块整体上被划分成两层：“数据平面”与“控制平面”。这两个概念是 Istio 的核心，也是最基础的逻辑划分，其详细解译如下。
○ 数据平面（Data Plane） ：由一系列代理网关构成（官方使用的是 Envoy，但不强耦合，可以很方便地替换成其他产品），这种代理与 Nginx 的最大区别是，它们拥有非常强大的扩展接口，可以通过 API 实时接收配置并生效，以此实现动态化的流量代理。从链路上来说，“数据平面”是服务之间的桥梁。
○ 控制平面（Control Plane ） ：是对“数据平面”中网关的统一配置与维护平台，这里的配置不仅包含请求路由，还包括限流降级、熔断、日志收集、性能监控等各种请求相关信息。其中控制平面又被划分成了Pilot、Mixer 及 Citadel三个小模块。
对于“数据平面”，笔者将在 2.2节为大家做比较全面的介绍。“数据平面”主要是由边界网关（IngressGateway 与 EngressGateway）及服务之间的 Sidecar两部分组成，目前具体实现都是 Envoy，只是职责不同而已。
设计两个平面的好处在于能让 Istio 专注于其中一个而将另一个交给其他团队。例如，数据平面就可以交给比较成熟的 Envoy 或者 Nginmesh
之类的产品，如此一来就形成明显的责任划分，有利于生态化。这就是说，只要按两个平面的思想，大家都可以选择一个而投入其中，将焦点进一步缩小。例如 A 团队专注于数据平面，B 团队则专注于控制平面，不同的数据平面产品与控制平面产品可以根据使用的实际生产情况随意搭配，让整个服务网格生态更加丰富。
如果只是单纯地实现“数据平面”与“控制平面”这两个功能，那么 Istio 充其量只能算一个产品。然而，作为一个诞生就被定位成生态的产品，Google 当然希望其是引领时代的标准，就像 Android 一样，用户都按照自己设计的规范来使用。
为此Istio 在“数据平面”与“控制平面”上都做了丰富的扩展支持，并设计成不依赖具体服务平台。这一切都依赖于“适配器”这个重要的理念。例如，Istio 为了不强依赖于某种“数据平面”，对所有的链路路由及管控逻辑进行了统一的抽象，使用标准的 yaml 配置模板，然后再将其翻译成各数据平面认识的配置（例如 Envoy 的 xDS 配置）。再例如 Istio 的 Pilot 本身并不实现服务注册与服务发现功能，仅仅是提供了对接接口，这样不管是 Eureka、Consul，还是 Kubernetes，都可以接入 Istio 体系。
所以，Istio 的野心可谓巨大，是想做服务网格的生态基石，通过接口将现有的产品都接入，帮助业界快速过渡到 Service Mesh 中。如果这真的得以实现，那么Kubernetes 的地位将会愈加稳固，当然也顺水推舟完善了 GCP（Google Cloud Platform）云计算环境，战略思路是非常明确的。
笔者将在2.2及2.3节中对“数据平面”及“控制平面”进行详细的分析，并进一步阐释Istio的扩展功能及原理。
Istio 的设计原则是要做到尽量少的业务侵入、方便快捷的系统维护以及超高的可用性。所以 Istio 将整体链路下沉至协议级别，虽然对于业务是完全透明的，但这就要求设计实现本身具有非常高的稳定性，也就是出了问题首先应该想到不是下层的支撑性问题，而是自己使用错了或者业务本身的代码逻辑有问题。
这种稳定性要求与 TCP/IP 协议一样，即在网络通信出现问题时，不会有人质疑“拥塞控制”与“流量控制”的逻辑——它们已诞生几十年了，时间已经证明了它们的稳定性，大家都淡忘了其存在，除少数据情况或者特殊场景外，在应用层没有工程师会去留意 TCP/IP 协议里的传输内容。只有达到这样的稳定性，才能为透明无侵入这种设计带来优秀的用户体验。
这就是 Istio 的难点，设计初衷虽然听上去美好——与上层业务完全解耦，链路逻辑与业务分享——但实现上却有非常高的操作难度。因为Istio 对业务是一个黑盒，如果不够稳定，排查问题涉及下沉逻辑时，根本无从下手。特别是大型企业，对稳定性都有相当高的要求，中间件这类的基础设施推一个新版至少都需要 1 年的时间（阿里巴巴为了解决中间件客户端升级，还专门推出一个叫潘多拉的类隔离容器方案），像 Istio 的 Sidecar 这种普遍型的中间件，每个应用都会部署一套，其升级难度可想而知。
为了最大限度地缓解以上问题，Istio 的工程师们想出了一个思路：将架构重心尽量向中心倾斜，即将逻辑统一地放置了在 Mixer 中，数据平面仅仅是做简单的转发。这样，如果我们对链路逻辑做了升级，比如增加链路跟踪等，只需要对中心模块加以扩展即可，否则需要逐一去升级前端的 Sidecar，不仅风险高，而且非常麻烦。
对于 Mixer 缓存的设计，也有人持不同的观点。蚂蚁金服的工程师们就认为Mixer 的中心化设计也不能完全满足其生产场景，主要原因便是存在流量集中的现象，即由于中心节点 Mixer 的存在，链路的认证、鉴权、统计等信息都需要请求中心来实现，在大规模微服务体系中，确实有很大的吞吐量压力。
蚂蚁金服的工程师们为了规避上述问题，将 Mixer 的部分逻辑（比如内存、Redis配额逻辑）移到了 Sidecar 中（蚂蚁金服使用的Sidecar 并不是官方的 Envoy），如图2.3所示。这确实可以大幅度提高性能，不过可就与 Istio 的设计哲学有些冲突了，所以各有取舍。笔者个人认为，蚂蚁金服须面对流量与系统的超复杂性，同时拥有对整个业务基础的控制能力，这种设计也未尝不是一个好的设计；相对地，Istio 想要实现的毕竟是面向全世界的一个大而全的解决方案，其需要做的就是尽量地解耦，贯彻零侵入这一特性，让大家尽量地忘记其存在，成为横向的支撑服务网格平面，这就是 Istio 的设计哲学。
图2.3 “蚂蚁金服在其主办的 Service
至此，我们已经大体了解了 Istio 的设计思想。在接下来的一节中，笔者将会依次向读者介绍 Istio 架构中的三个方面：“数据平面”“控制平面”及“安全控制”，即从局部理解 Istio 的设计。