作者：褚杏娟
前言：
云几乎给每项基础设施都带来了冲击，网关也不例外。近期，云原生网关概念也越来越被大家热议。那么，究竟云原生网关需要具备哪些特点？主流网关产品如何适应云原生？网关标准统一是否必要？云原生网关未来如何发展？
此前，Higress 发起人、阿里云微服务引擎负责人李艳林（彦林）受邀与企业用户代表一起聊聊网关的演进历程。
本文根据李艳林（彦林）回答摘取整理而成。
如何应对业务需求？
首先，请针对 UU 跑腿的一个场景来提出自己的解决方案。
UU 跑腿已经是云原生架构了，但作为一家配送平台，UU 跑腿有大量的客户需要通过网关接入平台，同时也有大量的后端服务需要接入网关，因此确保网关的稳定性和可靠性是非常重要的，这样才能保障业务的持续性和客户的满意度。在这样的需求背景下，Higress 会用怎样的方式来帮助企业达成目标呢？
李艳林（彦林）：我了解到 UU 跑腿业务是线上线下结合的。因此，相比于一般的纯线上业务，对于稳定性的要求会更高一些，这是可以理解的。随着整个业务逐渐上云，行业对可靠性的要求会越来越高，特别是网关作为整个公司的入口，如果出现问题就会带来非常大的损失。我们在做 Higress 的过程中也是更加关注稳定性。我想分享一些想法。
首先，我们的架构和内核使用了 Envoy 和 Istio，它们的好处是将数据面和控制面解耦。这意味着，如果控制面出现问题，数据面不会受到影响。这种分离有效地避免了控制面的安全和稳定性问题对数据面的影响。在内核上，我们使用了一种称为 WASM 的沙箱扩展机制。如果扩展逻辑代码出现问题，WASM 沙箱会做很好的隔离，不会影响整个网关的主业务。这种设计可以在一定程度上控制整个系统的爆炸半径。
其次，关于 UU 跑腿和阿里巴巴的 IoT 设备，因为在线上线下结合的过程中，这些设备对稳定性有更高的要求，特别是在多端情况下。如果在一般情况下去更新规则、路由或证书插件，连接可能会发生抖动。但由于 Higress 采用了 Envoy 内核，所有规则变更都是热更新的，因此对长连接都是非常友好的，不会抖动。这将显著提高在线业务的连续性和稳定性。
最后，简单介绍一下 Higress。虽然我们在 2022 年 7 月的云栖大会上开源了它，但在阿里云内部，我们已经孵化云原生网关大概三到四年了。最初，它是为了解决阿里电商和蚂蚁之间的互通问题，让 RPC 可以直接调用并使用 gRPC 协议。经过几年的验证，包括在双十一等大促场景和成千上万家企业的验证，它现在非常稳定。在这些基础上，Higress 主要关注一些推空保护和其他细节方面的功能。
企业需要怎样的网关？
除了刚才提到的，现在企业对网关产品还有哪些要求？现在网关产品已经解决了哪些问题？还有哪些需求未被满足？
李艳林（彦林）：这个话题很有意思，它实际上关乎人们对整个网关未来的定位和趋势判断。从阿里云的角度来看，我们认为客户最关注的是网关的安全问题。事实上，阿里巴巴最初开发网关也是为了解决安全问题，因为我们希望能够通过一个统一的入口来解决安全问题。
以前我在外部也遇到很多客户的应用因为一些问题而被攻击，导致整个风险极大。因此，网关的第一个重要作用就是建立统一的安全防线。Higress 在这方面提供了一些 WAF 插件、认证插件，以及黑白名单机制，可以为企业数字化升级过程中保驾护航。
我认为，无论是国内还是海外，安全都是网关的首要问题。虽然国内许多人关注高可用性，但海外很多人更加注重安全性，它们都在某些公有云上运行，并且非常注重应用安全和基础设施安全。
其次，我想谈谈高可用和稳定性。其实，大家最关心的问题可能是我们的网关稳定性如何、能否帮助我们解决高可用问题。在这方面，Higress 做了一个深度集成，使用阿里云的 Sentinel，在入口提供整体的降级防护能力，以防止业务雪崩。
今年我们搞了很多次大促、海外业务等爆发性增长，当流量达到峰值时，建立防护线以防止异常流量打垮整个系统非常重要。特别是对于像 UU 跑腿这样有高峰值场景的业务，保障业务的整体意义更加重大。
过去两年，我在做海外网关竞品分析时发现，最早的架构可能是 SLB+ECS（单体应用架构），包括云服务都是这样的架构。随着微服务的兴起，人们开始使用 API 网关等工具来管理微服务，并将其集成到服务网格体系中。在 Serverless 时代，每个领域都有独立的入口，并且运营数据是独立统计的。这种架构演进也带来了问题。例如，我们今年做了一个标杆客户，需要挂三层网关，相当于在单体到微服务、再到 Kubernetes 的过程中添加了网关层，导致整个访问链路多层网关，最终影响 RT 和运维效率。
我看到 UU 跑腿之前也在处理协议的转换，将 HTTP 转换为 Dubbo，需要加一个网关，这样代价太大了。因此，Higress 定位是支持多种后端服务负载模式的统一，包括单体微服务、Kubernetes 和整个服务器的负载均衡。我们将后端的能力暴露到北向，进行服务发现，并将整个微服务网关、流量网关和安全网关三合一，以便高效地解决业务问题。这样，用户的业务和运维成本，以及资源成本都会大幅降低。我们发现客户非常认可这种做法。
在网关的标准方面，我最近在研究时发现，有三个标准，分别是协议标准（HTTP 加 RESTFUL），文档标准（Swagger），以及路由标准（Kubernetes Ingress / Gateway API）。Kubernetes 推出了路由标准，并通过 Higress 逐渐将路由标准统一起来，这是非常好的事情。
此外，开源社区正在推动 Gateway API 的完善，这将进一步统一路由标准。我们希望通过开源标准的建立来推进整个产业的发展。类似于 Linux 标准、MySQL 标准等，网关标准的建立对于未来云计算的发展是至关重要的。未来，我们相信这些需求，包括 API 管理的更多能力，能够更好地跨越云、混合云和多云。这是我思考的一些问题，希望对大家有帮助。
你眼中的云原生网关
对于未来 1 年在云原生网关的规划是什么样的？
李艳林（彦林）：我们一直参与阿里容器化的架构演进。这个过程中，我们发现云原生网关应该具备四个特点：标准化、高集成、热更新和易扩展。为什么呢？
首先，我们期望代码可以跨云、混合云、私有云和公有云运行，而不受厂商的限制。比如，采用某个厂商的实现时，如果需要切换到另一个厂商，不会因为厂商差异而出现问题。因此，标准化非常重要，它解除了厂商的绑定。Ingress 标准、Gateway API 标准和容器标准等构成了云原生的基础。
在此基础之上，我们强调云原生网关应该具备高集成特点。作为一家以公有云为主的厂商，我们的思路与专有云为主的厂商有所不同。我们提到高集成，是因为我们发现在传统架构中，通常有三层：前端安全网关 WAF、中间流量网关 Nginx 、后端微服务网关 Spring Cloud Gateway。例如，我曾遇到一位客户在面对超时问题时需要拉三拨人去查，判断到底是 WAF 超时，还是 Nginx 或 SpringCloud Gateway 超时，这样的部署资源成本很高，而且排查链路效率非常低。
我们认为“合久必分，久必合”。为什么有这个想法？因为我们是从第一性原理出发，阿里内部并没有那么多网关，为什么今天会有三个？其实是为了简化架构，更好地拆分模块和职能，但实际上这不符合用户的利益。用户的实际利益在于成本，包括运维成本和部署成本。因此，我们认为大部分客户可能都需要高集成，包括像阿里、快手、抖音和腾讯等头部厂商。这些大厂也需要拆分，拆分逻辑包括四层和七层，上层使用 SRB，下层可能使用原生网关，上层承担流量，下层负责路由转发。但对于大部分中小客户，一层就足够了。例如，我们的客户已经有数百万连接和几百万 TPS 的数据，但只需要一层就足以应对。这显然降低了整个运维和部署成本。
第三个是热更新。实际上，我们认为 Kubernetes 带来的一个核心变化是业务频繁调度。如果调度频繁，后端发布和规则变更需要快速联动，尤其是在存在长连接和 IOT 设备的情况下，连接的抖动是不可接受的。因此，热更新在确保连接稳定性方面非常必要。随着基础设施和使用场景的不断变化，包括线上线下结合、IoT 设备等，热更新的重要性会越来越突出。
第四个，易扩展性也是重要的一点。我们发现许多客户在网关上都进行了定制，主要包括安全和路由方面的定制，甚至包括存储方面的定制，这是因为不同公司在安全定制方面的策略不同。因此，易扩展性非常重要。我们采用了多语言热更新等机制，使得我们的网关可以更好地支持定制需求。
因此，我们认为在未来，这四个能力：易用性、高集成、热更新和易扩展性，将是云原生网关必备的。
在今天的云原生网关定位和发展过程中，我们围绕着四个关键点展开，以差异化能力为目标。大家都知道，像 APISIX 和 NGINX 这样的巨头拥有非常强的护城河，所以我们需要构建差异化能力，围绕着这四个关键点进行。目前，我们已经完成了整个云原生网关的布局，接下来会在易用性和 Gateway API 的标准化上继续探索。
我发现云原生网关与 API 网关的区别在于云原生网关多了一个 API 的层次。这是非常重要的，因为有了 API，我们可以利用其自动化测试、调用和安全审计的能力，这对于未来结合人工智能非常重要。我们意识到，如果只做底层的原生网关和基本的路由能力，就无法获取服务和 API 的元数据，这将限制我们在增加更多功能时的扩展能力。因此，我们最近在内部探索一种可能的演进方向。
我们已经完成了阿里巴巴的 Nacos 和 Dubbo 生态的整合，包括在灰度发布方面集成了 Kubernetes OpenKruise，这为我们打造更多的生态扩展奠定了基础。尽管我们目前的插件相对于 NGINX 或 APISIX 来说较少，但我们采用的是整个服务网格的架构，可以复用一套扩展机制来快速构建统一控制东西南北流量的能力。
我们正在不断积累这些能力。我们相信通过插件市场，可以一起扩展整个上下游，包括 API 管理和安全等能力，这样就能为客户提供一站式的网关解决方案，而不需要过多地研究其他技术。
云原生网关演化思路
产品提供方都是如何进行自己的产品演化的？社区推动与企业推动，哪个更重要？
李艳林（彦林）：这个话题很有趣。我之前看到一篇文章，讲的是《开源与商业的关系》。我认为，今天的开源与商业关系正处在一个非常重要的阶段，就像中国的软件市场一样。例如，你的手机里有多少款软件是付费的呢？这反映了中国人民对软件付费的态度。如果没有人为软件付费，软件的持续发展就会受到威胁。因此，开源与商业之间的关系非常重要，就像如今社区与企业之间的关系一样。
有点像之前的 360 互联网模式，其中大部分人免费使用，只有 1% 的人付费。这种模式可以使开源与商业相互促进，从而实现持续的发展。如果没有这个正循环，一些项目就很难维持下去，例如早期的 Dubbo 以及现在的 Spring Cloud Netflix，每公司都有自己的 KPI，如果项目没有持续发展，就会面临失败的风险。今天我们能够在这里交流，说明我们背后有一个力量在支持着我们。但是如果没有这个力量，这些事情就会变得更加困难。
我们需要不断地加强社区投入，促进生态建设。我们都知道，在数字化时代、云时代，开源就是标准。我们通过开源软件构建了整个开源标准，然后借助众人的力量推动它的使用场景和通用性，然后达到最佳状态，这样我们才能把整个领域做大、扩大这个蓄水池。这其实是一种互联网经营模式，当这个蓄水池足够大之后，我们才能继续生存下去。只有这样，我们才能更好地回馈社区。
不过，如今开源的诉求与商业的要求还是有所区别：开源更关注易用性、生态；商业版本则更关心产品的稳定性、安全性、高可用性和兜底服务能力。
阿里巴巴是开源、商业和内部三位一体。我们通过开源软件打磨产品的易用性和生态、和扩展性，而商业上更关注企业级特性，如稳定性和安全性，我们在阿里内部的场景打磨高可用性和高性能。这几个方面是相辅相成的，大家都明白开源到商业、社区到企业的闭环非常重要，这也是我们能够生存下去的关键。
云原生网关可以在企业数字化升级中发挥什么样的作用？
李艳林（彦林）：大家对数字化的理解大概是这样的：首先有一个网站，其次有一个大盘。不知道大家是否看过在朋友圈中转发的“灵隐寺的大盘”，一般来说，传统公司对数字化的需求可能就是有一个网站和一个大盘；对于已经进行了数字化升级的公司来说，它们需要从传统架构过渡到云原生架构。
第一类用户需要快速构建企业级、高可用、安全的入口，我们可以帮助他们实现这个目标。第二类客户，也是我们目前关注的重点客户，因为他们通常是传统架构，希望升级到微服务和云原生架构。最简单的方法是在前面加一个网关。有了网关，传统的应用可以继续使用传统的负载方式，而微服务可以使用微服务负载方式，这样就能快速进入云原生时代。
那么，如何实现新老系统之间的互联互通呢？云原生网关充当了统一的控制中心，可以控制流量和管理新旧系统之间的互动。举个例子，可以实现上云和下云之间的互通，不同业务域之间的跨域互通，通过网关来快速解决新老系统之间的连接和升级。这样一来，新的 IDC 和老的 IDC 之间可以快速连接和升级，从而加快整个数字化升级和创新的速度。
因为大家都知道，当一个 IT 系统变得越来越复杂时，采用微服务架构可以释放出更大的研发效率红利，尤其在海外更为明显。这也是为什么海外要推崇 Serverless 架构，从微服务走向 Serverless，因为人力成本是最高的，所以要尽可能降低运维和开发成本。所以，对我们来说，这意味着我们可以加快企业的创新速度。
另外一个我最近研究的课题是关于上云和数字化过程的。实际上，它可以分为两个部分：业务数字化和业务智能化。在第一个阶段，我们的云原生网关可以帮助用户快速将单体应用、微服务应用以及整个 Kubernetes 等多种负载快速地将后端服务能力输送到客户端，这是我们的第一个价值所在。
第二个价值在于如何快速将后端的数据能力和 AI 能力输送到客户端。这个问题也非常重要，包括之前提到的 GraphQL 等。在研究中，我发现通过低代码和快速的方式将后端的数据能力快速输出到客户端非常有意义。从业务智能化的升级过程来看，我们的网关可以快速将后端的 AI 能力输送到手机端，这样就可以帮助企业快速将后端能力输出到客户端和生态系统。
提到 API 领域，通过服务的货币化将调用、生态全部整合起来，也具有很大的意义。在海外，这种做法已经得到了很好的发展，而我相信国内未来也会成为趋势。为什么这样判断？因为国外的人力成本较高，所以他们更倾向于使用别人的服务而不是自己开发，而国内则相对较少。但随着中国数字化水平的提升，程序员的工资持续上涨，API 化仍然是未来的趋势，这是第二个可能性，即我们能够帮助企业快速将后端能力输出到客户端。
第三个价值在于网关本身。云原生网关在入口处建立安全和高可用的防线非常重要，因为近年来行业内出现了数据泄漏和稳定性问题，网关作为一个关键位置具有致命的意义。
网关会被取代吗？
当前的网关行业处于什么阶段？为什么？对于想要进入这个市场的开发者来说还有哪些机会？
李艳林(彦林)：我的判断是这样的，现在正是传统网关向云原生网关迅速发展的爆发期。首先，我们可以看到容器已经成为基础设施的主要架构，而 Kubernetes 通过网关构建了一个标准，这实际上是行业发展的基础。第二点是，从 CNCF 报告和整个行业动态来看，云原生网关和 API 网关在过去三年里增长了一倍以上，每年都在持续增加，增长速度非常快。我最近做分享时仔细数了一下，在 CNCF 里大约有二三十个项目涉及这个领域。
在这个领域有这么多的参与者，说明这是一个机会，吸引了许多人涉足。在这个领域中，我进行了一些分析。大约有 40%的项目是基于 NGINX 内核构建的，而 35% 的项目是基于 Envoy 内核构建的。可以说，Envoy 与 NGINX 占据了 75% 的网关实现市场份额，这确实是两个主要的主流力量。
统一标准，重要吗？
当前，网关行业的发展面临着哪些问题？如何保证网关生态的长期健康发展？
李艳林（彦林）：从整个行业的角度来看，现在的标准正在逐渐建立，但还没有完全稳定下来。目前实践方面相对来说已经比较集中，大约占了 75% 的份额，但还有 35% 是比较分散的长尾部分。我们希望行业标准能够统一，让大家都能达成共识。
比如，MySQL、PostgreSQL、Oracle 等数据库在市场上占有较大份额，加上其他一些常见的网关产品，可能占据了 90% 左右的市场份额，这种收敛的趋势对整个产业会有积极的影响。我们需要共同推动这些标准的发展，加快标准的形成。
未来，我认为网关在安全和 Serverless 领域都有巨大的挑战和机遇。首先，对于开发者而言，他们在软件开发过程中首先关注的是研发效率，其次是扩展性，然后是稳定性，最后才是安全性。但实际上，随着数字资产的增大，我们会发现各种攻击和防御正在不断增加。这些安全威胁的加大将带来巨大的变数和机遇。例如，能否利用人工智能自动进行攻击和防御，这都是攻防之间的问题。谁能够利用人工智能和算力快速构建防护壁垒？包括阿里云自身在内也在进行相关探索。
其次，将网关发展到极致，实现服务化也是一个有趣的方向。当前的四层网关和云厂商的第二层网关基本上都是基于特定内核构建的。而对于我们的七层网关来说，原生网关应该具备流量付费和弹性调整能力，以适应资源需求的变化。将网关无服务化将会是一个有意义的发展方向。我们一直在对网络进行抽象，从四层到七层再到网关实质上是网络一层层向上抽象，对开发者越来越易用。未来，能否实现网关的无服务化和极致弹性是一个重要的挑战。
目前看来，网关行业处于一个非常有前景的阶段，市场需求强劲，各家企业都在争相进入，并通过共同努力来推动行业的发展。
云原生网关的未来
最后，请总结下未来云原生网关的发展趋势？
李艳林（彦林）：这块我可以给大家一些建议。首先，未来云原生网关的发展趋势应该朝着标准化、高集成、易扩展和热更新的方向不断加强。我们推测，Ingress 和 Gateway API 可能会成为 API 路由的标准，这个标准可能不会受个人主观意愿的影响。
第二个趋势是，对于一些小中型客户来说，Higress 对于一些简单的 4 层路由和 7 层简单路由可能足够了，但对于一些中大型客户来说，他们可能对于复杂的 API 管理和路由有更多需求，未来可能会朝这个方向发展。我注意到在群里也有人提问，当 API 变得复杂并且规模扩大时，如何进行 API 管理和治理，我们可以在以后讨论这个问题。
第三个趋势是统一东西南北流量。我们采用 Envoy 内核，可以看到东西南北流量的统一加速趋势。无论是从北向进来的流量，还是跨安全域、跨业务域、跨区域的东西向流量，包括 sidecar 之间的流量，因为采用 Envoy 内核，我们在统一东西南北流量方面具有一些优势。当然，我也看到一些尝试将 NGINX 用作 sidecar 内核的设计，包括 APISIX 也在进行这方面的尝试。我认为大家的思路都很好，核心本质是大家都认为统一东西南北流量控制是一个重要的方向。
第四个趋势可能是关于 AI 领域的探索，AI 的入口到底是谁？包括在阿里内部以及与其他合作伙伴进行的一些尝试。未来的 AI 能力和大模型能力都是基于容器作为基础设施进行输出的，对于连接的稳定性、高可用性以及流量防护也有较高的要求。所以，我相信在未来的 AI 探索领域中，探索 AI 的入口将是值得的。
最后，根据 CNCF 的数据，我认为以 NGINX、Envoy 为内核可能是未来原生网关的关键实现。我也相信 Higress 在未来一年会有爆发性增长，加速推动原生网关的认知建立，这只是我大致的判断。
