谷歌、IBM、微软等跨国巨头已经相当深入地使用了 Envoy。 这种信任并非来自于“云原生”、“下一代”等简单的噱头概念，而是可以从其TPS表现中获得。 更直观的印象。 早在2020年，网易书凡云计算技术专家裴飞在接受InfoQ采访时给出了一组直观的对比数据：8核部署的EnvoyTPS可以达到12W左右，这是基于Java的异步API相同的环境。 大约是网关的4.2倍，基于Nginx的Kong的2.4倍，APISIX的1.3倍。 同时，Envoy 与 Istio 的深度融合以及开源的成熟也为其锦上添花。
阻碍 Envoy 在中国广泛使用的主要问题是 Envoy 的架构复杂。 Envoy 最初设计时并没有考虑易用性。 而且Envoy是使用C++开发的，这让国内基于Java的技术团队望而却步。 但语言和所谓架构的复杂性真的会对各个技术团队的实施造成障碍吗？ 从网易的做法来看，情况可能并非如此。
带着Envoy选型考虑、实现、可扩展性改进等各种问题，InfoQ再次采访了裴飞。 他是网易大规模落地Envoy的见证者。 相信他可以帮助正在准备或者考虑升级API网关的你。 带来收获。
网易的选型考虑
InfoQ：我们知道网易早在 2017 年就开始考虑基于 Istio 和 Envoy 实现一个 Service Mesh 平台和 API 网关。它是基于什么背景，或者说想要解决什么样的问题，所以你开始探索这些两个方向？
裴飞：总体背景是网易集团内部业务微服务基础设施的升级和统一。 服务网格是微服务框架的升级。 在此之前，网易拥有SpringCloud、Dubbo、自研RPC等多个微服务框架。 技术栈不同导致研发和维护成本较高； API网关供内部使用。 Zuul、Kong以及自研网关都有很多升级。 旧的网关在性能、可扩展性、容器兼容性等方面都或多或少存在不足。
因此，我们正在探索一种能力全面、性能优良、代表未来技术发展趋势的技术方案。 可以统一开发和维护网易集团内部复杂的微服务技术栈，从基础设施层面推动业务架构逐步升级和演进。 主要出发点。
InfoQ：在云原生时代，您对网关的需求与过去相比有什么根本的区别吗？
裴飞：云原生时代，我们对网关的要求更加全面、严格。 简而言之，它们是“既需要又需要”——满足云原生环境（托管容器环境的入口和出口流量）的新需求，必须覆盖新旧应用的多样化流量管理功能需求，确保一致的高性能和稳定性，并能够作为面向未来的统一网关来管理所有网络七层流量。 Envoy是云原生背景下全新设计的产品。 与 HAProxy、Nginx 等传统网关代理软件相比，Envoy 原生具有更丰富的功能、可观察性、动态配置和可扩展性，并且不需要专门的扩展编程。 能够满足大多数流量管理场景下网关的功能和性能稳定性要求。
我们最初对 Envoy 的关注来自于对下一代微服务架构——服务网格的选择。 当时，Istio 是一个具有“巨星形象”的服务网格框架。 在研究和实施 Istio 的过程中，我们发现了 Envoy 成为“下一代网关”的许多特性。 经过几个月的技术可行性验证和商业实践，我们决定选择 Envoy 来构建下一代网关。
InfoQ：您能分享一下详细的技术选择过程以及做了哪些比较吗？
裴飞：一般来说，应用网关倾向于选择Java异步转发的网关和Nginx为核心的网关。
Java异步网关的典型代表是Zuul2。 易于扩展和维护，适合以Java为核心语言栈的团队。 缺点是Java语言本身在异步效率、内存回收等性能方面难以与传统代理软件竞争，在大规模流量场景下存在明显的性能瓶颈。 。
对于以Nginx为核心的网关来说，当时比较成熟的选择是Kong。 当时网易内部很多核心产品线都在使用Kong作为API网关。 运行比较稳定，性能比Java异步网关好很多。 当时业务面临着大规模的云原生、容器化、Service Mesh 架构升级。 Kong作为一个相对传统的API网关，直接在容器化环境中用作网关需要做很多额外的工作，包括基于ETCD注册中心的Kubernetes实现。 管理和稳定运行给生产业务的架构升级带来了大量额外的开发和维护负担。
Envoy 作为服务网格 Istio 框架中 sidecar 和 gateway 的实现而存在。 网关实现可以原生用作容器化和服务网格环境的入口流量代理和治理，但目前还没有系统的API网关。 能力封装。 当时国内几乎没有围绕Envoy的企业级实践，而国外的一些开源项目（如Gloo和Ambassador）已经完成了初步探索。 我们为此进行了专门的技术可行性研究，并在几个月内完成了基于 Envoy 的 API 网关第一版的总体设计、主要功能开发和封装。 第一个版本的发布可以满足网易云内部对API网关的功能需求。 ，在性能上，也远远优于Java异步网关和以Nginx为核心的网关。 至此，网易特使API网关开始起航。
InfoQ：事实上，直到今天，国内基于 Envoy 构建 API 网关的公司还很少。 您认为造成这种情况的原因有哪些？
裴飞：主要是领域认知和技术栈熟悉程度。
在领域感知方面，虽然 Envoy 最先在国外作为网关代理应用于生产环境（Google、Lyft），但国内早期对 Envoy 的认识只是作为服务网格 Istio 的数据面组件，这导致企业熟悉并研究过服务网格的人可以轻松采用 Envoy 并将其用作下一代网关； 相反，不熟悉 Service Mesh 或 Envoy 的企业会认为 Envoy 只有云原生、Service Mesh 等特定功能。 场景能力（其实根本没有）。
从对技术栈的熟悉程度来看，Envoy的主体是基于C++开发的。 国内企业比较熟悉的是Java、Go语言和Nginx。 在选择上，他们也会从更多控制和“折腾”的角度出发，这一点很容易被忽视。 未来选择的正确性和长期性。 我了解到很多国内大公司的团队和开发人员因为C++语言本身与他们团队或个人的技术不匹配而被解雇。
我们在选择 Envoy 的前期确实有这样的顾虑，最终在上手的难度和选择的正确性和长期稳定性之间选择了后者。 事实上，根据我们的实际开发经验，在突破了早期的语言和原理认知瓶颈后，Envoy 并没有想象中的那么“可怕”。 我们团队中的 Envoy 开发者都是非常年轻的同学。
InfoQ：根据您的经验，什么样的公司或业务场景适合使用 Envoy 作为 API 网关？
裴飞：Envoy是一个面向未来的网关选择。 我认为，如果业务满足以下条件，可以采用Envoy作为API网关选择：
现有API网关在性能、稳定性、可扩展性、可观测性等方面存在痛点，希望升级网关基础设施；
希望管理未来多样化的业务流量场景，包括容器化、服务网格等；
计划将现有的Nginx、微服务API网关、负载均衡器、KubernetesIngress、Serverless功能路由等网络七层流量代理设施合二为一，简化链路和组件。
迁移转型实施实践
InfoQ：在将旧网关迁移到新网关之前，开发者需要做哪些准备？
裴飞：最重要的准备工作是梳理。
例如按service、interface、Path等，后面需要根据基础信息配置相同的路由信息2d游戏素材，完成基本的网关配置准备工作；
如果涉及专门的呼叫场景，需要将专门的用途尽可能详细、完整地梳理出来，以确定新的网关是否能够适应专门的用途；
部分功能新网关无法满足，可能需要通过插件扩展来满足需求。
我们的Envoy网关提供了开源的企业级Lua扩展框架——Rider，可以方便地支持用户用Lua语言扩展网关的数据面能力。
InfoQ：实施基于 Envoy 的新网关后，与旧方案相比，业务方获得了哪些好处？
裴飞：对业务方最大的好处是网关基础设施得到了长期的架构和能力保障。 新的网关解决方案原生兼容容器、服务网格、Serverless，还可以接管之前Nginx和传统API网关代理的流量，真正帮助企业实现网关基础设施的平滑演进和迁移。 此外，Envoy自身的架构也给业务带来了很多好处，比如高转发性能、低延迟、完整的监控、轻松的动态控制，提供更好的云原生基础设施体验。
InfoQ：据了解，到2020年，网易将有不止一项核心业务在EnvoyGateway上实现。 目前业务实施最新情况如何？
裴飞：网易的大部分互联网业务都在EnvoyGateway上实现。 作为应用集群的入口网络基础设施，少数因历史原因无法完全迁移的业务也在一些新的场景中得到了落地。
InfoQ：根据您的经验，实施 EnvoyGateway 的主要陷阱或困难是什么？ 你是怎么解决的？
裴飞：在我们实施EnvoyGateway的早期，我们在可扩展性方面遇到了一个重大陷阱。 Native Envoy 提供了 Lua 插件机制，但从 API 库的丰富程度和插件性能来看，距离实现到生产环境还有很长的路要走。 让业务自己开发Envoy，或者所有的扩展都由我们来完成显然是不现实的，所以就有了开发Envoy扩展插件机制的计划。 我们借鉴了OpenResty和Kong在Lua扩展方面的优秀设计，快速完成了EnvoyLua扩展插件框架——Rider。 目前，该项目已经开源。 有兴趣的读者可以参阅文章了解详情。
InfoQ：您能以一个业务场景（如网易严选）为例，介绍一下API网关的完整演进过程吗？
网易严选杨文超（原文链接）：
整体演进过程如下图所示，主要可分为5大节点：
整体进化
API网关1.0部署架构
在API网关1.0阶段，精心挑选的团队初步实现了：
统一精心挑选的API访问入口，90%以上的流量运行在精心挑选的Ianus网关上。
统一流量管理，实现与控制平面微服务的统一。
提供标准的容灾能力，如频控、降级、静态化等，使服务可以复用。
充分利用LUA的插件能力，满足个性化的业务需求。
期间对线上问题进行了实时汇总和归档，例如Nginx配置和使用问题、Kong版本跟踪问题、PostgreSQL优化等。在实际实施过程中，严选团队并不仅仅局限于网关，而是专注于关于燕选微服务系统的构建。
随着ServiceMesh从1.0向2.0的演进，过渡期间将出现两种类型的ServiceMesh：ServiceMesh1.0（精选VM）和ServiceMesh2.0（青州Kubernetes）。 自然，两个ServiceMesh之间就会存在流量分配问题。 这里，“云外”代表ServiceMesh1.0，“云内”代表ServiceMesh2.0。
针对跨ServiceMesh接入的问题，严选团队在每个ServiceMesh上部署了自建的边缘网关（EdgeGateway），与数据中心基础设施集成。 云内推动青州替换了原有Istio服务网格中的Ingress/Egress，并与青州特使网关（以下API网关2.0）统一。 云外部署采用精心挑选的Ianus网关，云内部署采用Envoy。
同时存在跨环境访问，SA需要打开两个IP之间的防火墙。 一方面，应用服务器IPtable每次都需要专门配置； 另一方面，所有相互访问的配置都分散到各个应用服务器上，无法进行集中管理和控制。 这里，跨数据中心的访问流量统一发送到边缘网关，并在网关上进行相应的认证（基于插件实现）。
跨ServiceMesh可以认为是东西向流量，而跨环境可以认为是南北向流量。 最终支持各大环境之间的相互访问开发学习，统一业务接入方式，消除环境差异，实现流量的集中管控，方便统一运维。
在API网关2.0阶段，在上云之初，严选API网关团队也对Kong、Traefik、Ambassador、Gloo、IstioGateway等的特性进行了调研和比较，以构建云原生API为目标网关。
经过综合考虑游戏充值网关开发，决定将云内门户建设任务交给网易舒凡-青州门户团队。 严选将根据API网关的需求和当前项目建设计划提供设计和建议。 对于数据平面，我们考虑了现有青舟微服务系统与主流产品实现的无缝融合，选择了Envoy来进行数据平面的建设； 对于控制平面，我们考虑了复用现有管理平台功能的需要。 ，将基于现有的Istio系统进行共建。
API网关2.0分为控制平面和数据平面两部分。 数据面由双方共同设计，由青州负责实施； 控制平面由严选与青州联合打造，并统一纳入严选API网关管理平台。 具体的数据面集群规划遵循精心挑选的Ianus网关的部署方式，这里不再赘述。
关于数据面、控制面、插件能力的构建以及更详细的架构设计和演进内容游戏充值网关开发，可以参考原文《网易严选网关架构演进之路》以及InfoQ之前的另一篇文章《流量在云端》 《原生时代》入口：使者网关》。
InfoQ：从网易书饭的实践来看，如果可以总结一下最重要的三个经验，它们会是什么？ 对于想要探索基于 Envoy 构建 API 网关的技术团队，您有什么建议？
裴飞：
战略上鄙视（新技术难度），战术上重视（适配和增强）。 无论是从最初的可行性研究向前推演，还是从当前大规模生产应用的结果向后推演，选择 Envoy 作为下一代网关都是一次看似冒险，实则顺利的实践。 不要因为在早期选择阶段就被 Envoy 的架构和 C++ 语言吓倒而错过了很多后期的好处。 另外，在不断的实践和探索中，需要结合API网关的传统能力和实际业务场景进行精心设计并逐步适配和增强，以保证最终技术的严谨性。
正面统一设计。 早期我们构建EnvoyGateway的目的是升级和替换旧的网关能力。 在实践中，我们发现EnvoyGateway的强大之处不仅如此——我们还成功实现了基于Envoy的七层负载均衡器（替代Nginx），并且还支持Serverless Gateway场景，可以作为KubernetesIngress。 基于Envoy实现统一的七层网络流量网关在技术上是可行的，并且前期可以考虑统一的软件设计。 这项工作也是我们今年工作的一大重点。
关注配置推送性能。 Envoy 从设计初期就基于 xDS 协议实现了服务发现和配置交付。 这种设计可以更方便地实现动态配置。 配置推送需要更高效稳定的策略，避免配置推送过多、频繁，影响Envoy的动态性能。
对于想要探索基于 Envoy 构建 API 网关的技术团队，有两个建议：
了解 Envoy 和 Istio 的核心原理。 Envoy和Istio技术具有明显的云原生设计印记，在设计理念上与传统开发框架有很大不同。 大家可以先结合官方文档和网上分享的文章来了解Envoy和Istio的交互控制原理，以及EnvoyxDS协议。 IstioVirtualService/DestinationRuleCRD等核心机制将为后期API网关的建设提供很多帮助。
寻找现有的开源项目来理解和实践。 实践是检验真理的唯一标准。 这里推荐结合我们的开源云原生网关项目Hango作为参考。 项目提供了比较简单的架构和简单易用的页面控制台，方便国内技术同学理解和上手。 项目地址：
二次开发及技术前景
InfoQ：网易数饭开源了 Hango，一个基于 Envoy 的云原生 API 网关。 它和Envoy有什么区别？ 您基于 Envoy 做过哪些二次开发工作？
裴飞：准确来说，Envoy 是云原生 API 网关的数据平面选择。 一个完整的API网关平台一般会包括数据平面（核心）、控制平面、管理平面等。与Envoy相比，Hango项目主要有以下增强：
上层封装； 为Envoy提供上层控制平面和管理平面，可以方便对Envoy进行配置、管理和监控；
插件扩展； 为Envoy构建了企业级Lua扩展插件机制，弥补目前插件扩展Envoy无法在生产中实现的缺点；
协议扩展； 以Dubbo、gRPC、WebService、WebSocket等协议为业务服务提供协议转换和治理能力；
兼容适配：针对生产业务中的“非标准”使用进行一些兼容适配工作。
InfoQ：您为什么不考虑将这些工作直接贡献给 Envoy 社区，而是开源一个新项目？
裴飞：事实上，我们对 Envoy 的大部分增强都贡献给了社区，我们贡献了超过 10000 行代码。 我们团队的王柏平同学也因为这些贡献而晋升为 EnvoyMaintainer。 开源的 Hango 项目也是基于 Envoy 的。 完整、成熟的API网关项目很少。 几乎没有好的开源项目可以为想要基于 Envoy 构建 API 网关的技术团队提供指导。 Hango项目中的建设内容更多的是围绕Envoy构建API网关所需要的其他能力，比如插件扩展机制Rider、网关管理控制台等。
InfoQ：现在官方有了EnvoyGateway这个新的开源项目，会不会影响Hango未来的发展？ 接下来，您如何看待Hango的发展规划以及Hango与Envoy和EnvoyGateway两个项目的关系？
裴飞：EnvoyGateway官方刚刚上线，这方面整体进展还不是很大。 我们也比较早期参与了社区EnvoyGateway的前期工作。 在建设思路上，EnvoyGateway也正在尝试整合现有的Emissary、Contour等项目，形成统一的云原生网关标准，进而实施真正意义上的建设。 一方面，Hango将继续通过版本发布网易特使API网关中一些常用且易用的能力； 另一方面，也将积极参与社区EnvoyGateway的建设，努力真正建立云原生网关标准，帮助企业下一代网关选型。
InfoQ：目前，团队希望在 Envoy 中添加或优化哪些功能？
裴飞：首先是协议的多样性和可扩展性。
Envoy 社区提供的最完整、最稳定的协议是 HTTP 和 gRPC，这与 Envoy 运行的国外互联网技术环境有关。 在我们的实践中，国内有很多企业或者客户使用国内比较流行的协议（比如Dubbo），也有开发自研RPC协议的案例。 基于任何代理软件来实现完整的代理、治理、观察等能力都将花费大量成本。 因此，如果社区原生支持更多样化的协议或者提供更便捷的协议扩展能力，将有效消除这些服务的使用障碍。 我们团队也在朝这个方向探索，努力为社区贡献自己的沉淀能力。
然后是WebAssembly（WASM）插件性能。 WASM 技术为前端、边缘计算、物联网等多个领域带来了商业效益，Envoy 的下一代插件扩展能力就是基于 WASM 的。 可以使用多种语言扩展和开发代理软件，极大地方便了与熟悉的语言栈的业务集成。 自己扩展 Envoy。 然而，目前 Envoy 和 WASM 的结合仍然存在一些性能问题。 开发的插件很难满足生产级的性能要求。 Envoy 社区和 WebAssembly 社区之间仍然需要更好的集成。 正因为如此，我们在 EnvoyWASM 真正成熟之前就构建了企业级 Lua 扩展插件 Rider，让业务在多语言扩展插件银弹之前具备了实现生产级扩展插件的能力已启动，推出。
InfoQ：围绕 EnvoyGateway，您还做了哪些工作以及未来计划做什么？
裴飞：
作为通用云原生网关，可以管理所有七层网络流量。 基于EnvoyGateway，我们实现了微服务API网关、负载均衡器LB（替代Nginx）、Serverless功能网关、KubernetesIngress、KubernetesGatewayAPI等不同场景。下一步，我们计划将这些场景形式统一为一个网关（实例）。 ，业务不需要针对不同场景部署不同的网关（实例）。 一组网关（实例）即可实现业务所有七层网络流量的代理和管理。
在Hango项目的推广方面，我们下一步将与领先的金融公司合作，开源V1.0版本，带来更多适合生产的网关功能和金融场景功能。
InfoQ：业界有没有同样可以满足云原生网关需求的开源项目或产品？ 您认为未来Envoy有可能成为云原生时代统一的API网关标准吗？ 为什么？
裴飞：目前能够真正满足云原生网关需求的项目或者产品还很少。 Envoy 最大的优势来自于其先进的设计和背书。 Envoy 是一个年轻的项目。 由于它年轻，并没有像HAProxy或Nginx那样有很多“老粉丝”，目前的关注度和应用量还比较低。 但正是因为年轻，Envoy 的设计更新、更具前瞻性，充分考虑传统场景和云原生场景的需求，能够更好地发挥“继往开来”的作用。 此外，还有谷歌、IBM、微软等行业巨头。 背书，Envoy 有潜力成为云原生时代统一的 API 网关标准。
查看专题《Envoy 掌权了吗？云原生时代的下一代网关选型与实践》，阅读更多关于 Envoy Gateway 的实用文章！
