1) 是什么
Higress 是一款云原生 API 网关，内核基于 Istio 和 Envoy。
它的几个关键标签：
- 云原生 API 网关
- AI 网关（AI Native API Gateway）
- 支持 Wasm 插件扩展
- 兼容 Kubernetes Ingress / Gateway API
- 可作为微服务网关和安全防护网关
Higress 最初在阿里内部诞生，主要为了解决：
- Nginx/Tengine reload 对长连接业务有损
- gRPC / Dubbo 负载均衡能力不足
添加图片注释，不超过 140 字（可选）
从定位上看，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 最有特色的场景。
添加图片注释，不超过 140 字（可选）
适合：
- 同时接多家 LLM 厂商 API
- 需要统一鉴权、流控、审计、可观测
- 需要模型级别路由、负载均衡、fallback
- 需要缓存与成本控制
- 要支撑流式输出
典型例子：
- 企业内部统一大模型接入层
- AI 应用平台
- 多模型代理层
- 面向业务团队提供标准化模型 API 的平台
4.2 Kubernetes Ingress 网关
适合：
- 作为 K8s 集群入口网关
- 现有系统基于 Nginx Ingress，希望平滑迁移
- 希望逐步从 Ingress API 迁移到 Gateway API
- 希望降低资源消耗、提高路由变更生效速度
如果团队已经在 Kubernetes 里大量使用 Ingress，这类场景比较容易落地。
4.3 微服务网关
添加图片注释，不超过 140 字（可选）
适合：
- 有 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 应用和云原生业务入口治理场景。”
