热启动
易于操作是特使的主要目标之一。除了强大的统计数据和本地管理界面之外，Envoy还具有“热”或“实时”重启的能力。这意味着Envoy可以完全重新加载自己（代码和配置）而不会丢失任何连接。热启动功能具有以下通用架构：
- 统计和一些锁保存在共享内存区域。这意味着在重启过程中，仪表将在两个过程中保持一致。
- 两个活动进程使用基本的RPC协议通过unix域套接字相互通信。
- 新进程完全初始化自己（加载配置，执行初始服务发现和健康检查阶段等），然后再请求旧进程的侦听套接字的副本。新流程开始监听，然后告诉旧流程开始排水。
- 在排水阶段，旧的进程试图正常关闭现有的连接。如何完成取决于配置的过滤器。排水时间可通过 - 排水时间选项进行配置，并且随着排水时间的增加，排水更加积极。
- 排水顺序后，新的特使进程告诉旧的特使进程关闭自己。这一次可以通过--parent-shutdown-time-s选项来配置。
- 特使的热启动支持被设计成即使新的特使进程和旧的特使进程在不同的容器内运行，它也能正常工作。进程之间的通信仅使用unix域套接字进行。
- 源代码发行版中包含以Python编写的示例重启器/父进程。这个父进程可用于标准的进程控制工具，如monit / runit /等。
动态配置
特使的架构使得不同类型的配置管理方法成为可能。部署中采用的方法将取决于实现者的需求。完全静态的配置可以实现简单的部署。更复杂的部署可以递增地添加更复杂的动态配置，缺点是实现者必须提供一个或多个基于外部REST的配置提供者API。本文档概述了当前可用的选项。
- 顶级配置参考。
- 参考配置。
- Envoy v2 API概述。
完全静态
在完全静态配置中，实现者提供了一组侦听器（和过滤器链），集群以及可选的HTTP路由配置。动态主机发现只能通过基于DNS的服务发现来实现。配置重新加载必须通过内置的热启动机制进行。
虽然简单，但可以使用静态配置和优雅的热重启来创建相当复杂的部署。
仅限SDS / EDS
服务发现服务（SDS）API提供了一种更高级的机制，Envoy可以通过该机制发现上游群集的成员。SDS已在v2 API中重命名为Endpoint Discovery Service（EDS）。在静态配置的基础上，SDS允许Envoy部署避开DNS的限制（响应中的最大记录等），并消耗更多用于负载平衡和路由的信息（例如，金丝雀状态，区域等）。
SDS / EDS和CDS
群集发现服务（CDS）API层上Envoy可以发现路由期间使用的上游群集的机制。Envoy将优雅地添加，更新和删除由API指定的集群。这个API允许实现者构建一个拓扑，在这个拓扑中，Envoy在初始配置时不需要知道所有的上游集群。通常，在与CDS一起进行HTTP路由（但没有路由发现服务）时，实现者将利用路由器将请求转发到HTTP请求标头中指定的集群的能力。
虽然可以通过指定完全静态集群来使用没有SDS / EDS的CDS，但我们建议仍然使用SDS / EDS API来通过CDS指定集群。在内部，更新集群定义时，操作是优雅的。但是，所有现有的连接池将被排空并重新连接。SDS / EDS不受此限制。当通过SDS / EDS添加和删除主机时，群集中的现有主机不受影响。
SDS / EDS，CDS和RDS
路由发现服务（RDS）API层，Envoy可以在运行时发现HTTP连接管理器过滤器的整个路由配置。路由配置将优雅地交换，而不会影响现有的请求。该API与SDS / EDS和CDS一起使用时，允许执行者构建复杂的路由拓扑（流量转移，蓝/绿部署等），除了获取新的Envoy二进制文件外，不需要任何特使重启。
SDS / EDS，CDS，RDS和LDS
侦听器发现服务（LDS）在Envoy可以在运行时发现整个侦听器的机制上分层。这包括所有的过滤器堆栈，直到并包含嵌入式参考RDS的HTTP过滤器。在混合中添加LDS可以使Envoy的几乎所有方面都能够进行动态配置。只有非常少见的配置更改（管理员，跟踪驱动程序等）或二进制更新时才需要热启动。
初始化
Envoy在启动时如何初始化是复杂的。本节将从高层次解释流程的工作原理。以下所有情况都发生在任何听众开始收听并接受新连接之前。
- 在启动过程中，集群管理器会经历多阶段初始化，首先初始化静态/ DNS集群，然后是预定义的SDS集群。然后，如果适用，它将初始化CDS，等待一个响应（或失败），并执行CDS提供的集群的相同主/次初始化。
- 如果群集使用主动健康检查，特使也做一个活跃的HC轮。
- 集群管理器初始化完成后，RDS和LDS将初始化（如果适用）。在LDS / RDS请求至少有一个响应（或失败）之前，服务器不会开始接受连接。
- 如果LDS本身返回需要RDS响应的侦听器，则Envoy会进一步等待，直到收到RDS响应（或失败）。请注意，这个过程通过LDS发生在每个未来的收听者身上，并被称为收听者变暖。
- 在所有先前的步骤发生之后，听众开始接受新的连接。该流程确保在热启动期间，新流程完全能够在旧流程开始排放之前接受并处理新的连接。
排水
排水是Envoy试图优雅地脱离各种事件的连接的过程。排水发生在下列时间：
- 服务器已通过健康检查/失败管理端点进行手动健康检查失败。有关更多信息，请参阅运行状况检查过滤器体系结
- 服务器正在热启动。
- 个别听众正在通过LDS进行修改或删除。
每个配置的监听器都有一个drain_type设置，用于控制何时发生排空。目前支持的值是：
默认
特使将听取上述所有三种情况（管理员流失，热启动和LDS更新/删除）的响应。这是默认设置。
modify_only
特使只会响应上述第二和第三种情况（热启动和LDS更新/删除）而排斥监听者。如果Envoy同时拥有入口和出口监听器，则此设置很有用。可能需要在出口监听器上设置modify_only，以便在尝试进行受控关闭时依靠入口监听器耗尽来执行完整的服务器耗尽时，它们只在修改期间耗尽。
请注意，虽然排水是每个听众的概念，但它必须在网络过滤器级别上得到支持。目前唯一支持正常排水的过滤器是HTTP连接管理器，Redis和Mongo。
脚本
Envoy支持实验性的Lua脚本作为专用HTTP过滤器的一部分。
