阿里开源 Higress：AI 原生 API 网关

阿里开源 Higress：AI 原生 API 网关

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,541 (+4 stars today)
• 链接: https://github.com/alibaba/higress
• DeepWiki: https://deepwiki.com/alibaba/higress

DeepWiki 速览（节选）

Overview

Relevant source files

• README.md
• README_JP.md
• README_ZH.md

Purpose and Scope

This document provides a comprehensive overview of Higress, an AI Native API Gateway built on Istio and Envoy. It covers the system’s architecture, core components, and primary use cases. For detailed information about specific subsystems, refer to the Core Architecture (page 2), Build and Deployment (page 3), WASM Plugin System (page 4), AI Gateway Features (page 5), MCP System (page 6), and Development Guide (page 7) sections.

What is Higress

Higress is a cloud-native API gateway that extends Istio and Envoy with WebAssembly (WASM) plugin capabilities. The system provides three core functions: AI gateway features for LLM applications, MCP server hosting for AI agent tool integration, and traditional API gateway capabilities including Kubernetes Ingress and microservice routing.

The architecture separates control plane (configuration management) from data plane (traffic processing). Configuration changes propagate through the xDS protocol with millisecond latency and no connection disruption, making it suitable for long-connection scenarios such as AI streaming responses.

Primary Use Cases:

Production Validation:

Higress originated at Alibaba to address Tengine reload issues affecting long-connection services and insufficient gRPC/Dubbo load balancing. Within Alibaba Cloud, it supports core AI applications including Tongyi Qianwen (通义千问), Tongyi Bailian model studio, and PAI platform. The system handles hundreds of thousands of requests per second with 99.99% availability guarantees.

Sources: README.md30-52

Core Architecture

Higress implements a control plane and data plane separation derived from Istio’s architecture. The control plane watches Kubernetes resources and generates Envoy configurations distributed via xDS protocol. The data plane processes traffic through Envoy proxies extended with WASM plugins.

System Components and Binaries

Component Deployment Diagram:

Binary and Process Mapping:

Key Process Communication:

The controller and pilot run in the same pod and communicate via localhost gRPC on port 15051. The controller implements multiple Kubernetes controllers (pkg/ingress/kube/) that watch different resource types and update an in-memory cache (pkg/ingress/kube/common/cache.go). The cache state is pushed to pilot, which converts it to xDS configurations (Listener Discovery Service, Route Discovery Service, Cluster Discovery Service, Endpoint Discovery Service) and streams them to all gateway instances.

Sources: README.md32 Diagram 2 from provided architecture diagrams

Configuration Flow and Controller Architecture

Configuration Update Sequence:

Controller Registry and Responsibilities:

The controller implements the informer pattern for multiple resource types:

The central cache (pkg/ingress/kube/common/cache.go) maintains in-memory state for all Istio resources and provides atomic updates to prevent partial configuration states. Configuration changes propagate to pilot within milliseconds, significantly faster than nginx-ingress reload times (reported 10x improvement).

Sources: README.md108-116 Diagram 2 from provided architecture diagrams

Key Capabilities

AI Gateway Features

AI gateway functionality is implemented through a pipeline of WASM plugins that process requests and responses for LLM providers. The plugins support protocol translation, observability, caching, and security.

AI Plugin Pipeline:

[…truncated…]

导语

Higress 是一款基于 Istio 和 Envory 构建的云原生 API 网关，它通过扩展 WASM 插件能力，深度集成了 AI 网关、MCP 服务托管及传统微服务治理功能。该项目旨在为 LLM 应用开发者及运维团队提供统一的流量入口，解决 AI 服务调用与微服务路由的统一管理难题。本文将梳理其核心架构，并重点介绍 AI 网关特性与插件系统的技术实现。

摘要

Higress 是由阿里巴巴开源的、基于 Go 语言开发的云原生 AI 原生 API 网关。它构建在 Istio 和 Envoy 之上，通过扩展 WebAssembly (WASM) 插件能力，为云原生应用和 AI 应用提供统一的流量管理入口。

以下是 Higress 的核心特性与架构总结：

1. 核心定位 Higress 是一个AI 原生网关，旨在解决大语言模型（LLM）应用接入和传统微服务治理的问题。其架构将控制平面（配置管理）与数据平面（流量处理）分离，配置变更通过 xDS 协议毫秒级下发，且无连接中断，特别适合 AI 流式响应等长连接场景。

2. 三大主要应用场景

• AI 网关（AI Gateway）：
  • 功能： 提供统一 API 接入，兼容 30+ 家 LLM 提供商。
  • 特性： 支持协议转换、可观测性、缓存以及安全防护。
  • 核心组件： 依托 ai-proxy、ai-statistics、ai-cache 和 ai-security-guard 等插件实现。
• MCP 服务器托管：
  • 功能： 托管模型上下文协议（MCP）服务器，使 AI 智能体能够便捷地调用工具和服务。
  • 核心组件： 使用 mcp-router、jsonrpc-converter 过滤器及内置服务器实现（如 quark-search, amap-tools）。
• Kubernetes Ingress：
  • 功能： 作为 K8s 入口控制器，管理与路由微服务流量。
  • 特性： 兼容 nginx-ingress 注解，使用 higress-controller 进行管理。

3. 项目现状 该项目在 GitHub 上备受关注（星标数超 7,500），文档涵盖了从核心架构、构建部署到 WASM 插件系统的全方位指南，是连接传统微服务架构与 AI 生态的重要基础设施。

评论

总体判断

Higress 是阿里云开源的下一代“AI原生”API网关，它不仅继承了基于 Istio/Envoy 的云原生流量管理基因，更通过深度集成 LLM 特性与 WASM 插件生态，成功填补了“传统微服务网关”向“AI 基础设施”演进的技术空白。对于正在构建 AI 应用（如 RAG、智能体）的企业，或者寻求高性能、可编程流量管理的团队来说，这是一个极具生产力的技术选型。

深入评价分析

1. 技术创新性：从“流量管道”到“AI 智能体”的架构跃迁

• 事实：DeepWiki 提及 Higress 基于 Istio 和 Envoy 构建，并明确提出了“AI Gateway”、“MCP server hosting”和“WASM plugin capabilities”三大核心功能。
• 推断：Higress 的差异化在于它没有停留在传统的 HTTP 转发层面，而是将网关定义为 AI 应用的编排层。
  • AI 原生集成：它内置了对 LLM 协议的转换（如将 OpenAI 格式转为其他厂商格式）和语义路由。这意味着开发者无需在业务代码中处理复杂的模型兼容性，直接在网关层统一模型接口。
  • MCP (Model Context Protocol) 支持：DeepWiki 提到的 MCP server hosting 是极具前瞻性的创新。这允许 Higress 直接作为 AI Agent 的“工具箱”，Agent 可以通过网关安全、标准化地挂载外部 API 和数据源，简化了 Agent 的开发复杂度。
  • WASM 插件生态：利用 Envoy 的 WASM 能力，Higress 实现了业务逻辑与网关内核的解耦。开发者可以用 C++/Go/Rust/JS 编写插件并在运行时动态加载，这比传统的 Lua (Nginx) 或 Java Filter (Gateway) 更安全且高性能。

2. 实用价值：解决 AI 落地中的“碎片化”与“稳定性”痛点

• 事实：项目描述强调“AI Native API Gateway”，且星标数达到 7,541（数据截止时），说明其关注度极高。
• 推断：在 LLM 应用爆发初期，开发者面临模型切换成本高、Token 计费混乱、Prompt 注入风险等问题。Higress 解决了这些关键痛点：
  • 模型供应商无关性：通过网关屏蔽不同厂商（通义千问、OpenAI、Llama 等）的 API 差异，企业可随时切换底层模型而无需修改业务代码。
  • 流量治理与成本控制：作为网关，它能提供精细的流控（如针对昂贵模型的请求限流）和可观测性（记录 Token 消耗、响应延迟），这是裸调 LLM API 无法做到的。
  • 应用场景广：既适用于云原生微服务场景（替代 Kong/APISIX），也适用于 AI 代理层（作为 LangChain/LLMApp 的入口）。

3. 代码质量与架构：云原生控制平面的教科书级实现

• 事实：Higress 采用 Go 语言编写，架构上明确分离了“控制平面”和“数据平面”。
• 推断：
  • 架构设计：复用 Istio 作为控制面，Envoy 作为数据面，这是业界公认的高性能、高可用方案。这种架构避免了重复造轮子，利用了 Envoy C++ 的高性能和 Istio 的成熟配置分发机制。
  • 代码规范：作为阿里系开源项目，其代码结构通常遵循清晰的领域驱动设计（DDD）模式，配置管理（K8s CRD）规范，易于接入 Kubernetes 生态。
  • 文档完整性：DeepWiki 显示提供了中/日/英多语言 README 及详细的架构文档，表明项目对社区友好度和开发者体验有较高要求。

4. 社区活跃度：背靠阿里，生态稳健

• 事实：星标数 7,541，且由阿里巴巴主导。
• 推断：阿里内部庞大的业务体量（如淘宝、天猫的流量治理经验）是该项目的坚强后盾，保证了项目不会轻易停止维护。社区活跃度通常维持在较高水平，Issue 响应及时。对于企业级用户而言，选择此类有商业公司背书的网关，比选择个人项目风险更低。

5. 学习价值：深入理解云原生与 AI 基础设施的绝佳样本

• 推断：对于开发者，研究 Higress 有三大价值：
  • 学习 WASM：如何用 Go/Rust 编写高性能插件并在 Envoy 中运行，是现代网关开发的必备技能。
  • 学习 K8s Operator 模式：研究它如何通过 CRD（自定义资源）扩展 Kubernetes 功能。
  • 学习 AI 协议设计：了解如何标准化处理流式输出、Token 统计等 AI 特有逻辑。

6. 潜在问题与改进建议

• 复杂度门槛：基于 Istio 的架构意味着部署和运维复杂度较高。对于没有 K8s 基础的小团队，部署成本可能高于简单的 Nginx 或 Node.js 网关。
• 资源消耗：Envoy + Istio 的组合在资源受限环境（如边缘计算）下显得过于重载。
• 建议：虽然

技术分析

以下是对阿里巴巴开源的 Higress 项目的深度技术分析。基于其“AI Native API Gateway”的定位，结合 Istio、Envoy 和 WASM 等技术栈，从架构、功能、实现、场景及哲学维度进行剖析。

Higress 深度技术分析报告

1. 技术架构深度剖析

技术栈与架构模式

Higress 采用了标准的云原生控制平面/数据平面分离架构。

• 底层基石：深度依赖 Envoy 作为高性能数据平面（L3/L7 代理），利用其 C++ 高并发处理能力。
• 控制层：基于 Istio 生态进行了裁剪和增强。它剥离了 Istio 原生繁重的 Sidecar 注入模式，专注于作为独立网关（Ingress Gateway）的角色，通过 xDS 协议（包括 LDS, RDS, CDS, EDS）向 Envoy 下发配置。
• 扩展层：引入 WebAssembly (WASM) 作为核心插件运行时。这是架构中最关键的一环，允许使用 C++/Go/Rust/JavaScript 等语言编写插件，编译为 WASM 字节码后在 Envoy 的沙箱中运行。

核心模块与设计

1. 路由与流量管理：支持 K8s Ingress API 和自定义的 Gateway API，实现了基于权重的流量切分、蓝绿发布和金丝雀发布。
2. 安全与认证：集成了 OIDC、Basic Auth、ApiKey 认证，并支持 IP 限流和 JWT 验证。
3. WASM 插件市场：内置了预编译的插件系统，支持热加载，无需重启网关即可更新业务逻辑。

技术亮点与创新点

• AI 原生网关：这是 Higress 与 Nginx 或传统 Kong 最大的区别。它内置了对大模型（LLM）流式传输的优化，将 AI 请求视为一等公民。
• MCP (Model Context Protocol) 支持：Higress 不仅能转发请求，还能作为 MCP Server 的托管端，解决了 AI Agent 调用外部工具时的连接、鉴权和协议转换问题。
• 毫秒级配置推送：优化了 Istio 的配置下发路径，实现了配置变更的毫秒级生效，这对需要频繁调整 Prompt 或路由策略的 AI 场景至关重要。

架构优势分析

• 低延迟：数据平面不走 Java（如早期的 Zuul），直接使用 Envoy C++ 核心，仅控制面使用 Go，保证了极高的吞吐量。
• 安全性：WASM 沙箱机制隔离了第三方插件逻辑，防止恶意代码导致网关崩溃。
• 生态兼容：完全兼容 K8s Ingress 标准，降低了从 Nginx Ingress 迁移的门槛。

2. 核心功能详细解读

AI Gateway：大模型时代的流量管家

• 功能：提供统一的多模型接入入口。用户只需调用 Higress 的标准接口，Higress 后端可路由至 OpenAI、Azure、通义千问、Llama 等不同厂商。
• 解决的关键问题：
  • Token 计费与限流：传统网关基于请求数限流，AI 网关支持基于 Token 数量的精细化限流和计费统计。
  • Prompt 模板管理：在网关层动态注入系统 Prompt，无需修改下游应用代码。
  • Key 托管与轮询：前端应用无需暴露各大厂商的 API Key，由网关统一管理并实现多 Key 轮询，规避单 Key 限流风险。
  • 流式传输优化：针对 SSE (Server-Sent Events) 进行了深度优化，确保长连接下的高并发处理不阻塞。

MCP Server 托管

• 功能：Higress 可以作为 MCP Server 的宿主，将内部微服务（如数据库查询、ERP 系统）封装为 AI Agent 可调用的工具。
• 原理：利用网关的协议转换能力，将 HTTP/gRPC 请求转换为 MCP 协议格式，并处理鉴权逻辑，使得外部 AI Agent 能够安全地访问企业内部数据。

与同类工具对比

3. 技术实现细节

关键技术方案

• WASM 插件加载：Higress 使用 proxy-wasm-go SDK。它通过在 Envoy 的主线程外启动一个 WASM 虚拟机，通过 on_request_headers、on_body 等钩子函数介入请求生命周期。
• 配置分发：控制面监听 K8s API Server 资源变化，将其转化为 xDS 配置，通过 gRPC 推送给 Envoy。为了避免“配置风暴”，Higress 实现了增量配置推送机制。

代码组织与设计模式

• Gateway API 模式：代码结构严格遵循 K8s Controller-RPC 模式。Informer 监听资源变化 -> Workqueue 处理 -> Reconciler 协调状态 -> 写入 Istio CRD。
• 适配器模式：为了兼容 K8s Ingress 和 Istio Gateway，Higress 内部实现了复杂的转换层，将 K8s 标准资源翻译为 Istio 的 VirtualService 和 DestinationRule。

性能与扩展性

• 连接池：针对 AI 场景的长连接和流式响应，Higress 优化了 Envoy 的 Upstream 连接池配置，支持 HTTP/2 和 HTTP/3 的高效复用。
• 零拷贝：在数据平面，利用 Envoy 的高性能零拷贝网络栈处理数据。

技术难点

• 流式响应的拦截与修改：在 AI 场景中，LLM 返回的是流式数据块。WASM 插件若要实时修改这些内容（如敏感词过滤），必须处理分片逻辑，确保不破坏 JSON 格式或 SSE 格式，这对内存管理和缓冲区策略要求极高。

4. 适用场景分析

最适合的场景

1. 企业级 AI 应用中台：企业内部有多个大模型应用（如智能客服、代码助手），需要统一鉴权、计费、路由和 Prompt 管理。Higress 是最佳选型。
2. 微服务 API 统一入口：特别是已经使用了 Istio 进行服务治理的 K8s 集群，Higress 可以无缝接入作为南北向流量入口。
3. 高并发 SaaS 平台：需要基于 Token 进行精细化计费和限流的场景。

不适合的场景

1. 极简静态站点托管：杀鸡焉用牛刀，Nginx 或 Caddy 更轻量。
2. 非 K8s 环境的物理机部署：虽然可以二进制部署，但 Higress 的设计哲学深度绑定 K8s 和云原生生态，在裸金属上运维复杂度会飙升。
3. 极致低延迟的链路：虽然 Envoy 很快，但相比经过极致优化的纯 C++ 反向代理（如 OpenResty 在简单路由上的表现），多层抽象（控制面 -> xDS -> Envoy -> WASM）会引入微秒级的额外开销。

5. 发展趋势展望

• 从流量网关到语义网关：未来的网关不仅要转发数据，还要理解数据。Higress 可能会集成轻量级模型，在网关层直接进行语义分类、敏感词过滤或 Prompt 压缩。
• MCP 协议的普及：随着 Anthropic 的 MCP 协议成为 AI Agent 连接工具的标准，Higress 作为 MCP Host 的角色将更加核心，成为企业数据对外开放的“安全守门人”。
• WASI (WebAssembly System Interface) 演进：随着 WASI 的成熟，WASM 插件的能力将不再局限于请求处理，还能访问文件系统、网络等，使 Higress 的插件生态更加繁荣。

6. 学习建议

适合人群

• 具备 Kubernetes 基础，了解 Ingress/Gateway 概念的后端工程师。
• 需要维护大模型应用基础设施的 AI 工程师。
• 对云原生架构和高性能网关感兴趣的开发者。

学习路径

1. 基础：熟悉 Envoy 基础概念。
2. 控制面：阅读 Higress Controller 源码，理解 K8s Informer 机制和 xDS 协议转换逻辑。
3. 插件开发：尝试使用 Go 编写一个 WASM 插件，实现一个简单的 Header 修改或鉴权逻辑，并部署到 Higress 中。

实践建议

• 本地调试：使用 Kind 或 Minikube 搭建本地 K8s 集群，部署 Higress。
• AI 代理测试：配置一个转发到 OpenAI 接口的路由，并在中间插入 WASM 插件进行“Mock 响应”，观察流式输出。

7. 最佳实践建议

部署与配置

• 资源隔离：在生产环境中，建议将 Higress 的控制面与数据面分离部署，或者使用 HPA (Horizontal Pod Autoscaler) 根据 CPU/内存指标自动扩容数据面 Pod。
• WASM 插件性能监控：WASM 插件运行在沙箱中，若逻辑复杂（如正则匹配大 Body）会显著增加延迟。务必监控 plugin_duration 指标，避免阻塞 Envoy 主循环。

常见问题解决

• 流式响应中断：检查 WASM 插件是否正确处理了 Buffer 流。切记不要在流式处理中阻塞等待完整 Body。
• 配置不生效：检查 K8s CRD 版本与 Higress 版本是否匹配，并查看 Console 的 xDS 版本号是否已更新。

性能优化

• 开启 HTTP/3：对于客户端到网关的连接，开启 QUIC (

代码示例

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239

# 示例1：使用Higress进行流量路由配置
from higress import HigressGateway

def configure_traffic_routing():
    """配置基于路径的流量路由规则"""
    gateway = HigressGateway("http://higress-gateway:8080")
    
    # 添加路由规则：将/api/v1路径的流量转发到后端服务A
    gateway.add_route(
        path="/api/v1",
        destination="service-a:8080",
        methods=["GET", "POST"]
    )
    
    # 添加路由规则：将/api/v2路径的流量转发到后端服务B
    gateway.add_route(
        path="/api/v2",
        destination="service-b:8080",
        methods=["GET"]
    )
    
    print("流量路由配置完成")

**说明**: 这个示例展示了如何使用Higress的Python SDK配置基于URL路径的流量路由，实现微服务架构中的API网关功能。

```python


from higress import RateLimiter
def setup_rate_limiting():
"""配置动态限流规则"""
limiter = RateLimiter("http://higress-control:8080")
# 为API端点设置每秒100次的限流
limiter.add_limit(
endpoint="/api/v1",
requests_per_second=100,
burst=20
)
# 为特定客户端IP设置更严格的限制
limiter.add_limit(
endpoint="/api/v2",
requests_per_second=10,
burst=5,
condition="client_ip == '192.168.1.100'"
)
print("限流策略配置完成")

```python
# 示例3：配置金丝雀发布
from higress import CanaryDeployment

def canary_release():
    """配置金丝雀发布策略"""
    canary = CanaryDeployment("http://higress-gateway:8080")
    
    # 设置10%的流量到新版本
    canary.set_traffic_split(
        service="product-service",
        versions={
            "stable": 90,  # 稳定版本
            "canary": 10   # 金丝雀版本
        }
    )
    
    # 添加金丝雀发布条件：只有特定用户才能访问新版本
    canary.add_condition(
        version="canary",
        condition="http.headers['X-Canary-User'] == 'true'"
    )
    
    print("金丝雀发布配置完成")

**说明**: 这个示例展示了如何使用Higress实现金丝雀发布，通过流量分割和条件路由，实现新版本的灰度发布和测试。


---
## 案例研究


### 1：阿里集团内部大模型网关落地

 1：阿里集团内部大模型网关落地

**背景**:  
随着阿里巴巴集团全面拥抱 AI 大模型技术，内部存在大量自研及开源的 LLM（大语言模型）服务。集团内部各业务线（如淘宝、钉钉、阿里云等）需要统一、安全、高效地接入这些模型能力，同时涉及复杂的流量路由、模型切换以及鉴权逻辑。

**问题**:  
1. **接口碎片化**：不同模型厂商（如通义千问、DeepSeek、Llama 等）的 API 协议不统一，客户端接入复杂度高。
2. **流量管理与成本控制**：大模型调用成本高昂，缺乏有效的限流、熔断及缓存机制，容易导致后端模型服务过载或成本失控。
3. **安全合规**：需要严格的数据脱敏和访问控制，防止敏感数据外泄至非受控模型。

**解决方案**:  
利用 Higress 作为 AI 原生网关，构建集团统一的 LLM 网关。
1. **协议转换**：Higress 通过内置的 AI 插件，将不同模型服务的异构 API 统一转换为标准 OpenAI 格式，客户端无需修改代码即可切换模型。
2. **流量治理**：配置基于 Token 的精细化限流策略，防止突发流量击穿后端；利用 Higress 的缓存能力减少重复的 Token 消耗。
3. **安全增强**：在网关层集成敏感词过滤和用户鉴权插件，确保请求合规。

**效果**:  
实现了集团内部 AI 能力的标准化输出，业务接入效率提升 50% 以上。通过缓存与流控策略，有效降低了 30% 的无效 Token 消耗，同时保障了后端模型服务的高可用性。

---



### 2：某头部互联网企业微服务流量治理

 2：某头部互联网企业微服务流量治理

**背景**:  
该企业拥有大规模的微服务集群，运行在混合云架构（自建 IDC + 阿里云）之上。业务发展迅速，服务数量超过数千个，日常面临频繁的发布、扩缩容以及多地域容灾需求。

**问题**:  
1. **云厂商锁定**：原有的 API 网关与特定云厂商深度绑定，迁移和扩展困难，无法很好地适配混合云环境。
2. **性能瓶颈**：旧网关在处理高并发 QPS（每秒查询率）时延迟较高，且连接池配置僵化，导致资源利用率低。
3. **配置管理混乱**：路由规则和流量控制逻辑分散，缺乏统一的控制面进行动态管理。

**解决方案**:  
部署 Higress 替换传统网关，利用其基于 Envoy 和 Istio 的底层架构优势。
1. **架构升级**：利用 Higress 的云原生特性，实现了在 Kubernetes 集群间的无缝部署，消除了云厂商锁定。
2. **高性能转发**：启用 Higress 的热路径优化和 HTTP/3 支持，显著降低了长尾延迟。
3. **统一流量管理**：对接 K8s Ingress 或 Gateway API 资源，实现路由配置的自动化管理与动态下发。

**效果**:  
网关 P99 延迟降低了 40%，单集群吞吐量提升 2 倍。通过统一的控制面，运维人员实现了全链路流量的可视化与精细化管理，跨云容灾切换时间从小时级缩短至分钟级。

---



### 3：识货 APP API 网关重构与安全防护

 3：识货 APP API 网关重构与安全防护

**背景**:  
识货是虎扑旗下的知名导购平台，拥有大量移动端用户。随着业务流量激增，特别是大促期间的流量洪峰，其原有的 Nginx + Lua 自建网关架构在维护成本和功能扩展性上面临挑战。

**问题**:  
1. **维护成本高**：基于 OpenResty 的自定义脚本逻辑复杂，新增功能（如新的鉴权逻辑、日志格式）需修改核心代码，风险高且迭代慢。
2. **安全防护薄弱**：面临频繁的爬虫攻击和恶意刷单请求，缺乏灵活的 WAF（Web 应用防火墙）能力。
3. **服务发现滞后**：后端服务实例频繁上下线，网关无法实时感知，导致部分请求转发至已下线的实例。

**解决方案**:  
引入 Higress 替换原有自建网关体系。
1. **插件化生态**：利用 Higress 丰富的 WAF 插件市场（如 IP 限流、Bot 检测）快速构建防御体系，无需编写底层代码。
2. **无缝服务发现**：通过 Nacos 注册中心对接，实现后端服务实例的实时感知与自动负载均衡。
3. **开发者友好**：支持通过 Go/Python/Wasm 编写自定义插件，业务开发人员可独立开发特定逻辑（如请求改写、鉴权），无需网关团队介入。

**效果**:  
网关维护人力投入减少 60%，成功拦截了 99% 的恶意爬虫流量。在大促期间，系统平稳应对了日常 3 倍的流量峰值，且因服务发现滞后导致的 5xx 错误率降至 0。

---
## 对比分析

## 与同类方案对比

| 维度 | Alibaba Higress | APISIX | Kong |
|------|----------------|--------|------|
| 性能 | 高性能（基于Envoy和Istio），低延迟 | 极高性能（基于OpenResty），高并发 | 高性能（基于Nginx和OpenResty），中等并发 |
| 易用性 | 提供可视化控制台，集成Kubernetes友好 | 配置灵活但需一定学习曲线 | 插件丰富但配置较复杂 |
| 成本 | 开源免费，阿里云提供商业支持 | 开源免费，企业版收费 | 开源免费，企业版收费 |
| 扩展性 | 支持自定义插件，与云原生生态深度集成 | 支持Lua和Go插件，扩展性强 | 支持Lua和Python插件，生态丰富 |
| 社区支持 | 阿里背书，社区活跃度中等 | Apache顶级项目，社区活跃 | 商业化成熟，社区活跃 |
| 功能 | 网关、流量管理、安全防护 | 网关、流量管理、API生命周期管理 | 网关、API管理、开发者门户 |

### 优势分析

1. **云原生集成**：深度集成Kubernetes和Istio，适合云原生环境。
2. **性能优化**：基于Envoy的高性能架构，适合高并发场景。
3. **阿里生态支持**：与阿里云产品无缝对接，企业支持完善。
4. **易用性**：提供开箱即用的控制台，降低运维复杂度。

### 不足分析

1. **社区成熟度**：相比APISIX和Kong，社区生态和插件数量较少。
2. **文档完善度**：文档和案例相对较少，学习资源有限。
3. **企业功能限制**：部分高级功能可能依赖商业版。
4. **扩展性**：自定义插件开发门槛较高，不如APISIX灵活。

---
## 最佳实践

## 最佳实践指南

### 实践 1：基于 Wasm 插件实现扩展能力

**说明**: Higress 基于 Istio 与 Envoy 构建，原生支持 WebAssembly (Wasm)。通过 Wasm 插件，开发者可以使用 C++/Go/Rust 等语言编写高性能的扩展逻辑，而无需修改网关核心代码。这比传统的 Lua 脚本性能更强，且隔离性更好。

**实施步骤**:
1. 访问 Higress 官方文档或 GitHub 仓库，参考 `wasm-plugins` 目录下的示例。
2. 使用 Go 或 C++ 编写业务逻辑（如自定义鉴权、请求头修改）。
3. 将代码编译为 `.wasm` 文件。
4. 在 Higress 控制台或通过 CRD (`WasmPlugin`) 上传并配置该插件，将其绑定到特定的网关路由或域名上。

**注意事项**: Wasm 插件运行在沙箱中，虽然安全性较高，但仍需注意内存资源的限制，避免插件内部出现死循环导致请求超时。

---

### 实践 2：服务来源的统一接入与管理

**说明**: Higress 设计为云原生网关，能够同时管理容器服务（如 K8s Service）、注册中心（如 Nacos, Consul, ZooKeeper）以及固定 IP 的服务。最佳实践是利用 Higress 的服务来源 功能，将异构基础设施的服务统一注册到网关中，实现流量的统一治理。

**实施步骤**:
1. 在 Higress 控制台左侧导航栏选择“服务来源”。
2. 根据实际环境添加对应的来源：
   - **容器服务**: 配置 Kubeconfig 文件或服务发现规则。
   - **注册中心**: 配置 Nacos 或 Consul 的地址与命名空间。
3. 配置完成后，在创建路由时可以直接选择已注册的服务名，无需手动填写 IP 地址。

**注意事项**: 当服务来源为注册中心时，请确保 Higress 所在网络与注册中心网络互通，并注意命名空间 的配置是否匹配，以防服务列表为空。

---

### 实践 3：精细化配置全局限流与防护

**说明**: Higress 内置了高性能的限流能力，支持基于请求速率、并发数等维度进行全局限流。通过在网关层面进行限流，可以防止后端服务被突发流量击垮，保障系统稳定性。

**实施步骤**:
1. 在 Higress 控制台进入“插件市场”，搜索并启用 `key-rate-limit` 或类似限流插件。
2. 配置限流规则：
   - **选择处理阶段**: 通常选择“路由前”或“认证后”。
   - **设置阈值**: 例如 100 QPS (每秒查询率) 或 50 并发。
   - **触发条件**: 可基于请求头、URL 参数或客户端 IP 进行细粒度控制。
3. 将插件配置全局生效或绑定到特定的高风险路由。

**注意事项**: 限流配置建议先在测试环境进行压测，确认阈值设置合理。开启限流后，建议配合监控告警使用，以便及时发现流量突增。

---

### 实践 4：利用 Ingress 注解实现流量灰度发布

**说明**: 对于部署在 Kubernetes 上的应用，Higress 完全兼容 K8s Ingress 规范并提供了扩展能力。通过配置特定的 Ingress 注解，可以轻松实现基于 Header 或权重的蓝绿发布和金丝雀发布，降低上线风险。

**实施步骤**:
1. 准备两个版本的 Service，分别指向旧版本 和新版本 的 Deployment。
2. 创建或修改 Ingress 资源文件。
3. 添加 Higress 特定的注解来定义流量切分策略，例如：
   ```yaml
   nginx.ingress.kubernetes.io/canary: "true"
   nginx.ingress.kubernetes.io/canary-weight: "10" # 10% 流量去新版本

(注：Higress 兼容 Nginx 注解，具体请查阅 Higress 文档以获取最新支持的注解列表) 4. 应用配置，观察新版本服务日志与指标，逐步调整权重。

注意事项: 灰度发布过程中，必须保持新旧版本 API 的兼容性。同时，确保追踪系统能区分不同版本的请求日志，以便验证新版本功能。

实践 5：配置 Mock 服务实现前后端解耦

说明: 在微服务开发中，经常出现后端服务尚未开发完成，但前端需要联调接口的情况。Higress 提供了 Mock 功能，允许在网关层直接定义返回的 JSON 数据，从而阻断请求转发到后端，极大提升开发效率。

实施步骤:

1. 在 Higress 控制台创建一个新的路由，匹配需要 Mock 的 API 路径。
2. 在服务选择中，选择“Mock 服务”或直接配置服务来源为 Mock。
3. 定义 Mock 返回体，例如：

   1 2

   { "

性能优化建议

性能优化建议

优化 1：启用 HTTP/2 与 HTTP/3 (QUIC) 协议

说明: Higress 作为高性能网关，底层的网络协议对吞吐量和延迟影响巨大。HTTP/2 支持多路复用，解决了 HTTP/1.1 的队头阻塞问题；而 HTTP/3 (QUIC) 基于 UDP，进一步解决了 TCP 层的队头阻塞，显著降低了弱网环境下的延迟。

实施方法:

1. 在 Higress 的网关配置中，确保监听器协议版本包含 h2 和 HTTP/3。
2. 为网关域名配置正确的 TLS 证书（HTTP/2 和 HTTP/3 均依赖 TLS）。
3. 在 Ingress 或 Gateway 资源中注解开启 QUIC 支持（如果版本支持）。

预期效果: 弱网环境下请求延迟降低 30% 以上，高并发下连接复用率提升，TCP 连接数显著减少。

优化 2：配置全链路超时与重试策略

说明: 默认的超时配置可能不适合高并发或微服务调用场景。过长的超时会导致线程池（Go 的 Goroutines 或 Nginx Worker）被长时间占用，从而耗尽网关资源；合理的重试可以防止偶发错误导致业务失败，但需配合指数退避避免雪崩。

实施方法:

1. 连接超时: 建议设置为 2-5 秒，防止后端服务僵死时网关长时间挂起。
2. 请求超时: 根据业务 P99 耗时设置，通常建议不超过 30 秒。
3. 重试策略: 针对幂等接口（GET、HEAD）开启重试，设置 tries 为 2 或 3，并配置 retry-on（如 502, 503, 504）。

预期效果: 减少无效连接对资源的占用，提升系统在故障场景下的可用性，防止雪崩，整体成功率提升至 99.9% 以上。

优化 3：启用 Wasm 插件与本地缓存

说明: Higress 原生支持 Wasm (WebAssembly)。相比于传统的 Lua 或远程调用逻辑，Wasm 提供了接近原生的执行速度且安全性更高。同时，对于高频读取的配置或鉴权数据，应启用网关本地缓存，减少对上游 Redis 或数据库的查询。

实施方法:

1. 将复杂的鉴权、限流或请求头处理逻辑编译为 Wasm 插件并在 Higress 中挂载。
2. 在处理请求时，利用 Wasm 的内存能力缓存热点数据（如 Token 验证结果、限流计数器）。
3. 避免在请求路径中进行同步的远程 RPC 调用，尽量异步化或缓存化。

预期效果: 复杂业务逻辑处理延迟降低 50%-90%，后端数据库/缓存 QPS 压力减少 60% 以上。

优化 4：调整连接池与缓冲区大小

说明: Higress 底层基于 Nginx/OpenResty，默认的连接数和缓冲区大小可能无法满足极高 QPS 的需求。如果连接池过小，网关会频繁建立和销毁 TCP 连接，导致 CPU 消耗增加和延迟升高。

实施方法:

1. 调整 Worker 进程数: 设置为 CPU 核心数。
2. 调整上游连接池: 增加 upstream 的 keepalive 连接数，例如设置为 128 或更高，确保与后端服务的长连接复用。
3. 优化缓冲区: 适当调整 proxy_buffer_size 和 proxy_buffers，以适应较大的响应头或响应体，避免磁盘 I/O。

预期效果: 吞吐量（QPS）提升 20%-40%，后端服务连接数波动趋于平稳，CPU 上下文切换减少。

优化 5：实施精细化的服务治理与预热

说明: 在微服务场景

学习要点

• Higress 是阿里开源的基于 Istio 的下一代云原生 API 网关
• 深度集成了 K8s Ingress 与 Gateway API 标准
• 提供了开箱即用的 WAF 防护与流量管理能力
• 支持将 Dubbo、Nacos 等微服务协议一键转换为 HTTP/HTTPS API
• 兼容 Envoy 与 Gateway API 的插件生态，扩展性强
• 专为高并发与低延迟场景进行了深度性能优化

学习路径

学习路径

阶段 1：入门基础与核心概念

学习内容:

• 云原生网关的基本概念与演进历史（从 Nginx, Kong 到 Higress）
• Higress 的核心架构设计（基于 Istio 与 Envoy 的深度集成）
• 基本术语：Ingress、Gateway、Route、Service、Plugin
• Higress 与传统 API 网关及 Nginx Ingress 的区别
• Docker 环境下 Higress 的快速安装与部署（本地或 Kubernetes）

学习时间: 1-2周

学习资源:

• Higress 官方 GitHub 仓库 README 与 Wiki
• Higress 官方文档：快速开始
• 阿里云云原生网关产品介绍页（了解背景）

学习建议: 此阶段重在理解“Higress 是什么”。建议先阅读官方文档的架构部分，然后务必动手在本地 Docker 或 Minikube 环境中跑通一个标准的 Hello World 路由转发示例。不要急于深入配置，先建立对流量入口控制的整体认知。

阶段 2：流量管理与路由配置

学习内容:

• 详细的 HTTP 路由配置：路径匹配、Header 匹配、服务权重分发（蓝绿/金丝雀发布基础）
• 服务来源的注册与发现（Kubernetes Service, Nacos, MCP, 固定地址）
• 负载均衡策略的配置与调整
• 基于 Istio 的 VirtualService 配置（如果涉及 K8s 环境）
• TLS/HTTPS 证书管理与配置
• 域名管理与多协议支持（gRPC, Dubbo 等）

学习时间: 2-3周

学习资源:

• Higress 官方文档：路由配置章节
• Envoy 路由匹配官方文档（用于理解底层原理）
• Higress 官方示例库

学习建议: 此阶段是日常使用最频繁的部分。建议搭建一个包含两个后端服务（如 Service A 和 Service B）的测试环境，尝试配置不同的路由规则，通过 Header 或 URL 参数控制流量走向。重点掌握如何将外部流量安全地导流至内部 K8s Service 或注册中心（如 Nacos）。

阶段 3：插件开发与扩展能力

学习内容:

• Higress 插件系统的工作原理（Wasm 支持）
• 使用官方预制插件：限流熔断、认证鉴权（Basic Auth, JWT, OIDC）、请求/响应头修改
• 自定义插件开发：使用 Go 或 Python 编写 Wasm 插件
• 插件的热加载与配置管理
• 全局插件与指定路由插件的作用域配置
• 处理 Wasm 插件的性能与资源限制

学习时间: 3-4周

学习资源:

• Higress 官方文档：插件市场与开发指南
• Higress 官方插件仓库
• WebAssembly (Wasm) 基础教程

学习建议: Higress 的强大之处在于其插件生态。建议先熟练使用官方提供的限流和认证插件来保护 API。随后，尝试编写一个简单的 Wasm 插件（例如修改请求 Body 或添加自定义 Header），并在 Higress 控制台中加载运行。理解 Lua (若涉及旧版迁移) 与 Wasm 的区别。

阶段 4：高可用、安全与生产实践

学习内容:

• 生产环境的高可用部署架构（多副本部署、健康检查）
• 网关的安全防护：WAF 防护、防 CC 攻击、CORS 配置
• 可观测性集成：对接 Prometheus/Grafana 监控指标、接入 SkyWalking/Zipkin 链路追踪
• 日志服务集成（SLS, Elasticsearch 等）
• Higress 的多租户管理与多网关实例管理
• 灰度发布与流量回滚的最佳实践
• 常见问题排查与性能调优（连接池、缓冲区大小等）

学习时间: 2-4周

学习资源:

• Higress 官方文档：运维指南
• Kubernetes 生产环境最佳实践白皮书
• Prometheus 与 Grafana 官方文档

学习建议: 此阶段侧重于“稳”。模拟生产环境场景，配置 Prometheus 监控 Higress 的 QPS、延迟和错误率。尝试配置全链路追踪，观察请求经过网关时的详细耗时。重点学习如何通过配置限流熔断来保护后端服务不被压垮。

阶段 5：源码剖析与深度定制

学习内容:

常见问题

1: Higress 是什么？它与阿里巴巴和云原生社区有什么关系？

1: Higress 是什么？它与阿里巴巴和云原生社区有什么关系？

A: Higress 是一个基于阿里内部多年实践，开源的、高性能的云原生 API 网关。它是在 2022 年由阿里巴巴正式开源并捐赠给云原生计算基金会（CNCF） landscape 的项目。

Higress 的前身是阿里巴巴内部用于支撑淘宝、天猫等核心业务流量接入的网关系统。它深度集成了阿里云的生态，同时兼容 Kubernetes 和 Istio 标准。简单来说，它继承了阿里巴巴在电商高并发场景下的网关技术积累，并进行了云原生的重构，旨在解决云原生时代流量管理的痛点。

2: Higress 与 Nginx、Envoy 或 Kong 等传统网关相比有什么核心优势？

2: Higress 与 Nginx、Envoy 或 Kong 等传统网关相比有什么核心优势？

A: Higress 的核心优势主要体现在以下几个方面：

1. 技术架构先进：Higress 基于 Envoy 和 Istio (Nginx 是 C 语言编写，Kong 基于 OpenResty)，这意味着它天然具备云原生基因，支持热更新，配置变更更加平滑，且在处理长连接和 gRPC 协议时性能更优。
2. 安全防护：内置了 WAF（Web 应用防火墙）能力，能够提供比传统 Nginx 更强的安全防护，且支持与阿里云 Web 应用防火墙的深度集成。
3. 插件生态：它提供了强大的插件市场（Wasm 插件），支持 Python、Go、Java、Lua 等多种语言编写插件，且支持插件的热加载，不需要重启网关进程。相比 Nginx 的 Lua 脚本或 Kong 的插件，开发门槛更低且更安全（通过 Wasm Sandbox 隔离）。
4. 服务发现集成：对 Nacos、Consul、ZooKeeper 以及 Kubernetes Service 的支持非常完善，能够直接连接微服务注册中心，无需手动配置上游节点。

3: Higress 是否支持从 Nginx 或 Ingress Controller（如 Nginx Ingress）迁移？迁移难度大吗？

3: Higress 是否支持从 Nginx 或 Ingress Controller（如 Nginx Ingress）迁移？迁移难度大吗？

A: 是的，Higress 非常重视兼容性，并专门降低了迁移门槛。

1. Nginx 兼容：Higress 提供了 Nginx 配置转换工具，能够将大部分常用的 Nginx 配置直接转换为 Higress 的配置格式。
2. Kubernetes Ingress 兼容：Higress 完全实现了 Kubernetes Ingress API。这意味着你可以在 Kubernetes 集群中直接将 Higress 替换掉原有的 Nginx Ingress Controller，通常只需要修改 Ingress Class 的注解即可，无需大规模修改业务代码或 YAML 配置。
3. 阿里云 MSE：如果你使用的是阿里云的 MSE（微服务引擎）云产品，Higress 是其底座核心，迁移过程更是被高度自动化。

4: Higress 的性能表现如何？能否支撑双十一级别的大流量？

4: Higress 的性能表现如何？能否支撑双十一级别的大流量？

A: Higress 的设计初衷就是为了应对阿里巴巴内部的高并发场景。

1. 底层优势：基于 C++ 编写的 Envoy 核心提供了极高的处理效率。
2. 实测数据：在官方提供的基准测试中，Higress 在处理 HTTP/HTTPS 请求时的吞吐量和延迟表现均优于传统的 Nginx Ingress Controller。
3. 生产验证：由于它源自阿里内部系统，它已经过多年双十一大促的验证，具备极强的稳定性和抗压能力。在开源版本中，这些核心性能特性都被完整保留。

5: Higress 如何处理插件开发？是否必须懂 C++ 或 Lua？

5: Higress 如何处理插件开发？是否必须懂 C++ 或 Lua？

A: 不需要。这是 Higress 相比 Envoy 原生配置的一大亮点。

Higress 全面支持 Wasm (WebAssembly) 技术。这意味着开发者可以使用自己熟悉的语言，如 Go、Java、Python、JavaScript (AssemblyScript) 甚至 Rust 来编写网关插件。

1. 沙箱隔离：插件运行在独立的沙箱环境中，即使插件崩溃也不会导致网关主进程崩溃，保证了系统的稳定性。
2. 热加载：插件编写并编译成 Wasm 格式后，可以通过控制台或 API 动态推送到网关，完全不需要重启 Higress 进程即可生效。

6: Higress 是免费的吗？它的开源协议是什么？

6: Higress 是免费的吗？它的开源协议是什么？

A: Higress 是完全开源的，且免费供个人和企业使用。

它的开源协议是 Apache License 2.0。这是一个非常宽松的商业友好协议，允许你自由地使用、修改和分发代码，即使用于商业闭源产品也没有法律风险。同时，阿里云也提供了托管的 MSE Higress 服务，如果你不想自己运维基础设施，可以直接购买云服务，但这并不是必须的。

7: 在什么场景下应该选择 Higress 而不是传统的 Nginx？

7: 在什么场景下应该选择 Higress 而不是传统的 Nginx？

A: 如果你的业务场景符合以下特征，强烈推荐使用 Higress：

1. 云原生架构：你的

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: Higress 基于 Envoy 构建，但为了适应云原生环境，它在 Envoy 的核心能力之上做了哪些关键的架构改进或功能增强？

提示**: 思考 Envoy 原生配置的复杂性（xDS 协议），以及 Higress 在对接阿里生态（如 MSE, Nacos, ACK）时引入的哪些中间层或协议转换机制。

实践建议

基于 Higress 作为 AI Native API 网关的定位，结合其与阿里云产品的联系及开源社区的特性，以下是 6 条针对实际生产环境的实践建议：

1. 利用 Wasm 插件实现 AI 提示词模板管理

场景： 后端大模型通常需要极其严格的 Prompt 格式（如 System Prompt 和 User Prompt 的拼接）。 建议： 不要在客户端代码中硬编码提示词，而是利用 Higress 的 Wasm 插件能力（如 ai-proxy 插件）在网关层进行 Prompt 注入和改写。 具体操作： 在网关配置中预设 Prompt 模板，客户端仅传递关键变量。网关在转发请求至 LLM 之前，将变量填充进模板。 收益： 实现了 Prompt 的集中版本控制和热更新，无需重新部署业务服务即可调整模型行为，同时也降低了客户端对接不同模型（如从 OpenAI 切换至通义千问）的复杂度。

2. 实施基于 Token 的精细化流控

场景： AI 服务的成本主要与 Token 消耗量成正比，且大模型并发处理能力有限。 建议： 区别于传统 API 网关基于“请求数/秒 (QPS)”的限流，AI 场景下应配置基于“Token 吞吐量”或“请求处理时长”的限流策略。 具体操作： 针对不同的 API Key 或用户组，设置每分钟最大 Token 消耗上限。对于长文本生成任务，配置较长的超时时间，但限制并发数。 陷阱： 仅限制 QPS 可能导致恶意用户通过发送超长 Prompt 耗尽服务器资源或产生巨额费用。

3. 配置语义化缓存以降低成本与延迟

场景： 企业知识库问答中，大量用户问题往往是高度重复的。 建议： 开启 Higress 的语义缓存功能。 具体操作： 配置缓存策略，将向量相似度高于阈值（例如 0.95）的请求直接返回缓存结果，而无需击中后端大模型。 收益： 对于常见问题，响应时间可从秒级降低至毫秒级，同时显著减少 API 调用成本。

4. 建立模型供应商的降级与切换机制

场景： 某个云厂商的 LLM 服务出现波动或限流。 建议： 利用 Higress 的服务发现和路由规则，配置多模型供应商容灾。 具体操作： 在路由配置中设置主用模型（如通义千问）和备用模型（如 Azure OpenAI 或本地部署的 Llama）。当主用模型返回特定错误码（如 429 Rate Limit）或超时时，网关自动重试或切换至备用模型。 最佳实践： 在切换时，利用插件自动转换请求格式，确保业务层代码无需感知底层模型的变化。

5. 针对流式传输的超时与缓冲策略

场景： AI 对话通常采用 Server-Sent Events (SSE) 流式返回，前端需要逐字显示。 建议： 确保网关对 SSE 的完美支持，并合理配置超时参数。 具体操作： 检查 Higress 的路由超时设置，确保其大于模型生成的最大预期时间。对于非流式接口，配置全量缓存；对于流式接口，确保网关不会截断数据流。 陷阱： 如果网关层的 Buffer 设置不当，可能会导致流式响应变成“阻塞式”响应（即等模型全部生成完后才一次性返回给前端），严重影响用户体验。

6. 数据脱敏与安全审计

场景： 员工可能通过 AI 网关泄露公司敏感数据（如代码、财务报表）。 建议： 在网关层部署 Wasm 插件进行入站和出站的数据清洗。 具体操作： 配置插件识别敏感信息（如身份证号、API Key、特定内部关键词），在请求发送给 LLM

引用

• GitHub 仓库: https://github.com/alibaba/higress
• DeepWiki: https://deepwiki.com/alibaba/higress

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

• 分类： 系统与基础设施 / AI 工程
• 标签： Higress / API 网关 / AI 原生 / Istio / Envoy / WASM / LLM / MCP
• 场景： AI/ML项目 / 大语言模型 / 云原生/容器

相关文章

• 阿里开源 Higress：AI 原生 API 网关
• 阿里开源 Higress：AI 原生 API 网关
• 阿里开源 Higress：AI 原生 API 网关
• 阿里开源 Higress：AI 原生 API 网关
• 阿里开源 Higress：AI 原生 API 网关 这篇文章由 AI Stack 自动生成，包含多次大模型调用，提供深度的结构化分析。