夜雨聆风1) 是什么
Higress 是一款云原生 API 网关，内核基于 Istio 和 Envoy。
它的几个关键标签：
云原生 API 网关
AI 网关（AI Native API Gateway）
支持 Wasm 插件扩展
兼容 Kubernetes Ingress / Gateway API
可作为微服务网关和安全防护网关
Higress 最初在阿里内部诞生，主要为了解决：
Nginx/Tengine reload 对长连接业务有损
gRPC / Dubbo 负载均衡能力不足
从定位上看，Higress 不是单纯的“流量转发器”，而是一个把 API 治理、AI 能力接入、可观测、安全防护和插件扩展整合在一起的统一网关层。
2) 解决什么问题
2.1 传统网关的问题
传统 API 网关或基于 Nginx 的 Ingress 常见问题：
配置变更依赖 reload，可能引起流量抖动
对长连接、流式响应、SSE 等场景不够友好
对 gRPC、Dubbo、微服务注册发现等支持不够统一
扩展能力有限，很多功能要靠 Lua/旁路系统/二次开发拼起来
AI 场景下缺少模型路由、token 限流、fallback、缓存、AI 可观测等原生能力
2.2 Higress 主要解决的事
| 问题 | Higress 的解决方式 |
|---|---|
| 配置变更影响在线流量 | 避免 Nginx reload 带来的抖动，配置毫秒级生效 |
| 长连接和流式场景支持弱 | 支持真正的流式请求/响应处理，适合 SSE、AI 流式输出 |
| 扩展困难 | 使用 Wasm 插件机制，可用 Go / Rust / JS 等语言扩展 |
| AI 业务缺少原生网关能力 | 提供统一接入多模型、负载均衡、fallback、token 流控、缓存、AI 可观测 |
| K8s 网关迁移成本高 | 兼容大量 Nginx Ingress 注解，支持平滑迁移到 Higress 或 Gateway API |
| 微服务治理整合复杂 | 可对接 Nacos、ZooKeeper、Consul、Eureka 等注册中心 |
| 安全能力需要额外拼装 | 提供 WAF、认证鉴权等插件能力 |
3) 怎么工作的
3.1 内核架构
Higress 基于 Istio 和 Envoy。
可以把它理解成：
Envoy 负责高性能数据面转发
Istio 相关能力提供云原生治理基础
Higress 在此基础上封装成更易用的 API / AI 网关产品形态
通过 Wasm 插件机制把很多网关能力做成可插拔模块
所以它兼顾了两件事：
底层性能和稳定性
上层业务能力的快速扩展
3.2 插件机制
Higress 的一个核心设计是 Wasm 插件扩展。
这意味着：
网关能力不是全部写死在内核里
可以把认证、限流、安全、AI 路由、协议处理等做成插件
插件通过沙箱隔离，内存安全更好
插件版本可以独立升级
网关逻辑可以热更新，尽量做到流量无损
这比传统把逻辑塞进 Nginx reload、Lua 脚本或自定义 sidecar 的方式更现代。
3.3 AI 网关能力
AI Gateway = AI Native API Gateway。
“AI Native”的意思不是把普通网关换个名字，而是把 AI 当成一等公民。围绕 AI API 的研发、供应、消费和观测，网关层会提供专门能力，例如：
统一接入不同大模型厂商
多模型路由
负载均衡
fallback 失败切换
token 级别流控
AI 缓存
AI 可观测
因此，Higress 不只是“把请求转发给模型”，而是在模型调用链路前面提供统一治理层。
3.4 流式处理
Higress 支持真正的完全流式处理请求和响应 Body。
这点非常重要，因为 AI 场景里大量使用：
SSE
流式文本生成
长时间连接
大带宽响应
这样可以：
更方便处理流式协议报文
显著降低大带宽 AI 场景下的内存开销
4) 适合什么场景
4.1 AI 网关
这是 Higress 最有特色的场景。
适合：
同时接多家 LLM 厂商 API
需要统一鉴权、流控、审计、可观测
需要模型级别路由、负载均衡、fallback
需要缓存与成本控制
要支撑流式输出
典型例子：
企业内部统一大模型接入层
AI 应用平台
多模型代理层
面向业务团队提供标准化模型 API 的平台
4.2 Kubernetes Ingress 网关
适合：
作为 K8s 集群入口网关
现有系统基于 Nginx Ingress，希望平滑迁移
希望逐步从 Ingress API 迁移到 Gateway API
希望降低资源消耗、提高路由变更生效速度
如果团队已经在 Kubernetes 里大量使用 Ingress，这类场景比较容易落地。
4.3 微服务网关
适合：
有 Dubbo、Nacos、Sentinel 等技术栈
服务发现依赖 Nacos / ZooKeeper / Consul / Eureka
希望统一南北向与部分东西向入口治理
希望比传统 Java 网关更省资源
它更像一个高性能、可扩展、云原生友好的微服务入口层。
4.4 安全防护网关
适合：
API 暴露在公网
需要 WAF
需要认证鉴权插件
希望把安全策略前置到网关层
文档里明确提到支持多种认证鉴权策略，例如：
key-auth
hmac-auth
jwt-auth
basic-auth
oidc
5) 有什么优缺点
| 维度 | 优点 | 缺点 / 注意点 |
|---|---|---|
| 性能与稳定性 | 基于 Envoy，生产级验证；避免 Nginx reload 抖动 | 架构能力更强，同时理解门槛也更高 |
| AI 场景适配 | 对模型接入、流控、fallback、缓存、可观测支持更原生 | 如果团队没有 AI 网关需求，部分能力可能用不上 |
| 扩展性 | Wasm 插件机制强，支持多语言扩展 | 插件开发和调试比简单配置更复杂 |
| 云原生兼容性 | 支持 Ingress API / Gateway API，适合 K8s | 如果团队完全不在云原生体系，收益会下降 |
| 微服务集成 | 能对接多种注册中心，适合复杂服务治理 | 需要理解注册发现、路由治理等体系 |
| 易用性 | 有现成插件、控制台、支持 Docker 启动 | 真正用深之后，运维和治理仍然需要平台化能力 |
| 安全能力 | WAF、鉴权插件开箱即用 | 高级安全策略仍需要结合企业自身规范设计 |
一句话总结
Higress 可以理解为“面向云原生和 AI 时代的新一代 API 网关”：
底层用 Envoy / Istio 提供性能和治理基础
中间用 Wasm 插件提供可扩展能力
上层面向 AI、K8s、微服务和安全场景提供开箱即用的网关能力
如果你的系统同时有下面几类需求，Higress 会比较合适：
要做 Kubernetes 入口网关
要兼容或替换 Nginx Ingress
要做统一 AI 模型接入层
要支持流式输出和长连接
要统一认证、限流、观测、安全和插件扩展
一句话总结 ：
“Higress 是一个基于 Istio 和 Envoy 的云原生 API 网关，它既能做 Kubernetes Ingress，也能做微服务网关和 AI 网关。它最大的特点是支持 Wasm 插件扩展、对流式和长连接场景友好，并且原生支持多模型接入、AI 流控、fallback、缓存和可观测，所以特别适合 AI 应用和云原生业务入口治理场景。”
