Envoy之代码架构

灰子学技术

发布于 2021-07-09 11:46:11

7440

发布于 2021-07-09 11:46:11

本篇文章主要来介绍Envoy都做了哪些事情，分成了哪些模块。笔者会按照下面的思路来介绍这部分内容：

对于Envoy来说，几乎所有配置都可以通过订阅来动态获取，如监控指定路径下的文件、启动gRPC流或轮询REST接口，对应的发现服务以及各种各样的API统称为xDS。Envoy与xDS之间通过Proto约定请求和响应的数据模型，不同类型资源，对应的数据模型也不同。

1. 资源介绍：

也正是这个原因，Envoy抽象出来了四种资源，他们分别是Listener，Router，Cluster，以及Filter。

备注：资源是指Envoy根据相关配置创建出来的具有某种特定功能或者目的的实体。

2. XDS协议：

定义：对应的发现服务以及各种各样的 API 统称为 xDS。

XDS处理流程：Envoy通过xDS协议与控制面实现配置数据的交换。当控制面检测中配置变化（比如通过Kubernetes Watch到新service或者其他的CRD资源更新），会向Envoy发送一个discoveryResponse来将更新后的配置下发到Envoy。之后，Envoy主线程在接受到数据之后，通过向各个工作线程中追加配置更新事件来完成配置的实际更新和生效。

增量XDS： 因为这种全量更新，在路由中的很小的更新都必须要全量通知，这也就导致了大量的流量浪费和不必要的计算开销。Envoy社区提出了delta xDS方案，实现增量的xDS配置更新。简单的说，在delta增量更新方案中，当配置发生变化时，只有发生变化的一项配置（配置的最小单位为一个完整的proto message）需要下发和更新。

下面是xDS以及各个资源之间的关系：

3. 可观察性部分：

日志: 是对 Envoy 中事件（主要是指下游请求）的详细记录，用于定位一些疑难问题。 Envoy提供了灵活的的标记符系统来让用户可以自由的组装和定义自己的日志格式以及所包含的内容。同时， Envoy也提供了强大的日志过滤能力，在数据量较大时，可以以此过滤掉非关键数据。借助 xDS 协议，无论是日志格式还是过滤规则，都可以在运行时动态的变化和修改。

代码中与access_log对应起来。

指标:是对 Envoy 中事件的数值化统计，往往需要搭配 Prometheus 等事件数据库配合使用。 Envoy提供了筛选器、集群等多种维度的丰富的指标，包括请求响应码类型、响应耗时区间、异常事件记录等等。而且 Envoy允许筛选器自由的扩展属于自己的独特指标计数，如 HTTP 限流、鉴权等筛选器都扩展了对应的指标，使得 Envoy也可以从某个具体的流量治理功能的角度观察流量情况。

代码中与stats对应起来。

追踪:是对 Envoy 以及上下游服务中多个事件因果关系的记录，必须要上下游服务同时支持，并对接外部追踪系统。 Envoy原生支持了 Lightstep、Zipkin 等多种追踪系统，无需额外的修改或者开发，只需要简单的配置即可。

代码中与tracing对应起来。

4. 外部API和进程管理

Main 线程负责配置更新（对接 xDS 服务）、监控指标刷新和输出、对外提供 Admin 端口等工作。此外，Main 线程也负责整个进程的管理。如处理操作系统信号、Envoy热重启等。

5.角色功能：

作为一个服务代理软件，Envoy并不限定自己的使用方法。它最常扮演的是两种不同的角色，一种是作为集群流量入口API网关（Gateway），管理南北流量；一种是作为服务Sidecar，拦截并治理服务网格中东西流量。

南北流量通过API网关来管理，集中管理集群或者网格对外暴露的接口，为集群外或者网格外客户端调用集群内或网格内服务提供了统一的流量入口和治理方案。

东西流量通过使用Sidecar拦截服务的进出口流量。作为Sidecar时，Envoy通过修改IP Table实现对服务的进出口流量的拦截，并进一步实现对进出口流量的管理。每个Sidecar通过xDS协议和控制面交互，获取集群中其他服务的相关信息以及各种服务治理相关（鉴权、分流、流量复制等等）的配置。服务本身只需要专注于业务逻辑，所有网络流量相关的工作都委托给Envoy Sidecar。

6.Envoy配置下发流程

当Pilot发现新的服务或路由规则被创建（通过监控K8S集群中特定CRD资源变化、或者发现Consul服务注册和配置变化），Pilot会通过已经和Envoy之间建立好的gRPC流将相关的配置推送到Envoy。Envoy接收到相关配置并校验无误之后，就会动态的更新运行时配置，使用新的配置更新相关资源，如下图所示：