Service Mesh 最火项目 Istio 分层架构，你真的了解吗？

做者 | 王夕宁  阿里巴巴高级技术专家

参与“阿里巴巴云原生”公众号文末留言互动，即有机会得到赠书福利！

本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，文章从基础概念入手，介绍了什么是服务网格及 Istio，针对 2020 服务网格的三大发展趋势，体系化、全方位地介绍了 Istio 服务网格的相关知识。你只需开心参与文末互动，咱们负责买单！技术人必备书籍《Istio 服务网格技术解析与实践》免费领~

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

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

(Istio 架构)

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

(Pilot 与 Envoy 数据平面)

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

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

(Mixer 架构)

此外，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 架构)

借助 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 代理）

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-conf?ig-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 的参考文档（https://www.envoyproxy.io/docs）还提供了明确区分 v1 和 v2 的文档。本文将只关注 v2 配置，由于它是最新的版本，也是 Istio 使用的版本。

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 的文档（www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns）。
在前面的部分中，咱们指出 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。

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

（xDS 服务信息）

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

本文摘自于《Istio 服务网格解析与实战》，经出版方受权发布。本书由阿里云高级技术专家王夕宁撰写，详细介绍 Istio 的基本原理与开发实战，包含大量精选案例和参考代码能够下载，可快速入门 Istio 开发。Gartner 认为，2020 年服务网格将成为全部领先的容器管理系统的标配技术。本书适合全部对微服务和云原生感兴趣的读者，推荐你们对本书进行深刻的阅读。

参与公众号留言互动，即有机会获取下列福利！

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”