Envoy Proxy使用介绍教程（三）: envoy设计思路、配置文件和功能特性概览
目录
说明
这篇笔记比较老，不再更新维护，请移步最新的手册：envoy相关笔记。
通过走读envoy的文档，对envoy有一个整体的认识，了解设计思路、配置方法。特别是配置文件，我们需要的不是零零碎碎的对配置文件的介绍，而是一个大一统的、包含所有配置项的配置文件模板。当我们想实现某项功能的时候，不需要漫天搜索，只需要到这个完整的配置文件模板中看一看有没有相关配置即可。
Envoy的设计思路
Envoy是单进程、多线程设计，主线程负责协调任务，连接listener的连接建立之后，由woker线程负责处理。
一个envoy进程支持创建多个listener，建议一台机器上只部署一个envoy，这样更方便数据统计，listener现在只支持TCP协议（2018-12-20 18:56:55）
在envoy中最主要的两个概念是listener和cluster 。
listener就是envoy的监听地址，包含请求转发之前的所有配置。
cluster就是一组最终提供服务的机器（upstream server）。
用户请求通过listener的监听地址进入envoy后，经过listener中一系列filter的处理，转发给cluster中的某个upstream server。
Listener
每个listener的配置都是独立的，可以配置分别多个network level filter。
Listener可以有多个，可以通过LDS（listener discovery service）动态发现。
在listener中可以配置filters，filter一共有三种：listener filter、network filter和http filter。
listener filter是listener层的插件，network filter是网络层（L3/L4)插件，http filter是HTTP插件。
listener filter在network filter之前调用，http_filter是名为envoy.http_connection_manager的filter中的filter。
listener filter管理连接的元数据，envoy已经实现了几个listener filter。
network filter相对简单，处理的是原始字节，分为Read、Write和Read/Write三类，envoy已经实现了多个network filter，支持TLS认证、限速、RBAC等。
其中HTTP connection manager是一个比较复杂的network filter，它将原始字节转换成http格式，从而可以对http协议进行精确控制。
HTTP connection manager内部又实现了HTTP filters，分为Decoder、Encoder和Decoder/Encoder三类。HTTP router filter实现了根据http协议字段进行路由的功能。
其它内容
Envoy状态分为static state和dynamic state
Cluster manager管理upstreams，向network filter暴露API，由network filter决定是否要建立连接。
Clusters可以在配置文件中设置，也可以动态获取：Cluster discovery service。
Access logging的输出格式可以自己定义。
进行全局限速的时候需要配置Rate limit service。
Runtime可以将指定目录中的所有文件作为配置读取，并可以通过admin接口查看、修改。
Statistics中给出了envoy的统计数据。
Envoy还提供了一个路由表检测工具。
Envoy过载时可以采取一定的动作、限制某些功能，通过overload manager设置。
TLS证书可以在配置文件中设置，也可以通过Secret discovery service (SDS)动态获取。
Envoy提供了一个封装了envoy命令的python脚本，使用这个脚本后，可以通过systemd、monit、runit等进行热加载，见Hot restart Python wrapper。
Administration interface中列出Envoy的admin api。
可以在upstream和downstream之间捕获报文https://www.envoyproxy.io/docs/envoy/latest/operations/traffic_capture 。
Envoy的filter的开发方法见Extending Envoy for custom use cases。
envoy的命令行参数
Envoy的命令行参数不多，大都比较好理解。目前还有下面三个参数，还没搞清楚具体作用：
--service-cluster <string>
--service-node <string>
--service-zone <string>
envoy的配置文件
Envoy文档中没有对配置文件的详细介绍，而是给出了v2 API reference，配置文件中的内容和这些API一一对应。
Bootstrap就是envoy的配置文件的完整定义：
{
"node": "{...}",
"static_resources": "{...}",
"dynamic_resources": "{...}",
"cluster_manager": "{...}",
"hds_config": "{...}",
"flags_path": "...",
"stats_sinks": [],
"stats_config": "{...}",
"stats_flush_interval": "{...}",
"watchdog": "{...}",
"tracing": "{...}",
"rate_limit_service": "{...}",
"runtime": "{...}",
"admin": "{...}",
"overload_manager": "{...}"
}
每个配置项的定义都可以在config.bootstrap.v2.Bootstrap中找到。
envoy配置的动态更新
Envoy的作者Matt Klein在The universal data plane API讲述了envoy api的设计过程。envoy最初是一个最终一致的服务发现系统，定义了很简洁的api，开源以后陆续有人咨询能否支持kubernetes等系统，并且有人自己动手实现了。
Matt Klein意识到envoy能够被越来越多人采纳，主要是因为它的api设计，envoy的api设计使envoy规则更新很方便（对比nginx和haproxy）。
目前envoy的发展方向是成为一个接口丰富、性能优良的data plane。
有了动态获取配置的功能后，每台机器上的envoy可以用同样的配置文件启动，
Envoy有志于设计一套通用的data plane api，并且已经将自己的api定义抽取出来，成立了一个单独的项目data-plane-api。
将data plane和control plane解耦后，data plane可以专注于性能提升和新特性，control plane可以专注于管理和流程。
go-control-plane是envoy提供的一个用Go语言实现的control plane。
Envoy的动态配置主要有以下几个概念：
CDS：用于发现clusters，在”dynamic_resources”中配置。
LDS：用于发现listeners，在”dynamic_resources”中配置。
ADS：聚合发现， 用于将更新聚合，使用ADS，可以在一个连接中完成相关的CDS、LDS、RDS的更新，在”dynamic_resources”中配置。
EDS：endpoint discovery service，用于发现cluster中的upstream，在每个cluster中单独配置。
RDS：route discovery service，用于发现路由规则，在每个HTTP connection manager中单独配置。
SDS：用于发现TLS证书。
HDS：只在The universal data plane API中看到一句说明，说是将envoy加入健康检查网络，避免出现N的平方个连接。
后续
envoy的配置文件比较庞大，后面单独开一篇笔记将envoy的配置文件完全展开，并且试验各项功能。
参考
