Envoy，使者，使节，代表！就像其单词含义本身一样，带着一种权威感，一种全代理的神圣感。结合其本身用途与角色，真是“人如其名”，不禁为Lyft点赞，不知是得到了哪位大师的指点来起这个名字。在当前火热的微服务时代下，Envoy是个绝对的明星，用众人皆知来形容可以说一点也不为过。曾有人问我如何看Envoy以及在云原生时代下是否Enovy将取代F5取代NGINX，作为一个经历了两次应用交付技术领域更迭浪潮的老兵，在本文中我将来浅谈一下Envoy，以及试图从个人角度来理解与回答一下这个问题。为什么说浅谈一下，这真的不是谦虚，而是客观上真的没有那么深入的大规模长时间使用和研究Envoy的所有技术细节，因此我将结合我的从业经历与经验来对Envoy做一个浅谈。

星光熠熠的Envoy

首先我们看一下Envoy官方是如何介绍Envoy的：

从网站首页的这一段描述可以清晰的看出官方对Envoy的定义，简单来说就是云原生时代下东西南北流量的代理。Lfyt公司是微服务应用架构的先导者，在大量的微服务类布道文章中我们都可以看到Lfyt的身影，在从单体应用大规模转向微服务架构后，一个严重的问题摆在了开发与架构人员面前，一方面Lyft的服务采用了多种语言开发，而采用类库来解决分布式架构下的各种问题需要进行大量的语言适配以及对代码的侵入，另一方面Lyft的业务都是部署在AWS上的，大量依赖AWS的ELB以及EC2，但是ELB以及AWS在当时所提供的服务间流量管控、洞察与问题排除都不能满足Lyft的需求，正是基于这样的背景，Lfyt于2015年5月开始了Envoy的开发，最早是作为一个边缘代理进行部署并开始替代ELB，随后开始作为sidecar方式进行大规模部署。2016年9月14日，Lyft在其博客上正式对外宣布了这一项目： Envoy C++ L7代理与通信总线 。 一时间Envoy得到了大量的关注，Google等公司开始贡献到这个项目里，并在一年后的2017年9月将项目捐献给CNCF。有了Lyft这样一个好妈，又过继给了CNCF这样一个富爸，再加上同父异母的Istio明星兄弟的加持，可以说Envoy一时风光无两，赚足了眼球与开发者的支持，仅一年多点时间便从CNCF毕业了。

容器技术助推了企业实践Devops与进行微服务改造，k8s容器编排平台则让企业能够更加自信的将更多业务从传统架构迁移到基于容器的现代基础架构之上，k8s解决了容器编排、应用发布等问题，但是当服务之间的通信从以前的内存之间调用变成了基于TCP的网络通信后，网络对应用服务的影响变得更加巨大与不确定，基于传统的应用架构的运维手段无法适应与解决巨大且复杂的服务间通信洞察、排错，为了解决这样的问题，sevice mesh应用而生，并迅速成为关注的热点。Istio项目则是此生态中最重要的玩家，Istio的架构是一个典型的管理平面与数据分离的架构，在数据平面的选择上是开放的，但是Istio默认选择了Envoy作为数据平面。两大人气明星强强联手，让几乎同一时期的linkerd变得黯然失色。而在这个时间点，NGINX同样也曾短暂的进行了Nginmesh项目，试图让NGINX作为Istio的数据平面，但最终在2018年底放弃了，为什么会放弃，这个本文后面会提到。

当前除了Istio选择Envoy作为数据平面外，以Envoy为基础的项目还有很多，例如k8s的多个Ingress Controller项目：Gloo, Contur, Ambassador。 Istio自身的Ingress gateway与Egress gateway同样选择的是Envoy。来看下其官方首页列出的Envoy用户，说星光熠熠一点也不为过。注意列表里的F5，是不是很有意思。

[root@k8s-master-v1-16 ~]# kubectl exec -it productpage-v1-7f4cc988c6-qxqjs -n istio-bookinfo -c istio-proxy -- sh $ curl http://127.0.0.1:15000/config_dump | wc -l % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 634k 0 634k 0 0 10.1M 0 --:--:-- --:--:-- --:--:-- 10.1M 20550

显然，Envoy的设计天生就不是为手工而设，因此Envoy设计了大量的xDS协议接口，需要用户自行设计一个xDS的服务端实现对所有配置处理，Envoy支持gRPC或者REST与服务端进行通信从而更新自身的配置。 xDS是Envoy DS（discover service）协议的统称，具体可分为Listener DS（LDS), Route DS(RDS), Cluster DS(CDS), Endpoint DS(EDS), 此外还有Secret DS，为了保证配置一致性的聚合DS-ADS等， 更多的xDS可查看 这里。这些接口用于自动化产生各种具体不同的配置对象。可以看出，这是一个高度动态性的运行时配置，要想用好它则必须开发一个具有足够能力的server端，显然这不是传统反向代理软件的设计思维。

[root@k8s-master-v1-16 ~]# kubectl exec -it productpage-v1-7f4cc988c6-qxqjs -n istio-bookinfo -c istio-proxy -- sh $ ps -ef UID PID PPID C STIME TTY TIME CMD istio-p+ 1 0 0 Jun25 ? 00:00:33 /usr/local/bin/pilot-agent proxy sidecar --domain istio-bookinfo.svc.cluster.local --serviceCluster productpage.istio-bookinfo --proxyLogLevel=warning --proxyComp istio-p+ 14 1 0 Jun25 ? 00:05:31 /usr/local/bin/envoy -c etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster productpage.istio-bookin istio-p+ 142 0 0 15:38 pts/0 00:00:00 sh istio-p+ 148 142 0 15:38 pts/0 00:00:00 ps -ef

Envoy容许用户以灵活的方式在灵活的位置定义灵活的日志格式，这些变化可以通过动态配置下发从而实现立即生效，并容许定义对日志的采样等。在Metrics则提供了能够与Prometheus进行集成的诸多指标，值得一提的是Envoy容许filter本身来扩充这些指标，例如在限流或者验证等filter中容许插件本身定义属于自己的指标从而帮助用户更好的使用和量化插件的运行状态。在Tracing方面Envoy支持向zipkin，jaeger，datadog，lightStep等第三方集成，Envoy能够生产统一的请求ID并在整个网络结构中保持传播，同时也支持外部的x-client-trace-id，从而实现对微服务之间关系拓扑的描述。

请求的开始时间和持续时间。

通过设置 --service-node 的原始主机信息 。

通过 x -envoy-downstream-service-cluster 标头设置的下游集群 。

HTTP请求URL，方法，协议和用户代理。

通过 custom_tags 设置的其他自定义标签 。

上游群集名称和地址。

HTTP响应状态代码。

GRPC响应状态和消息（如果可用）。

HTTP状态为5xx或GRPC状态不是“OK”时的错误标记。

跟踪特定于系统的元数据。

其实，说Envoy具有现代性显然是正确的废话，Envoy天生为现代应用架构而生，这里主要是想从几个我们最容易能够感受到的方面来说明一下。首先是其特殊的结构设计，在Envoy里它支持利用iptables截取流量并做透明处理，其本身能够利用getsockopt()实现对NAT条目中原始目的信息的提取，并在listener监听上容许在从被跳转的端口listener中跳跃到实际能匹配原始目的信息的非绑定型listener，尽管从反向代理角度看这就有点像F5的VS内部跳转，NGINX的subrequest，但是其最大的特点和能力在于对连接的透明性，这在Pod sidecar模式的部署中显得尤其重要。具体原理可参考我的 另一篇博文 。

对于现代应用最爱的灰度发布，流量镜像，断路器，全局限流等等功能，其在配置上也非常的简洁，这一点尽管F5/NGINX等软件也能完成类似的工作，但在原生性上以及配置的难易程度上Envoy具有更大优势。

现代性的另一个表现就是对协议的支持，看看以下支持的协议，熟悉应用交付、反向代理软件的同学可能会情不自禁的表示赞叹，而这些协议的支持更从另一方面表现了Envoy作为更加面向开发者和SRE的一个特质。

Envoy采用了单进程多线程的设计结构，主线程负责配置更新，进程信号处理等。请求则是由多个worker线程来处理，为了简化与避免处理复杂，一个连接始终由一个线程处理，这样可尽量减少线程间的数据共享而引发的一些锁操作。Envoy尽可能的避免线程之间的状态共享，为此设计了Thread Local Store机制。在日志的写入上，实际上是worker线程写入到内存缓存，最后再由文件刷新线程来负责写入到磁盘，这样可以在一定程度上提高效率。整体上来说，Envoy在设计时候还是比较偏重于简化复杂性，并强调灵活性，因此与NGINX不同它并没有把对性能的追求放在第一位，这一点在Envoy的相关官方博客里可以得到验证。

记得NGINX的作者Igor在F5中国520大会上曾这样对大家介绍NGINX为何如此成功。他说，他没有想到会如此成功，究其原因是他在正确的时间点开发了一个正确的软件。 我们知道，在2003年左右那个时期，还谈不上什么分布式架构、微服务，那时候主要要解决的是单机性能问题，正是基于这样的背景，NGINX无论从架构设计还是代码质量都严格苛求于性能。在功能上，NGINX本来是一款Web Server软件，L7反向代理则是后续的能力，而L4代理能力的增加则更晚，鉴于这样的背景，从现代应用架构角度来看，确实有一些能力是较难覆盖的。同样，Envoy诞生和发展于现代应用架构时代，正如Envoy自我阐述，其参考了大量已有的软硬件反向代理、负载均衡产品，从上面的技术分析中也可以看出Envoy有很多NGINX以及F5架构理念，可以说Envoy从成熟的反向代理产品中吸取了诸多精华，并在设计时候充分考虑现代应用架构的需求，它也是一个在正确的时间的一个正确软件。

微服务架构下，很多问题都变成了如何控制服务之间的通信与流量洞察，这是典型的应用交付领域，作为这个领域的前浪一方面需积极拥抱和适应新时代的应用架构，一方面需要创新并继续引领新的方向。历史上这个领域发生了两次技术革新，第一次是在2006年左右，当时一度关于“负载均衡已死”话题被炒爆，实质是当时市场开始发生变换，大家不再满足于简单的负载均衡，需求衍生到应用安全、网络优化、应用优化、接入控制、流量控制等更多复杂的场景，应用交付概念开始被提出，可以说在2006年前，市场的主要概念和技术方向是以四层交换机为核心理念的负载均衡技术，大部分玩家是传统网络厂商，思维与概念都是以网络交换为基础，而F5就像一个奇怪的家伙，产品设计思想完全在另一个维度之上，自2004年就开始发布的TMOS V9操作系统自此开始引领市场，此后10年，无人超越。第二次技术革新发生在2016年左右，受云、微服务的影响，软件化、轻量化变为市场主流，同时Devops思想意味着使用者角色发生了变化，传统的面向网络运维人员的设计开始变得难以满足市场需求。以F5为主导的这个领域在市场上也发生了新的变化，Gartner不再对应用交付领域发布魔力象限分析，转而形成以Guide方式的指导。

现代应用架构飞速发展，大量应用开始微服务化，但从业务访问的整体链条来看，Enovy还不能解决所有问题，例如应用安全防护，复杂的企业协议，以及不同的组织关系导致的不同需求。可以看到以F5/NGINX为代表的应用交付产品在Devops大潮下也开始积极的实现产品融入，F5发布了完整的自动化工具链，从产品的bootstrap到网络配置、到应用服务配置，到最后的监控遥测都已经形成了完整的接口，并采用声明式接口来将产品管理提升到更高角色人群与管理系统中。NGINX同样构建了自身的API以及Controller平面，对外提供声明式API接口，开发者可以更好的利用接口融入自身的控制平面。这些变化都是为了让开发者或者SRE能够更好的使用F5/NGINX, 详细可以参考我的《从传统ADC迈向Cloud Native ADC》 系列文章 。

F5在收购NGINX与Shape之后，提出了新的view，将充分利用可广泛触达的数据平面能力，借助AI进一步挖掘数据潜能帮助用户更好的掌握和了解应用行为、性能，为业务运营提出参考，并反馈到组件配置与运行管理，从而形成闭环。

现代应用交付依然不能缺少一个重要场景，那就是应用安全，尽管Istio等产品在安全通信，身份，策略方面做了不错的尝试，但是应用安全本身则比较缺乏，F5作为WAF安全领域的领导厂商，通过将安全能力转移到NGINX上形成了新的NGINX APP Protect，利用其跨平台的能力帮助用户更好的管理微服务场景下的应用安全能力，帮助企业更好的落地DevSecOps。

如果将Envoy的那些技术特征与F5进行对比的话，我们可以看到F5一定程度上欠缺在扩展性与现代性上，F5具有较好的编程控制能力，但是相对于更大的插件开发来说是不足的，这和现代性往往可以联系到一起看，比如想针对某个很新的协议做一个类似Envoy的复杂7层filter是无法实现的，尽管iRule或者iRuleLX可以一定程度上做一些事情。然而无论怎样，最终F5的产品形态本身决定了F5的BIGIP是无法完全跨平台的，因为它无法以容器来运行。值得期待的是，这样的形态限制将会被F5 下一代TMOS系统打破。

Service Mesh是当前热门的技术方向，F5 基于Istio打造了企业级的Aspen Mesh服务网格产品，帮助企业更好、更容易的部署和使用Istio。 Aspen mesh团队成员进入仅有7个位置的的Istio Technical Oversight Committee，负责Istio的RFCs/Designs/APIs等方面的重要职责。尽管Istio在service mesh领域拥有绝对的生态与热度，但这并不表示Istio是唯一的选择，在很多时候客户可能希望采用一种更加简洁的Service Mesh去实现大部分所需功能而不是去部署一整套复杂的Istio方案，基于NGINX组件打造的NGINX Service Mesh(NSM)将为用户带来新的选择，一个更加简单易用的Service Mesh产品，这这是我们在文章最开始提到NGINX终止Nginmesh的原因。

技术发展是一个必然的过程，2006年从传统的负载均衡技术演变为应用交付，除了负载均衡之外，引入安全、访问控制、接入控制、流量控制等诸多方面。2016年左右，这个领域再次发生新的技术变革，大量新生代反向代理开源软件的出现对传统应用交付类产品产生了一次新的冲击，积极适应与改变并创新是制胜的关键。Envoy作为新代表有着优秀的能力，但它也不是解决所有问题的银弹，Envoy拥有更陡峭的学习曲线以及更高开发成本与维护成本，对于企业来说应根据实际情况选择合适的解决方案与产品来解决架构中的不同问题，避免追赶潮流而让自己陷入陷阱。

F5则更加需要让开发人员了解TMOS系统所拥有的巨大潜能（特别是下一代产品在架构以及形态上的颠覆），了解其优秀全代理架构以及可以在任意层面进行的编程控制， 让开发者、SRE以F5 TMOS作为一种能力平台和中间件进行开发，更好的利用F5自身已经拥有的应用交付能力来快速实现自身需求。

最后，再次引用Envoy官方网站首页的一句话：

写完文章已是凌晨快四点，扫了眼邮箱，发现F5中国的工程师已经拿到了第30个CKA认证，据我所知第31个也应该很快出现。可以比较负责任的说，无论是绝对数量还是通过CKA的工程师比例，在业界F5中国应该是唯此一家吧。

此文一并发表于 Service Mesher社区 https://deploy-preview-228--servicemesher-preview.netlify.app/blog/thoughts-to-envoy-from-adn-perspective/

最后更新：2020年07月12日 F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator

点击查看本博技术要素列表