网关,作为互联网流量入口,同时承载着业务安全的期待,在数字时代又被融入云原生能力。对于现代化分布式架构来说,网关所扮演的角色越来越重要。网易数帆在覆盖互联网、银行、证券、保险、能源、制造等行业的云原生网关实践过程中,发现企业对网关的要求日益全面、严苛—— 既要满足云原生环境的新需求(纳管容器环境出入口流量),又要覆盖新老应用多样的服务纳管功能需求,还要保证始终如一的高性能与稳定性,也要能够作为面向未来的统一网关纳管主流的七层应用流量。
鉴于此,网易数帆提出了“融合网关”的概念,并相信这是下一代网关产品的标准形态。本文将解读融合网关诞生的背景与价值,探讨融合网关的设计与实现,并分享基于开源 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 还需提供动态创建虚拟网关的能力,以便用户按需快速交付流量代理产品给业务方,满足云原生场景下业务敏捷化的诉求。
虚拟网关实现了资源的逻辑划分,在实现方案上,我们有两个选择:
基于 Envoy 的 Listener 端口形式区分不同形态的网关不同的虚拟网关提供不同的访问入口,为每一个虚拟网关提供一个端口。
基于 Envoy 的 VirtualHost 概念进行流量隔离的网关多个虚拟网关提供同一个访问入口,不同虚拟网关通过域名进行逻辑隔离。
相对于 Listener 隔离方案,VirtualHost 隔离是一种更细粒度的管理,Envoy Listener 概念下可以分多个 VirtualHost,我们一般可以把他与网关域名做关联。对比以上两种方案,我们最终选择了基于 Listener 端口的方案作为融合网关的技术方案,主要考虑了如下几个因素:
VirtualHost 隔离方案不支持 TCP/UDP 等四层代理和七层代理的融合;
多个业务方使用相同域名的场景,采用 VirtualHost 隔离方案,存在路由冲突的风险;
采用 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 网关负责人,专注于云原生和微服务领域技术研究及实践,负责云原生网关和分布式事务等微服务领域产品的研发和落地。
评论