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

在美国西雅图召开的首届 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