Service Mesh 最火项目： Istio 架构解析

Istio 是一个开源的服务网格，可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台，开发者必须使用微服务设计架构以实现可移植性，而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio 采用一种一致的方式来保护、连接和监控微服务，降低了管理微服务部署的复杂性。

从架构设计上来看，Istio 服务网格在逻辑上分为控制平面和数据平面两部分。其中，控制平面 Pilot 负责管理和配置代理来路由流量，并配置 Mixer 以实施策略和收集遥测数据；数据平面由一组以 Sidecar 方式部署的智能代理（Envoy）组成，这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。

作为代理，Envoy 非常适合服务网格的场景，但要发挥 Envoy 的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。Envoy 构成了服务网格的数据平面，Istio 提供的支撑组件则是创建了控制平面。

一方面，我们在 Envoy 中看到，可以使用静态配置文件或使用一组发现服务来配置一组服务代理，以便在运行时发现监听器、端点和集群。Istio 在 Pilot 中实现了这些 Envoy 代理的 xDS API。

另一方面，Envoy 的服务发现依赖于某种服务注册表来发现服务端点。Istio Pilot 实现了这个 API，但也将 Envoy 从任何特定的服务注册实现中抽象出来。当 Istio 部署在 Kubernetes 上时，Kubernetes 的服务注册表是 Istio 用于服务发现的。其它注册表也可以像 HashiCorp 的 Consul 那样使用。Envoy 数据平面完全不受这些实施细节的影响。

此外，Envoy 代理可以发出很多指标和遥测数据，这些遥测数据发送到何处，取决于 Envoy 的配置。Istio 提供遥测接收器 Mixer 作为其控制平面的一部分，Envoy 代理可以将这些数据发送到 Mixer。Envoy 还将分布式跟踪数据发送到开放式跟踪引擎（遵循 Open Tracing API）。Istio 可以支持兼容的开放式跟踪引擎并配置 Envoy 将其跟踪数据发送到该位置。

剖析 Istio 控制平面

Istio 的控制平面和 Envoy 的数据平面共同构成了一个引人注目的服务网格实现。两者都拥有蓬勃发展和充满活力的社区，并且面向下一代服务架构。Istio 是独立于平台的，可运行于各种环境中，包括跨云、内部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支持在 Kubernetes 上部署的服务、使用 Consul 注册的服务以及在虚拟机上部署的服务。

其中，控制平面部分包括了 Pilot、Mixer、Citadel 和 Galley 四个组件。参见 Istio 架构一图。

1. Pilot

Istio 的 Pilot 组件用于管理流量，可以控制服务之间的流量流动和 API 调用，通过 Pilot 可以更好地了解流量，以便在问题出现之前发现问题。这使得调用更加可靠、网络更加强健，即使遇到不利条件也能让应用稳如磐石。借助 Istio 的 Pilot，你能够配置熔断器、超时和重试等服务级属性，并设置常见的连续部署任务，如金丝雀发布、A/B 测试和基于百分比拆分流量的分阶段发布。Pilot 为 Envoy 代理提供服务发现功能，为智能路由和弹性能力（如超时、重试、熔断器等）提供流量管理功能。Pilot 将控制流量行为的高级路由规则转换为特定于 Envoy 代理的配置，并在运行时将它们传播到 Envoy。此外，Istio 提供了强大的开箱即用故障恢复功能，包括超时、支持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进行的定期主动运行状况检查，以及被动运行状况检查。

Pilot 将平台特定的服务发现机制抽象化并将其合成为标准格式，符合数据平面 API 的任何 Sidecar 都可以使用这种标准格式。这种松散耦合使得 Istio 能够在多种环境下运行（例如 Kubernetes、Consul、Nomad），同时可保持用于流量管理的操作界面相同。

2. Mixer

Istio 的 Mixer 组件提供策略控制和遥测收集功能，将 Istio 的其余部分与各个后端基础设施后端的实现细节隔离开来。Mixer 是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。

Mixer 中包括一个灵活的插件模型，使其能够接入到各种主机环境和后端基础设施，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。利用 Mixer，你可以精细控制网格和后端基础设施后端之间的所有交互。

与必须节省内存的 Sidecar 代理不同，Mixer 独立运行，因此它可以使用相当大的缓存和输出缓冲区，充当 Sidecar 的高度可伸缩且高度可用的二级缓存。

Mixer 旨在为每个实例提供高可用性。它的本地缓存和缓冲区可以减少延迟时间，还有助于屏蔽后端基础设施后端故障，即使后端没有响应也是如此。

3. Citadel

Istio Citadel 安全功能提供强大的身份验证功能、强大的策略、透明的 TLS 加密以及用于保护服务和数据的身份验证、授权和审计（AAA）工具，Envoy 可以终止或向网格中的服务发起 TLS 流量。为此，Citadel 需要支持创建、签署和轮换证书。Istio Citadel 提供特定于应用程序的证书，可用于建立双向 TLS 以保护服务之间的流量。

借助 Istio Citadel，确保只能从经过严格身份验证和授权的客户端访问包含敏感数据的服务。Citadel 通过内置身份和凭证管理提供了强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。Istio 的配置策略在服务器端配置平台身份验证，但不在客户端强制实施该策略，同时允许你指定服务的身份验证要求。Istio 的密钥管理系统可自动生成、分发、轮换与撤销密钥和证书。

Istio RBAC 为 Istio 网格中的服务提供命名空间级别、服务级别和方法级别的访问权限控制，包括易于使用的基于角色的语义、服务到服务和最终用户到服务的授权，并在角色和角色绑定方面提供灵活的自定义属性支持。

Istio 可以增强微服务及其通信（包括服务到服务和最终用户到服务的通信）的安全性，且不需要更改服务代码。它为每个服务提供基于角色的强大身份机制，以实现跨集群、跨云端的交互操作。

4. Galley

Galley 用于验证用户编写的 Istio API 配置。随着时间的推移，Galley 将接管 Istio 获取配置、处理和分配组件的顶级责任。它负责将其他的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节中隔离开来。

总而言之，通过 Pilot，Istio 可在部署规模逐步扩大的过程中帮助你简化流量管理。通过 Mixer，借助强健且易于使用的监控功能，能够快速有效地检测和修复问题。通过 Citadel，减轻安全负担，让开发者可以专注于其他关键任务。

Istio 的架构设计中有几个关键目标，这些目标对于系统应对大规模流量和高性能的服务处理至关重要。

• 最大化透明度：要采用 Istio，应该让运维和开发人员只需付出很少的代价就可以从中获得实际价值。为此，Istio 将自身自动注入到服务间所有的网络路径中。Istio 使用 Envoy 代理来捕获流量，并且在可能的情况下自动对网络层进行编程，以便通过这些代理路由流量，而无需对已部署的应用程序代码进行太多的更改，甚至不需要任何更改。在 Kubernetes 中，Envoy 代理被注入到 pod 中，通过 iptables 规则来捕获流量。一旦注入 Envoy 代理到 pod 中并且修改路由规则，Istio 就能够调节所有流量。这个原则也适用于性能。当将 Istio 用于部署时，运维人员可以发现，为提供这些功能而增加的资源开销是很小的。所有组件和 API 在设计时都必须考虑性能和规模。

• 可扩展性：随着运维人员和开发人员越来越依赖 Istio 提供的功能，系统必然和他们的需求一起成长。在我们继续添加新功能的同时，最需要的是能够扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的新信号来强制执行策略。

• 可移植性：使用 Istio 的生态系统在很多方面都有所不同。Istio 必须能够以最少的代价运行在任何云或本地环境中。将基于 Istio 的服务移植到新环境应该是轻而易举的，而使用 Istio 将一个服务同时部署到多个环境中也是可行的，例如可以在混合云上部署以实现冗余灾备。

• 策略一致性：策略应用于服务之间的 API 调用，可以很好地控制网格行为。但对于无需在 API 级别表达的资源来说，对资源应用策略也同样重要。例如，将配额应用到机器学习训练任务消耗的 CPU 数量上，比将配额应用到启动这个工作的调用上更为有用。因此，Istio 将策略系统维护为具有自己的 API 的独特服务，而不是将其放到代理中，这允许服务根据需要直接与其集成。

剖析 Istio 数据平面

当介绍服务网格的概念时，提到了服务代理的概念以及如何使用代理构建一个服务网格，以调节和控制微服务之间的所有网络通信。Istio 使用 Envoy 代理作为默认的开箱即用服务代理，这些 Envoy 代理与参与服务网格的所有应用程序实例一起运行，但不在同一个容器进程中，形成了服务网格的数据平面。只要应用程序想要与其他服务通信，就会通过服务代理 Envoy 进行。由此可见，Envoy 代理是数据平面和整个服务网格架构中的关键组成部分。

1. Envoy 代理

Envoy 最初是由 Lyft 开发的，用于解决构建分布式系统时出现的一些复杂的网络问题。它于 2016 年 9 月作为开源项目提供，一年后加入了云原生计算基金会（CNCF）。Envoy 是用 C++ 语言实现的，具有很高的性能，更重要的是，它在高负载运行时也非常稳定和可靠。网络对应用程序来说应该是透明的，当网络和应用程序出现问题时，应该很容易确定问题的根源。正是基于这样的一种设计理念，将 Envoy 设计为一个面向服务架构的七层代理和通信总线。

为了更好地理解 Envoy，我们需要先搞清楚相关的几个基本术语：

• 进程外（Out of Process）架构：Envoy 是一个独立进程，Envoy 之间形成一个透明的通信网格，每个应用程序发送消息到本地主机或从本地主机接收消息，但无需关心网络拓扑。

• 单进程多线程模型：Envoy 使用了单进程多线程的架构模型。一个主线程管理各种琐碎的任务，而一些工作子线程则负责执行监听、过滤和转发功能。

• 下游（Downstream）：连接到 Envoy 并发送请求、接收响应的主机叫下游主机，也就是说下游主机代表的是发送请求的主机。

• 上游（Upstream）：与下游相对，接收请求的主机叫上游主机。

• 监听器（Listener）：监听器是命名网络地址，包括端口、unix domain socket 等，可以被下游主机连接。Envoy 暴露一个或者多个监听器给下游主机连接。每个监听器都独立配置一些网络级别（即三层或四层）的过滤器。当监听器接收到新连接时，配置好的本地过滤器将被实例化，并开始处理后续事件。一般来说监听器架构用于执行绝大多数不同的代理任务，例如限速、TLS 客户端认证、HTTP 连接管理、MongoDB sniff?ing、原始 TCP 代理等。

• 集群（Cluster）：集群是指 Envoy 连接的一组逻辑相同的上游主机。

• xDS 协议：在 Envoy 中 xDS 协议代表的是多个发现服务协议，包括集群发现服务（CDS，
  Cluster Discovery Service）、监听器发现服务（LDS，Listener Discovery Service）、路由发现服务（RDS，Route Discovery Service）、端点发现服务（EDS，Endpoint Discovery Service），以及密钥发现服务（SDS，Secret Discovery Service）。

Envoy 代理有许多功能可用于服务间通信，例如，暴露一个或者多个监听器给下游主机连接，通过端口暴露给外部的应用程序；通过定义路由规则处理监听器中传输的流量，并将该流量定向到目标集群，等等。后续章节会进一步分析这几个发现服务在 Istio 中的角色和作用。

在了解了 Envoy 的术语之后，你可能想尽快知道 Envoy 到底起到了什么作用？

首先，Envoy 是一种代理，在网络体系架构中扮演着中介的角色，可以为网络中的流量管理添加额外的功能，包括提供安全性、隐私保护或策略等。在服务间调用的场景中，代理可以为客户端隐藏服务后端的拓扑细节，简化交互的复杂性，并保护后端服务不会过载。例如，后端服务实际上是运行的一组相同实例，每个实例能够处理一定量的负载。

其次，Envoy 中的集群（Cluster）本质上是指 Envoy 连接到的逻辑上相同的一组上游主机。那么客户端如何知道在与后端服务交互时要使用哪个实例或 IP 地址？Envoy 作为代理起到了路由选择的作用，通过服务发现（SDS，Service Discovery Service），Envoy 代理发现集群中的所有成员，然后通过主动健康检查来确定集群成员的健康状态，并根据健康状态，通过负载均衡策略决定将请求路由到哪个集群成员。而在 Envoy 代理处理跨服务实例的负载均衡过程中，客户端不需要知道实际部署的任何细节。

2. Envoy 的启动配置

Envoy 目前提供了两个版本的 API，即 v1 和 v2，从 Envoy 1.5.0 起就有 v2 API 了，为了能够让用户顺利地向 v2 版本 API 迁移，Envoy 启动的时候设置了一个参数--v2-conf?ig-only。通过这个参数，可以明确指定 Envoy 使用 v2 API 的协议。幸运的是，v2 API 是 v1 的一个超集，兼容 v1 的 API。在当前的 Istio 1.0 之后的版本中，明确指定了其支持 v2 的 API。通过查看使用 Envoy 作为 Sidecar 代理的容器启动命令，可以看到如下类似的启动参数，其中指定了参数--v2-config-only：

$ /usr/local/bin/envoy -c
/etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45
--parent-shutdown-time-s 60 --service-cluster ratings --service-node
sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local
--max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only

其中，参数 -c 表示的是基于版本 v2 的引导配置文件的路径，格式为 JSON，也支持其他格式，如 YAML、Proto3等。它会首先作为版本 v2 的引导配置文件进行解析，若解析失败，会根据 [--v2-conf?ig-only] 选项决定是否作为版本 v1 的 JSON 配置文件进行解析。其他参数解释如下，以便读者及时理解 Envoy 代理启动时的配置信息：

• restart-epoch 表示热重启周期，对于第一次启动默认为 0，每次热重启后都应该增加它。

• service-cluster 定义 Envoy 运行的本地服务集群名称。

• service-node 定义 Envoy 运行的本地服务节点名称。

• drain-time-s 表示热重启期间 Envoy 将耗尽连接的时间（秒），默认为 600 秒（10 分钟）。通常耗尽时间应小于通过 --parent-shutdown-time-s 选项设置的父进程关闭时间。

• parent-shutdown-time-s 表示 Envoy 在热重启时关闭父进程之前等待的时间（秒）。

• max-obj-name-len 描述的是集群 cluster、路由配置 route_conf?ig 以及监听器 listener 中名称字段的最大长度，以字节为单位。此选项通常用于自动生成集群名称的场景，通常会超过 60 个字符的内部限制。默认为 60。

• Envoy 的启动配置文件分为两种方式：静态配置和动态配置。具体表现为：

• 静态配置是将所有信息都放在配置文件中，启动的时候直接加载。

• 动态配置需要提供一个 Envoy 的服务端，用于动态生成 Envoy 需要的服务发现接口，也就是通常说的 xDS，通过发现服务来动态调整配置信息，Istio 实现了 v2 的 xDS API。

3. Envoy 静态与动态配置

Envoy 是由 JSON 或 YAML 格式的配置文件驱动的智能代理，对于已经熟悉 Envoy 或 Envoy 配置的用户来说，相信应该已经知道了 Envoy 的配置也有不同的版本。初始版本 v1 是 Envoy 启动时配置 Envoy 的原始方式。此版本已被弃用，以支持 Envoy 配置的 v2 版本。

Envoy 版本 v2 的配置 API 建立在 gRPC 之上，v2 API 的一个重要特性是可以在调用 API 时利用流功能来减少 Envoy 代理汇聚配置所需的时间。实际上，这也消除了轮询 API 的弊端，允许服务器将更新推送到 Envoy 代理，而不是定期轮询代理。

Envoy 的架构使得使用不同类型的配置管理方法成为可能。部署中采用的方法将取决于实现者的需求。简单部署可以通过全静态配置来实现，更复杂的部署可以递增地添加更复杂的动态配置。主要分为以下几种情况：

• 全静态：在全静态配置中，实现者提供一组监听器和过滤器链、集群和可选的 HTTP 路由配置。动态主机发现仅能通过基于 DNS 的服务发现。配置重载必须通过内置的热重启机制进行。

• 仅SDS/EDS：在静态配置之上，Envoy 可以通过该机制发现上游集群中的成员。

• SDS/EDS 和 CDS：Envoy 可以通过该机制发现使用的上游集群。

• SDS/EDS、CDS 和 RDS：RDS 可以在运行时发现用于 HTTP 连接管理器过滤器的整个路由配置。

• SDS/EDS、CDS、RDS 和 LDS：LDS 可以在运行时发现整个监听器。这包括所有的过滤器堆栈，包括带有内嵌到 RDS 的应用的 HTTP 过滤器。

 静态配置

我们可以使用 Envoy 的配置文件指定监听器、路由规则和集群。如下示例提供了一个非常简单的 Envoy 配置：

static_resources:
 
listeners:
 
- name: httpbin-demo
   
address:
     
socket_address: { address: 0.0.0.0, port_value: 15001 }
   
filter_chains:
   
- filters:
     
- name: envoy.http_connection_manager
       
config:
          stat_prefix: egress_http
          route_config:
            name: httpbin_local_route
            virtual_hosts:
            - name: httpbin_local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/"
}
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service
          http_filters:
          - name: envoy.router
 
clusters:
   
- name: httpbin_service
     
connect_timeout: 5s
     
type: LOGICAL_DNS
     
# Comment out the following line to test on v6 networks
     
dns_lookup_family: V4_ONLY
     
lb_policy: ROUND_ROBIN
     
hosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]

在这个简单的 Envoy 配置文件中，我们声明了一个监听器，它在端口 15001 上打开一个套接字并为其附加一个过滤器链。过滤器 http_connection_manager 在 Envoy 配置中使用路由指令（在此示例中看到的简单路由指令是匹配所有虚拟主机的通配符），并将所有流量路由到 httpbin_service 集群。配置的最后一部分定义了 httpbin_service 集群的连接属性。在此示例中，我们指定端点服务发现的类型为 LOGICAL_DNS、与上游 httpbin 服务通信时的负载均衡算法为 ROUND_ROBIN。

这是一个简单的配置文件，用于创建监听器传入的流量，并将所有流量路由到 httpbin 集群。它还指定要使用的负载均衡算法的设置以及要使用的连接超时配置。

你会注意到很多配置是明确指定的，例如指定了哪些监听器，路由规则是什么，我们可以路由到哪些集群等。这是完全静态配置文件的示例。

在前面的部分中，我们指出 Envoy 能够动态配置其各种设置。下面将介绍 Envoy 的动态配置以及 Envoy 如何使用 xDS API 进行动态配置。

动态配置

Envoy 可以利用一组 API 进行配置更新，而无需任何停机或重启。Envoy 只需要一个简单的引导配置文件，该配置文件将配置指向正确的发现服务 API，其余动态配置。Envoy 进行动态配置的 API 通常统称为 xDS 服务，具体包括如下：

• 监听器发现服务（LDS）：一种允许 Envoy 查询整个监听器的机制，通过调用该 API 可以动态添加、修改或删除已知监听器；每个监听器都必须具有唯一的名称。如果未提供名称，Envoy 将创建一个 UUID。

• 路由发现服务（RDS）：Envoy 动态获取路由配置的机制，路由配置包括 HTTP 标头修改、虚拟主机以及每个虚拟主机中包含的单个路由规则。每个 HTTP 连接管理器都可以通过 API 独立地获取自身的路由配置。RDS 配置隶属于监听器发现服务 LDS 的一部分，是 LDS 的一个子集，用于指定何时应使用静态和动态配置，以及指定使用哪个路由。

• 集群发现服务（CDS）：一个可选的 API，Envoy 将调用该 API 来动态获取集群管理成员。Envoy 还将根据 API 响应协调集群管理，根据需要添加、修改或删除已知的集群。在 Envoy 配置中静态定义的任何集群都不能通过 CDS API 进行修改或删除。

• 端点发现服务（EDS）：一种允许 Envoy 获取集群成员的机制，基于 gRPC 或 RESTJSON 的 API，它是 CDS 的一个子集；集群成员在 Envoy 术语中称为端点（Endpoint）。对于每个集群，Envoy 从发现服务获取端点。EDS 是首选的服务发现机制。

• 密钥发现服务（SDS）：用于分发证书的 API；SDS 最重要的好处是简化证书管理。如果没有此功能，在 Kubernetes 部署中，必须将证书创建为密钥并挂载到 Envoy 代理容器中。如果证书过期，则需要更新密钥并且需要重新部署代理容器。使用密钥发现服务 SDS，那么 SDS 服务器会将证书推送到所有 Envoy 实例。如果证书过期，服务器只需将新证书推送到 Envoy 实例，Envoy 将立即使用新证书而无需重新部署。

• 聚合发现服务（ADS）：上述其他 API 的所有更改的序列化流；你可以使用此单个 API 按顺序获取所有更改；ADS 并不是一个实际意义上的 xDS，它提供了一个汇聚的功能，在需要多个同步 xDS 访问的时候，ADS 可以在一个流中完成。配置可以使用上述服务中的一个或其中几个的组合，不必全部使用它们。需要注意的一点是，Envoy 的 xDS API 是建立在最终一致性的前提下，正确的配置最终会收敛。例如，Envoy 最终可能会使用新路由获取RDS的更新，该路由将流量路由到尚未在 CDS 中更新的集群。这意味着，路由可能会引入路由错误，直到更新 CDS。Envoy 引入了聚合发现服务 ADS 来解决这种问题，而 Istio 实现了聚合发现服务 ADS，并使用 ADS 进行代理配置的更改。

例如，Envoy 代理要动态发现监听器，可以使用如下配置：

dynamic_resources:
 
lds_config:
   
api_config_source:
     
api_type: GRPC
     
grpc_services:
       
- envoy_grpc:
            cluster_name: xds_cluster
clusters:
- name: xds_cluster
 
connect_timeout: 0.25s
 
type: STATIC
 
lb_policy: ROUND_ROBIN
 
http2_protocol_options: {}
 
hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

通过上面的配置，我们不需要在配置文件中显式配置每个监听器。我们告诉 Envoy 使用 LDS API 在运行时发现正确的监听器配置值。但是，我们需要明确配置一个集群，这个集群就是 LDS API 所在的位置，也就是该示例中定义的集群 xds_cluster。

在静态配置的基础上，比较直观地表示出各个发现服务所提供的信息。

在静态配置的基础上，比较直观地表示出各个发现服务所提供的信息。

 动动小手指 了解更多详情 ！