Envoy学习笔记

Envoy是一个大规模面向服务架构设计的7层代理和通信总线，它的信条是 —— 网络应该对应用程序透明，当出现问题时，应该很容易定位到源头在网络还是应用。

Envoy的高层特性包括：

1. 进程外架构：Envoy以独立的进程、伴随着每个应用服务运行。每个应用服务都和localhost通信而不关注网络拓扑，Envoy监听localhost并转发给其它Envoy，所有Envoy构成一个网格。进程外架构的优势是：
   1. 让Envoy可以和任何编程语言交互
   2. 不会像库那样引入升级、分发的负担
2. 基于C++ 11编写：性能好
3. L3/L4过滤器架构：Envoy的核心包含L3/L4网络代理功能，可拔插的过滤器链能实现各种TCP层代理行为，以支持HTTP、TLS等协议
4. HTTP L7过滤器架构：Envoy为HTTP单独设计了一个过滤器链，实现缓冲、限速、路由/转发等功能
5. HTTP/2支持：Envoy同时支持HTTP 1.1和HTTP 2
6. HTTP L7路由：支持基于URL路径、内容类型、各种上下文属性来路由HTTP请求
7. gRPC支持：gRPC是Google开源的、以HTTP/2为传输机制的RPC框架。Envoy支持gRPC请求的路由、负载均衡
8. MongoDB、DynamoDB的L7支持
9. 服务发现和动态配置：Envoy支持一组动态配置API，能够在运行时更改流量管理配置
10. 健康检查：Envoy支持对上游服务集群进行主动健康检查、被动健康检查（断路器）
11. 高级流量管理特性：自动重试、断路器、全局限速、请求复制等等
12. 前置/边缘代理支持：尽管Envoy主要用作服务之间的代理，但是它包含TLS Termination、HTTP 1/1和HTTP/2支持、HTTP L7路由等特性，可以作为大部分现代Web应用的边缘代理
13. 可观察性：Envoy的所有子系统都支持指标统计，指标可以落地到Statd或其它兼容的服务。统计信息也可以通过管理端口查询
14. 分布式跟踪：支持基于第三方Tracer的分布式跟踪

此图来自https://jimmysong.io。

Envoy可以作为服务网格的数据平面。

Envoy提出的资源发现协议集 —— xDS（包括CDS、EDS、LDS、RDS，以及后续补充的密钥发现服务/SDS、聚合发现服务/ADS、健康发现服务/HDS、限速服务/RLS等），已经被多个服务网格项目支持，其中包括著名的Istio。这些项目主要实现服务网格的控制平面。

xDS有时候也用于代指实现xDS API的那些发现服务。Envoy通过订阅（subscription）方式获取资源的更新，具体有三种：

1. 文件订阅：监控指定路径下的文件，最简单的动态资源发现方式
2. gRPC订阅：向发现服务发起gRPC请求，后者主动将更新推送过来
3. REST-JSON轮询订阅：向发现服务发起REST长轮询

Envoy采用单进程多线程的线程模型，其中一个master线程控制一些零散的协作任务，若干worker线程负责监听、过滤、转发。一旦监听器接受了连接，连接的后续生命周期都绑定到单个工作线程。

Envoy完全使用非阻塞的网络调用，大部分工作负载下，worker的数量应该设置的和硬件线程数量一致。

Envoy支持在单个进程中创建任意数量的监听器，通常建议在一台机器上仅部署单个Envoy，不管需要多少监听器。目前Envoy仅仅支持TCP监听器。

每个监听器都可以独立的配置若干网络（L3/L4）过滤器。一旦监听器接收到新的连接，过滤器链就会被初始化，并负责处理连接的后续事件。

你还可以为监听器配置“监听器过滤器”，这些过滤器在网络过滤器之前执行，能够操控连接元数据，影响连接的后续处理行为。

监听器发现服务（Listener discovery service，LDS）用于动态的发现监听器。

通过LDS加载的监听器必须在预热（warmed）之后才能接收流量。例如，如果监听器引用一个RDS配置，RDS必须被解析、抓取，然后监听器才能预热。

这种过滤器用于操控连接的元数据信息。监听器过滤器的API比较简单，它仅仅操控新接受的套接字。

网络层（L3/L4）过滤器是Envoy连接处理的核心。Envoy的过滤器API允许若干过滤器被编排、匹配、关联到指定的监听器。

网络过滤器分为三类：

1. 读过滤器：当从下游连接接收到数据后调用
2. 写过滤器：当写入数据给下游服务器时调用
3. 读写过滤器：对下游连接读写数据时都调用

网络过滤器的API也比较简单，因为过滤器仅仅处理原始字节和少量连接事件（例如TLS握手完成、连接断开）。

过滤器链中某个成员可以停止处理并迭代到下一个过滤器。

过滤器可以共享针对同一下游连接的静态、动态的状态信息。

HTTP对于现代SOA架构非常重要，因此Envoy实现了大量针对HTTP协议的功能。其中一个是网络过滤器  —— HTTP连接管理器。该管理器将原始字节转换为HTTP报文和事件（报文头已接收、报文体已接收…），并且负责访问日志、请求ID生成和追踪、请求/响应头操控、路由表管理、统计指标收集。

HTTP连接管理器支持HTTP 1.1、HTTP 2、WebSocket协议，但是不支持SPDY。

Envoy在HTTP连接管理器内部支持HTTP过滤器链。HTTP过滤器操控HTTP消息，不需要理解底层协议（HTTP/1.1，HTTP/2…）。

HTTP过滤器分为三种：

1. 解码过滤器：当HTTP连接管理器执行请求解码时调用
2. 编码过滤器：当HTTP连接管理器进行响应编码时调用
3. 编解码过滤器

Envoy包含了一个HTTP Router Filter，用于执行高级的路由任务，不管是处理边缘流量还是网格内部流量，都可以用到此过滤器。

Envoy具有作为正向代理的能力，网格的客户端需要将其HTTP代理设置为一个Envoy实例，以使用代理。

此过滤器实现的特性包括：

1. 虚拟主机：将Domain/Authority映射到一组路由规则（作为路由决策的一部分）
2. 前缀或精确的路径匹配
3. 在虚拟主机级别的TLS重定向
4. 在路由级别的Path/Host重定向
5. 在路由级别直接返回响应
6. 显式的Host改写
7. 基于选中的上游Host的DNS名称进行自动的Host改写
8. 路径前缀改写
9. 根据请求头或者路由配置，进行HTTP重试
10. 根据请求头或者路由配置，设定HTTP超时
11. 流量转移：根据运行时值将流量从一个上游集群转移到另外一个
12. 流量分割：在多个上游集群之间分配流量比例
13. 根据请求头路由
14. 基于优先级的路由
15. 基于哈希策略的路由
16. 对于非TLS正向代理，支持绝对URL

HTTP连接管理器维护所有HTTP过滤器所使用（尽管路由过滤器是主要使用者）的路由表，这样过滤器可以根据目的地作出决策。

Envoy提供一系列静态、动态状态，用于在过滤器之间或者向其它核心子系统（例如访问日志）传递配置、元数据、请求/连接的状态。

静态状态是在配置加载阶段（例如通过xDS）生成的不可变信息。静态状态分为三类：

静态状态	说明
元数据	某些Envoy配置（例如监听器、路由、集群）包含元数据，元数据是任意数量的键值对。通常以过滤器名称的DNS反转写法为Key，以过滤器特有的配置为Value。 元数据是不可变的，且被所有请求/连接共享。这些元数据要么在Bootstrap时提供，要么作为xDS的一部分提供
强类型元数据	过滤器可以注册一个转换器，在接收到（通过xDS）配置元数据时将指定的Key转换为强类型的C++对象，这样过滤器不需要在每次处理连接/请求时都执行ProtobufWkt::Struct到某种内部结构的转换
HTTP路由过滤器配置	HTTP过滤器可以提供针对单个虚拟主机的配置，用于覆盖全局的、面向所有虚拟主机的配置

动态状态为每个网络连接或者HTTP流生成。取决于生成动态状态的过滤器，这些状态可以变化。

Envoy::Network::Connection和Envoy::Http::Filter提供StreamInfo对象，此对象包含当前TCP连接/HTTP流的信息。StreamInfo除了包含一系列静态字段外，还包含map<string, FilterState::Object>映射，用于存储任意类型的状态。 

负责管理上游集群，可以配置任意数量的上游集群。此管理器支持两种方式获得集群：

1. 静态配置
2. 通过集群发现服务（CDS）API动态获取

上游集群从网络/HTTP过滤器栈中剥离出来，以便被不同的代理任务重用。集群管理器向过滤器暴露了API，允许它们：

1. 获取到上游集群的L3/L4连接
2. 获取用于处理上游集群的抽象（隐藏协议类型）连接池的句柄

过滤器根据需要来获取L3/L4连接或者新的HTTP流，集群管理器负责处理其它的复杂性，包括：

1. 确定哪些主机可用、健康
2. 进行负载均衡
3. 在ThreadLocal存储上游连接数据

不管是通过静态配置，还是通过CDS加载，只有当集群经过以下处理后，才是warmed状态，才可以使用：

1. 初始的服务发现加载，例如DNS解析、EDS更新
2. 初始的主动健康检查（如果配置的话）。Envoy会向每个发现的主机发送健康检查，确定其初始健康状态

讨论集群预热（cluster warming）时，所谓集群可用，是指：

1. 对于新添加的集群，仅当集群预热完毕，它才被Envoy的其它部分可见。否则，一个引用集群的HTTP Route会可能会返回404/503
2. 对于被更新的集群，在新配置预热之前，旧的集群仍然会提供服务。预热之后，新集群替换旧集群，不会发生任何的流量中断

服务发现是Envoy确定集群成员的过程，支持的服务发现类型包括：

1. 静态发现：在配置中明确指出每个上游主机的网络名称（IP地址、端口，或者UDS）
2. 严格DNS发现：Envoy持续异步的解析目标服务的DNS名称，DNS结果中返回的每个IP地址都视为上游主机
3. 逻辑DNS发现：类似于上一个，但是在需要初始化新连接时，仅仅使用DNS结果中第一个IP地址。大型Web服务常常使用循环DNS返回很多IP地址，如果使用严格DNS发现，连接池太多（每个上游主机需要一个连接池）会导致系统资源枯竭
4. 原始目的地：如果传入的连接来自Iptables重定向（可以通过conntrack表或读取SO_ORIGINAL_DST选项得到原始目的地），或者使用了代理协议（从代理协议头得到原始目的地），则可以使用其原始目的地，这种情况下实际上不需要发现上游主机
5. 端点发现服务（Endpoint Discovery Service，EDS）：一个基于gRPC/REST-JSON的xDS管理服务，Envoy使用它来获取集群成员。每个集群成员都叫端点。EDS是首选的服务发现机制

很多RPC系统的服务发现是一个完全一致性过程，它们使用一致性的领导选举算法，例如ZK、Etcd、Consul。大规模使用完全一致性会存在性能问题，因此Envoy使用最终一致性的方式。

可以为每个上游集群配置主动健康检查，对于EDS服务发现来说，主动健康检查是和服务发现过程一同进行的。其它类型的服务发现也可以联用主动健康检查。

Envoy目前支持三种健康检查：

1. HTTP：将上游主机发送HTTP请求，如果返回200则认为正常，如果返回503则立即禁止转发流量给目标端点
2. L3/L4：发送一个可配置的字节缓冲给上游主机，如果上游主机Echo了此字节缓冲，则认为通过检查
3. Redis：发送PING命令给上游Redis服务，如果返回PONG应答则认为通过检查。Envoy也可以针对特定的键进行EXISTS操作，如果键不存在则认为通过检查

Envoy目前支持检查间隔、标记为不健康需要的连续失败次数、标记为健康需要的连续成功次数等健康检查相关配置。此外，可以针对每个端点配置健康检查逻辑。

联用主动健康检查+被动健康检查时，通常会延长主动检查的间隔，避免过大的流量。你甚至可以通过管理端点 /healthcheck/fail来快速的Drain掉某个上游主机。

如果你通过管理端点标记主机为失败，则该主机的Envoy中的HTTP健康检查过滤器会自动设置响应头 x-envoy-immediate-health-check-fail。请求方的路由过滤器会识别这个头，并立即将目标主机标记为主动健康检查失败。

仅仅简单的检查一个URL，不足以判断某个服务的主机正常。原因是，在云环境下，服务实例可能被销毁，而其IP地址被其它类型服务的实例重用。

为了解决此问题，HTTP健康检查支持配置service_name选项，此选项设置后，健康检查器会额外检查x-envoy-upstream-healthchecked-cluster响应头，只有它的值和service_name选项一致，才可能通过健康检查。

Envoy支持基于异常检测（outlier detection）的被动健康检查（不刻意发起请求，而是检测业务流量是否正常）

Envoy支持为HTTP监听器配置HTTP健康检查过滤器，此过滤器允许以下操作模式：

1. 不穿透：此模式下健康检查请求不会转发给Envoy背后的上游服务，Envoy根据服务当前的draining state决定返回200还是503
2. 不穿透，根据上游集群健康状态决定检查结果：如果一个或者多个上游集群中，至少特定比例的主机是健康的，则返回200，否则503
3. 穿透：直接将健康检查请求转发给背后的服务
4. 穿透+缓存：支持一定时间的缓存

太多的穿透可能引发大量的健康检查流量。

对于HTTP流量来说，Envoy支持连接池。HTTP/1.1和HTTP/2连接池的行为有所不同：

1. HTTP/1.1：按需创建到上游主机的TCP连接，当连接可用时，将请求绑定到连接。如果TCP连接意外断开，则仅仅一个请求会被重置
2. HTTP/2：创建到上游主机的单个TCP连接，所有请求复用此连接。如果接收到GOAWAY帧或者到达最大Stream限制，则连接池会创建一个新的连接

如果针对上游主机的主动/被动健康检查失败，则此主机的连接池会被关闭；反之，如果上游主机恢复健康，则连接池会重新创建。

Envoy根据知晓的上游集群成员信息，自己决定应该把负载分发给哪个端点。

一个全局性的权威负责决定负载如何在主机之间分发。对于Envoy来说，则可以通过控制平面达成。控制平面可以调整优先级、权重、端点健康状况来满足复杂的负载均衡需求。

算法	说明
加权轮询	Weighted round robin，轮询上游主机，但是主机可以设置权重
加权最少请求	Weighted least request，使用 O(1) 算法选择两个随机健康主机，并选择主动请求较少的主机
环哈希	Ring hash，针对上游主机实现一致性哈希，此算法将所有主机映射到一个环上，这样添加/删除一个主机，仅仅1/N的请求受到影响 也叫做ketama hashing 目前不支持权重
磁悬浮	Maglev，类似针对上游主机实现一致性哈希，但具有快得多的查表编译时间以及主机选择时间（当使用 256K 条目的大环时大约分别为 10 倍和 5 倍），缺点是不如环哈希稳定，主机移除时更多请求需要移动（以达到再平衡）
随机	Random，随机选择一个健康主机

异常检测属于被动健康检查，是被动的（观测业务流量，而非主动发起流量）检查上游集群，并发现其中的不正常主机，然后将其剔除出负载均衡池的过程。

异常检测通常和主动健康检查联合使用。

根据异常检测的类型，驱除行为要么定期触发，要么在连续的异常时间发生后触发。算法工作方式如下：

1. 主机被确定为异常
2. 如果集群中没有主机被驱除，则立即驱除当前主机。否则检查被驱除主机是否小于阈值outlier_detection.max_ejection_percent，如果大于则不驱除
3. 主机被驱除，也就是标记为不健康，且不参与负载均衡。除非上游集群处于Panic状态（也就是健康主机太少）
4. 驱除持续的时间是 outlier_detection.base_ejection_time_ms * 主机已经被驱除的次数，超过此时间后，自动回到负载均衡池。主机被驱除的次数越多，则返回负载均衡池需要等待的时间越长

检测类型	说明
连续5xx	如果上游主机连续返回若干（由outlier_detection.consecutive_5xx 控制）5xx响应，则会被驱除
连续网关故障	如果上游主机连续返回若干（由outlier_detection.consecutive_gateway_failure控制）网关错误（502 503 504），则会被驱除
成功率	如果在指定聚合周期内，请求处理成功率低于阈值，则驱除 如果聚合周期内，主机请求量小于outlier_detection.success_rate_request_volume，或者聚合周期内请求量小于outlier_detection.success_rate_request_volume的主机总数小于outlier_detection.success_rate_minimum_hosts ，都不进行驱除

Envoy支持多种类型的完全分布式的断路器，以保护上游集群不因过载而崩溃：

1. 集群最大连接数：为上游集群的所有主机设置总和最大连接数。注意这仅仅适用于HTTP/1.1，因为HTTP/2为每个上游主机维护单个连接
2. 集群最大挂起请求数：排队等待可用连接的最大请求数。注意这仅仅适用于HTTP/1.1，因为HTTP/2允许多个请求复用TCP连接
3. 集群最大请求数：在给定的时间内，集群总计可以处理的请求数量
4. 集群最大活动重试次数：在给定的时间内，集群总计允许发送的重试次数

你可以针对每个上游集群进行断路器配置。

对于HTTP请求，被断路后，路由过滤器会设置响应头x-envoy-overloaded。

分布式系统中，断路器对吞吐量的控制一般非常有效。但是某些场景下，可能需要引入全局的限速机制。典型的场景例如数据库，来自大量主机的请求被转发给少量的服务器，很难在所有下游主机上配置断路器来防止级联性失败（雪崩）。

Envoy集成了全局的gRPC限速服务，Lyft提供该服务的参考实现，此外任何实现了RPC/IDL协议的程序都可以作为服务实现。

限速服务的功能包括：

1. 网络层限速过滤器：安装此过滤器的监听器，在接受新连接时就会调用限速服务。支持根据每秒连接次数进行限制
2. HTTP级限速过滤器

对于监听器，Envoy支持TLS Termination。向上游发起请求时，Envoy支持TLS Origination。Envoy的SSL支持由BoringSSL库提供。

Envoy的一个目标是使网格可理解（观察），为此它可以收集大量的统计信息，统计信息可以分为三类：

1. 下游：牵涉到传入的连接/请求。由监听器、HTTP连接管理器、TCP代理过滤器生成
2. 上游：牵涉到传出的连接/请求。由连接池、路由器过滤器、TCP代理过滤器生成
3. 服务器：牵涉到服务实例，统计指标包括服务器正常运行时间、内存分配量等

在v1版本的API中，Envoy仅仅支持Statd作为输出格式。在v2版本的API中，可以使用自定义，可拔插的统计信息接收器。

统计信息都使用规范化的字符串来标识，字符串的动态部分被抽取成为标签（Tag）。

Envoy支持Counter、Gauge、Histogram三种指标类型。

在大型分布式架构中，分布式追踪让调用过程能够被可视化的展示，在了解串并行执行、延迟分析时非常重要。

Envoy包含三个和分布式追踪相关的特性：

1. 请求ID生成：如果需要，Envoy会自动生成 x-request-id 头表示请求UUID
2. 外部追踪服务集成：Envoy支持可拔插的、外部的追踪可视化服务。目前支持LightStep，Datadog，Zipkin，以及任何Zipkin兼容的服务（例如Jaeger）
3. 客户端Trace ID连接：头x-client-trace-id可以用于将不受信任的请求ID连接到内部受信任的x-request-id

初始化追踪的方式有多种：

1. 外部客户端，使用 x-client-trace-id 头
2. 内部服务，使用x-envoy-force-trace头
3. 随机采样，使用运行时设置random_sampling

路由过滤器可以使用start_child_span为出口调用创建下一级Span。

Envoy提供了根据网格中服务之间通信来报告追踪信息的能力，但是要想把一个调用流中各个代理产生的追踪片断关联起来，服务必须在入口、出口请求之间传递一些上下文信息。

不管使用哪种Tracer，所有服务都必须传播x-request-id头，服务实现者可能需要在代码层次上保证这一点（技术上无法实现通用的自动传播x-request-id的机制）。

Tracer还会需要额外的上下文信息，确保Span之间的父子关系能够被理解。

可以在服务中直接调用LightStep（OpenTracing API）或Zipkin来抽取入站请求的上下文信息，并注入到出站请求中。使用这种方式，服务也可以创建额外的Span。

另外一种方式是由服务手动的传播追踪信息：

1. 如果使用LightStep，Envoy依赖服务在发起请求时传播x-ot-span-context头
2. 如果使用Zipkin，Envoy依赖服务B3请求头（x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, x-b3-flags）。外部客户端也可以提供x-b3-sampled头，以启用/禁用对某个请求的追踪
3. 如果使用Datadog，Envoy依赖服务在发起请求时传播 x-datadog-trace-id, x-datadog-parent-id, x-datadog-sampling-priority头

一个端到端的Trace包含1-N个Span。一个Span代表了一个逻辑的工作单元。工作单元包括开始时间，持续时间，以及一系列的元数据：

1. 源自的服务集群，通过--service-cluster指定
2. 开始时间、持续时长
3. 源自的主机，通过--service-node指定
4. 下游服务集群，通过x-envoy-downstream-service-cluster头指定
5. HTTP URL
6. HTTP方法
7. HTTP响应码
8. Tracer相关的信息

Envoy自动将Span发送给跟踪收集器（Tracing collector），Span根据一些公共信息（例如x-request-id）组合在一起，产生单个Trace。

TCP代理过滤器可以实现下游 - 上游的基本的1:1代理功能。

TCP代理过滤器受到上游集群全局资源管理器的连接限制的约束。

HTTP 连接管理器与 TCP 代理支持可扩展的访问记录，并拥有以下特性：

1. 可按每个 HTTP 连接管理器或 TCP 代理记录任何数量的访问记录
2. 异步 IO 架构。访问记录将永远不会阻塞主网络处理线程
3. 可定制化的访问记录格式，可使用预定义的字段，也可使用任意的 HTTP 请求和应答
4. 可定制化的访问记录过滤器，可允许不同类型的请求以及应答写入至不同的访问记录

Envoy实现了网络层的MongoDB嗅探过滤器，特性包括：

1. MongoDB的数据格式BSON的解析
2. 详细的MongoDB查询/操作统计，例如耗时、Scatter/multi-get次数
3. 查询日志
4. 基于$comment 参数做每个调用点的统计分析报告
5. 故障注入

Envoy可以作为Redis代理，在Redis实例之间进行命令分区（partitioning commands）。Envoy的目标是维持可用性、分区容忍性（partition tolerance），它实现一个尽最大努力的缓存，而不会尝试维护数据一致性或者Redis集群成员的一致性。这和Redis Cluster不同。

Envoy Redis的特性包括：

1. Redis协议编解码
2. 基于哈希的分区
3. 基于一致性哈希（Ketama）的分区
4. 详细的命令统计
5. 主动和被动健康检查

未来计划添加的特性包括：

1. 额外的耗时统计
2. 断路器
3. 对片断化命令进行请求合并
4. 数据复制
5. 内置重试
6. 追踪支持
7. Hash Tagging

Redis上游集群应该以哈希环负载均衡的方式配置（ring hash load balancing）。

此代理支持Redis流水线，但是不支持MULTI。此外，不是所有Redis命令被支持，仅仅那些可以被可靠的哈希到一个服务器的操作被支持。

一个特殊命令是PING，Envoy会直接答复PONG，为PING指定参数是不允许的。

gRPC是Google开源的RPC框架，它使用Protocol Buffer作为串行化格式。在传输层，它使用HTTP/2进行请求/应答的多路复用。

Envoy对gRPC在传输层、应用层都做了支持：

1. gRPC使用HTTP/2 Trailers来递送请求状态。Envoy是少数几个能正确支持HTTP/2 Trailers的代理——也就是能支持gRPC的代理
2. 某些语言的gRPC实现尚不成熟，Envoy提供了一些过滤器，能够将gRPC桥接到这些语言
3. Envoy通过过滤器grpc_web支持gRPC-Web，允许客户端向Envoy发送HTTP/1.1请求，由Envoy将其转换为gRPC协议并转发给上游服务器。此过滤器将在未来代替grpc_http1_bridge
4. Envoy通过过滤器支持gRPC-JSON转码，允许客户端基于REST JSON API发送请求，由Envoy转换其为gRPC请求给上游服务器

Envoy支持两种gRPC桥接：

1. grpc_http1_bridge filter：允许gRPC请求通过HTTP/1.1发送给Envoy，后者通过标准的gRPC协议转发给gRPC服务器
2. grpc_http1_reverse_bridge filter：能够将gRPC请求转换为HTTP/1.1并发送给上游服务器。此过滤器能够管理gRPC帧的头，允许上游服务器对gRPC协议一无所知

Envoy在它的控制平面中大量使用gRPC协议，例如从管理服务器订阅资源配置信息时。一些过滤器，例如限速、授权，也使用gRPC协议。

Envoy gRPC client是最小化的gRPC客户端实现，利用Envoy的HTTP/2上游连接管理机制。

Google C++ gRPC提供完备的gRPC实现，包含Envoy所缺失的特性，具有自己的负载均衡、重试、超时、端点管理等功能。

进行Envoy相关的开发时，建议使用Envoy gRPC client。

Envoy 可以在不丢失任何连接的情况下完全地重载自己，包括代码与配置。

你可以提供一组监听器（和过滤器链）、集群、HTTP路由配置。动态主机仅通过DNS发现。

如果变更配置，则可以利用Envoy的热重启机制加载最新配置。

通过服务发现服务（SDS）API，Envoy可以发现上游集群的成员，在v2版本的API中，SDS已经更名为EDS。

使用SDS可以规避DNS发现的缺点（记录数量受限），并遵从负载均衡、路由配置。

通过集群发现服务（CDS）API，Envoy可以发现上游集群。

通过路由发现服务（RDS）API，Envoy可以在运行时发现用于HTTP连接管理器过滤器的整个路由配置。路由配置可以优雅的切换，而不影响处理中的请求。

通过监听器发现服务（LDS）API，Envoy可以发现整个监听器，包括它的完整过滤器栈。

配合使用SDS/EDS、CDS、RDS 和 LDS，几乎可以动态配置Envoy的所有方面。只有非常少见的配置更改（管理员、追踪驱动程序等）或二进制更新时才需要热重启。

任何监听器启动监听并接收新连接前，会发生如下事件序列：

1. 启动期间，集群管理器会执行多步骤的初始化过程：
   1. 初始化静态/DNS集群
   2. 初始化预定义EDS集群
   3. 如果可用，初始化CDS并等待响应，然后初始化CDS提供的集群
2. 如果集群启用了健康检查，则执行一轮检查
3. 集群管理器初始化完毕后，RDS和LDS开始初始化
4. 如果LDS本身返回的监听器要求RDS响应，则Envoy会等待RDS响应的到达
5. 监听器开始接受连接

关闭（Draining）发生在以下时机：

1. 通过healthcheck/fail管理客户端，对服务器执行手工的健康检查失败
2. Envoy被热重启
3. 单个监听器通过LDS添加或移除

每个监听器都具有drain_type配置，决定何时发生Draining：

1. default，上述三种时机都发生
2. modify_only，仅仅上述2-3时发生

HTTP过滤器支持使用Lua脚本。

这是一个可扩展组件，用于保护Envoy本身（和断路器不同），防止过载导致各种系统资源（内存、CPU、文件描述符）不足。和断路器用于保护上游服务的目的不同，过载管理器是为了保护Envoy代理所在机器本身。

1. 访问日志：
   1. 支持字段%DOWNSTREAM_LOCAL_PORT%
   2. 引入连接级别的日志记录器
2. 自适应并发：
   1. 修复允许的并发限制小于配置的最小值的缺陷
3. 管理：
   1. 支持再certs页面显示IP地址的SAN
   2. POST /reopen_logs用于控制日志轮换
4. API：冻结v2 xDS API，新特性将在v3 xDS中开发。v2 xDS API目前已经启用，支持在2020年底结束
5. AWS特性：
   1. 过滤器aws_lambda，能够将HTTP请求转换为Lambda调用
   2. aws_request_signing，一些缺陷修复
6. 配置：
   1. 添加统计项update_time
7. 数据源：为远程异步数据源天津爱重试策略
8. DNS：
   1. 为DNS缓存添加dns_failure_refresh_rate配置项，可以设置失败期间的DNS刷新率
   2. 如果DNS查询返回0主机，则STRICT_DNS类型的集群仅仅解析0主机
9. EDS：
   1. 为端点、端点的健康检查增加hostname字段。可以实现自动hostname重写，定制健康检查使用的host头
10. HTTP：
    1. HTTP1.1泛洪保护
    2. 配置 headers_with_underscores_action，指定遇到具有下划线的HTTP头时怎么处理，可以允许头、丢弃头、拒绝请求
    3. 配置max_stream_duration，允许指定现有流持续时间
11. LB：
    1. 支持使用hostname进行一致性哈希负载均衡（consistent_hash_lb_config）
12. Lua：
    1. 为httpCall添加一个参数，是其可以异步化
    2. 添加moonjit支持
13. 网络过滤器：
    1. 添加envoy.filters.network.direct_response
14. RBAC：
    1. 添加remote_ip、 direct_remote_ip 用于匹配下游远程地址。启用source_ip
15. request_id_extension：可以在HTTP连接管理器中扩展request id处理逻辑

1. 完全移除对v1 API的支持
2. 添加对xDS v3 API的支持
3. 集群：支持聚合集群，在多个集群之间进行负载均衡
4. 监听器：添加reuse_port选项
5. 限速：支持本地限速
6. RBAC：支持基于所有SAN进行匹配principal_name
7. 路由：支持基于百分比的retry budgets
8. 路由：允许基于查询参数进行一致性哈希
9. 路由：添加auto_sni，支持基于下游HTTP host/authority头来设置SNI
10. TCP代理：添加hash_policy
11. UDP代理：初步支持
12. 支持HTTP/1.1泛洪保护，此特性可以通过运行时特性envoy.reloadable_features.http1_flood_protection停用

1. 配置：支持增量xDS（包括ADS）传递
2. 配置：确保终止过滤器（例如L4的HTTP连接管理器、L7的路由器）位于过滤器链的尾部
3. HTTP：支持自动合并Path中连续的 /
4. HTTP：支持在正向代理中进行host rewrite

1. 支持Dubbo Proxy过滤器
2. 健康检查：添加initial jitter，在第一次健康检查时添加jitter，防止Envoy启动时的惊群效应
3. 热重启：新旧进程不再通过共享内存共享状态，而是gRPC
4. HTTP：支持正向代理
5. 监听器：添加基于source IP、source Port的过滤器链匹配
6. 添加original_src过滤器，可以获取原始的源地址

1. 添加CSRF过滤器
2. 支持将gRPC请求转换为HTTP/1.1请求
3. 添加MySQL过滤器，能够基于MySQL wire协议解析SQL查询
4. 路由：虚拟主机域名支持前缀统配
5. 添加Tap HTTP过滤器，用于录制流量

名词	说明
Host	一个支持网络通信的实体，例如手机、服务器、虚拟机上的应用程序  这里的Host是逻辑的网络应用，一个物理设备上可以有很多Host，只要它们可以被独立寻址
Downstream	向Envoy发送请求、接收响应的Host
Upstream	Envoy向其发送请求、接收响应的Host
Listener	命名的网络位置，例如端口、UNIX域套接字，可以被下游Host连接 Envoy暴露一个或多个Listener供下游主机连接
Cluster	一组逻辑相似的上游Host。Envoy通过服务发现机制识别Cluster的成员，并可选的通过主动健康检查确认Cluster成员的健康状态 Envoy根据负载均衡策略来决定将请求路由给哪个成员
Mesh	一组Host通过协作产生的网络拓扑。Envoy Mesh是指由Envoy代理构成的Mesh
Runtime Config	不需要重启就可以重新配置Envoy的机制

这种场景下，Envoy仅仅代理一个SOA架构的内部的通信，Envoy需要暴露若干监听器，供本地发起的流量、服务到服务的流量使用。

用于本地应用程序和基础设施中其它服务进行交互。HTTP/gRPC请求通过HTTP/1.1的host头或HTTP/2的authority来指示它的目标是哪里。Envoy负责处理服务发现、负载均衡、限速。

本地应用程序仅仅需要和Envoy通信，而不需要知道网络拓扑，不需要知道自己运行在开发环境还是线上环境。

这种监听器供需要和本地Envoy通信的外部Envoy使用。流量被路由到本地服务的端口。本地代理负责缓冲、断路器等功能。

通常来说，对于每个本地服务需要与之通信的外部服务，都分配一个明确的、独占的出口端口。这是由于某些外部服务的SDK无法容易的基于重写host头来实现标准的HTTP反向代理行为。

可以在服务到服务部署方式基础上，配合基于Envoy实现的边缘代理。并在边缘代理实现：

1. TLS Termination
2. 同时支持HTTP/1.1和HTTP/2
3. 完整的HTTP L7路由支持
4. 基于标准的Ingress端口和S2S的Envoy集群通信

尝试Envoy功能最轻松的途径是使用官方的Docker镜像：

 此镜像包含了一个默认的配置，将入站请求路由给某个外部网站：

在容器中执行下面的容器启动Envoy：

启动完毕后，Envoy会监听环回网卡的9901端口，以及0.0.0.0:10000端口。可以在容器中

验证是否访问到了blog.gmem.cc。 

在Envoy源码的examples目录下，有若干基于Docker Compose创建的沙盒环境，可以用来试验Envoy各方面的功能。 

Envoy使用Bazel作为构建系统。 

尽管基于GCC 4.9编译的Envoy已经在生产环境中运行，最好使用GCC 5以上版本，原因是std::string线程安全有关的一个缺陷。

从GCC 5.1开始，libstdc++引入了一个新的库ABI，此ABI包含新的std::string、std::list实现，遵循2011 C++标准：

1. 禁止Copy-On-Write字符串
2. List应当跟踪自身的尺寸

为了保持对已经链接到libstdc++的程序的向后兼容，libstdc++的soname没有修改，老版本和新版本并行存在于同一个库文件中。具体实现方式是，在内联的命名空间中定义新的实现，例如新版本的 std::list<int>实际上定义在std::__cxx11::list<int>。

宏_GLIBCXX_USE_CXX11_ABI决定了libstdc++库的头文件使用新的还是就的ABI，这意味着每个源文件都可以决定自己在编译时使用新的还是就的ABI。GCC 5默认配置此宏为1也就是新ABI，但是某些Linux发行版配置为0，你需要手工定义此宏为1才能使用新ABI。

Clang 4.0以上版本也被支持。但是注意默认情况下Clang丢弃了格式化打印所需的一些调试符号，你需要在.bazelrc文件中添加 --copt=-fno-limit-debug-info解决。

Envoy支持三种编译模式，可以通过Bazel的-c参数传递：

1. fastbuild，即 -O0，默认值，用于开发环境
2. opt，即 -O2 -DNDEBUG -ggdb3，用于产品环境和性能基准测试
3. dbg，即 -O0 -ggdb3，不优化，保留调试符号

修改编译模式的例子：

下面的可选特性可通过Bazel命令行参数禁用：

1. 热重启，通过--define hot_restart=disabled禁用
2. Google C++ gRPC客户端，通过--define google_grpc=disabled禁用
3. 捕获到信号时打印堆栈，通过--define signal_trace=disabled禁用
4. tcmalloc，通过-define tcmalloc=disabled禁用

下面的可选特性可通过Bazel命令行参数启用：

1. 在链接时导出符号：--define exported_symbols=enabled，如果你的Lua脚本加载共享对象库，可以启用
2. Perf注解：--define perf_annotation=enabled，用于配合性能剖析
3. 在FIPS兼容模式下构建BoringSSL：--define boringssl=fips
4. 内存调试：--define tcmalloc=debug

Envoy使用模块化的构建风格，不需要的扩展可以被移除。所有可以被禁用的扩展列在文件中extensions_build_config.bzl中。

使用下面的步骤来定制你需要的扩展集：

1. 构建Envoy时，默认假设@envoy_build_config//:extensions_build_config.bzl存在，此文件默认包含所有扩展
2. 创建一个新的WORKSPACE，在其中包含：
   1. 空白的WORKSPACE文件
   2. 空白的BUILD文件
   3. extensions_build_config.bzl的拷贝
   4. 注释掉你不需要的扩展

要想让你的本地构建使用修改后的extensions_build_config.bzl，可以使用下面两种方法之一：

1. 使用--override_repository选项，覆盖@envoy_build_config存储库
2. 在你的WORKSPACE中添加如下片断：
   
   Shell

   1 2 3 4 5 6 7

   workspace(name = "envoy")   local_repository(     name = "envoy_build_config",     # Relative paths are also supported.     path = "/somewhere/on/filesystem/envoy_build_config", )

Envoy把构建环境固化在Docker镜像中，可以执行下面的命令在容器中构建Envoy：

为了便于开发者，Envoy提供了一个WORKSPACE、构建最近版本的依赖的规则集，这仅仅适用于开发和测试，因为依赖可能不是最新的而包含安全缺陷。

构建步骤如下：

1. 安装Bazel
2. 安装必要的库和工具：
   
   Shell

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   echo "deb http://apt.llvm.org/trusty/ llvm-toolchain-trusty-7 main" | sudo tee /etc/apt/sources.list.d/llvm.list sudo apt-get install \    libtool \    cmake \    realpath \    clang-format-7 \    automake \    ninja-build \    curl \    unzip   # Ubuntu 14.04执行下面的步骤，因为需要GCC-5，因此添加下面的源并安装 sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt-get update sudo apt-get install gcc-5 g++-5 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5 1 --slave /usr/bin/g++ g++ /usr/bin/g++-5

3. 安装Golang SDK，构建BoringSSL、Buildifer（用于格式化BUILD文件）需要用到
4. 安装buildifier：
   
   Shell

   1 2	go get github.com/golang/protobuf/proto go get github.com/bazelbuild/buildtools/buildifier

5. 进入Envoy源码根目录，执行：
   
   Shell

   1	bazel build  --copt "-DENVOY_IGNORE_GLIBCXX_USE_CXX11_ABI_ERROR=1"  //source/exe:envoy-static

可以手工删除~/.cache/bazel，以清除全部缓存。 

如果想理解Bazel在做什么，可以启用-s、--explain选项，Bazel会提供更多的输出。

Bazel提供了支持CLion的插件，可以将Bazel项目导入到CLion中。但是CLion是基于CMake的，必须生成CMakeLists.txt才能进行代码导航，否则到处都是红色的错误。

bazel-cmakelists是一个Python小工具，能够从Bazel的C++目标生成CMakeLists.txt。

执行下面的命令，可以生成CMakeLists.txt：

Istio为Envoy添加了mixer、authn等多个过滤器，这些过滤器代码是独立在Istio Proxy项目中维护的。

Istio Proxy项目以Bazel外部依赖的形式引入Envoy的源码

你可以修改ENVOY_SHA来引用其它版本的Envoy源码。

执行下面的命令，构建出包含了Istio特有过滤器的Envoy二进制文件：

运行下面的命令，执行所有测试：

如果报错ERROR: circular symlinks detected，说明存在符号链接错误。存在错误的路径会打印在控制台，手工修改一下即可。 

运行下面的命令，仅仅执行的单元测试test/common/http:async_client_impl_test：

要查看更多的测试日志输出，使用下面的选项：

要为测试用例传递额外的命令行参数，使用下面的选项：

默认情况下，用例同时针对IPv4和IPv6测试，在仅仅支持IPv4或IPv6的环境下，可以使用下面的环境变量：

默认情况下，Envoy运行测试时使用gperftools的normal模式来检查堆内存泄漏，你可以禁用gperftools或者修改模式：

内存泄漏的偏移量需要通过addr2line来解释，可以利用 --config=clang-asan选项自动化的进行地址到代码行的转换。 

默认情况下，已经通过的测试结果会被缓存，不再测试。如果要强制重新测试，使用选项：

默认情况下，所有测试在沙盒中运行，不能访问本地文件系统。 使用下面的选项可以禁用沙盒：

某些测试要求特殊权限，例如CAP_NET_ADMIN。在物理机上运行测试时，你可以用sudo提权。

如果在容器环境下测试且需要特权，可以利用tools/bazel-test-docker.sh脚本，此脚本可以在本地或者远程Docker引擎上以--privileged运行测试。此脚本的调用格式如下：

此脚本读取两个环境变量：

1. RUN_REMOTE=yes|no，是否在远程Docker引擎上执行
2. LOCAL_MOUNT=yes|no，是否拷贝或挂载本地库到容器中

你可以启用GCC的ASAN（address sanitizer，地址消毒剂，检测内存访问错误）、UBSAN（undefined behavior sanitizer，未定义行为消毒剂），来构建和测试Envoy：

包含行号的ASAN错误栈会打印出来，如果看不见符号，尝试将环境变量ASAN_SYMBOLIZER_PATH设置到 llvm-symbolizer所在位置，后者将 llvm-symbolizer放入$PATH。

如果使用clang-5.0或更高版本构建，可以启用额外的sanitizer：

Envoy能够根据需要生成堆栈追踪（backtraces），也可以由断言或其它失败（例如段错误）触发栈追踪。

在不支持absl::Symbolization的系统上，打印到日志或者标准错误的栈追踪包含地址而非符号。脚本tools/stack_decode.py可以来将这些地址转换为符号+行号。用法示例：

你需要使用dbg或者opt构建类型，这样才能从二进制文件中获取符号信息。

下面的命令示意了如何在GDB之下运行单个Bazel测试：

下面的命令示意了如何测试符号表正常：

如果调试符号表可用，则可以看到envoy-static的main.cc的源码。

你可能需要设置souce path，否则GDB找不到源码而进行反汇编：

如果想Attach到现有Envoy进程，可以点选Run - Attach to Process...并选中envoy-static进程。关于Clion Attach方式调试的注意点参考：CLion知识集锦

Envoy v2 API以Protocol Buffers的proto3语言定义，该API支持：

1. 通过gRPC进行xDS API更新的流式递送，这可以降低更新延迟。Envoy可以从文件系统或管理服务器动态发现资源定义，这一功能由一系列发现服务完成，这些发现服务统称为xDS
2. 一个新的REST-JSON API，支持以YAML/JSON格式传递配置，底层依靠proto3 canonical JSON mapping实现
3. 通过文件系统，REST-JSON或gRPC端点来递送更新
4. 如果需要，可以保证更强的一致性。最终一致性总是得到保证

旧版本的Envoy v1 API已经废弃，但是其功能尚未完全迁移到v2中，有些情况下，需要使用 deprecated_v1字段使用v1 API。

Envoy的配置API文档比较零散，本节使用从一个Istio proxy中dump出的Envoy完整配置来总览的了解Envoy配置规格：

转换为yaml格式后，内容如下：

Envoy同时支持TLS Termination（接受下游HTTPS请求）和TLS Origination（向上游发送HTTPS请求）：

要使用v2 API，Envoy实例需要一个Bootstrap配置信息。Bootstrap配置中可以包含静态的服务器信息，告诉Envoy如何访问动态配置。自举配置通过-c传入：

配置的根是一个Bootstrap消息，该消息的一个核心特点是将静态资源（static_resources）和动态资源分离（dynamic_resources）

第一个例子就是最简单的全静态配置。 

下面的示例，在clusters配置中使用了EDS，以动态的发现上游集群包含哪些端点：

EDS管理服务器可能会提供如下的DiscoveryResponse：

从而为some_service提供端点。

下面是一个完全动态的自举配置，除了和管理服务器相关的信息之外，都是通过xDS发现：

xDS管理服务器可能这样应答一个LDS请求：

这样应答一个RDS请求：

这样应答一个CDS请求：

这样应答一个EDS请求：

一个v2 xDS管理服务器需要实现若干gRPC/REST端点，请求总是以 DiscoveryRequest发送，应答则以遵守xDS协议的DiscoveryResponse发送：

gRPC端点如下表：

POST /envoy.api.v2.ClusterDiscoveryService/StreamClusters，服务定义参考cds.proto 如果在Envoy的自举配置的dynamic_resources段包含以下形式的配置，Envoy调用此端点： YAML 1 2 3 4 5 6 cds_config:   api_config_source:     api_type: GRPC     grpc_services:       envoy_grpc:         cluster_name: some_xds_cluster

POST /envoy.api.v2.EndpointDiscoveryService/StreamEndpoints ，服务定义参考eds.proto 如果在Envoy的Cluster配置的eds_cluster_config段包含以下形式的配置，Envoy调用此端点： YAML 1 2 3 4 5 6 eds_config:   api_config_source:     api_type: GRPC     grpc_services:       envoy_grpc:         cluster_name: some_xds_cluster

POST /envoy.api.v2.ListenerDiscoveryService/StreamListeners，服务定义参考lds.proto 如果在Envoy的自举配置的dynamic_resources段包含以下形式的配置，Envoy调用此端点： YAML 1 2 3 4 5 6 lds_config:   api_config_source:     api_type: GRPC     grpc_services:       envoy_grpc:         cluster_name: some_xds_cluster

POST /envoy.api.v2.RouteDiscoveryService/StreamRoutes，服务定义参考rds.proto 如果在Envoy的HttpConnectionManager配置的rds段包含以下形式的配置，Envoy调用此端点： YAML 1 2 3 4 5 6 7 route_config_name: some_route_name config_source:   api_config_source:     api_type: GRPC     grpc_services:       envoy_grpc:         cluster_name: some_xds_cluster

REST端点包括：

1. POST /v2/discovery:clusters
2. POST /v2/discovery:endpoints
3. POST /v2/discovery:endpoints
4. POST /v2/discovery:routes

Envoy使用了最终一致性模型，这意味着存在配置不一致的时间窗口。ADS能够将Envoy节点绑定到单个管理服务器，并且串行化API更新推送。

监听器包含的属性如下：

包含的属性如下：

过滤器名称envoy.listener.original_dst。当一个连接通过iptables REDIRECT（或TPROXY+监听器的transparent配置）重定向到监听器时，此过滤器读取套接字选项SO_ORIGINAL_DST。Envoy的后续处理过程中看到的连接本地地址（connection’s local，也就是服务器端地址）是原始的目的地址，而不是监听器正在监听的地址。

此外，基于原始目的地类型的上游集群，可以作为转发目标，也就是说Envoy直接把HTTP/TCP发送给原始的目的地址。

过滤器名称envoy.listener.original_src。

此过滤器能够复制下游连接的远程地址，并将上游连接的源地址设置为此原始的源地址，而不是默认的使用Envoy代理自身的地址。例如，如果下游连接到Envoy时使用的IP地址时10.1.2.3，则Envoy连接上游的时候，使用10.1.2.3，而非Envoy本机IP地址。

如果下游连接的源地址没有被代理或转换，可以简单的获得原始源地址。如果使用的代理协议，则原始源地址可以通过proxy_protocol过滤器获取。

此过滤器支持IPv4和IPv6。

下游的远程地址常常是全局可路由的，默认情况下，从上游返回的包不会经过Envoy路由，你必须进行网络配置，将任何Envoy复制了（作为自己的源地址发往上游）的那些下游IP的路由强制的定向给Envoy。

如果Envoy和上游在同一主机（Sidecar模式），则通过配置Iptables和路由策略即可保证正确行为。此过滤器包含配置项mark：

1. 如果将其设置为X，则Envoy会将所有从当前监听器发起的对上游的流量打上标记X
2. 如果将其设置为0，则不会打标记

假设mark=1986，则配合下面的规则即可正确的路由回来：

Envoy配置示例：

回顾一下工作原理：

1. Envoy接收到下游连接
2. 得到下游连接的IP地址，然后以此地址作为源地址，标记封包为1986
3. 由于封包具有1987标记，因此到912表查路由，结果发给lo
4. lo网卡接收到上述封包，在PREROUTING时发现有标记1986，将当前连接标记为1986
5. 路由给本地的上游服务进程
6. 进程处理完毕请求后，在OUTPUT时，将封包标记为1986，注意这里的连接同一个，因此可以标记封包
7. 由于封包具有1987标记，因此到912表查路由，还是发给lo
8. 由于目的地址是最初下游连接的地址，因此封包发给Envoy

过滤器名称envoy.listener.proxy_protocol，用于支持HAProxy代理协议。

启用此过滤器后，连接被假设来自一个代理，此代理将原始的源地址（IP+PORT）存放在一个连接字符串中，Envoy会抽取此字符串，并将其设置为远程地址。

此协议自动识别HAProxy代理协议的v1/v2版本。

过滤器名称envoy.listener.tls_inspector，用于探测连接是基于TLS还是明文的。如果是基于TLS，则此过滤器会：

1. 检测SNI（Server Name Indication，服务器名称指示）
2. 检测应用层协议协商（ Application-Layer Protocol Negotiation）

利用这些信息，可以FilterChainMatch的server_names、application_protocols来选择一个FilterChain

这里讨论除了HTTP连接管理器之外的网络过滤器。

过滤器名称envoy.client_ssl_auth，用于执行TLS身份验证。

此过滤器每个刷新间隔都调用REST API：GET /v1/certs/list/approved，以获取被许可的证书/主体列表。

包含的属性如下：

过滤器名称envoy.echo，仅仅用于示例网络过滤器API的用法。它会回响所有数据包给下游服务器。

过滤器名称envoy.ext_authz，调用外部的授权服务，验证入站请求是否有权限访问。如果无权访问则连接会被关闭。发送给外部服务的请求格式由CheckRequest提供。

建议把此过滤器配置在过滤器链的头部，这样非法请求不会执行其它过滤器。

包含的属性如下：

配置示例：

过滤器名称envoy.mongo_proxy，支持嗅探MongoDB协议，支持故障注入。

包含的属性如下：

过滤器名称envoy.ratelimit，用于支持全局性限速。

包含的属性如下：

此过滤器包含以下运行时设置：

设置	说明
ratelimit.tcp_filter_enabled	多少百分比的连接会调用限速服务，默认100
ratelimit.tcp_filter_enforcing	多少百分比的连接会调用限速服务并且强制限速策略，默认100

过滤器名称envoy.filters.network.local_ratelimit，实现本地限速。

使用令牌桶算法，每个入站连接会占用一个令牌，如果没有令牌可用，立即关闭下游连接。

过滤器名称envoy.redis_proxy。Envoy实现了一个Redis代理，可以基于哈希来将请求分发给上游Redis服务集群。

此过滤器包含的属性如下：

过滤器名称envoy.tcp_proxy。

此代理使用的上游集群可以被其它网络过滤器动态的设置。具体做法时为每个连接设置在键envoy.tcp_proxy.cluster下设置一个状态对象。

此过滤器包含的属性如下：

过滤器名称envoy.filters.network.sni_cluster。此过滤器在TLS连接中，以SNI为上游集群的名称。

没有配置项，必须在tcp_proxy之前安装。

过滤器名称：envoy.filters.network.mysql_proxy。此过滤器处于开发阶段，2019年1月17日PR刚刚合并。

此过滤器能够解析MySQL协议，能解析出协议载荷中的SQL查询。解码后的信息作为作为动态元数据释放。这些动态元数据包括：

元数据	说明
<table.db>	string，以table.db形式表示的资源名称，如果无法得知db，则为table 值是在资源上执行单操作的列表，操作包括insert/update/select/drop/delete/create/alter/show

配置示例：

MySQL释放的动态元数据，可以和RBAC过滤器联用，实现对表的访问控制：

过滤器名称envoy.filters.network.rbac。该过滤器完成对下游服务器的授权（依据其principal）操作，可以明确管理到应用程序的调用，阻止非法访问。

此过滤器支持配置以下两者之一：

1. 安全列表（ALLOW）
2. 禁止列表（DENY） 

列表基于连接属性（IP、端口、SSL subject）来设置访问策略。

访问策略可以工作在enforcement或shadown模式，后者不会实际影响用户，用于在上线前测试策略会产生的影响。

此过滤器包含的属性如下：

此过滤器名称envoy.filters.network.dubbo_proxy。

解码Dubbo客户端和服务器之间的RPC协议，信息中抽取的信息转换为元数据，包括：请求ID、请求类型、串行化类型、请求服务名、方法名、参数名、参数值。

此过滤器会暴露很多统计信息。

支持配置dubbo_filters，你可以影响Dubbo路由：

过滤器名称envoy.filters.network.kafka_broker。

该过滤器解码Kafka客户端协议，包括请求和应答。Kafka 2.4中的消息版本被支持。该过滤器尝试不去影响客户端和服务器之间的通信，因此无法解码的报文原样转发。

该过滤器必须和tcp_proxy联用，示例：

解码PostgresSQl客户端（下游）和服务器（上游）之间的wire协议，获取的信息用于生成Postgres级别的统计信息：会话、语句、执行的事务…… 目前不去解析SQL查询。

应当和tcp_proxy联用：

使用TLS连接中的SNI来作为上游集群的名称。对于非TLS连接没有影响。

需要联用tls_inspector。基于SNI进行动态代理，下面是一个完整配置： 

对一个下游HTTP请求进行路由匹配的流程如下：

1. HTTP请求的host或authority头匹配到一个虚拟主机（virtual host）
2. 虚拟主机中的每个路由条目按顺序检查，如果找到匹配立即使用，不进行后续检查
3. 虚拟主机中的每个虚拟集群（virtual cluster），如果找到立即使用

Envoy支持在虚拟主机的多个上游集群之间划分流量，具体有两种应用场景：

1. 版本升级，流量逐步的从一个集群转移（Shifting）到另外一个
2. A/B测试，多个版本同时被使用。下一节讨论

路由配置中的runtime对象决定选择虚拟主机的某个特定集群的概率。通过runtime_fraction配置，某个虚拟主机的流量可以逐步的转移，下面是个例子：

完成流量转移的步骤如下：

1. 最初，将routing.traffic_shift.helloworld设置为100，所有请求路由给v1
2. 逐步减小routing.traffic_shift.helloworld的值，导致越来越多的请求路由给v2
3. routing.traffic_shift.helloworld设置为0，完成转移

示例：

对于该例子，可以通过运行时变量routing.traffic_split.helloworld.helloworld_v1/2/3动态调整权重。

HTTP连接管理器在编码响应/解码请求时，都会操控一系列HTTP头：

头	说明
user-agent	如果配置了add_user_agent选项，解码请求时会添加此头。如果头已经存在则不会修改 此头的值取决于--service-cluster命令行参数
server	解码时设置为 server_name选项的值
x-client-trace-id	如果外部客户端设置了此头，则Envoy将此ID和内部生成的x-request-id连接起来 如果此头被设置，其效果类似于x-envoy-force-trace，参考运行时配置tracing.client_enabled
x-envoy-downstream-service-cluster	用于提示上游集群，是哪个服务集群调用了它。其值由命令行选项--service-cluster决定 需要将user_agent选项设置为true以使用该头
x-envoy-downstream-service-node	用于提示上游集群，是哪个服务实例调用了它。其值由命令行选项--service-node决定
x-envoy-external-address	如果请求来自网格外部，则设置为客户端地址（trusted client address ） 如果请求来自内部，不会设置或修改此头。也就是说，此头可以在多个内部服务之间传递来传递去，不需要考虑XFF头那样的复杂性
x-envoy-force-trace	如果某个内部服务设置了此头，则Envoy会修改自动生成的x-request-id并强制调用链跟踪 这也强制在响应头中返回x-request-id  如果此x-request-id传播到了其它主机，这些主机也会进行调用链收集，这会最终生成完整的调用链 参考运行时配置 tracing.global_enabled、tracing.random_sampling
x-envoy-internal	用于区分请求来自内部还是外部，Envoy根据XFF判断，并自动设置此头为true或false
x-envoy-original-dst-host	使用原始目的地这个负载均衡策略时，此头用于覆盖目的地地址 默认情况下此头被忽略，除非特定通过use_http_header启用
x-forwarded-client-cert	XFCC是一个代理头，用于指出请求穿过的客户端、所有中间代理的的证书信息
x-forwarded-for	XFF是一个标准代理头，用于指示请求穿过的客户端、所有中间代理的IP地址。任何代理都应该用逗号分隔的方式，将直接客户端的地址附加到此头中 仅仅当HTTP连接管理器的use_remote_address选项为true且skip_xff_append=false，Envoy才会附加XFF。否则HTTP连接管理器运行在“透明”模式，导致上游服务不会感知它的存在
x-forwarded-proto	用于指示原始的协议（HTTP还是HTTPS）
x-request-id	Envoy根据此头来唯一的识别请求，并进行稳定的访问日志和请求追踪 Envoy会为所有外部原始请求生成x-request-id（消毒），对于内部请求，如果没有此头，Envoy也会生成一个 经过网格中各节点时，此x-request-id应该被正确的传播，以便调用链可以被追踪。由于Envoy的进程外架构，它无法自动的转发此ID，你需要自己转发，要么手工编码，要么使用某种Agent或库 如果x-request-id正确的传播到所有主机上，则以下特性可用： 基于v2 API 运行时过滤器的稳定的访问日志 稳定的请求追踪，不管是采样（tracing.random_sampling）、还是强制（x-envoy-force-trace、x-client-trace-id 头）
x-ot-span-context	使用LightStep这一Tracer时，Envoy使用此头来建立Tracing Span之间的父子关系
x-b3-traceid	使用Zipkin这一Tracer时，此头是一个8字节的字符串，表示整个Trace的标识
x-b3-spanid	使用Zipkin这一Tracer时，此头是一个8字节的字符串，表示当前操作在Span树中的位置
x-b3-parentspanid	使用Zipkin这一Tracer时，此头是一个8字节的字符串，表示当前操作的父操作在Span树中的位置
x-b3-sampled	使用Zipkin这一Tracer时，如果设置为1或者不设置，则Span会被报告给Tracer，整个Trace中此值应该恒定
x-b3-flags	使用Zipkin这一Tracer时，编码多个选项
b3	使用Zipkin这一Tracer时，更加复杂的头格式
x-datadog-trace-id	Datadog（一种Tracer）相关的头
x-datadog-parent-id
x-datadog-sampling-priority

在权重集群、路由、虚拟主机、全局配置级别，都可以添加自定义请求/响应头。

以-开头的伪头可以通过自定义头来覆盖。而:path和:authority头则可以通过prefix_rewrite或host_rewrite机制修改。

头的优先级顺序（从高到低）：权重集群、路由、虚拟主机、全局配置级别。

在自定义头中可以使用以下变量：

变量	说明
%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%	下游连接的地址，不带端口
%DOWNSTREAM_LOCAL_ADDRESS%	下游连接的本地的地址，包含IP和端口 如果原始请求基于Iptables REDIRECT转发，此变量存储原始目的地址 如果原始请求基于Iptables TPROXY转发，且监听器的transparent为true，此变量存储原始目的地址和端口
%DOWNSTREAM_LOCAL_ADDRESS_WITHOUT_PORT%	上面的，不包含端口
%PROTOCOL%	原始的协议，和x-forwarded-proto头相同
%UPSTREAM_METADATA([“namespace”, “key”, …])%	从被路由选择的上游主机的EDS端点元数据中获取的元数据
%PER_REQUEST_STATE(reverse.dns.data.name)%
%START_TIME%	请求处理开始时间，示例： YAML 1 2 3 4 5 6 7 8 route:   cluster: www   request_headers_to_add:     - header:         key: "x-request-start"         # 当前时间，以秒表示，精确到ms         value: "%START_TIME(%s.%3f)%"       append: true

由于安全原因，Envoy会对收到的HTTP头进行消毒（sanitize） —— 要么添加、修改、删除。

HTTP连接管理器支持以下运行时设置：

设置	说明
tracing.client_enabled	如果设置了x-client-trace-id头，多少比例的请求被追踪，默认100
tracing.global_enabled	如果其它条件都满足，则多少比例的请求被追踪，默认100
tracing.random_sampling	多少请求被采样式的追踪，取值0-10000之间，100表示百分之一

路有发现服务RDS是一个可选的API，Envoy可以调用此API以动态的抓取路由配置。每个HTTP连接管理器可以独立的抓取。

过滤器名称envoy.buffer。此过滤器用于停止过滤器迭代，然后等待完整的请求到达。用途是：

1. 保护某些应用程序，使其不必处理不完整请求（partial request）
2. 降低网络延迟

此过滤器包含的属性：

在每个路由级别，buffer过滤器可以被覆盖配置或者禁用：

过滤器名称envoy.cors。此过滤器基于路由/虚拟主机的配置来处理跨站资源共享（Cross-Origin Resource Sharing）请求。

此过滤器包含的属性：

此过滤器支持以下运行时RuntimeFractionalPercent设置：

1. filter_enabled：对于多少比例的请求启用此过滤器，默认100/HUNDRED
2. shadow_enabled：多少比例的请求在shadow模式下运行此过滤器，默认0

过滤器名称envoy.ext_authz。此过滤器调用外部的gRPC/HTTP服务，以确认请求是否有权访问。如果验证失败会返回403/Forbidden应答。

从授权服务传递额外的元数据到上游、下游也是支持的，反方向也是。发送给授权服务的请求内容由CheckRequest规定。

此过滤器包含的属性：

基于gRPC授权服务的配置示例：

基于HTTP授权服务的配置示例： 

在路由级别定制配置：

过滤器名称envoy.fault。故障注入过滤器可以用于测试微服务的顽强性（resiliency） ，它能够注入延迟（目前仅支持固定延迟），或者注入用户指定的错误码（仅仅支持HTTP状态码），从而模拟各种错误场景。这些场景包括：服务过载、高网络延迟、网络分区。

故障注入可以仅仅应用于特定的请求集，这些请求集以请求头、上游服集群等信息识别。

此过滤器的属性包括：

此过滤器支持以下运行时配置：

配置	说明
fault.http.abort.abort_percent	请求头匹配的请求，有多少百分比被注入abort 下游集群可以覆盖： fault.http.<downstream-cluster>.abort.abort_percent
fault.http.abort.http_status	注入什么状态码 下游集群可以覆盖： fault.http.<downstream-cluster>.abort.http_status
fault.http.delay.fixed_delay_percent	请求头匹配的请求，有多少百分比被注入延迟 下游集群可以覆盖： fault.http.<downstream-cluster>.delay.fixed_delay_percent
fault.http.delay.fixed_duration_ms	注入多久的延迟 下游集群可以覆盖： fault.http.<downstream-cluster>.delay.fixed_duration_ms

这些运行时设置可以为每个下游集群覆盖，<downstream-cluster>取请求头x-envoy-downstream-service-cluster。

过滤器名称envoy.grpc_http1_bridge，用于桥接一个不支持响应报尾（response trailers）的HTTP/1.1客户端到gRPC服务器。其工作方式如下：

1. 请求发送时，此过滤器检查连接是否基于HTTP/1.1，且MIME类型为application/grpc，如果是
2. 当Envoy接收到应答时，过滤器会缓冲它，并等待trailers，检查grpc-status码
3. 如果此码不为0，则过滤器将HTTP状态码设置为503，同时将grpc-status、grpc-message这两个tailers存放到响应头中
4. 客户端必须发送包含以下伪头的HTTP/1.1请求：
   1. :method，取值POST
   2. :path，取值gRPC方法的名称
   3. content-type，取值application/grpc
   4. 请求体必须是串行化的gRPC体：
      1. 第一字节为非压缩的0
      2. 网络字节序的4字节，Proto消息的长度
      3. 串行化后的Proto消息
5. 由于需要缓冲响应并寻找grpc-status报尾，因此仅仅支持一元gRPC API

过滤器名称envoy.grpc_http1_reverse_bridge。将gRPC请求转换为HTTP 1.1请求，并转发给不理解gRPC或HTTP/2的服务器处理。

过滤器名称envoy.grpc_json_transcoder。将RESTful JSON API请求转换为gRPC请求并转发给gRPC服务器。

过滤器名称envoy.grpc_web。实现gRPC-Web客户端到gRPC服务器的桥接。

过滤器名称envoy.gzip。实现压缩功能。

过滤器名称envoy.health_check。参考1.12 健康检查。

过滤器名称envoy.filters.http.header_to_metadata。此过滤器包含一系列规则，规则对请求/响应进行匹配。每个规则包含一个头，当请求/响应包含或不包含此头时，规则匹配，并添加动态元数据。

动态元数据可以用来决定如何负载均衡，或者被日志模块使用。最典型的用法是动态的匹配请求和负载均衡子集：

过滤器名称envoy.lua。此过滤器运行你提供Lua脚本，处理请求/应答流。此过滤器适用于简单的场景，如果要实现复杂的、高性能的逻辑，请编写原生的C++过滤器。

注意：

1. 所有Lua环境是每个工作线程独占的，也就是说没有真正全局性的数据。加载期间生成的全局变量，对于每个工作线程来说都是独立副本
2. 所有脚本以协程的形式执行，也就是说它们以同步的方式运行，即使实际执行的是复杂的异步工作。网络/异步处理由Envoy执行，Envoy在适当的时机调用Lua脚本
3. 绝不要在Lua中包含阻塞性操作
4. 默认构建的Envoy没有导出符号，和以共享对象安装的Lua模块交互时可能需要这些符号

目前支持的特性：

1. 查看报文头、报文体、报尾
2. 修改报文头、报文尾
3. 阻塞并等到完整的请求/应答，以进行完整的inspection
4. 向上游主机发起异步的HTTP出站调用
5. 直接提供响应，终止过滤器迭代

LuaJIT作为Lua的运行时，支持的版本是5.1，以及一些5.2特性。

示例：

流句柄（Stream handle）API，也就是envoy_on_request/envoy_on_response函数的入参handle的方法列表：

方法	说明
headers()	返回请求/应答流的头，在发送到header chain中另一个过滤器链之前，这些头可以被修改。例如，你可以在httpCall()、body()调用之后进行头修改
body()	返回流的体，此调用导致Envoy yield掉脚本，直到整个体被缓冲完毕
bodyChunks()	返回一个迭代器，用于编译流体的所有片断。Envoy会在获取每个片断时yield脚本，但是不会进行缓冲操作。示例： Lua 1 2 3 for chunk in request_handle:bodyChunks() do   request_handle:log(0, chunk:length()) end
trailers()	返回报文尾，如果没有可能返回nil。发送到下一个过滤器之间你可以修改trailers
log*()	记录Envoy应用程序日志： Lua 1 2 3 4 5 6 handle:logTrace(message) handle:logDebug(message) handle:logInfo(message) handle:logWarn(message) handle:logErr(message) handle:logCritical(message)
httpCall()	向上游主机发起HTTP调用： Lua 1 headers, body = handle:httpCall(cluster, headers, body, timeout) Envoy会yield脚本，知道请求完成或者出错。cluster是已经配置好的集群名称，超时单位ms
respond()	不再继续过滤器迭代，立即进行应答。仅仅在请求流中可以调用： Lua 1 handle:respond(headers, body)
metadata()	返回当前路由条目元数据（route entry metadata），这些元数据必须声明在命名空间envoy.lua下面，例如： YAML 1 2 3 4 5 6 7 metadata:   filter_metadata:     envoy.lua:       foo: bar       baz:         - bad         - baz
streamInfo()	返回和当前流有关的信息
connection()	返回当前请求使用的底层连接对象

头对象的API：

方法	说明
add()	添加一个头
get()	获取一个头
__pairs()	用于迭代所有头： Lua 1 2 for key, value in pairs(headers) do end
remove()	移除头
replace()	替换头

Buffer的API：

方法	说明
length()	返回缓冲的长度
getBytes()	从缓冲中读取字节： buffer:getBytes(index, length)

Metadata对象的API：

方法	说明
get()	获取一个元数据，值的类型可能是nil, boolean, number, string, table
__pairs()	用于迭代所有元数据

StreamInfo对象的API：

方法	说明
protocol()	返回使用的协议，可能的值包括HTTP/1.0, HTTP/1.1, HTTP/2
dynamicMetadata()	返回动态元数据

动态元数据的API：

方法	说明
get()	获取动态元数据： Lua 1 2 dynamicMetadata:get(filterName) dynamicMetadata:get(filterName)[key]
set()	设置动态元数据： dynamicMetadata:set(filterName, key, value)
__pairs()	迭代所有元数据

API示例：

过滤器名称envoy.rate_limit。如果请求的路由/虚拟主机配置包含1-N个限速配置匹配过滤器的stage，则此过滤器会调用限速服务，将每个限速配置产生的描述符发送给限速服务。

如果限速服务返回的响应，提示任何一个描述符超限，则返回429响应给客户端。

如果调用限速服务失败，且failure_mode_deny配置为true，则返回500应答。

此过滤器包含的属性：

过滤器名称envoy.filters.http.rbac。此过滤器用于授权下游客户端的访问权限，用于明确管理谁能访问服务。可以根据连接属性（IP、端口、SSL主体）或者请求头来决定ALLOW/DENY访问请求。

过滤器名称envoy.router。此过滤器实现了HTTP forwarding，几乎会用在所有HTTP代理场景下。此过滤器的职责包括：

1. 根据路由表配置进行转发
2. 处理重试
3. 处理统计信息收集 

此过滤器包含的属性：

此过滤器会读取以下头：

头	说明
x-envoy-max-retries	如果路由/虚拟主机的重试策略存在，默认情况下Envoy会重试一次，除非明确指定重试次数 重试次数可以在几个地方提供： 路由、虚拟主机的重试配置 x-envoy-max-retries头中 如果重试策略没有配置，且x-envoy-retry-on、x-envoy-retry-grpc-on头不存在，则Envoy不会进行重试 如果有多个配置，取其中最大的重试次数 关于Envoy重试的一些细节： 路由超时（在路由配置中指定，或者通过x-envoy-upstream-rq-timeout-ms头设置）是包含所有重试的总超时 Envoy基于 fully jittered exponential backoff algorithm 来进行重试，第一次重试随机延迟0-24ms，第二次0-74ms，第三次0-174ms
x-envoy-retry-on	为出站请求设置该头，会导致在特定时机自动重试，多个时机用逗号分隔： 5xx，如果接收到上游主机的5xx响应码 gateway-error，如果接收到502、503、504响应码 connect-failure，如果出现连接错误（例如超时），包括5xx retriable-4xx，如果接收到可重试的4xx，当前仅仅支持409 refused-stream，如果上游服务器以REFUSED_STREAM重置了流 retriable-status-codes，如果解说道任何可重试的状态码
x-envoy-retry-grpc-on	为出站请求设置该头，会导致在特定时机自动重试gRPC请求： cancelled，如果gRPC响应头状态码是cancelled deadline-exceeded internal resource-exhausted unavailable
x-envoy-retriable-status-codes	提示哪些状态码是“可重试”的
x-envoy-upstream-rq-timeout-ms	覆盖路由配置中的超时，单位ms
x-envoy-upstream-rq-per-try-timeout-ms	每次重试的超时，单位ms
x-envoy-immediate-health-check-fail	如果上游主机返回此响应头，则Envoy立即认为上游主机主动检查失败（如果配置了主动检查的话），用于快速失败而不是等待下次健康检查
x-envoy-overloaded	如果上游主机返回此响应头，则不进行重试
x-envoy-ratelimited	如果上游主机返回此响应头，则不进行重试

此过滤器会设置以下头：

头	说明
x-envoy-attempt-count	发送给上游主机，提示已经重试的次数，最初请求设置为1，每次重试+1
x-envoy-expected-rq-timeout-ms	路由器期望请求在多长时间内完成。这个头发送给上游服务器，辅助其决策（例如超时后仍然在处理中，可以直接终止处理）
x-envoy-upstream-service-time	上游主机处理请求消耗的时间，客户端可以依次判断网络延迟的影响
x-envoy-original-path	原始的路径，由于前缀重写，路径可能变化了，用于日志和调试
x-envoy-overloaded	如果请求由于维护模式、上游断路而失败，在给下游的应答中设置此头

包含的属性：

访问日志配置，是HTTP连接管理器或者TCP代理配置的一部分。具体参考官方文档。 

过载管理器用于保护Envoy代理所在机器本身，过载管理器的配置，放在Bootstrap配置的overload_manager字段下。

TLS证书、密码等敏感信息可以在static_resource中配置，也可以从远程的SDS服务抓取。

SDS的价值主要是简化证书管理。如果没有此特性，在K8S场景下，证书只能以Secret的方式定义并挂载到代理容器中。如果证书过期，则需要重现挂载。使用SDS，过期后新证书自动被推送到Envoy代理。

监听器管理器在命名空间listener_manager.下暴露以下监控指标：

指标	说明
listener_added	Counter，总计添加的监听器数量（包括静态和LDS）
listener_modified	Counter，通过LDS修改监听器的次数
listener_removed	Counter，通过LDS删除监听器的次数
listener_create_success	Counter，总计成功添加到Worker中的监听器对象数量
listener_create_failure	Counter，总计失败添加到Worker中的监听器对象数量
total_listeners_warming	Gauge，当前处于预热状态的监听器数量
total_listeners_active	Gauge，当前处于活动状态的监听器数量
total_listeners_draining	Gauge，当前处于draining状态的监听器数量

每个监听器都在命名空间 listener.<address>下暴露以下监控指标：

指标	说明
downstream_cx_total	Counter，连接总数
downstream_cx_destroy	Counter，销毁的连接总数
downstream_cx_active	Gauge，当前活动的连接总数
downstream_cx_length_ms	Histogram，连接持续时间ms
downstream_pre_cx_timeout	Counter，在监听器过滤器处理期间，超时的套接字数量
downstream_pre_cx_active	Gauge，正在被监听器过滤器处理的连接请求数量
no_filter_chain_match	Counter，总计的不匹配任何过滤器链的连接数量
ssl.connection_error	Counter，总计的TLS连接错误数量，包括证书验证失败的情况
ssl.handshake	Counter，总计的TLS握手成功次数
ssl.session_reused	Counter，总计的TLS会话重用次数/home/alex/CPP/projects/clion/envoy
ssl.no_certificate	Counter，总计的没有客户端证书的成功TLS连接次数
ssl.fail_verify_no_cert	Counter，总计的由于没有客户端证书而导致TLS连接失败的次数
ssl.fail_verify_error	Counter，总计的由于证书验证失败而导致TLS连接失败的次数
ssl.fail_verify_san	Counter，总计的由SAN验证失败而导致TLS连接失败的次数
ssl.fail_verify_cert_hash	Counter，总计的由证书哈希验证失败而导致TLS连接失败的次数
ssl.ciphers.<cipher>	Counter，使用cipher的成功TLS连接次数
ssl.curves.<curve>	Counter，使用curve的成功TLS连接次数
ssl.sigalgs.<sigalg>	Counter，使用签名算法sigalg的成功TLS连接次数
ssl.versions.<version>	Counter，使用协议版本version的成功TLS连接次数

此过滤器产生以下指标：

指标	说明
downstream_cx_proxy_proto_error	Counter，总计的代理协议错误数量

此过滤器在命名空间下暴露以下指标：

指标	说明
connection_closed	Counter，总计关闭的连接数量
client_hello_too_large	Counter，总计收到的客户端不合理的大尺寸Hello报文数量
read_error	Counter，总计读错误数量
tls_found	Counter，TLS被找到的数量（也就是说入站连接没有使用TLS协议）
tls_not_found	Counter，TLS没被找到的数量
alpn_found	Counter，应用层协议协商找到的次数
alpn_not_found	Counter，应用层协议协商未找到的次数
sni_found	Counter，SNI找到的次数
sni_not_found	Counter，SNI未找到的次数

此过滤器在命名空间 auth.clientssl.<stat_prefix>.下暴露以下指标：

指标	说明
update_success	Counter，总计Principal更新成功次数
update_failure	Counter，总计Principal更新失败次数
auth_no_ssl	Counter，由于没有TLS而忽略的连接数量
auth_ip_white_list	Counter，由于IP白名单而允许的连接数量
auth_digest_match	Counter，由于证书匹配而允许的连接数量
auth_digest_no_match	Counter，由于证书不匹配而拒绝的连接数量
total_principals	Gauge，总计加载的Principal数量

此过滤器在命名空间config.ext_authz.下暴露以下指标：

指标	说明
total	Counter，此过滤器的响应总数
error	Counter，联系授权服务失败的次数
denied	Counter，无权访问的次数
failure_mode_allowed	Counter，验证不通过，但是由于failure_mode_allow设置为true而允许通过的请求数量
ok	Counter，授权服务允许连接通过的次数
cx_closed	Counter，被关闭的连接数
active	Gauge，当前活动的，正在被授权服务处理的请求

此过滤器在ratelimit.<stat_prefix>下暴露以下指标：

指标	说明
total	Gauge，向限速服务发送的总请求数
error	Gauge，访问限速服务出错的次数
over_limit	Gauge，限速服务提示超过限制的次数
ok	Gauge，限速服务提示没有超过限制的次数/home/alex/CPP/projects/clion/envoy
cx_closed	Gauge，由于限速服务提示超限，而关闭的连接数量
active	Gauge，正在被限速服务处理的请求数量
failure_mode_allowed	Gauge，虽然超限，但是被允许的连接数

此过滤器在redis.<stat_prefix>下暴露如下指标：

指标	说明
downstream_cx_active	Gauge，活动连接数
downstream_cx_protocol_error	Counter，总的协议错误数量
downstream_cx_rx_bytes_buffered	Gauge，当前缓冲的接收字节数
downstream_cx_rx_bytes_total	Counter，总计接收字节数
downstream_cx_total	Counter，总计连接数
downstream_cx_tx_bytes_buffered	Gauge，当前缓冲的发送字节数
downstream_cx_tx_bytes_total	Counter，总计发送字节数
downstream_cx_drain_close	Counter，由于Draing导致关闭的连接数
downstream_rq_active	Gauge，活动的请求数
downstream_rq_total	Counter，总请求数

 此过滤器在 redis.<stat_prefix>.splitter 下暴露了命令分流器（command splitter）相关的指标：

指标	说明
invalid_request	Counter，参数数量不正确的请求数
unsupported_command	Counter，命令分流器不能识别的命令数量

对于每个不同的Redis命令，此过滤器在 redis.<stat_prefix>.command.<command> 下暴露指标：

指标	说明
total	Counter，命令数量
success	Counter，成功数量
error	Counter，失败数量

此代理会在tcp.<stat_prefix>下产生下游、上游相关的统计指标：

指标	说明
downstream_cx_total	Counter，此过滤器处理的连接总数
downstream_cx_no_route	Counter，没有匹配路由、或者路由对应的集群不存在的连接数
downstream_cx_tx_bytes_total	Counter，写到下游的字节总数
downstream_cx_tx_bytes_buffered	Gauge，当前缓冲的准备发给下游集群的字节总数
downstream_cx_rx_bytes_total	Counter，从下游读取的字节总数
downstream_cx_rx_bytes_buffered	Gauge，从下游接收并正在缓冲中的字节总数
downstream_flow_control_paused_reading_total	Counter，流控制暂停从下游读取数据的次数
downstream_flow_control_resumed_reading_total	Counter，流控制恢复从下游读取数据的次数
idle_timeout	Counter，由于空闲而被关闭的连接数
upstream_flush_total	Counter，下游连接关闭后仍然向上游刷出数据的连接总数
upstream_flush_active	Gauge，下游连接关闭，正在向上游刷出数据的连接数

此过滤器在命名空间mysql.<stat_prefix>下暴露以下指标：

指标	说明
auth_switch_request	Counter，上游服务器要求客户端切换到其它身份验证模式的次数
decoder_errors	Counter，MySQL协议解码错误次数
login_attempts	Counter，登陆尝试次数
login_failures	Counter，登陆失败次数
protocol_errors	Counter，在会话中协议消息失序的次数
queries_parse_error	Counter，MySQL查询解析失败次数
queries_parsed	Counter，MySQL查询解析成功次数
sessions	Counter，从启动依赖创建的MySQL会话个数
upgraded_to_ssl	Counter，升级到SSL的会话/连接个数

此过滤器在命名空间<stat_prefix>.cors.* 下暴露以下指标：

指标	说明
origin_valid	Counter，有效源计数
origin_invalid	Counter，无效源计数

此过滤器在命名空间cluster.<route target cluster>.ext_authz.下暴露以下指标：

指标	说明
ok	Counter，从此过滤器返回的应答总数
error	Counter，连接外部授权服务失败的次数
denied	Counter，外部授权服务认为请求无权的次数
failure_mode_allowed	Counter，由于failure_mode_allow=true，尽管出错仍然允许通过的请求数

此过滤器在命名空间http.<stat_prefix>.fault. 下暴露以下指标：

指标	说明
delays_injected	Counter，总计注入延迟数量
aborts_injected	Counter，总计注入中断数量
<downstream-cluster>.delays_injected	Counter，某个特定下游集群总计注入延迟数量
<downstream-cluster>.aborts_injected	Counter，某个特定下游集群总计注入中断数量

此过滤器在命名空间 cluster.<route target cluster>.ratelimit 下暴露以下指标：

指标	说明
ok	Counter，未超限的请求数
error	Counter，调用限速服务错误的次数
over_limit	Counter，超限的请求数
failure_mode_allowed	Counter，请求限速服务失败，但是允许请求通过的次数

此过滤器在命名空间 http.<stat_prefix>下暴露以下指标，stat_prefix取决于所属的HTTP连接管理器：

指标	说明
no_route	Counter，由于没有路由而404的请求数
no_cluster	Counter，由于上游集群不存在而404的请求数
rq_redirect	Counter，导致重定向的请求数
rq_direct_response	Counter，导致直接应答的请求数
rq_total	Counter，总计被路由的请求数

虚拟集群的统计信息暴露在<virtual host name>.vcluster.<virtual cluster name>，包含以下指标：

指标	说明
upstream_rq_<*xx>	Counter，聚合状态码计数，例如5xx
upstream_rq_<*>	Counter，具体状态码计数，例如500
upstream_rq_time	Histogram，请求耗时ms

Envoy由一个JSON配置文件和一系列命令行选项一起驱动。命令行选项如下：

选项	说明
-c	v2版本的JSON/YAML/Proto3格式的配置文件路径。如果此选项缺失，则必须提供--config-yaml 有效的扩展名包括.json, .yaml, .pb, .pb_text
--config-yaml	v2版本的YAML格式、JSON格式的Bootstrap配置 如果同时指定了--config-path，则当前选项的配置覆盖到--config-path指定的配置
--mode	运行模式： serve，默认，启动代理 validate，验证配置是否有效并退出
--admin-address-path	管理地址/端口写入到什么文件中
--local-address-ip-version	服务本地IP地址使用v4还是v6
--base-id	共享内存区域的Base ID，Envoy在热重启时使用此区域 如果在一个节点上运行多个Envoy实例，则每个实例必须具有不同的Base ID
--concurrency	工作线程数量
-l	日志级别
--component-log-level	为每个组件定制日志级别
--log-path	日志记录未知，默认stderr
--log-format	日志格式，默认[%Y-%m-%d %T.%e][%t][%l][%n] %v
--service-cluster	定义Envoy所在节点的服务集群的名称
--service-node	定义Envoy所在节点的名称
--service-zone	定义Envoy所在的区域，区域的定义取决于上下文，例如AWS的可用性区域
--file-flush-interval-msec	文件（例如访问日志）刷出间隔ms，默认10秒
--drain-time-s	热重启时，等待多久Envoy会Drain掉连接。默认600s 通常应该小于--parent-shutdown-time-s
--parent-shutdown-time-s	热重启时，等待多久关闭主进程
--max-obj-name-len	cluster/route_config/listener的名字最大长度
--disable-hot-restart	禁用热重启
--allow-unknown-fields	用于禁用protobuf未知字段校验

Envoy暴露了一个本地的管理接口，可以用于查询/修改Envoy的各个方面。端点列表：

端点	说明
GET /	返回一个HTML页面，包含所有选项的链接
GET /help	所有选项的文本表格
GET /certs	列出加载的TLS证书
GET /clusters GET /clusters?format=json	列出所有已经配置的集群管理器集群，包括每个集群的所有上游主机、每个主机的统计信息
GET /config_dump	以JSON形式导出当前配置
GET /contention	如果mutex争用跟踪被启用，导出Envoy mutex争用信息
POST /cpuprofiler	启用或禁用CPU剖析，需要启用gperftools编译
POST /healthcheck/fail	发起一个入站健康检查失败
POST /healthcheck/ok	发起一个入站健康检查成功
POST /logging	修改组件的日志级别 Shell 1 2 3 4 # 修改所有级别 curl -X POST localhost:15000/logging?level=trace # 修改特定组件级别 curl -X POST localhost:15000/logging?main=trace
POST /memor	显示内存、堆使用情况
POST /quitquitquit	立即停止服务
POST /reset_counters	重置所有计数器
GET /server_info	获取服务器信息
GET /stats GET /stats?filter=regex GET /stats?format=json	输出统计信息
GET /stats/prometheus	以Prometheus v0.04格式输出统计信息，目前仅仅输出Counter、Gauge
GET /runtime	输出所有运行时设置

Envoy可以从文件系统或者一个/多个管理服务器发现各种动态资源。这些管理服务器提供的发现服务，以及发现服务的API，被称为xDS。

资源的通过订阅（subscription）的方式获得，订阅的初始化方式是 —— 指定需要监控的文件系统路径，初始化gRPC流，或者轮询REST-JSON URL。后两种方式需要发送DiscoveryRequest请求，资源则通过DiscoveryResponse返回。

本章主要讨论基于gRPC的流式订阅。

已经彻底废弃，基于REST-JSON的API。现在使用的是基于REST/gRPC的xDS API

不赞成使用，2020 EOL

推荐使用此版本。仍然是基于gRPC的REST。

对于每一个xDS API，你都可以指定一个ApiConfigSource：

这样，可以为每种xDS资源类型发起独立的（可以和不同服务器建立）双向gRPC流。

每种xDS API都操作某种类型的资源。xDS API和资源类型具有1:1对应关系：

1. LDS: envoy.api.v2.Listener
2. RDS: envoy.api.v2.RouteConfiguration
3. CDS: envoy.api.v2.Cluster
4. EDS: envoy.api.v2.ClusterLoadAssignment
5. SDS: envoy.api.v2.Auth.Secret

Envoy发送的多种请求、管理服务器返回的多种响应中，都需要声明Type URL。这些xDS API的Type URL的形式均为：type.googleapis.com/资源类型，例如type.googleapis.com/envoy.api.v2.Listener。

每个gRPC流以来自Envoy的DiscoveryRequest请求开始，指定一系列需要订阅的资源、这些资源对应的Type URL、节点标识符、空白的version_info，示例：

管理服务器可以立即应答，或者在请求的资源可用时进行应答，应答都封装在DiscoveryResponse中：

处理完DiscoveryResponse之后，Envoy会在gRPC流上发送新请求，提供最后一次成功应用的版本号以及管理服务器提供的nonce。在上面的例子中，如果DiscoveryResponse成功应用，则后续请求的version_info为X， response_nonce为A。

如果Envoy无法应用DiscoveryResponse，则会回复error_detail和上一个版本号给管理服务器。

每个gRPC流具有自己的版本号，不存在跨资源共享的版本号机制。当不使用ADS时，每种资源的版本不一样很正常。

仅仅DiscoveryResponse中的资源发生变化后，管理服务器才应该发送更新给Envoy。Envoy会在应用/拒绝DiscoveryResponse后，发送包含ACK/NACK的DiscoveryRequest给管理服务器。

在单个流中，后面的DiscoveryRequest代替先前的、相同资源类型的DiscoveryRequest。如果管理服务器接收到多个DiscoveryRequest，它可能只需要回复最后一个。

DiscoveryRequest中的resource_names字段是一个“提示”。

Cluster、Listener等资源类型的resource_name字段为空，管理服务器应该每次都提供完整的LDS/CDS资源列表。列表中不存在，但是Envoy中存在的资源会被删除。Listener/Cluster对应的EDS/RDS资源会自动被级联删除。

对于EDS/RDS，管理服务器不需要提供每个请求的资源，另外它也可以提供没有请求的资源。resource_names仅仅是个提示。管理服务器能够从DiscoveryRequest的node（节点标识）字段推断出哪些资源是需要的。

Envoy的xDS API是最终一致性的。在一次次DiscoveryResponse可能导致应用程序流量丢失。

考虑这样的一个场景，当前通过CDS/EDS仅仅获知了集群X的信息。一个引用X的RouteConfiguration，将X改为Y并更新，在Y集群的尚未通过CDS/EDS发现指前，流量都进入黑洞。

部分应用程序允许流量丢失，应用代码或者Sidecar中的重试可能隐藏这种流量丢失。另外一些应用则不能忍受流量丢失，这就要求管理服务器以一定的顺序推送更新。一般来说，避免流量丢失的推送时序如下：

1. 如果存在CDS更新，则必须首先推送
2. EDS更新必须在对应CDS更新之后推送
3. LDS更新必须在对应的CDS/EDS更新之后推送
4. 和新添加监听器有关的RDS必须在最后推送

如果没有新的集群/路由/监听器、或者可以容忍临时的流量丢失，则xDS更新可以独立的推送。

前面提到了最终一致性问题和解决流量丢失的手段。在分布式管理服务器场景下，保证更新的时序是很困难的。

ADS允许单个管理服务器通过单个gRPC流来推送所有的API更新。使用ADS，管理服务器可以小心编排推送时序，避免流量丢失。多个DiscoveryRequest/DiscoveryResponse序列可以基于Type URL进行gRPC流的多路复用，并且保证上节描述的推送时序

Incremental xDS是ADS/CDS/RDS的独立的xDS端点，允许：

1. 增量式的更新被xDS客户端跟踪的资源列表。这允许Envoy按需/延迟的请求额外的资源。例如当一个针对位置集群的请求到达时，触发对此集群的更新
2. 增强xDS可扩容性，避免单个集群信息变更就被迫推送100K的完整集群列表

Incremental xDS仅仅支持gRPC，增量xDS会话总是在单个gRPC双向流的上下文中发生，xDS服务器可以跟踪每个连接到它的xDS客户端的状态，以决定什么需要推送。

增量xDS使用nonce字段将 IncrementalDiscoveryResponse和IncrementalDiscoveryRequest的ACK/NACK进行配对。