在美国西雅图召开的首届EnvoyCon大会上，来自Pinterest、Yelp和Groupon的工程师们展示了他们目前的Envoy Proxy用例。最重要的信息是，Envoy Proxy似乎离实现他们的愿景越来越近了：为现代网络提供“通用[代理]数据层API”，其中包括边缘网关、服务网格和混合网桥。

正文：

在美国西雅图召开的首届EnvoyCon大会上，来自Pinterest、Yelp和Groupon的工程师们展示了他们目前的Envoy Proxy用例。最重要的信息是，Envoy似乎离实现他们的愿景越来越近了：为现代网络提供“通用[代理]数据层API”。大型商业组织正委托Envoy管理各种用例的生产流量，其中包括边缘网关、服务网格和混合网桥。

在过去的一年里，Pinterest工程团队已经把“周边负载均衡器”模型迁移到基于Envoy的边缘代理，其中所有的生产边缘流量现在都通过Envoy。Pinterest的流量站点可靠性工程师（Site Reliability Engineer，简称SRE）Derek Argueta描述了现有基础设施是如何部署到AWS公共云中的，并使用一个第7层AWS经典弹性负载均衡器和一个Varnish缓存来提供入口流量管理。该解决方案遇到的挑战包括ELB扩展问题、TLS终止不够理想和缺乏对动态上游处理（如，在部署新服务或旧实例退出时更新路由）的有效支持。在分析了当前可用的网络代理之后，该团队还发现迁移到Envoy的其他动机，包括扩展API、更有效的可观察性以及与服务网格计划的一致性。

最初的Envoy迁移工作集中于创建新的边缘解决方案，该方案提供了与现有堆栈相同的特性，包括服务A/B部署、机器人检测和CDN请求签名。在迁移过程中遇到了几个小问题，包括Envoy的积极的默认断路、编排跨容器的热启动以防止流量下降，和各种HTTP的问题（与Hyrum的定律有关）。因此，该工程团队投入了大量的研发力量以调试Envoy问题。这是个挑战，原因是边缘工程团队中现有的技能特别侧重于基于硬件的企业负载平衡器解决方案。

对Pinterest用由Envoy支持的边缘新解决方案实施“基于阶段的”A/B部署，Argueta提供了一个全面的概述。为了与现有的部署系统兼容，这是作为“定制解决方案”实施的。在新特性推出的过程中，部署了该服务的多个版本，通过一系列添加到Zookeepe的主机、IP和的阶段数据控制路由。数据通过定制的控制计划传递给边缘Envoys，该控制计划由与端点发现服务（endpoint discovery service，简称EDS）API交互的边车进程组成。

在可观察性方面，创建了一系列图表和控制面板，并进行了迭代，目的是提供“高信噪比”及帮助SRE及其他工程师快速识别问题和相关的潜在原因。对边缘Envoy配置了警报，用于监视高资源使用情况、连接错误和协议错误。未来要做的工作包括提供Thrift支持和Memcached集成、添加MySQL和Apache Kafka过滤器，并把API身份验证移到边缘Envoy。

接下来是由来自Yelp的软件工程师Ben Plotnich和技术负责人John Billings分别就“如何用Envoy（和其他迁移）来DDOS你自己”进行了演示。John Billings一开始就提到应用程序开发人员主要关心的是，快速交付没有错误的代码以解决客户的问题，而新RPC技术的应用或通信超时值的设置等问题却没那么在意。因此，在2014年，Yelp的基础设施工程团队实施了他们所谓的“服务网格第1版”。它从应用程序到基础设施抽象了一些网络通信处理，通过运行中心化的（和人工配置）HAProxy路由层实现。这和来自传统的面向服务体系结构（service-oriented architecture，简称SOA）的企业服务总线（enterprise service bus，简称ESB）模式有点类似。

尽管有用，但需人工重复加载HAProxy（和相关的工程工作）再加上扩展的问题，致使架构团队又实现了“服务网格第2版”，它是基于AirBnb的SmartStack的服务发现解决方案。该解决方案仍然使用HAProxy，但是利用边车进程自动实施了很多常规操作任务。这意味着不需要等待人工操作来实施配置更改，也不再存在人工扩展问题。

尽管这个解决方案成功地运行了4年，但在2018年进行的一项应用程序“开发人员幸福感”问卷调查结果中，揭示了一些有改善潜力的领域。这包括实施动态请求路由的能力和在将其暴露给用户流量（无需运营工程师的时间）之前获得访问生产Canaries的能力。通过对相关的操作风险进行评估，探索了3个潜在的解决方案：因为工程团队已经熟悉HAProxy，可以扩展它提供该功能；转而使用Envoy，可以借鉴Lyft、谷歌和IBM的成功案例；或者切换到Linkerd，这是另一个流行的开源服务网格实现。最终决定使用SmartStack提供的底层架构模式，迁移到Envoy支持的服务网格。

基础设施工程团队实现了“meshd”，这是一个Envoy的简单控制平面，用Python编写而成（因为该团队熟悉Python），并使用平面文件加载配置。应用“增量开发”原则，确定了一个精简的用例，和一个用meshd实现端到端的解决方案以验证该方法。
Plotnick讨论了如何识别提供最大影响(最少入侵)的“切点”，从而引导他们实现供开发团队使用的瘦客户端库。这些瘦客户端提供的功能包括：上下文传播、设置x-envoy-*报头和数据编组。客户端库也是实现功能标识的理想位置，通过在现有的和Envoy支持的新解决方案之间路由的切换来实验。

在Envoy支持的新网格的开发过程中，应用了持续集成和持续交付原则，端到端的自动测试取代了先前解决方案中的人工验证。

在演示的结尾部分提醒道，尽管用像Envoy这样的新技术很有趣，但对工程来讲，主要的关注点应该是解决用户问题，毕竟，这是成立组织和团队的原因。

随后，Groupon的软件工程师Tristan Blease和高级软件工程师Michael Chang做了题为“缩小本地和云之间的差距：一个关于Envoy+混合边界的故事”的演讲。Groupon目前在内部运行其大多数应用程序负载，但是，计划最终运行混合栈，其中包括部署在Kubernetes上的公共云和容器化服务。

目前的栈使用各种技术来处理边缘和内部流量，而计划的迁移创造了新的需求，需要评估这些需求：避免人工配置流程、围绕可观察性提供“更强大的故事”、实现TLS和对服务到服务通信的访问控制。他们的工程团队实验并确定了他们的“理想架构组件”，其中之一是Envoy。

Tristan Blease和Michael Chang提供了对目前和计划的系统架构全面的概述，讨论了把流量从本地迁移到云以及从云迁移到本地的挑战，Envoy实例将部署成边缘代理节点，负责不同环境之间的路由流量。Envoy的配置将主要用NoSQL数据库存储，只需一点点粘合就可以作为控制平面工作，提供主机、路由和端点数据给相关的Envoy管理xDS API。

请从EnvoyCon Sched页面下载有关演讲的幻灯片，另外在CNCF的油管频道上有很多演讲的视频。

原文作者：Daniel Bryant，发布于2018年12月31日

原文链接：The Many Faces of Envoy Proxy: Edge Gateway, Service Mesh, and Hybrid Networking Bridge，https://www.infoq.com/news/2018/12/envoycon-service-mesh

创作场景

Envoy Proxy 的多面性：边缘网关、服务网格和混合网桥