01 Envoy基础理论

服务网格概述

服务网格是指专注于处理服务间通信的基础设施，它负责在现代云原生应用组成的复杂拓扑中可靠地传递请求;

Sidecar治理模式是新一代的解决方案：让服务集中解决业务逻辑的问题，网络相关的功能则与业务逻辑剥离，并封装为独立的运行单元并作为服务的反向透明代理，从而不再与业务紧密关联。换句话说，微服务的业务程序独立运行，而网络功能则以独立的代理层工作于客户端与服务之间，专门为代理的服务提供熔断、限流、追踪、指标采集和服务发现等功能; 而这些由各服务的专用代理层联合组成的服务通信网络则称之为服务网格(Service Mesh);

Service Mesh解决方案极大降低了业务逻辑与网络功能之间的耦合度，能够快捷、方便地集成到现有的业务环境中，并提供了多语言、多协议支持，运维和管理成本被大大压缩，且开发人员能够将精力集中于业务逻辑本身，而无须再关注业务代码以外的其它功能。

数据平面与控制平面

数据平面：触及系统中的每个数据包或请求，负责服务发现、健康检查、路由、负载均衡、身份验证/授权和可观测性等;

控制平面：为网格中的所有正在运行的数据平面提供策略和配置，从而将所有数据平面联合构建为分布式系统，它不接触系统中的任何数据包或请求;负责的任务包括例如确定两个服务Service X到Sevice Y之间的路由，Service Y相关集群的负载均衡机制、断路策略、流量转移机制等，并将决策下发给Service X和Service Y的Sidecar;

控制平面组件

工作负载调度程序:借助于底层的基础设施(例如kubernetes)完成服务及其Sidecar运行位置的调度决策;
服务发现:服务网格中的服务发现;·
Sidecar代理配置API:各Sidecar代理以最终一致的方式从各种系统组件获取配置;
控制平面UI:管理人员的操作接口，用于配置全局级别的设置，例如部署、身份认证和授权、路由及负载均衡等;

服务网格通讯逻辑

一旦启用Service Mesh，服务间的通信将遵循以下通信逻辑。

微服务彼此间不会直接进行通信，而是由各服务前端的称为Service Mesh的代理程序进行;
Service Mesh内置支持服务发现、熔断、负载均衡等网络相关的用于控制服务间通信的各种高级功能;
Service Mesh与编程语言无关，开发人员可以使用任何编程语言编写微服务的业务逻辑，各服务之间也可以使用不同的编程语言开发;
服务间的通信的局部故障可由Service Mesh自动处理;
Service Mesh中的各服务的代理程序由控制平面(Control Plane)集中管理;各代理程序之间的通信网络也称为数据平面(Data Plane);
部署于容器编排平台时，各代理程序会以微服务容器的Sidecar模式运行;

服务网格的基本功能

控制服务间通信:熔断、重试、超时、故障注入、负载均衡和故障转移等;
服务发现:通过专用的服务总线发现服务端点;
可观测:指标数据采集、监控、分布式日志记录和分布式追踪;
安全性:TLS/SSL通信和密钥管理;
身份认证和授权检查:身份认证，以及基于黑白名单或RBAC的访问控制功能;
部署:对容器技术的原生支持，例如Docker和Kubernetes等;
服务间的通信协议:HTTP 1.1、HTTP 2.0和gRPC等;
健康状态检测:监测上游服务的健康状态;
……

服务网格的部署模式

服务网格的部署模式有两种:主机共享代理及Sidecar容器

主机共享代理
- 适用于同一主机上存在许多容器的场景，并且还可利用连接池来提高吞吐量
- 但一个代理进程故障将终止其所在主机上的整个容器队列，受影响的不仅仅是单个服务
- 实现方式中，常见的是运行为Kubernetes之上的DaemonSet
sidecar容器
- 代理进程注入每个Pod定义以与主容器一同运行
- Sidecar进程应该尽可能轻量且功能完善
- 实现方案:Linkerd、Envoy和Conduit

Envoy概述

Envoy是一个7层代理和通信总线。

Envoy数据通道

Envoy的几个显著特性

性能、可扩展性及动态可配置性
- 性能：除了大量功能外，Envoy还提供极高的吞吐量和低尾延迟差异，同时消耗相对较少的CPU和RAM;
- 可扩展性：Envoy在L4和L7上提供丰富的可插拔过滤器功能，允许用户轻松添加新功能；同时用户可以自己开发所需的过滤器。
- API动态可配置性：Envoy提供了一组可由控制平面服务实现的管理API(动态可配置)，也称为xDS API。若控制平面实现了这所有的API，则可以使用通用引导配置在整个基础架构中运行Envoy，所有进一步的配置更改都可通过管理服务器无缝地进行动态传递，使得Envoy永远不需要重新启动，于是，这使得Envoy成为一个通用数据平面，当与足够复杂的控制平面相结合时，可大大降低整体操作复杂性。简而言之，xDS API使得Envoy从外部(控制平面)获取配置文件，并能够动态生效配置。
Envoy xDS API存在v1和v2两个版本：v1 API仅使用 JSON/REST，本质上是轮询； v2 API是v1的演进，而不是革命，它是v1功能的超集，新的API模式使用proto3指定，并同时以gRPC和REST+JSON/YAML端点实现；
Envoy已成为现代服务网格和边缘网关的“通用数据平面API”，Istio、 Ambassador和Gloo等项目均是为此数据平面代理提供的控制平面;

高级特性

分区识别(zone aware)，最小请求负载均衡
熔断
故障识别
支持重试和重试策略
支持超时
流量镜像
速率限制
访问日志、统计信息收集
……

Envoy基础组件

集群(Cluster)：集群是Envoy连接到的一组逻辑上相似的端点;在v2中，RDS通过路由指向集群，CDS提供集群配置，而Envoy通过EDS发现集群成员，即端点;
下游(Downstream)：下游主机连接到Envoy，发送请求并接收响应，它们是Envoy的客户端;
上游(Upstream)：上游主机接收来自Envoy的连接和请求并返回响应，它们是Envoy代理的后端服务器;
端点(Endpoint)：端点即上游主机，是一个或多个集群的成员，可通过EDS发现;
侦听器(Listener)：侦听器是能够由下游客户端连接的命名网络位置，例如端口或unix域套接字等 ;
位置(Locality)：上游端点运行的区域拓扑(位置)，包括地域、区域和子区域等;
管理服务器(Management Server):实现v2 API的服务器，它支持复制和分片，并且能够在不同的物理机器上实现针对不同xDS API的API服务;
地域(Region)：区域所属地理位置;
区域(Zone)：AWS中的可用区(AZ)或GCP中的区域等;
子区域：Envoy实例或端点运行的区域内的位置，用于支持区域内的多个负载均衡目标;
xDS：CDS 、EDS、HDS 、LDS、RLS(Rate Limit)、 RDS 、 SDS、VHDS和RTDS等API的统称;

部署类型

Envoy通常用于以容器编排系统为底层环境的服务网格中，并以sidecar的形式与主程序容器运行为单个Pod;

非编排系统环境中测试时，可以将主程序与Envoy运行于同一容器，或手动组织主程序容器与Envoy容器共享同一网络名称空间;

3种常见的部署类型(场景)：

Service to service

Service to service only

Service to service egress listener
- The port used by applications to talk to other services in the infrastructure
Service to service ingress listener
- The port used by remote Envoys when they want to talk to the local Envoy
Optional external service egress listeners

Service to service egress listener

This is the port used by applications to talk to other services in the infrastructure.

HTTP and gRPC requests use the HTTP/1.1 host header or the HTTP/2 :authority header to indicate which remote cluster the request is destined for.
Envoy handles service discovery, load balancing, rate limiting, etc. depending on the details in the configuration.
Services only need to know about the local Envoy and do not need to concern themselves with network topology, whether they are running in development or production, etc.

Service to service ingress listener

This is the port used by remote Envoys when they want to talk to the local Envoy.

Incoming requests are routed to the local service on the configured port(s).
Multiple application ports may be involved depending on application or load balancing needs (for example if the service needs both an HTTP port and a gRPC port).
The local Envoy performs buffering, circuit breaking, etc. as needed.

Front proxy

Service to service Plus front proxy

The above diagram shows the service to service configuration sitting behind an Envoy cluster used as an HTTP L7 edge reverse proxy.
- 终止TLS连接;
- 支持HTTP/1.1和HTTP/2;
- HTTP L7路由;
- 通过Front-Envoy的Ingress接入请求，并结合发现服务与Service-to-Service的Envoy网格进行通信;
The front Envoy hosts work identically to any other Envoy host, other than the fact that they do not run collocated with another service.

Double proxy

Service to service, front proxy, and double proxy

双代理的目标是尽可能接近用户地终止 TLS 和客户端连接会更高效

Envoy线程模型

Envoy使用单进程/多线程的架构模型，一个主线程 (Main thread)负责实现各类管理任务，而一些工作线程(Worker threads)则负责执行监听、过滤和转发等代理服务器的核心功能

主线程：负责Envoy程序的启动和关闭、xDS API调用处理(包括DNS、健康状态检测和集群管理等)、运行时配置、统计数据刷新、管理接口维护和其它线程管理( 信号和热重启等)等，相关的所有事件均以异步非阻塞模式完成;
工作线程：默认情况下，Envoy根据当前主机CPU核心数来创建等同数量的工作线程，不过，管理员也可以通过程序选项-- concurrency具体指定；每个工作线程运行一个非阻塞型事件循环，负责为每个侦听器监听指定的套接字、接收新请求、为每个连接初始一个过滤器栈并处理此连接整个生命周期中的所有事件;
文件刷写线程：Envoy写入的每个文件都有一个专用、独立的阻塞型刷写线程，当工作线程需要写入文件时，数据实际上被移入内存缓冲区，最终通过文件刷写线程同步至文件中

Envoy连接处理

Envoy通过侦听器监听套接字并接收客户端请求，而Envoy的所有工作线程会同时共同监听用户配置的所有套接字，对于某次连接请求，由内核负责将其派发至某个具体的工作线程(Worker)处理; 随后，相关的工作线程基于特定的处理逻辑分别由相关组件依次完成连接管理;

Envoy配置

概述

启动时从Bootstrap配置文件中加载初始配置
支持动态配置
- xDS API
  - 从配置文件加载配置
  - 从管理服务器(Management Server)基于xds协议加载配置
- runtime
  - 某些关键特性(Feature flags)保存为key/value数据
  - 支持多层配置和覆盖机制
启用全动态配置机制后，仅极少数场景需要重新启动Envoy进程
- 支持热重启

配置方式

Envoy的架构支持非常灵活的配置方式：简单部署场景可以使用纯静态配置，而更复杂的部署场景则可以逐步添加需要的动态配置机制;

纯静态配置：用户自行提供侦听器、过滤器链、集群及HTTP路由(http代理场景)，上游端点的发现仅可通过DNS服务进行，且配置的重新加载必须通过内置的热重启(hot restart)完成;
使用EDS：EDS提供的端点发现功能可有效规避DNS的限制(响应中的最大记录数等 );其他配置通过静态配置
使用EDS和CDS：CDS能够让Envoy以优雅的方式添加、更新和删除上游集群，于是，初始配置时，Envoy无须事先了解所有上游集群;
EDS、CDS和RDS：动态发现路由配置;RDS与EDS、CDS一起使用时，为用户提供了构建复杂路由拓扑的能力(流量转移、蓝/绿部署等);
EDS、CDS、RDS和LDS：动态发现侦听器配置，包括内嵌的过滤器链;启用此四种发现服务后，除了较罕见的配置变动、证书轮替或更新Envoy程序之外，几乎无须再热重启 Envoy;
EDS、CDS、RDS、LDS和SDS：动态发现侦听器密钥相关的证书、私钥及TLS会话票据，以及对证书验证逻辑的配置(受信任的根证书和撤销机制等);

配置文件中的重要概念

Bootstrap配置中几个重要的基础概念

node：节点标识，以呈现给管理服务器并且用于标识实例目的;
static_resources：静态配置的资源，用于配置静态的listener、cluster 和secret;
dynamic_resources：动态配置的资源，用于配置基于xDS API获取listener、cluster和secret配置的lds_config、cds_config和ads_config;
admin：Envoy内置的管理接口;
tracing：分布式跟踪;
layered_runtime：层级化的运行时，支持使用RTDS从管理服务器动态加载;
hds_config：使用HDS从管理服务器加载上游主机健康状态检测相关的配置（health_check）;
overload_manager：过载管理器;
stats_sinks：统计信息接收器;

一般来说，侦听器和集群是最为常用基础配置，无论是以静态或者是动态方式提供;

{
    "node":"{...}",
    "static_resources":"{...}",
    "dynamic_resources":"{...}",
    "cluster_manager":"{...}",
    "hds_config":"{...}",
    "flags_path":"...",
    "stats_sinks":[],
    "stats_config":"{...}",
    "stats_flush_interval":"{...}",
    "watchdog":"{...}",
    "tracing":"{...}",
    "runtime":"{...}",
    "layered_runtime":"{...}",
    "admin":"{...}",
    "overload_manager":"{...}",
    "enable_dispatcher_stats":"...",
    "header_prefix":"..."
}

侦听器和集群配置概述

侦听器
- 接收客户端请求的入口端点，通常由监听的套接字及调用的过滤器链所定义
- 代理类的过滤器负责路由请求，例如tcp_proxy和http_connection_manager等
集群
- 集群是一组上游主机的逻辑组合
- 每个主机映射为集群中的一个端点
- 下游的请求被调度至上游主机

Listeners

Envoy支持在一个进程中配置任意个Listeners。

独立部署时，建议每个主机仅部署单个Envoy实例，并在必要时于此实例上运行一到多个侦听器；
目前，Envoy仅支持TCP侦听器;（不支持UDP侦听器）

每个侦听器都独立配置了一定数量的网络级别 (L3/L4) 过滤器。侦听器收到的连接请求将由其过滤器链中的各过滤器依次进行处理;

不同的过滤器执行不同代理任务：

rate limiting
TLS client authentication
HTTP connection management（HCM）
MongoDB sniffing
raw TCP proxy
etc.

每个侦听器都应独立配置一些网络(L3/L4)过滤器，在接收到请求后，侦听器负责实例化出指定的过滤器链中的各个过滤器，并由这些过滤器处理后续的相关事件。一般说来，用户可根据为其指定使用不同的过滤器链配置侦听器用于完成不同代理任务，例如HTTP代理、TCP代理、TLS客户端认证、限速等

Network (L3/L4) filters

Network level (L3/L4) filters form the core of Envoy connection handling.
- The filter API allows for different sets of filters to be mixed and matched and attached to a given listener.
- 有3种不同类型的L4过滤器:
  - Read: Read filters are invoked when Envoy receives data from a downstream connection（当Envoy从下游连接接收数据时调用Read过滤器）.
  - Write: Write filters are invoked when Envoy is about to send data to a downstream connection（当Envoy向下游连接发送数据前，调用Write过滤器）.
  - Read/Write: Read/Write filters are invoked both when Envoy receives data from a downstream connection and when it is about to send data to a downstream connection.
- The API for network level filters is relatively simple since ultimately the filters operate on raw bytes and a small number of connection events
- Filters in the chain can stop and subsequently continue iteration to further filters.
网络过滤器访问和操作L4连接上的原始数据，即TCP数据包。例如， TCP代理过滤器将客户端连接数据路由到上游主机，并生成连接统计信息等。
Enovy内置了许多L3/L4过滤器，例如
- 代理类：TCP Proxy、HTTP connection manager、Thrift Proxy、Mongo proxy、Dubbo Proxy、ZooKeeper proxy、MySQL proxy和Redis proxy等，
- 其它：Client TLS authentication、Rate limit、Role Based Access Control (RBAC) Network Filter和Upstream Cluster from SNI等;

HTTP (L7) filters

HTTP connection manager

HTTP connection manager自身是L3/L4过路器，它能够将原始字节转换为HTTP级别消息和事件(例如，headers和body等)
它还处理所有HTTP连接和请求共有的功能，例如访问日志记录、请求ID生成和跟踪、请求/响应头操作、路由表管理和统计信息等;
与L3/L4过滤器堆栈相似，Envoy还支持在HTTP连接管理器中使用HTTP级过滤器堆栈;
- HTTP过滤器在L7运行，它们访问和操作HTTP请求和响应;例如，gRPC-JSON Transcoder Filter为gRPC后端公开REST API，并将请求和响应转换为相应的格式;
- 常用的HTTP过路器有Router、Rate limit、Health check、Gzip和Fault Injection等;

Upstream clusters

Envoy可配置任意数量的上游集群，并使用Cluster Manager进行管理；由集群管理器负责管理的各集群可以由用户静态配置，也可借助于CDS API动态获取;

集群中的每个成员由endpoint进行标识，它可由用户静态配置，也可通过EDS或DNS服务动态发现，定义集群成员的方法：

Static：静态配置
Strict DNS：严格DNS，Envoy将持续和异步地解析指定的DNS目标，并将DNS结果中的返回的每个IP地址视为上游集群中可用成员;
Logical DNS：逻辑DNS，集群仅使用在需要启动新连接时返回的第一个IP地址，而非严格获取DNS查询的结果并假设它们构成整个上游集群；适用于必须通过DNS访问的大规模 Web服务集群;
Original destination：当传入连接通过iptables的REDIRECT或TPROXY target或使用代理协议重定向到Envoy时，可以使用原始目标集群;
Endpoint discovery service (EDS)：EDS是一种基于GRPC或REST-JSON API的xDS管理服务器获取集群成员的服务发现方式;
Custom cluster：Envoy还支持在集群配置上的cluster_type字段中指定使用自定义集群发现机制;

clusters:
- name: test_cluster
  connect_timeout: 0.25s
  type: STATIC
  lb_policy: ROUND_ROBIN 
  load_assignment:
    cluster_name: test_cluster 
    endpoints:
    - lb_endpoints:
      - endpoint: 
          address:
            socket_address: { address: 172.17.0.3, port_value: 80 } 
      - endpoint:
          address:
            socket_address: { address: 172.17.0.4, port_value: 80 }

01 Envoy基础 理论