开源云原生融合网关 Hango 的最新实践与思考

网关，作为互联网流量入口，同时承载着业务安全的期待，在数字时代又被融入云原生能力。对于现代化分布式架构来说，网关所扮演的角色越来越重要。网易数帆在覆盖互联网、银行、证券、保险、能源、制造等行业的云原生网关实践过程中，发现企业对网关的要求日益全面、严苛—— 既要满足云原生环境的新需求（纳管容器环境出入口流量），又要覆盖新老应用多样的服务纳管功能需求，还要保证始终如一的高性能与稳定性，也要能够作为面向未来的统一网关纳管主流的七层应用流量。

鉴于此，网易数帆提出了“融合网关”的概念，并相信这是下一代网关产品的标准形态。本文将解读融合网关诞生的背景与价值，探讨融合网关的设计与实现，并分享基于开源 Hango 的融合网关实践进展和未来规划。

企业为什么需要融合网关

2018 年网易数帆推出轻舟微服务治理平台时，最早采用的是基于 Java 开发的 API 网关 1.0。随着微服务平台在网易内外部多个项目的生产落地，我们逐渐意识到 API 网关 1.0 在性能、可扩展性和可观测性等方面无法满足用户未来的需求。在数据面代理组件选择上，最终聚焦到成熟的 Nginx 和新生代的 Envoy 上，最终我们选择了基于 Envoy 来构建新一代的 API 网关 2.0，Hango 网关由此诞生了。

Hango（github.com/hango-io/hango-gateway）是网易数帆基于 Envoy 和 Istio 构建的项目，于 2021 年 8 月作为高性能的云原生 API 网关开源，当前已演进为云原生融合网关平台，遵循 K8s Ingress/Gateway API 等接口标准，兼容云原生应用和传统应用，融合 API 网关、微服务网关、七层负载均衡和四层代理等多种形态为一体，帮助企业在云原生时代构建企业级统一的流量接入层和治理平台。

Hango 融合网关平台简化架构图如下：

作为云原生时代的 API 网关，我们认为除性能、稳定性、丰富的治理能力外，可观测性、可扩展性和热更新能力都是非常重要的能力，做出选择 Envoy 的决定，更多内容可以阅读 Hango 开源解读轻舟团队也有幸成为国内最早采用 Envoy 作为企业级网关数据面的团队之一，团队中的王佰平同学也是国内首位 Envoy Maintainer（https://sq.sf.163.com/blog/article/675467820063182848）。

在 API 网关 2.0 的生产实践过程中，我们发现客户的业务系统往往由多种异构应用组成，例如部署方式上有基于容器部署和基于虚拟机部署的，协议类型上有 HTTP、Dubbo、gRPC、TCP、UDP 和 SOAP 等等，服务发现上有采用 Eureka、Nacos、K8s 等等，如何通过 API 网关统一接入成为了新的挑战。

另外，云原生化演进并非一蹴而就，API 网关如何统一接入云原生应用和传统应用，这也成了企业应用云原生化演进的拦路虎。

让我们来看如下一些典型场景。

场景 1：当使用 HTTPS 协议对外暴露服务时，典型的部署方式是 API 网关之前部署流量网关（例如 Nginx），负责 SSL 证书的卸载。然而，引入流量网关存在增加整体延迟、引入新的故障点以及增加运维成本等问题。为了解决这些问题，一种潜在的解决方案是将流量网关和 API 网关合并。

场景 2：客户 A 将业务迁移到 K8s 集群，每个业务方单独部署一套 K8s 集群，业务方除了 HTTP 服务外，还有少量的 TCP 和 UDP 服务，如果为每个业务方部署一套四层代理，会增加额外的资源部署成本和运维成本，客户希望每个业务都能通过 API 网关访问 HTTP、TCP 和 UDP 服务。

场景 3：客户 B 将部分服务迁移到 K8s 集群，同时保留部分服务采用传统虚机部署方式，迁移到 K8s 集群的服务，希望通过 K8s Ingress 标准接口进行配置，客户 B 希望 API 网关支持 K8s Ingress 接口标准，这样对于不同的服务部署形态无需引入两种网关产品。

场景 4：客户 C 现有业务通过七层负载均衡对外暴露，随着业务云原生改造，现有的负载均衡在服务注册发现、服务治理、认证鉴权等方面已经无法满足业务方的需求，客户希望能够引入 API 网关能够统一接入云原生应用和传统应用。

在这样的背景下，网易数帆提出了融合网关的构想，不局限于 API 网关，它还可以是七层代理、七层负载均衡、K8s Ingress、K8s Gateway 等代理形态，目标是成为云原生时代企业级的统一流量接入层和治理平台。

对于企业而言，这样的融合网关不仅能够满足不同部署类型、不同协议类型、不同服务发现方式的应用统一接入，还能通过插件市场满足企业差异化的流量管理需求，从而实现统一的平台，大幅降低部署成本和运维成本，同时支撑业务云原生化平滑演进。

先进的融合网关如何设计

融合网关的本质，是在百花齐放的云原生时代实现技术平台的统一，不论是对流量管控领域的不同云原生资源实现和规范，还是对服务纳管领域的各种新老服务形态。解决这一问题，新一代 Hango 融合网关产品的实践，必须具备更加通用的扩展能力。

基于此，Hango 融合网关的设计目标，是统一流量、服务、协议等网关概念，并提供业务需要的简单操作方式。统一流量是指在原有 API 网关的基础上，融合业界主流的流量代理产品，包括七层负载均衡、Ingress、Gateway API、Knative 等等，实现一个 Envoy 网关可以代理所有 7 层应用流量。统一服务主要是针对网关代理的后端服务，可以支持对不同部署形态、不同网络协议、不同注册中心的业务服务进行统一的路由转发和流量治理。可以看到，统一服务也意味着统一协议。

为了融合多种流量代理产品，我们为 Hango 融合网关提出了“虚拟网关”的概念。虚拟网关是网关的逻辑划分，一个网关支持创建多个虚拟网关，多个虚拟网关共用网关处理资源，实现资源复用。同时，Hango 还需提供动态创建虚拟网关的能力，以便用户按需快速交付流量代理产品给业务方，满足云原生场景下业务敏捷化的诉求。

虚拟网关实现了资源的逻辑划分，在实现方案上，我们有两个选择：

1. 基于 Envoy 的 Listener 端口形式区分不同形态的网关不同的虚拟网关提供不同的访问入口，为每一个虚拟网关提供一个端口。
2. 基于 Envoy 的 VirtualHost 概念进行流量隔离的网关多个虚拟网关提供同一个访问入口，不同虚拟网关通过域名进行逻辑隔离。

相对于 Listener 隔离方案，VirtualHost 隔离是一种更细粒度的管理，Envoy Listener 概念下可以分多个 VirtualHost，我们一般可以把他与网关域名做关联。对比以上两种方案，我们最终选择了基于 Listener 端口的方案作为融合网关的技术方案，主要考虑了如下几个因素：

1. VirtualHost 隔离方案不支持 TCP/UDP 等四层代理和七层代理的融合；
2. 多个业务方使用相同域名的场景，采用 VirtualHost 隔离方案，存在路由冲突的风险；
3. 采用 VirtualHost 隔离方案，统一流量入口，缺少流量隔离能力且，对于服务（Envoy Clusters）和在 Envoy VirtualHost 之上的概念无法进行非常好的隔离。

主流的流量代理产品，例如七层负载均衡、API 网关、微服务网关、四层代理等，在产品功能和产品模型上都存在较大的差异。Hango 融合网关定义了虚拟网关类型，同时为不同类型的虚拟网关提供不同的能力集，对于使用单一流量代理产品的用户而言，使用融合网关并不会增加其使用难度。

Hango 目前抽象出了三类虚拟网关类型，分别是通用网关、负载均衡和 API 网关，后续还会陆续推出 K8s ngress、K8s Gateway、TCP 和 UDP 等虚拟网关类型，不同类型的虚拟网关将会提供差异化的能力，以简化用户的使用。

• 通用网关：通用网关涵盖了大部分网关的应用场景，在插件类型上最为丰富，功能也最为强大；
• API 网关：API 网关适用于需要对 API 进行统一管理和控制的场景，例如企业内部的 API 管理(目前仅商业版支持)、对外提供 API 服务的场景等；
• 负载均衡：七层负载均衡是是将网络流量分配到多个服务器上的场景，以实现提高系统的性能和可靠性。

相较于传统 API 网关，Hango 融合网关具有以下优势：

• 流量隔离：虚拟网关之间通过端口实现了逻辑隔离，不同业务使用不同的虚拟网关，业务流量相互不受影响；
• 统一管控：支持对多种代理形态的虚拟网关进行统一管控，同时不同代理提供差异化的产品功能和可观测性，提升产品易用性；
• 配置隔离：支持虚拟网关维度的治理配置，不同虚拟网关之间的路由配置相互隔离；
• 无侵入插件增强：统一产品插件形态，支持相同插件在所有代理产品生效，同时提供动态无侵入的自研插件体系，实现插件“一处开发，处处生效”的能力；
• 自定义插件：支持多语言的自定义插件能力，用户可以通过 Lua 或 Wasm 快速实现自定义插件。

Hango 融合网关未来展望

Hango 网关发展至今，已陆续发布了 5 个大版本（v1.0.0 - v1.4.0），如下图所示：

朝着云原生时代企业级的统一南北向流量接入和治理平台的目标，Hango 融合网关未来将会陆续推出一系列新特性，以支持不同部署类型、不同协议类型、不同服务发现方式的应用统一接入，提供多种代理形态。主要新特性如下：

• 遵循 Knative Gateway 接口标准

作为 Knative 服务的入口流量网关，纳管 Knative 南北向流量，同时提供 Knative 服务的流量治理能力和指标监控。



• TCP、UDP 协议

增强 Istio 的协议支持能力，提供基于 Envoy 端口维度的 TCP、UDP 协议路由转发，同时提供 TCP、UDP 流量的指标监控能力。



• 插件市场

提供多语言自定义插件扩展能力，主要包括社区的 Wasm 和网易数帆开源的 Hango Rider，目前 Wasm 支持多种语言（C++、Go、Rust 等），Rider 支持 Lua 语言。使用时用户可以基于 Lua、Go 等语言实现自定义插件逻辑，然后通过轻舟控制台进行导入即可生效。同时支持 schema 插件可视化，提供插件配置预览能力。

• 七层负载均衡代理形态

提供以多种部署方式，具有高可用、多租户、多协议、服务发现、流量转发，SSL/TLS 加速、缓存压缩、安全防护、数据分析、自定义插件等特性和能力的七层负载均衡代理形态。

近期后续版本 Hango 产品计划支持四层流量纳管方案，以及各类 7 层的高阶负载均衡能力，详细可参考 Hango 2023 RoadMap: https://hango-io.github.io/getting-started/roadmap/roadmap-2023

作者简介：

张明，网易数帆云原生产品专家，逾 15 年云计算、云原生领域开发、设计和产品等相关工作经验，目前主要负责云原生产品工作，聚焦于 API 网关、7 层负载均衡、K8s ingress 等产品规划和落地。

余涛，网易数帆云原生高级研发工程师，Hango 网关负责人，专注于云原生和微服务领域技术研究及实践，负责云原生网关和分布式事务等微服务领域产品的研发和落地。