作者：Higress 团队
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 正式对外开源，以 Kubernetes Ingress 网关为契机带来了流量网关与微服务网关交融的可能性，联合阿里外部实际积淀 Higress 实现了流量网关 + 微服务网关 + 平安网关三合一的高集成能力，同时深度集成了 Dubbo、Nacos、Sentinel 等，可能帮忙用户极大的升高网关的部署及运维老本，而且能力不打折。
03 为什么 Higress 能代替多层网关，成为下一代网关
Higress 是标准化、高集成、易扩大、热更新的云原生网关。无缝集成容器和微服务生态，是云原生时代的默认选项。
高集成，连贯微服务生态
Envoy 提供了 EDS/DNS/STATIC 等多种类型的 Cluster，Higress 基于此具备了对接多种服务发现的能力，能够实现：
- 通过 Nacos 发现服务 （EDS）
- 通过 Zookeeper 发现服务 （EDS）
- 通过 K8s Service 发现服务 （EDS）
- 通过 DNS 域名发现服务 （DNS）
- 通过配置动态 IP 发现服务 （STATIC）
通过 Higress 控制台能够很不便地进行相应的服务发现配置：
随着云原生技术的倒退，不少企业开始从传统架构向云原生架构演进，但这过程中传统架构部署的服务无奈被 K8s 的 Ingress 发现并路由成为一个阻塞点，导致业务架构无奈平滑地向云原生平滑演进。Higress 依靠于 Nacos 等注册核心的能力，无论服务是否部署在 K8s 集群内，都能够发现服务并进行申请路由。如上图所示，业务在迁徙过程中，能够通过 Higress 将 5% 的灰度流量导入部署在 K8s 上新架构的服务中，进行灰度测试验证，逐渐切流，从而实现业务架构安稳降级。
对于灰度能力，Higress 实现了和 OpenKruise Rollout 进行联动，能够实现服务灰度公布。整个 Rollout 过程，能够实现主动整合 Deployment、Service、Ingress 一起工作，并向用户屏蔽底层资源变动。用户无需手动编辑多个 K8s 资源，即可轻松应用金丝雀公布，A/B Test 等灰度机制。
易扩大，晋升网关的业务使命
将插件的生命周期划分为三个阶段：
- 插件开发阶段
- 散发集成阶段
- 运行失效阶段
Envoy 提供的 Wasm 插件机制，解决了插件运行失效阶段的问题，基于 ECDS 配置更新机制，插件代码和配置产生变更均不会导致连贯断开，并且插件运行在平安沙箱中，即便代码逻辑呈现空指针等异样，也不会导致网关产生 Crash。
在插件开发阶段，Higress 基于 Proxy Wasm 生态提供了更容易上手的 C++ 和 Go 语言的 Wasm 插件 sdk，在 sdk 中封装了插件路由和域名级失效的机制，开发者只需关怀插件配置解析和运行逻辑即可，在散发集成阶段，Higress 定义了 Wasm 插件的 OCI 镜像标准，将插件的 README 文档，配置字段束缚信息，以及 Wasm 文件等一起打包在一个 OCI 镜像中，能够通过反对 OCI 格局的镜像仓库进行存储和拉取。并且能够通过 Higress 控制台疾速启用插件：
Wasm 插件的 OCI 镜像标准：
https://higress.io/zh-cn/docs/user/wasm-image-spec
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: 5678Gateway 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 连贯断开。
04 Higress 生产实践最佳参考
可观测
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 等工具，进行全功能测试和试用：
helm install higress -n higress-system higress.io/higress --create-namespace --render-subchart-notes --set global.local=true --set higress-console.o11y.enabled=false --set higress-console.domain=console.higress.io --set higress-console.admin.password.value=admin详情能够参考：
《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/gat...
《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 注销信息，社区将邀请您退出 Higress 落地反对群，咱们会为落地用户提供领导和帮忙。
Higress GitHub issue：
https://github.com/alibaba/higress/issues/1
05 社区：回顾和瞻望
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 插件相干的我的项目推出，实现我的项目既能播种我的项目奖金，还能播种开源荣誉，欢送有趣味的同学参加。
致谢
要特别感谢大半年工夫里，陪伴 Higress 一起成长的开发者搭档们，你们为这个我的项目奉献了本人的工夫、智慧和激情。你们的编码技巧、开源奉献和对社区的沉闷参加，都使 Higress 变得更加稳固、性能更弱小，没有你们的奉献，Higress 无奈实现这一里程碑式的公布。以下是为 Higress 做过奉献的内部开发者名单：
Higress Committer
董艺荃（From 携程），刘训灼（From 腾讯），李强林（From 浙江大学），宋鹏远（From 小满科技），凌轶群（From 拼多多）
Higress Contributor
张小俊（From 端点科技），舞羡（From 蚂蚁金服），吴新军（From 创蓝云智），王金山（From 时速云科技），朱云辉（From 哈啰出行），封宇腾（From 西安邮电大学），韦鑫（From 南京航空航天大学），张宇坤（From 浙江大学），张嘉豪 （From 百威团体），陈忠润（From 端点科技），刘天祥（From 端点科技），陈淼晨（From 拓数派），陈特（From 云豪团体），张晨（From 论之语），谢怼怼（From 花生日记），Tom Kerkhove （From Microsoft Azure）
还有没留下实在姓名的贡献者， Github ID 如下：
whalecold,xcbeyond,gczz2022,tanjunchen,burningEvil0,ytwang0320, PerforMance308,OnlyPiglet,casun18,cobb-tx,wangshiqi308,gczz2022, tanjunchen, burningEvil0, ytwang0320, casun18