多层网关已成过去，网关多合一成潮流，网关改造正当时

01 前言

K8s 通过 Ingress / Gateway API 将网关标准化，逐步将安全网关、流量网关、微服务网关内聚，解决从单体到微服务到云原生多层网关的复杂度，合久必分，分久必合，多层网关已成过去，网关多合一成潮流，成为 K8s 开发者和微服务开发者共同关心的话题。

02 Higress 1.0 正式发布，即官方推荐生产可用

Higress 是阿里云开源的下一代网关，从 2022 年 11 月在云栖大会上宣布开源，走过大半年时间，发布了 GA 版本 1.0.0，即官方推荐生产可用。回顾 Higress 的发展历程，经历了三个阶段：

Higress 的技术选型和首次业务落地（2020.05~2020.11）

Higress 的创建源于阿里内部的“本地生活战役”，核心技术目标是实现阿里巴巴业务域与蚂蚁业务域之间 RPC 直接调用，但因阿里巴巴与蚂蚁业务域网络是隔离的，即网络是不通的，很自然想到利用网关来解决此问题。利用网关来解决阿里巴巴与蚂蚁跨业务域 RPC 互通问题，首先要对网关做技术选型。选型期，除了关注技术方案是否完美支持 HTTP/gRPC 协议、支持丰富路由策略以及是否业内主流技术，还关注是否支持热更新。

热更新是我们的核心关注点。

Tengine/Nginx 的配置更新需要 reload，reload 需要重启 worker 进程，重启时会引起流量抖动，对长连接影响尤为明显。在网关的集群规模非常大时，更是不能随意的做 reload，这时就会引发一个矛盾点：业务向网关提交配置后，希望能快速验证，但受限于 reload 机制和稳定性要求，无法满足业务快速验证与快速试错的诉求。

如何解决这点呢？

一是采用两层网关，即流量网关 + 业务网关；二是实现网关原生支持配置热更新。除了对比不同方案的优劣势，我们也调研了 Envoy 作为网关在业界的趋势，结论是目前 Envoy 作为 K8s 中的 Ingress Provider 增长最快的事实（Ingress Provider 指 K8s Ingress 规范具体实现，因 K8s Ingress 自身只是规范定义，是 K8s 下外部流量进入集群内部的网关规范定义），我们最终选择了 Envoy 来实现两层网关，并完美支撑双11大促每秒数十万的请求流量。

Higress 的重要演进和服务更多业务场景（2020.12~2021.10）

随着在阿里巴巴和蚂蚁的成功落地，越来越多的业务场景找到了我们。

这个过程中，Higress 实现了东西向、南北向全域流量的调度分发，东西向上不仅支持跨业务域的蚂蚁 RPC 互通，也扩展到了混合云的云上云下 RPC 互通场景，覆盖钉钉文档、阿里视频云、达摩院的店小蜜、智慧数字人等。

2021 年，阿里巴巴开启了中间件三位一体战役，目标是用云产品支撑集团业务。我们开始将孵化成熟的 Higress 技术沉淀为云产品，即目前阿里云上提供的 MSE 云原生网关，一方面面向广大的公有云用户提供托管的网关服务，另一方面也对内服务集团。

Higress 对外开源，通过社区力量加速发展（2021.11~至今）

随着 Higress 成为云产品服务于更多外部用户，我们逐步发现用户对 Higress 提出了更高的要求，其中反馈较多的大的需求点是插件扩展、Waf 防护、多注册中心、Nginx Ingress 注解兼容以及 HTTP 转 Dubbo 协议，当然也有很多小的需求点在此就不一一列出，因此该阶段我们重点发力在上述用户反馈的高频需求。

开源已经成为软件发展的必然趋势与快速路径，因为社区的力量是非常强大的。

因此我们将这套经过内部实践沉淀下来的网关方案 Higress 正式对外开源，以 Ku