下载掌阅APP，畅读海量书库
立即打开
本章内容包括：
■ 理解独立Envoy代理，以及它对Istio的贡献
■ 探索Envoy的能力如何成为Istio这样的服务网格的核心
■ 配置Envoy使用静态配置
■ 使用Envoy的Admin API来检查和调试它
我们在第1章中引入了服务网格的概念，阐述了服务代理的概念，以及代理如何理解应用程序（例如，应用程序协议，如HTTP和gRPC），通过通用的应用程序网络逻辑来增强应用程序的业务逻辑。服务代理与应用程序一起配置但在其进程外运行，每当应用程序想要与其他服务通信时，它都会通过服务代理来实现。
使用Istio时，Envoy代理与服务网格中的所有应用程序实例一起部署，从而形成服务网格数据平面。由于Envoy在数据平面和整个服务网格架构中是非常重要的一个组件，我们将在本章中熟悉它。这将使你更好地理解Istio，以及如何调试或排除故障。
Envoy是Lyft开发的，用来解决一些在构建分布式系统时出现的网络问题。它于2016年9月开源，一年后（2017年9月）加入了云原生计算基金会（CNCF）。Envoy是用C++编写的，旨在提高性能，而且它在更高的负载级别上更加稳定。
Envoy的创建遵循两个关键原则：
网络对应用程序应该是透明的。当网络和应用程序出现问题时，应该很容易确定问题的来源。
——Envoy公告
Envoy是一个代理，所以在进一步讨论之前，我们应该搞清楚什么是代理。我们已经提到，代理是网络架构中的中间组件，位于客户端和服务器的通信之间（参见图3.1）。处于中间位置使它能够提供额外的功能，如安全、隐私和策略。
图3.1 代理是向流量添加功能的中介
代理可以简化客户端与服务通信时需要知道的内容。例如，一个服务可以被实现为一组相同的实例（集群），每个实例都可以处理一定数量的负载。客户端如何知道在向该服务发出请求时使用哪个实例或IP地址？代理可以在中间使用一个标识符或IP地址，客户端使用它与服务的实例通信。图3.2显示了代理如何处理跨服务实例的负载均衡，而客户端不知道任何实际部署的细节。这种类型的反向代理的另一个常见功能是检查集群中实例的运行状况，并避开失败或异常的后端实例路由流量。通过这种方式，代理可以使客户端免于知道和了解哪些后端超载或出现故障。
图3.2 代理可以对客户端隐藏后端拓扑，并实现算法来公平地分配流量（负载均衡）
Envoy代理是一个应用程序级代理，我们可以将其插入应用程序的请求路径中，以提供服务发现、负载均衡和运行状况检查等功能，但Envoy可以做的远不止这些。在前面的章节中，我们已经暗示了一些增强的功能，在本章中将详细介绍它们。Envoy可以理解应用程序在与其他服务通信时可能使用的第7层协议。例如，在Envoy中，这些协议是开箱即用的：HTTP/1.1、HTTP/2、gRPC和其他协议，Envoy可以解析它们，配置请求级超时、重试、每次重试超时、熔断和其他弹性特性。仅使用理解连接的基本连接级（L3/L4）代理是无法完成此类任务的。
Envoy可以被扩展，以理解除开箱即用的默认协议之外的协议。Envoy已经为MongoDB、DynamoDB这样的数据库，甚至是高级消息队列协议（AMQP）这样的异步协议编写了过滤器。应用程序的可靠性和网络透明性是值得努力的目标，但快速理解分布式架构中发生的事情同样重要，特别是当应用程序没有按照预期工作时。由于Envoy理解应用程序级协议和通过Envoy的应用程序流量，代理可以收集关于流经系统的请求的大量遥测信息，例如，它们花费了多长时间、某些服务看到了多少请求（吞吐量），以及服务遇到的错误率。我们将在第7章中介绍Envoy的遥测采集功能，在第14章中介绍它的可扩展性。
作为代理，Envoy被设计为通过应用程序的进程外运行来避免开发人员受到网络问题的影响。这意味着用任何编程语言或用任何框架编写的任何应用程序都可以利用这些特性。此外，尽管服务架构（SOA、微服务等）是目前流行的架构，但Envoy并不关心是微服务，还是用任何语言编写的单体应用程序，只要它们使用的是Envoy能够理解的协议（如HTTP），Envoy就可以提供价值。
Envoy是一个非常通用的代理，可以扮演不同的角色：作为集群边缘的代理（作为一个入口点），或者作为单个主机或服务组的共享代理，甚至作为我们在Istio中看到的每个服务的代理。通过Istio，每个服务实例都部署一个Envoy代理，以实现最大的灵活性、最佳性能和控制。你使用了一种部署模式（sidecar服务代理），并不意味着你不能使用Envoy提供的优势。事实上，让代理在边缘和应用程序中具有相同的实现，可以使基础设施更容易操作和理解。我们将在第4章中看到，Envoy可以被部署在集群边缘作为流量入口，也可以被部署在集群内组成服务网格，以充分控制和观察流量的完整调用链路。
Envoy有许多对服务间通信有用的功能。为了理解这些功能，你应该在较高的层次上熟悉Envoy的以下概念：
● 监听器（Listener）——向外部公开一个应用程序可以连接的端口。例如，80端口上的监听器接收流量，并将任何配置的行为应用于该流量。
● 路由（Route）——如何处理进入监听器的流量的路由规则。例如，如果传入一个请求并匹配/catalog，则将该流量定向到catalog集群。
● 集群（Cluster）——特定的上游服务，Envoy可以将流量路由到这些服务。例如，catalog-v1和catalog-v2可以是单独的集群，路由可以指定将流量定向到catalog服务的v1或v2的规则。
这是对Envoy为第7层通信所做的工作的概念性理解。我们将在第14章中更详细地讨论。
Envoy在传递通信方向性时使用的术语与其他代理类似。例如，流量从下游系统进入监听器。该流量被路由到Envoy的一个集群，该集群负责将该流量发送到上游系统（如图3.3所示）。流量从下游经过Envoy流向上游。现在我们来看看Envoy的一些功能。
图3.3 请求通过监听器从下游系统进入，然后经过路由规则，最后到达集群，该集群将其发送到上游服务
服务发现
与使用特定于运行时的库来进行客户端服务发现不同，Envoy可以为应用程序自动完成此任务。通过配置Envoy从一个简单的发现API中查找服务端点，应用程序可以不知道如何找到服务端点。发现API（Discovery API）是一个简单的REST API，可用于包装其他常见的服务发现API（如HashiCorp Consul、Apache ZooKeeper、Netflix Eureka等）。Istio的控制平面实现了这个开箱即用的API。
Envoy是专门构建的，依赖对服务发现目录的最终一致性更新。这意味着在分布式系统中，我们不能期望知道可以通信的所有服务的确切状态，以及它们是否可用。我们能做的最好的事情是利用手头的知识，主动和被动地进行健康检查，并且不期望结果可能是最新的（它们也不可能是最新的）。
Istio通过提供驱动Envoy的服务发现机制配置的高级资源集，抽象出了很多这样的细节。我们将在整本书中更详细地讨论这个问题。
负载均衡
Envoy实现了一些应用程序可以利用的高级负载均衡算法，例如位置感知负载均衡。此时，Envoy足够聪明，可以阻止任何位置边界的流量，除非它符合某些标准，并将提供更好的流量负载均衡。例如，除非造成故障，否则Envoy会确保将服务间流量路由到同一位置的实例。Envoy为以下策略提供了开箱即用的负载均衡算法：
● 随机
● 轮询
● 权重，最小请求数
● 一致性哈希
流量和请求路由
因为Envoy可以解析像HTTP/1.1和HTTP/2这样的应用程序协议，所以它可以使用复杂的路由规则将流量定向到特定的后端集群。Envoy可以执行基本的反向代理路由，如虚拟主机和上下文路径匹配路由；还可以执行基于头和优先级的路由、路由的重试和超时，以及故障注入。
流量转移和镜像特性
Envoy支持基于百分比（即权重）的流量分割/转移，这使得敏捷团队能够使用持续交付技术来降低风险，比如金丝雀发布。尽管这样可以将风险影响范围缩减到最小，但金丝雀发布仍然要处理实时用户流量。
Envoy也可以复制流量，将流量镜像到另一个Envoy集群。你可以将这种镜像功能看作类似于流量分割的东西，但上游集群看到的请求是实时流量的副本；因此，我们可以将被镜像的流量路由到一个服务的新版本，而不需要真正地对实时生产流量进行操作。这是一个非常强大的功能，可以在不影响客户的情况下使用生产流量测试服务变更。我们将在第5章中详细介绍。
网络弹性
Envoy可以用来解决某些类型的弹性问题，但请注意，调整和配置参数是应用程序的责任。一方面，Envoy可以自动执行请求超时和请求级重试（每次重试超时）。当请求经历间歇性的网络不稳定时，这种类型的重试行为非常有用。另一方面，重试放大可能导致级联失败，Envoy允许你限制重试行为。还要注意，你可能仍然需要应用程序级重试，并且不能完全将重试任务交给Envoy。此外，当Envoy调用上游集群时，可以为它配置bulkheading特性，比如限制正在运行的连接或未完成的请求的数量，并快速处理所有超过这些阈值的请求（在这些阈值上有些抖动）。最后，Envoy可以执行异常点检测，它的行为类似于熔断器，当节点行为不符合预期时，将其从负载均衡池中弹出。
HTTP/2和gRPC
HTTP/2是对HTTP协议的一个重大改进，它允许在单个连接上复用请求、服务端推送交互、流交互和请求反压力。Envoy从一开始就被构建为一个HTTP/1.1和HTTP/2代理，为下游和上游的每个协议提供代理功能。也就是说，Envoy可以接受HTTP/1.1连接并转为HTTP/2请求——反之亦然——或者代理传入的HTTP/2请求到上游HTTP/2集群。gRPC是一个使用Google Protocol Buffers（Protobuf）的RPC协议，它位于HTTP/2之上，同时也得到了Envoy的天然支持。这些都是强大的特性（在实现中很难得到正确的实现），并将Envoy与其他服务代理区分开来。
可观测性之指标收集
正如我们在2016年9月Lyft发布的Envoy公告中看到的那样，Envoy的目标之一就是帮助人们理解网络。Envoy收集了大量的指标来实现这一目标。它追踪调用它的下游系统、服务器本身，以及向其发送请求的上游集群的多维指标。Envoy的统计数据以计数器、量表或直方图的形式进行追踪。表3.1列出了为上游集群追踪的统计数据类型的一些示例。
表3.1 Envoy代理收集的一些统计数据
Envoy可以使用可配置的适配器和格式发送统计数据。Envoy支持以下功能，开箱即用：
● StatsD
● Datadog;DogStatsD
● Hystrix格式化
● 通用指标服务
可观测性之分布式调用链路追踪
Envoy可以向OpenTracing引擎报告追踪的span，以可视化调用链路中的流量、跳转和延迟。这意味着你不必安装特殊的OpenTracing库。此外，应用程序负责传播必要的Zipkin头文件，这可以通过薄包装器库来完成。
Envoy生成一个x-request-id头来关联跨服务的调用，还可以在触发追踪时生成初始的x-b3*头。应用程序负责传播的头信息如下：
● x-b3-traceid
● x-b3-spanid
● x-b3-parentspanid
● x-b3-sampled
● x-b3-flags
自动终止和发起TLS
Envoy可以在集群的边缘和服务代理网格的深处终止以特定服务为目的地的传输层安全（Transport Level Security，TLS）流量。一个更有趣的功能是，Envoy可以用来代表应用程序向上游集群发起TLS流量。对于企业开发人员和运维人员来说，这意味着我们不必处理特定于语言的设置和密钥库或信任库。只要在请求路径中有Envoy，我们就可以自动获得TLS，甚至双向TLS。
限流
弹性的一个重要方面是能够限制对受保护资源的访问。诸如数据库、缓存或共享服务这样的资源可能会因为各种原因而受到保护：
● 调用开销很大（每次调用的开销）。
● 缓慢或不可预测的延迟。
● 保护免受饥饿的公平算法。
特别是当服务被配置为重试时，我们不希望放大系统中某些故障的影响。为了帮助控制这些场景中的请求，我们可以使用全局限流服务。Envoy可以在网络（每个连接）和HTTP（每个请求）级别上与限流服务集成。我们将在第14章中展示如何做到这一点。
Envoy扩展
Envoy的核心是一个字节处理引擎，可以在其上构建协议（第7层）编解码器（称为过滤器）。Envoy使构建额外的过滤器成为一级用例，并且是为特定用例扩展Envoy的一种令人兴奋的方式。Envoy过滤器是用C++编写的，并编译成Envoy二进制文件。此外，Envoy还支持Lua脚本和WebAssembly（Wasm），以一种侵入性更小的方式扩展Envoy的功能。Envoy扩展将在第14章中讨论。
Envoy的优点是扮演应用程序或服务代理的角色，Envoy通过代理促进应用程序之间的对话，并解决可靠性和可观测性的问题。其他代理已经从负载均衡器和Web服务器演变成功能更强大和性能更高的代理。其中一些社区发展得不那么快，或者封闭源代码，并且花了一段时间才发展到可以在应用程序到应用程序的场景中使用。特别地，Envoy在这些领域相对于其他代理而言大放异彩：
● WebAssembly的可扩展性。
● 开放社区。
● 构建便于维护和扩展的模块化代码库。
● 支持HTTP/2（上游和下游）。
● 深度协议指标收集。
● C++/非垃圾回收。
● 动态配置，无须热重启。
更具体、更详细的对比，请参见以下内容：
● Envoy文档和比较：“链接1”。
● Turbine实验室从Nginx切换到Envoy：“链接2”。
● Cindy Sridharan对Envoy的初步看法：“链接3”。
● 为什么Ambassador（API Gateway）选择Envoy，而不是HAProxy和Nginx：“链接4”。
Envoy由JSON或YAML格式的配置文件驱动。配置文件指定监听器、路由规则和集群，以及特定于服务器的设置，比如是否启用Admin API、访问日志应该放在哪里、追踪引擎的配置，等等。如果你已经熟悉Envoy及其配置，那么可能知道Envoy配置有不同的版本。最初的版本v1和v2已经被弃用，取而代之的是v3。在本书中，我们只讨论v3的配置，因为这是当前Istio使用的版本。
Envoy的v3配置API被构建在gRPC上。Envoy和v3 API的实现者在调用API时可以利用流功能，并减少Envoy代理聚合到正确配置所需的时间。在实践中，这消除了轮询API的需要，并允许服务器向Envoy推送更新，而不是代理定期轮询。
我们可以使用Envoy的配置文件指定监听器、路由规则和集群。以下是一个非常简单的Envoy配置：
这个简单的Envoy配置文件声明了一个监听器，该监听器在15001端口上打开一个socket，并将过滤器链附加到该socket上。过滤器使用路由指令配置Envoy中的http_connection_manager。本例中给出的简单路由指令是为了匹配通配符“*”，并将其所有流量路由到httpbin_service集群。配置的最后一部分定义了到httpbin_service集群的连接。这个示例指定LOGICAL_DNS用于端点服务发现，ROUND_ROBIN用于与上游httpbin服务通信时的负载均衡。更多信息请参阅Envoy文档。
这个配置文件创建了一个监听器，传入的流量可以连接到它，并将所有流量路由到httpbin集群。它还指定使用何种负载均衡设置，以及使用何种类型的连接超时。如果调用这个代理，我们希望请求被路由到httpbin服务。
注意，大部分配置都是显式指定的（有哪些监听器、路由规则是什么、可以路由到哪些集群，等等）。这是一个完全静态的配置文件示例。在前几节中，我们指出Envoy可以动态地配置其各种设置。在Envoy的实践部分，我们将使用静态配置，但是会先介绍动态服务，以及Envoy如何使用其xDS API进行动态配置。
Envoy可以使用一组API来执行内联配置更新，而无须重启。它只需要一个简单的引导配置文件，将配置指向正确的发现服务API；其余都是动态配置的。Envoy使用以下API进行动态配置：
● LDS（Listener Discovery Service）——允许Envoy查询应该在该代理上公开哪些监听器的API。
● RDS（Route Discovery Service）——监听器配置的一部分，指定使用哪些路由。这是LDS的一个子集，用于确定应该使用静态配置还是动态配置。
● CDS（Cluster Discovery Service）——这个API允许Envoy发现该代理应该拥有哪些集群以及每个集群各自的配置。
● EDS（Endpoint Discovery Service）——集群配置的一部分，指定用于特定集群的端点。这是CDS的一个子集。
● SDS（Secret Discovery Service）——用于分发证书的API。
● ADS（Aggregate Discovery Service）——对其他API的所有更改的序列化流。你可以使用这个API按顺序获取所有更改。
这些API被统称为xDS服务。配置时可以使用其中一种或几种组合；你不需要把它们都用上。注意，Envoy的xDS API是建立在最终一致性的前提下的，正确的配置最终会收敛。例如，Envoy可以通过一个新路由来更新RDS，该路由将流量路由到一个还没有在CDS中更新的foo集群。在CDS更新之前，该路由可能会引入路由错误。Envoy引入了ADS来解释这个竞争条件，Istio为代理配置的更改实现ADS。
例如，要动态地发现Envoy代理的监听器，我们可以使用如下配置：
使用这个配置，我们不需要在配置文件中显式地配置每个监听器。我们告诉Envoy在运行时使用LDS API来发现正确的监听器配置值。但是，我们确实显式地配置了一个集群：LDS API所在的集群（在本例中名为xds_cluster）。
举一个更具体的例子，Istio为它的服务代理使用了一个bootstrap配置，类似于如下配置：
我们修改一个简单的静态Envoy配置文件，看看Envoy是如何工作的。
Envoy是用C++编写的，并被编译到本地/特定平台。使用Envoy最好的方法是，使用Docker并运行一个Docker容器。在本书中，我们一直使用Docker Desktop，但在本节中可以使用任何Docker守护进程。例如，在一台Linux机器上，你可以直接安装Docker。
首先引入三个Docker镜像，我们将使用它们来探索Envoy的功能：
我们先创建一个简单的httpbin服务。如果你不熟悉httpbin，则可以访问“链接5”并探索不同的可用端点。它基本上实现了一个服务，该服务可以返回用于调用它的头、延迟HTTP请求或抛出错误，这取决于我们调用的端点，例如/headers端点。一旦启动了httpbin服务，我们将启动Envoy并配置其将所有流量代理到httpbin服务，然后启动一个客户端应用程序并调用代理。这个例子的简化架构如图3.4所示。
图3.4 我们将使用示例应用程序来实现Envoy的一些功能
执行如下命令，设置在Docker中运行的httpbin服务：
查询/headers端点，测试新的httpbin服务是否被正确部署：
你应该会看到类似这样的输出；响应返回的是调用/headers端点的头。
现在运行Envoy代理，将--help传递给命令，并研究它的一些标志和命令行参数：
以下是一些有趣的标志：-c，用于传入配置文件；--service-zone用于指定部署代理的可用性区域；--service-node，用于为代理提供唯一名称；--log-level，控制代理的日志记录的详细程度。
运行Envoy：
发生了什么事？我们尝试运行代理，但没有传入有效的配置文件。我们来解决这个问题，并传入一个基于前面的示例配置的简单配置文件。它有这样的结构：
简单来说，我们在15001端口上暴露一个监听器，并将所有流量路由到httpbin集群。我们用这个位于源代码根目录下的配置文件（ch3/simple.yaml）来启动Envoy：
代理成功启动，并在15001端口上监听。我们使用一个简单的命令行客户端curl来调用代理：
即使调用了代理，流量也被正确地发送到httpbin服务。我们也有了一些新的头：
● X-Envoy-Expected-Rq-Timeout-Ms
● X-Request-Id
这看起来微不足道，但Envoy已经为我们做了很多。它生成了一个新的X-Request-Id，可用于关联跨集群的请求，以及潜在的跨服务的多跳来实现请求。第二个头，X-Envoy-Expected-Rq-Timeout-Ms，是对上游服务的一个提示，表示请求预计在15 000ms后超时。上游系统和请求所经过的其他任何跳点都可以使用这个提示来实现一个最后期限。最后期限允许我们将超时意图传达给上游系统，并在超过最后期限时让它们停止处理。这将在执行超时后释放资源。
现在，我们稍微修改一下这个配置，并尝试将预期的请求超时设置为1s。在配置文件中，更新route规则：
我们已经更新了这个示例的配置文件，可以在Docker镜像中找到simple_change_timeout.yaml配置文件，并把它作为参数传递给Envoy。停止现有的代理，使用这个新的配置文件重新启动它：
现在，再次调用代理：
预期的请求超时值已更改为1000。接下来，我们做一些比更改最后期限更令人兴奋的事情。
要了解Envoy的更多功能，那就要先熟悉Envoy的Admin API。Admin API让我们了解代理的行为、访问其指标和配置。我们从运行curl http://proxy：15000/stats开始：
请求响应是监听器、集群、服务器的一长串统计数据和指标列表。我们可以使用grep修改输出，只显示包含单词retry的统计数据：
如果直接调用Admin API，而没有/stats上下文路径，你应该会看到可以调用的其他端点列表。需要探索的一些端点包括：
● /certs——机器上的证书。
● /clusters——Envoy配置的集群。
● /config_dump——Envoy配置的转储。
● /listeners——Envoy配置的监听器。
● /logging——查看和更改日志设置。
● /stats——Envoy统计数据。
● /stats/prometheus——使用Prometheus记录格式化的Envoy统计数据。
让我们在对httpbin的请求中制造一些失败，并观察Envoy如何自动重试请求。我们先使用retry_policy更新配置文件：
与前面的示例一样，不必更新配置文件：在更新版本的Docker镜像中可以找到simple_retry.yaml配置文件。在启动Envoy时传入配置文件：
现在，使用/status/500上下文路径调用代理。使用该上下文路径调用httpbin（代理会这样做）会导致一个错误：
当调用完成时，我们不应该看到任何响应。发生了什么事？我们来看看Envoy的Admin API：
Envoy在与上游集群httpbin通信时遇到HTTP 500响应。这正是我们所期望的。Envoy还自动重试了请求，这是cluster.httpbin_service.upstream_rq_retry：3所指示的结果。
我们刚刚演示了Envoy的一些非常基本的功能，这些功能自动地为应用程序网络提供了可靠性。我们使用静态配置文件来解释和演示这些功能；但是正如在上一节中所看到的，Istio使用动态配置功能。这样做可以让Istio管理大量的Envoy代理，每个代理都有其潜在的复杂配置。请参阅Envoy文档或“使用Envoy sidecar代理的微服务模式”系列博客文章，以获得关于Envoy功能的更多细节。
Envoy为本书中介绍的大多数Istio特性提供了大量的支持。作为代理，Envoy非常适合服务网格的应用；然而，要从Envoy中获得最大的价值，需要配套的基础设施或组件。Istio提供的涉及用户配置、安全策略和运行时设置的支持组件创建了控制平面。Envoy也不做数据平面的所有工作，需要额外的支持来实现。要了解更多，请参阅附录B。
我们通过几个示例来说明支持组件的必要性。我们可以看到，由于Envoy的功能，我们可以使用静态配置文件配置一组服务代理，或者使用一组 xDS 发现服务在运行时发现监听器、端点和集群。Istio在istiod控制平面组件中实现了这些xDS API。
如图3.5所示，说明了istiod如何使用Kubernetes API读取Istio配置，比如VirtualService，然后动态地配置服务代理。
图3.5 Istio抽象出了服务注册表，并提供了Envoy的xDS API实现
一个相关的例子是Envoy的服务发现，它依赖某种服务注册表来发现端点。istiod实现了这个API，但也将Envoy从所有特定的服务注册表实现中抽象出来。当Istio被部署在Kubernetes上时，Istio使用Kubernetes的服务注册表来发现服务。Envoy代理完全不涉及这些实现细节。
这里还有一个例子：Envoy可以输出许多指标和遥测信息，Envoy必须配置遥测信息将发往何处。Istio将数据平面配置为与Prometheus等时间序列系统集成。我们还看到了Envoy如何将分布式追踪span发送到OpenTracing引擎，而Istio可以配置Envoy将它的span发送到那里（参见图3.6）。例如，Istio集成了Jaeger追踪引擎，也可以使用Zipkin。
图3.6 Istio配置和集成指标收集与分布式追踪基础设施
最后，Envoy可以终止和发起到网络中服务的TLS流量。为此，我们需要支持基础设施创建、签名和轮换证书。Istio通过istiod组件提供了这个功能（参见图3.7）。
图3.7 istiod提供了特定于应用程序的证书，可用于建立双向TLS，以确保服务之间的通信安全
Istio的组件和Envoy代理一起构成了一个引人注目的服务网格实现。两者都有蓬勃发展的、充满活力的社区，并面向下一代服务架构。本书的其余部分假设Envoy是一个数据平面，因此，你从本章中学到的所有知识都可以转移到其他章节。从这里开始，我们将Envoy称为 Istio 服务代理，它的功能可以通过Istio的API看到——但是要知道，许多功能实际上都来自Envoy并由Envoy实现。
在下一章中，我们将介绍如何通过边缘网关/代理来控制流量，从而开始将流量引入服务网格集群中。当集群之外的客户端应用程序希望与运行在集群内的服务通信时，我们需要非常清楚和明确地知道哪些流量是允许的，哪些是不允许的。我们将研究Istio的网关，以及它如何提供建立受控入口点所需的功能。本章的所有知识都将适用：Istio的默认网关是建立在Envoy代理上的。
● Envoy是应用程序可以用于应用程序级行为的代理。
● Envoy是Istio的数据平面。
● Envoy能够一致且正确地解决云的可靠性问题（网络故障、拓扑变化、弹性）。
● Envoy使用了一个动态的API来控制运行时（Istio使用的）。
● Envoy公开了许多关于应用程序使用和代理内部的强大指标和信息。