11 月 5 日，2022 杭州 · 云栖大会 - 云原生峰会现场，阿里巴巴研究员、阿里云智能云原生利用平台总经理丁宇发表：云原生网关 Higress 正式开源，Higress 是一款标准化、高集成、易扩大、热更新的云原生网关。
Higress 源自阿里巴巴外部电商、交易等外围生产场景的实际积淀，遵循 Ingress/Gateway API 规范，将流量网关、微服务网关、平安网关三合一，并在此基础上扩大了服务治理插件、安全类插件和自定义插件，高度集成 K8s 和微服务生态，包含 Nacos 注册和配置、Sentinel 限流降级等能力，并反对规定变更毫秒级失效等热更新能力。
Higress 的前世今生
诞生背景
Higress 的创立源于阿里外部的“本地生存战斗”，该战斗始于“支付宝 2020 合作伙伴大会”，在此大会上支付宝发表降级为数字生存开放平台。该战斗的核心技术指标，是实现阿里巴巴业务域与蚂蚁业务域之间 RPC 间接调用，但因阿里巴巴与蚂蚁业务域网络是隔离的，即网络是不通的，很天然想到利用网关来解决此问题。
技术选型
利用网关来解决阿里巴巴与蚂蚁跨业务域 RPC 互通问题，首先要对网关做技术选型。
置信大家也都或多或少晓得，阿里巴巴开源的反向代理程序 Tengine。Tengine 在阿里外部对立接入网关 AServer 中被应用，咱们团队就是负责其开发运维，同时咱们团队也在负责阿里巴巴 Service Mesh 的落地，不论是对 Tengine 还是对 Istio + Envoy 这套架构都比拟相熟。
在选型时，尽管也调研过一些其余的软件，但思考到网关对性能、可靠性的高要求，在联合咱们本身的网关运维教训，决定看看 Tengine 与 Envoy 是否能够满足咱们的业务需要，在比照时咱们列举了四个要害要点，其比照如下：
这里提一下“为什么咱们认为配置的热更新，是十分重要的”？
Tengine/Nginx 的配置更新须要 reload，reload 须要重启 worker 过程，重启时会引起流量抖动，对长连贯影响尤为显著。在网关的集群规模十分大时，更是不能随便的做 reload，这时就会引发一个矛盾点：业务向网关提交配置后，心愿能疾速验证，但受限于 reload 机制和稳定性要求，无奈满足业务疾速验证与疾速试错的诉求。
当初曾经有很多支流利用抉择采纳长连贯，HTTP 1.1 个别默认会应用 Keep-Alive 去放弃长连贯，后续 HTTP 2 以及 HTTP 3 也是如此，随着网络协议的倒退，将来应用长连贯会变得更加广泛。而配置热更新人造对长连贯十分敌对。
如何解决这点呢？
一是采纳两层网关，即流量网关 + 业务网关；二是实现网关原生反对配置热更新。除了比照不同计划的优劣势，咱们也调研了 Envoy 作为网关在业界的趋势，论断是目前 Envoy 作为 K8s 中的 Ingress Provider 增长最快的事实（Ingress Provider 指 K8s Ingress 标准具体实现，因 K8s Ingress 本身只是标准定义，是 K8s 下内部流量进入集群外部的网关标准定义），咱们最终抉择了 Envoy 来实现两层网关。
倒退历程
Higress 从最后社区的 Istio + Envoy，到经验阿里巴巴外部的自研扩大，再到大规模生成验证，最初实现商业化产品的公布，其整个过程介绍如下：
上面的章节会对 Higress 的各个阶段做进一步的具体阐明。
Higress(2020.05-2020.11)
此阶段的大指标是为了满足团体与蚂蚁 RPC 互通，升高全链路的 RT，解决原 s2s 链路因 RT 过高带来的用户体验差及无奈满足更多团体与蚂蚁协同场景要求。s2s 链路是走公网链路，协定采纳 HTTP。与蚂蚁互通网关的架构图如下，这里以上海云单元为背景阐明。
上图次要展现的是团体侧的架构，最终采纳了 Istio+Envoy 的计划，在部署的时候又分成了进口集群和入口集群。之所以拆成两个集群，一方面是过后两边互访，蚂蚁调团体的流量要远远大于团体调蚂蚁的流量，上下行特地不均等；另一方面是离开之后两个集群能够各自保护，稳定性会更好。
Higress 从开始立项到实现第一期研发，网关革新的外围工作差不多两个人投入了一个半月左右，其中还波及到大量网络、平安等协调部门的工作。Higress 架构并没有齐全依照社区计划来设计，社区版本中配置变更和服务发现应用的是 K8s，在阿里外部宏大的服务规模及配置量下社区原生计划不论在稳定性及性能上都无奈满足要求，因而阿里这套计划重点对服务发现、配置存储组件做了替换，及优化 xDS 推送性能。
Higress 上线后，顺利达成了最后的业务诉求，目前蚂蚁互通网关链路曾经成为团体与蚂蚁互通的首选计划，一些领取链路也迁徙到了该计划，例如充值核心等，具体达到的成绩简述如下：
- 蚂蚁调用团体链路相比原链路 RT 升高 50%，网关本身 RT 0.3ms。
- Higress 胜利复制到团体与蚂蚁的音讯互通，目前团体与蚂蚁的音讯互通也是走的 Higress Triple 链路。
- 微服务网关从 5 月份上线，目前曾经成为团体与蚂蚁东西向流量的外围链路，飞猪、手淘、口碑、饿了么、1688、局部导购利用、商品库、评估等业务已胜利上线，而且圆满撑持了 618 大促、支付宝 717 夏至大促。
- 在 2020 双 11 大促每秒 数十万 的申请流量，圆满撑持了双 11 城市生存狂欢节的互动会场。
- 在技术侧实现了 Higress 在东西向流量散发的摸索。
Higress(2020.12-2021.10)
随着阿里巴巴上云战斗的推动，越来越多的场景找到咱们。比方云上云下业务互通，因为 Tengine 服务治理弱导致阿里外部大量二层微服务网关须要收敛，这就须要从业务上做 Tengine+Envoy 两层网关的演进，承当南北向网关流量。在 2020 年 12 月份，团队开始了 Higress 架构的持续演进，以优酷场景为例的演进过程如下图：
Higress 南北向的架构图如下：
在两层架构中，Higress 网关更多承当了微服务网关和微服务治理的需要，和 Tengine 流量网关实现了整合。在这个过程里，团队撑持优酷外部多个二层微服务网关对立的工作，大幅晋升了性能和运维效率。
在这一阶段，Higress Gateway 实现了东西向、南北向全域流量的调度散发，东西向上不仅反对跨业务域的蚂蚁 RPC 互通，也扩大到了混合云的云上云下 RPC 互通场景，笼罩钉钉文档、阿里视频云、达摩院的店小蜜、智慧数字人等。该阶段的业务大图如下（云上云下互通场景，以钉钉为例阐明）：
随着 Higress Gateway 笼罩的业务场景越来多，在跟优酷继续单干的过程中，单方团队不谋而合提出了一个构想：Tengine Gateway（承当流量网关角色）+ Higress Gateway（承当微服务网关角色）的两层网关是否能够合并为一层 Higress Gateway？
咱们对这一想法做了调研，答案是必定的，并且过后大家也单干设计了新的架构计划，如下图：
尽管因为各种各样的起因，这个计划最终没有跟优酷持续往下推动。但这个演进方向让团队明确了网关新的发展趋势：在以 K8s 主导的容器化背景下，因为 K8s 集群内外网络的人造隔离性，用户须要一款兼顾高性能与安全性，以及弱小服务治理能力的入口网关。这也为后续团队将技术积淀变成云产品、推动 Higress 的诞生打下了根底。
2021 年，阿里巴巴开启了中间件三位一体战斗，指标是用云产品撑持团体业务。咱们开始将孵化成熟的 Higress 技术积淀为云产品，即目前阿里云上提供的 MSE 云原生网关，一方面面向宽广的私有云用户提供托管的网关服务，另一方面也对内服务团体。MSE 云原生网关的技术架构简图如下：
Higress(2021.11-2022.11)
随着 Higress 成为云产品服务于更多内部用户，咱们逐渐发现用户对 Higress 提出了更高的要求，其中反馈较多的大的需要点是插件扩大、Waf 防护、多注册核心、Nginx Ingress 注解兼容以及 HTTP 转 Dubbo 协定，当然也有很多小的需要点在此就不一一列出，因而该阶段咱们重点发力在上述用户反馈的高频需要。
Higress 提供的插件市场，其一阶段反对 Wasm 插件，满足谋求高性能、高平安的用户对网关的扩大诉求，二阶段会反对 Lua 插件，满足传统用户应用 Lua 的扩大的诉求，如 Nginx 用户，三阶段会反对过程外插件，满足多语言用户诉求，尤其是 Java 用户因现阶段 Java 社区对 WebAssembly 反对尚不欠缺但又心愿对网关进行扩大的诉求。
Higress 也反对了 Nginx Ingress 注解平滑迁徙的能力，满足局部用户冀望迁徙到 Higress 但又不心愿重新配置网关的诉求，同时 Higress 突破了 Nginx Ingress 只能关联单个 K8s 集群的限度，反对关联多个 K8s 集群，即能够将 Higress 作为对立接入网关应用，同时又能够享受 Ingress 的红利。
对于传统应用 Dubbo 的微服务用户心愿应用原生 RPC 形式裸露对外服务，但通常提供内部拜访的服务以应用 HTTP 为主，为了帮忙 Dubbo 用户升高服务裸露的开发成本，Higress 提供了 HTTP 转 Dubbo 协定性能，且通过 Console 为用户提供白屏化的配置形式，某客户应用后反馈“这是业界完成度最高的 HTTP 转 Dubbo 协定”性能。
在云原生的浪潮下，开源曾经成为软件倒退的必然趋势与疾速门路，因为社区的力量是十分弱小的。
因而咱们将这套通过外部实际积淀下来的网关计划 Higress 正式对外开源，以 Kubernetes Ingress 网关为契机带来了流量网关与微服务网关交融的可能性，联合阿里外部实际积淀 Higress 实现了流量网关 + 微服务网关 + 平安网关三合一的高集成能力，同时深度集成了 Dubbo、Nacos、Sentinel 等，可能帮忙用户极大的升高网关的部署及运维老本，而且能力不打折。
Higress 将来瞻望
尽管目前云原生曾经成为必然趋势，但事实是有很大一部分用户处于迁徙上云的过程中，在从传统架构向以 Kubernetes 为代表的容器化云原生架构迁徙，可预感这在将来很长一段时间会始终继续，因而 Higress 后续会重点反对非 Kubernetes 部署架构，以 Higress + Nacos 的组合模式为用户提供最小集运行环境，同时满足用户服务注册、配置管理、微服务治理的诉求。
在以 Kubernetes 为代表的容器化云原生方向，咱们在兼容好现有 Ingress 规范的根底上，会重点发力下一代的 Ingress 规范 Gateway API，利用 Gateway API 带来的契机买通南北向与东西向的全域流量调度，帮忙用户应用一套架构架构同时治理内部与外部流量，升高部署运维老本、晋升开发及运维效率。
搭把手
国内云原生网关的开源我的项目并不多，Higress 明天刚开源，看看文章底部的浏览量，您就是这条街 Topxxxx 关注 Higress 的。如果再走近一步，例如奉献一份文档、提交一段代码，您就有可能成为 Higress 的第一批 Contributor 甚至 Committer。目前，咱们建设了 1 个钉群和 1 个微信群，退出咱们，分割群主或群管，共建云原生网关吧。