多层网关已成过去，网关多合一成潮流，网关改造正当时｜Higress 1.0 正式发布

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

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

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

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

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

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

因此我们将这套经过内部实践沉淀下来的网关方案 Higress 正式对外开源，以 Kubernetes Ingress 网关为契机带来了流量网关与微服务网关融合的可能性，结合阿里内部实践沉淀 Higress 实现了流量网关 + 微服务网关 + 安全网关三合一的高集成能力，同时深度集成了 Dubbo、Nacos、Sentinel 等，能够帮助用户极大的降低网关的部署及运维成本，而且能力不打折。

Higress 是 标准化、高集成、易扩展、热更新的云原生网关。无缝集成容器和微服务生态，是云原生时代的默认选项。

Envoy 提供了 EDS/DNS/STATIC 等多种类型的 Cluster，Higress 基于此具备了对接多种服务发现的能力，可以实现：

1. 通过 Nacos 发现服务 （EDS）

2. 通过 Zookeeper 发现服务 （EDS）

3. 通过 K8s Service 发现服务 （EDS）

4. 通过 DNS 域名发现服务 （DNS）

5. 通过配置静态 IP 发现服务 （STATIC）

通过 Higress 控制台可以很方便地进行相应的服务发现配置：

随着云原生技术的发展，不少企业开始从传统架构向云原生架构演进，但这过程中传统架构部署的服务无法被 K8s 的 Ingress 发现并路由成为一个阻塞点，导致业务架构无法平滑地向云原生平滑演进。Higress 依托于 Nacos 等注册中心的能力，无论服务是否部署在 K8s 集群内，都可以发现服务并进行请求路由。如上图所示，业务在迁移过程中，可以通过 Higress 将 5% 的灰度流量导入部署在 K8s 上新架构的服务中，进行灰度测试验证，逐步切流，从而实现业务架构平稳升级。

对于灰度能力，Higress 实现了和 OpenKruise Rollout 进行联动，可以实现服务灰度发布。整个 Rollout 过程，可以实现自动整合 Deployment、Service、Ingress 一起工作，并向用户屏蔽底层资源变化。用户无需手动编辑多个 K8s 资源，即可轻松使用金丝雀发布，A/B Test 等灰度机制。

将插件的生命周期划分为三个阶段：

1. 插件开发阶段

2. 分发集成阶段

3. 运行生效阶段

Envoy 提供的 Wasm 插件机制，解决了插件运行生效阶段的问题，基于 ECDS 配置更新机制，插件代码和配置发生变更均不会导致连接断开，并且插件运行在安全沙箱中，即使代码逻辑出现空指针等异常，也不会导致网关发生 Crash。

在插件开发阶段，Higress 基于 Proxy Wasm 生态提供了更容易上手的 C++ 和 Go 语言的 Wasm 插件 sdk，在 sdk 中封装了插件路由和域名级生效的机制，开发者只需关心插件配置解析和运行逻辑即可，在分发集成阶段，Higress 定义了 Wasm 插件的 OCI 镜像规范（https://higress.io/zh-cn/docs/user/wasm-image-spec），将插件的 README 文档，配置字段约束信息，以及 Wasm 文件等一起打包在一个 OCI 镜像中，可以通过支持 OCI 格式的镜像仓库进行存储和拉取。并且可以通过 Higress 控制台快速启用插件：

Higress 的插件机制和传统的基于 OpenResty Lua 扩展的插件机制最本质的区别，也是往往最容易被开发者忽略的是插件分发集成的环节。传统的 Lua 插件扩展机制，插件自身的版本生命周期是跟着网关的版本走，插件版本更新，以及自己开发插件都需要重新部署网关。而 Higress 依托于 OCI 镜像进行网关插件的版本管理和分发，实现了插件版本生命周期和网关版本的解耦，用户只需调整一行插件 OCI 镜像地址，即可完成插件的热更新，整个过程网关连接不会发生断开，流量完全无损。

基于此，在网关上的业务插件逻辑可以很方便地实现热更新。Higress 也基于此能力提供了很多业务认证和安全相关的官方插件，开箱即用。

因为 Envoy 是面向配置管理服务器设计的配置系统，对程序友好，对手写配置并不友好。因此像 Istio 设计了 VirtualService/DestinationRule/AuthorizationPolicy 等等 CRD 抽象，来解决 Envoy 配置复杂的问题，Istio 的 CRD 本身是解决 ServiceMesh 下复杂的服务治理场景而设计，而对于网关路由场景，更多用户需要的是 Ingress 这样更简单的 API 标准。

Higress 结合阿里内部实践以及阿里云产品沉淀，积累了基于 Ingress API 的丰富的路由策略扩展能力，同时还兼容大部分 Nginx Ingress 能力，并且可以通过 Higress 提供的控制台来创建路由，开箱即用：

Higress 控制台目前对接的底层模型是 Ingress API，如果你对 Gateway API 有了解，会发现 Higress 控制台上的路由模型，也完全可以用 Gateway API 进行描述：

apiVersion: gateway.networking.k8s.io/v1beta1kind: HTTPRoutemetadata:  name: foospec:  parentRefs:  - name: foo-example  hostnames:  - "foo.example.com"  rules:  - matches:    - path:        type: PathPrefix        value: /foo      headers:      - type: Prefix        name: x-higress-header        value: hi      queryParams:      - type: Exact        name: higressQuery        value: hi      method: POST    backendRefs:    - name: foo-service      port: 5678

Gateway API 标准目前还处在 beta 阶段，尚未完全定稿，生产使用我们更多还是建议用户使用 Ingress API，避免后续 Gateway API 标准改动带来 Breaking Change。Higress 对 Gateway API 的支持正在开发中，可以看到基于上面的模型，借助 Higress 控制台可以帮助用户屏蔽底层 API 路由标准的代际差异，实现路由从 Ingress API 平滑迁移到 Gateway API，根治对技术标准追赶的焦虑。

K8s 带来了云原生的路由标准 Ingress/Gateway API，如同 POSIX 定义 Unix 可移植操作系统标准，历时 35 年经久不衰，云原生的路由标准的生命周期一定会远超过 K8s 本身。

Higress 基于 Envoy 引擎，为适应现代应用和微服务架构的需求，对传统流量网关（本文以 Nginx 为例）的不足之处进行改进，实现了真正的配置热更新，并让流量网关和微服务网关的融合成为可能。

Nginx 的配置变更 reload ，会导致 downstream 和 upstream 连接都断开触发重连，在高并发场景下，downstream 并发重连将导致 Nginx 的 CPU 飙升，最严重的还是 upstream 的并发重连，很可能打垮后端业务程序的线程池，造成雪崩。

而 Envoy 依托于精确的配置变更管理，做到了真正的热更新。在 Envoy 中 downstream 对应 listener 配置，交由 LDS 实现配置发现；upstream 对应 cluster 配置，交由 CDS 实现配置发现。listener 配置更新重建，只会导致 downstream 连接断开，不会影响 upstream 的连接；downstream 和 upstream 的配置可以独立变更，互不影响。再进一步，listener 下的证书 (cert)，过滤器插件 (filter)，路由 (router) 均可以实现配置独立变更，这样不论是证书 / 插件 / 路由配置变更都不再会引起 downstream 连接断开。

Higress 提供了自带的 prometheus 和 grafana 可以开箱即用，同时也支持对接用户自建的监控系统，详细请参考：《基于 Prometheus 实现 Higress 流量观测》：https://higress.io/zh-cn/docs/user/prometheus

可以使用 Helm 一键完成 Higress 的生产安装部署

helm repo add higress.io https://higress.io/helm-chartshelm install higress -n higress-system higress.io/higress --create-namespace --render-subchart-notes --set higress-console.domain=console.higress.io

通过增加 helm 参数 --set global.local=true 可以在本地 PC 环境基于 k3s/kind 等工具，进行全功能测试和试用：

详情可以参考：

《Higress Quickstart》：https://higress.io/zh-cn/docs/user/quickstart

《Higress 安装部署》：https://higress.io/zh-cn/docs/ops/deploy-by-helm

不论 Dubbo/SpringCloud 服务是否部署在 K8s 集群内， Higress 都可以实现对接。因此在 K8s 场景下，用户可以将 Nginx Ingress 这类流量网关和 Spring Cloud Gateway 这类微服务网关合并，统一替换为 Higress。

《Higress 对接 Dubbo 服务》：https://cn.dubbo.apache.org/zh-cn/overview/what/ecosystem/gateway/higress/

《Higress 对接 SpringCloud 服务》：https://higress.io/zh-cn/docs/user/spring-cloud

Higress 和 Nginx 对比，在 HTTP1 上会略逊一筹，但在现代化协议如 gRPC/HTTP2 上则比 Nginx 好很多。

《gRPC 吞吐是 Nginx 的 4 倍》：https://gist.github.com/johnlanni/aac7480c17b0fde05fa64a20fc93b165

而如果你使用的是 K8s Nginx Ingress，因为其 Lua 代码性能较差，即使在 HTTP1 场景下，Higress 性能也更好，具体数据可以参考：

《K8s 网关选型初判》：https://xie.infoq.cn/article/0a2c9ac4ed139bc28f881d7c3

Higress 自从 4 月份发布 1.0.0 RC 版本以来，在社区有大量用户进行安装和测试，帮助 Higress 变得更成熟，并且适应了更多系统和安装环境。同时有多家企业完成了 Higress 技术的落地。

开源软件的发展离不开社区用户的实践，用户的参与和贡献是推动开源项目成功的关键因素。在这里，我们欢迎更多的社区用户加入 Higress 实践落地的行列！欢迎到 Higress GitHub issue（https://github.com/alibaba/higress/issues/1）登记信息，社区将邀请您加入 Higress 落地支持群，我们会为落地用户提供指导和帮助。

Higress 一路走来，保持一个月发布一个版本的频率，一共完成了 183 个 PR 的合并，发布了 13 个 Release，完成了 5 个里程碑：

Higress 在 1.0 版本 GA 后，将继续保持高投入，并快速迭代。社区未来三个大版本的核心功能规划如下：

• 1.1 版本（6 月）

• 实现 HTTP2RPC API

• 支持非 K8s 场景下使用

• 1.2 版本（7 月）

• 支持和 Skywalking 等更多可观测生态集成

• 完整实现 Gateway API

• 1.3 版本（8 月）

• 实现 API 管理产品形态建设

• 推出独立的 Wasm 插件集市项目

其中 Wasm 插件生态会作为 Higress 社区长期重点投入方向，目前在中科院开源之夏 /CCF 编程之夏 / 云原生编程挑战赛等活动中均有 Higress Wasm 插件相关的项目推出，完成项目既能收获项目奖金，还能收获开源荣誉，欢迎有兴趣的同学参与。