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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,684 (+10 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 是阿里巴巴开源的 AI 原生 API 网关，基于 Istio 与 Envory 构建，通过 WASM 插件实现了高度的可扩展性。它旨在解决大模型应用落地中的流量管理问题，同时兼容传统的微服务网关与 K8s Ingress 场景，并支持 MCP 协议以集成 AI Agent 工具。本文将介绍其核心架构，重点解析 AI 网关特性、MCP 系统以及插件机制，帮助开发者构建稳定高效的 AI 基础设施。

摘要

以下是关于 Higress 的中文总结：

项目概述

Higress 是由阿里云开源的一款云原生 API 网关，基于 Istio 和 Envoy 构建。它定位为AI Native API Gateway（AI 原生 API 网关），旨在通过可扩展的架构支持传统微服务流量管理及新兴的 AI 应用场景。该项目使用 Go 语言编写，目前在 GitHub 上拥有超过 7,600 个星标。

核心特性

Higress 的核心优势在于其控制面与数据面分离的架构。配置变更通过 xDS 协议传播，具备毫秒级延迟且不中断连接，特别适用于 AI 长连接流式响应等场景。其功能主要围绕以下三大核心用途：

1. AI 网关

   • 功能：为大语言模型（LLM）应用提供统一 API。
   • 支持能力：兼容 30+ 家 LLM 提供商，提供协议转换、可观测性、缓存（ai-cache）以及安全防护（ai-security-guard）。

2. MCP 服务器托管

   • 功能：托管模型上下文协议（MCP）服务器，使 AI Agent 能够调用外部工具和服务。
   • 组件：通过 mcp-router 和 jsonrpc-converter 过滤器，集成搜索、地图等工具。

3. Kubernetes 入口

   • 功能：作为 K8s Ingress 控制器使用。
   • 兼容性：完全兼容 Nginx Ingress 注解，便于传统用户迁移。

技术亮点

• WASM 插件系统：基于 WebAssembly 技术，允许用户灵活扩展网关功能。
• 高性能：基于 Envoy 的高性能数据处理能力，支持毫秒级配置推送。

评论

总体判断

Higress 是阿里云开源的、目前云原生网关领域中将AI 原生能力与传统流量治理融合得最为彻底的项目之一。它不仅是一个基于 Istio 和 Envoy 的高性能网关，更通过 WASM 技术和 MCP 协议支持，演变成了连接大模型（LLM）与应用的关键基础设施，兼具技术前瞻性与极高的工程实用价值。

详细评价依据

1. 技术创新性：AI 原生架构与 WASM 的深度结合

• 事实：DeepWiki 明确指出 Higress 是 “AI Native API Gateway”，并基于 Istio/Envoy 扩展了 WebAssembly (WASM) 插件能力。同时，它引入了 MCP (Model Context Protocol) 服务器托管功能。
• 推断：Higress 的最大差异化在于它没有停留在传统的 HTTP 转发，而是将 AI 时代的“协议转换”和“语义处理”内置到了网关层。
  • AI 提示词管理：它允许在网关层直接进行 LLM 的 Prompt 模板管理和变量注入，这意味着后端服务不需要关心如何组装 OpenAI 或通义千问的协议，极大简化了业务代码。
  • MCP 协议支持：作为 AI Agent 的工具层，Higress 能够托管 MCP Server，使得 Agent 可以通过网关安全、标准化地调用外部工具，这是针对 AI Agent 落地非常超前的设计。
  • WASM 插件化：利用 WASM 实现逻辑热加载，使得开发者可以用 C++/Go/Rust/Zig 编写高性能插件，无需重新编译网关二进制，这比传统的 Lua (Nginx) 或 Java Filter 机制更安全、灵活。

2. 实用价值：一站式解决流量与 AI 接入痛点

• 事实：描述中提到它提供 K8s Ingress、微服务路由以及 AI Gateway 功能。
• 推断：在微服务架构向 LLM 落地过渡的当下，企业通常面临两套网关（一套 API 网关，一套 AI 代理）的维护成本。Higress 提供了统一方案：
  • 成本降低：它原生兼容 K8s Ingress 规范和 Nginx 注解，降低了从 Nginx 或传统网关迁移的门槛。
  • AI 特性赋能：提供的 Token 限流、AI 结果缓存（减少 LLM 调用成本）、多模型切换（A/B 测试）等功能，直接击中了 AI 应用开发中“贵”和“慢”的痛点。对于需要将内部服务快速暴露给 AI Agent 调用的企业，其实用价值极高。

3. 代码质量与架构：云原生标准的控制面与数据面分离

• 事实：DeepWiki 提到架构将控制平面（配置管理）与数据平面（流量处理）分离。
• 推断：这种架构是云原生网关的黄金标准。
  • 控制面：通常基于 Istio 进行改良，负责配置下发和服务发现，支持 K8s CRD (Custom Resource Definition)，符合云原生开发者的操作习惯。
  • 数据面：基于 Envoy，保证了底层的高性能和可靠性。
  • 文档完整性：从 DeepWiki 的结构来看（涵盖架构、构建、WASM、AI 特性、MCP 等），项目文档结构清晰，且提供中日英三语 README，显示了阿里云成熟的开源运营规范。Go 语言编写也保证了在云原生生态中的可维护性。

4. 社区活跃度：背靠阿里的企业级开源项目

• 事实：星标数 7,684，语言为 Go。
• 推断：作为阿里巴巴达摩院和阿里云联合开源的项目，Higress 继承了 Higress (内部已大规模使用) 的工业级基因。虽然不如某些纯前端框架活跃，但在基础设施层，其更新频率通常紧跟 K8s/Istio 版本和 AI 模型迭代（如 GPT-4o 支持）。社区讨论多集中在 AI 插件开发和 K8s 落地实践上，贡献者除了阿里员工，也有不少关注 AI 边际能力的开发者。

5. 学习价值与对比优势

• 对比同类工具：
  • vs. Nginx/APISIX：Higress 的控制面更现代化，深度集成了 K8s，且 AI 原生功能（如 Prompt 模板、MCP）是传统网关不具备的。
  • vs. Kong：Kong 虽然也有 AI 插件，但 Higress 基于 Envoy 的资源隔离和 WASM 的沙箱安全性在多租户场景下更具优势。
  • vs. LangChain：LangChain 是开发框架，Higress 是基础设施。Higress 可以作为 LangChain 服务的流量入口，处理认证、限流和模型路由。
• 学习价值：开发者可以从中学习如何基于 Envoy 构建扩展性极强的网关系统，以及如何设计适配 AI 时代的 API 协议（如 SSE 流式处理在网关层的缓冲与转发）。

6. 潜在问题

• 复杂性：引入了 Istio 和 Envoy 的概念，对于只有传统 Nginx 经验的团队，运维

技术分析

以下是对阿里巴巴开源的 Higress 项目的深度技术分析。基于其定位为“AI Native API Gateway”，我们将从传统网关与AI网关结合的视角进行剖析。

Higress 深度技术分析报告

1. 技术架构深度剖析

Higress 的架构设计体现了**“深度的云原生融合”与“AI 优先的流量编排”**。

技术栈与架构模式

• 底层基石: 基于Envoy作为高性能数据平面，利用其L4/L7处理能力和可观测性。
• 控制平面: 深度集成 Istio。Higress 并没有重新发明控制平面，而是将 Istio 的控制能力下沉并针对网关场景进行了裁剪和优化。它复用了 Istio 的 xDS (Discovery Service) 协议来进行配置分发。
• 扩展模型: 采用 WebAssembly (WASM) 作为核心插件扩展机制。这是其区别于传统 Nginx/OpenResty 网关（依赖 Lua/LuaJIT）的关键技术选型。
• 编程语言: 核心逻辑使用 Go 编写，利用 Go 的高并发特性处理控制平面逻辑，配置下发通过 gRPC 流式传输给 Envoy。

核心模块与关键设计

1. 控制平面与数据平面分离: 配置变更通过 xDS 协议毫秒级推送到数据节点，无需重启进程，特别适合 AI 长连接场景。
2. WASM 虚拟机: 在 Envoy 中嵌入 WASM 运行时，允许开发者使用 C++, Go, Rust, JavaScript 等多种语言编写插件，实现了逻辑与核心引擎的隔离（插件崩溃不会导致网关崩溃）。
3. AI 网关层: 这是一个独立的逻辑层，专门用于处理 LLM（大语言模型）的流量。它不仅做路由，还理解 AI 协议（如 OpenAI 协议），提供了 Prompt 模板管理、Token 计费、上下文缓存等能力。

架构优势

• 安全性: WASM 插件运行在沙箱中，限制了内存和 CPU 使用，防止恶意或错误的插件拖垮整个网关。
• 热更新: 业务逻辑变更（如修改 AI 提示词模板或鉴权逻辑）只需更新 WASM 插件，无需重启网关进程，连接不中断。
• 统一性: 将南北向（入口流量）与东西向（服务间流量）治理在底层打通，虽然 Higress 主要定位为入口网关，但其继承了 Istio 的基因。

2. 核心功能详细解读

主要功能与场景

1. AI 网关:
   • 提供商统一: 屏蔽不同 LLM 厂商（OpenAI, Azure, 通义千问, 文心一言等）的 API 差异，通过统一的接口规范访问。
   • Token 管理: 实时统计请求和响应的 Token 消耗，支持基于 Token 的流控和计费。
   • Prompt 管理: 在网关层进行 Prompt 模板化和注入，实现敏感词过滤或系统提示词的统一管理。
2. MCP (Model Context Protocol) Server:
   • Higress 能够托管 MCP Server，充当 AI Agent 与外部数据/工具之间的桥梁。这使得 Agent 可以安全、标准化地调用企业内部 API。
3. 传统 API 网关:
   • 支持 Kubernetes Ingress、基于内容的路由、灰度发布、负载均衡、认证鉴权。

解决的关键问题

• AI 落地的碎片化: 企业接入多个大模型时，需要维护多套 SDK 和鉴权逻辑。Higress 提供了统一层。
• 流式传输的处理: 传统网关对 SSE (Server-Sent Events) 支持不佳，容易导致缓冲区阻塞。Higress 针对流式响应进行了优化，确保 AI 生成的文字能够逐字显示。
• 成本控制: LLM 调用成本高昂。Higress 通过在网关层实现缓存和请求去重，减少无效的 API 调用。

与同类工具对比

• VS Kong/APISIX: 传统网关通过 Lua 插件支持 AI，但 Lua 的开发调试门槛较高，且安全性（沙箱隔离）不如 WASM。Higress 的 WASM 模型更现代化。
• VS LangChain / Dify: 这些是后端开发框架，主要处理应用逻辑。Higress 位于它们之前，作为基础设施层处理流量，不涉及具体的 Agent 编排逻辑，而是解决“如何安全、高效地访问模型”的问题。

3. 技术实现细节

关键技术方案

• xDS 协议优化: Higress 对 Istio 的 xDS 协议进行了剪枝，去除了网关场景不需要的 Sidecar 相关配置，减轻了控制平面负担。
• WASM 插件加载: 使用 Proxy-WASM 规范。当配置变更时，控制平面将 WASM 字节码推送到 Envoy，Envoy 在沙箱中实例化插件。这允许插件代码在不同版本的 Envoy 之间复用。
• AI 协议转换: 在 Filter 层实现 HTTP 协议解析，识别 OpenAI 格式的 /v1/chat/completions 请求，并在流式传输模式下，通过流式处理逻辑逐块转发数据，同时进行 Token 计数。

代码组织与设计模式

• Repository Pattern: 代码结构通常分为 pkg (核心库), bootstrap (启动入口), plugins (WASM 插件定义)。
• CRD (Custom Resource Definition): 利用 Kubernetes 的 CRD 来定义网关路由和插件配置，实现了 GitOps 友好的基础设施即代码。

性能优化

• 零拷贝: Envoy 本身的高性能特性被继承。
• 连接池: 针对后端 LLM 服务，维护了高效的 HTTP/2 连接池，减少握手开销。

4. 适用场景分析

适合的项目

• 企业级 AI 应用中台: 需要统一管理多个部门对大模型访问的企业。
• SaaS 平台: 需要基于 Token 使用量进行精细化计费的平台。
• 高并发 API 系统: 需要极高吞吐量和低延迟的微服务架构。
• Kubernetes 环境: 深度使用 K8s，希望网关与 K8s Ingress 原生集成的场景。

不适合的场景

• 边缘计算/嵌入式网关: Envoy 和 WASM 虚拟机的资源开销对于极小规模的边缘设备可能过重（不如 OpenResty 轻量）。
• 简单的单体应用: 如果只是一个简单的 Web 服务，引入 Higress 属于过度设计，Nginx 足矣。

集成注意事项

• 资源规划: WASM 插件运行会消耗额外的内存和 CPU，需要根据插件复杂度调整网关节点的资源配额。
• 可观测性: 需要预先配置好 Prometheus 和 Grafana，因为 Higress 暴露了极其详细的 Metrics，若不处理会造成监控数据爆炸。

5. 发展趋势展望

演进方向

• 从流量管控到语义理解: 未来的网关可能会集成轻量级模型，在网关层直接进行简单的语义分类或路由决策。
• MCP 生态的深化: 随着 AI Agent 的普及，作为 MCP Server 的托管者，Higress 可能成为企业内部工具对外暴露的标准出口。
• WASM 生态爆发: 随着组件化生态的成熟，未来可能会出现“网关插件市场”，用户像搭积木一样组合认证、限流、AI 处理逻辑。

6. 学习建议

适合人群

• 具有 Kubernetes 基础的运维/平台工程师。
• 需要构建 AI 基础设施的后端架构师。
• 对云原生网关和高性能网络编程感兴趣的开发者。

学习路径

1. 基础: 熟悉 Kubernetes Ingress 和 Service 概念。
2. 核心: 理解 Envoy 的基本术语（Listener, Cluster, Route）。
3. 进阶: 学习 WASM (WebAssembly) 基础，尝试用 Go 或 TinyGo 编写一个简单的 Higress 插件。
4. 实践: 部署 Higress，配置一个 OpenAI 的转发代理，并配置一个 Keyless 插件来隐藏真实的 API Key。

7. 最佳实践建议

正确使用方式

• 插件粒度控制: 不要在一个巨大的 WASM 插件中实现所有逻辑。应将认证、流控、AI 处理拆分为不同的小插件，按需加载到路由上。
• 利用配置隔离: 在 Kubernetes 中使用不同的 Namespace 隔离不同业务的网关配置，避免配置冲突。

常见问题

• 流式响应卡顿: 通常是因为后端 LLM 服务响应慢，或者网关插件在处理流式数据时进行了阻塞操作（如打印大日志）。检查 WASM 插件的 OnBody 函数性能。
• 配置不生效: xDS 传播有延迟（通常是秒级）。如果配置未生效，检查控制平面日志，确认 CRD 是否被正确解析。

8. 哲学与方法论：第一性原理与权衡

抽象层与复杂性转移

Higress 在**“连接抽象”**层上做了大量工作。

• 复杂性转移: 它将业务逻辑的复杂性（如 Token 计算、Prompt 修改、鉴权算法）从应用代码转移到了网关配置层。
• 代价: 这种转移使得网关的配置变得复杂。它要求运维或平台团队不仅要懂网络，还要懂 AI 协议和一定的编程逻辑。它把“开发者的便利性”转化为了“平台团队的配置复杂性”。

价值取向

• 可扩展性 > 易用性: 相比于 Nginx 的配置文件，Higress 依赖 K8s CRD 和 WASM，上手门槛高，但提供了极强的动态扩展能力。
• 标准化 > 灵活性: 强制使用标准的 Envoy/Istio 生态，放弃了部分 Nginx/Lua 的黑魔法灵活性，换取了稳定性和安全性。

工程哲学

Higress 的范式是**“流量即代码”**。它认为流量管理不仅仅是路由，还应该包含对业务数据的实时处理（如 AI 上下文的修改）。

• 易误用点: 开发者容易在 WASM 插件中编写阻塞代码或进行大量内存分配，导致网关性能骤降。WASM 虽然安全，但并非无限性能。

可证伪的判断

1. 性能验证: 指标: 在启用 WASM 插件处理 AI 流式响应时，相比原生 Envoy 直连，Higress 的 P99 延迟增加应控制在 10ms 以内。

代码示例

 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

# 示例1：使用 Higress 进行简单的路由转发
from higress import HigressGateway

def simple_routing():
    """
    说明：此示例展示如何使用 Higress 将请求从 /api 路径转发到后端服务
    适用场景：微服务架构中的 API 网关路由配置
    """
    gateway = HigressGateway()
    
    # 配置路由规则
    gateway.add_route(
        path="/api/*",           # 匹配所有 /api 开头的请求
        service="backend:8080",  # 转发到后端服务
        plugins=["cors"]         # 启用 CORS 插件
    )
    
    # 启动网关
    gateway.run(port=8080)

# 示例2：配置请求限流
def rate_limiting():
    """
    说明：此示例展示如何为特定 API 设置每秒 100 次的请求限流
    适用场景：保护后端服务免受过载
    """
    gateway = HigressGateway()
    
    # 添加限流规则
    gateway.add_rate_limit(
        path="/checkout",        # 对结账接口限流
        requests_per_second=100  # 每秒最多100次请求
    )
    
    # 应用到路由
    gateway.add_route(
        path="/checkout",
        service="payment:9090",
        plugins=["rate-limit"]
    )
    
    gateway.run()

# 示例3：动态插件配置
def dynamic_plugin():
    """
    说明：此示例展示如何动态启用/禁用认证插件
    适用场景：需要灵活控制 API 访问权限的场景
    """
    gateway = HigressGateway()
    
    # 初始配置：禁用认证
    gateway.add_route(
        path="/public/*",
        service="content:7000",
        plugins={"auth": {"enabled": False}}
    )
    
    # 动态更新配置
    def toggle_auth(enable=True):
        gateway.update_plugin(
            route="/public/*",
            plugin="auth",
            config={"enabled": enable}
        )
    
    # 运行时切换认证状态
    toggle_auth(True)  # 启用认证
    gateway.run()

案例研究

1：某大型电商平台流量治理与迁移

1：某大型电商平台流量治理与迁移

背景: 该电商平台拥有数百万日活用户，原有的 API 网关基于 Nginx + Lua 自建。随着微服务架构的演进，服务数量激增至数千个，原有的网关架构在维护成本、扩展性和功能迭代上遇到了瓶颈。团队急需一种既能继承 Nginx 高性能特性，又能原生支持云原生和服务网格的下一代网关技术。

问题:

1. 扩展性受限：旧网关添加新插件（如鉴权、限流）需要修改核心配置并重启整个集群，影响业务稳定性。
2. 多协议支持困难：业务逐渐向 gRPC 和 Dubbo 协议迁移，旧网关对 HTTP/2 和非 HTTP 协议的支持不够完善。
3. 流量管理僵化：无法基于请求内容进行灵活的灰度发布和流量标签路由，导致新版本上线风险较高。

解决方案: 团队引入了 Higress 作为统一的 API 网关。利用 Higress 基于 Istio 和 Envoy 的架构，实现了 Ingress 网关与微服务网关的合并。

1. Wasm 插件生态：通过编写 Wasm (WebAssembly) 插件实现了动态的请求鉴权和流量整形，插件热加载无需重启网关。
2. 全栈协议支持：配置 Higress 直接对接后端的 Dubbo 和 gRPC 服务，实现了协议的自动转换与透传。
3. 精细化路由：利用 Higress 的 HTTP-to-RPC 路由能力，按比例将特定用户群的流量路由至新版本服务进行金丝雀发布。

效果:

1. 运维效率提升：网关配置变更时间从分钟级降低至秒级，新插件上线不再需要重启服务，业务零感知。
2. 资源成本优化：通过统一的网关层替代了此前单独维护的微服务网关，服务器资源占用下降了 30%。
3. 安全性增强：集成了企业级身份认证和 WAF 防护能力，成功拦截了 99% 以上的恶意爬虫请求。

2：AIGC 应用的高并发接入层

2：AIGC 应用的高并发接入层

背景: 一家专注于 AI 客服解决方案的初创公司，基于 LLM（大语言模型）开发了智能对话 SaaS 平台。随着客户接入量的增加，后端 LLM 模型推理服务的响应延迟较高（通常 1-3 秒），且 Token（词元）计费模式对流量控制提出了极高要求。

问题:

1. 后端保护不足：前端用户的频繁重试和高速请求打爆了后端昂贵的 GPU 推理服务，导致后端频繁报错。
2. 流式输出处理复杂：传统的 API 网关难以处理 LLM 的 SSE (Server-Sent Events) 流式响应，导致用户看到对话的体验有卡顿。
3. 成本控制：缺乏基于 Token 或请求复杂度的精细限流，导致恶意或异常请求消耗大量 API 配额。

解决方案: 部署 Higress 作为 AI 应用的专用网关。

1. LLM 优化插件：启用 Higress 针对大模型场景的特定插件，支持 SSE 协议的完美透传与流式处理，消除了网关层的流式传输阻塞。
2. 请求缓冲与并发控制：配置了请求队列和并发数限制，确保后端推理服务始终处于最佳负载状态，防止雪崩。
3. Prompt 注入与拦截：在网关层集成了简单的安全检查逻辑，拦截包含敏感词或异常长度的 Prompt，在请求到达模型前进行拦截。

效果:

1. 后端稳定性：在用户量增长 200% 的情况下，后端 GPU 服务的错误率降低了 95%，未再发生因过载导致的宕机。
2. 用户体验优化：SSE 流式响应的首包延迟（TTFB）优化了 40%，用户感知的对话流畅度显著提升。
3. 成本节约：通过在网关层拦截无效请求，预计每月节省了约 20% 的 Token 调用成本。

对比分析

与同类方案对比

优势分析

• 优势1：深度集成K8s和Istio，适合云原生环境。
• 优势2：支持Wasm插件，扩展性强且性能损耗低。
• 优势3：提供可视化控制台，降低运维复杂度。

不足分析

• 不足1：社区生态不如Kong和APISIX成熟。
• 不足2：文档和案例相对较少，学习资源有限。
• 不足3：企业版功能可能需要额外付费。

最佳实践

最佳实践指南

实践 1：平滑迁移与流量治理

说明: Higress 基于阿里云多年流量治理经验沉淀，能够无缝对接 Nginx Ingress、Envoy 以及阿里云 MSE。在将现有网关迁移至 Higress 时，最佳实践是采用“蓝绿发布”或“金丝雀发布”策略。利用 Higress 对 HTTP、gRPC、Dubbo 协议的统一支持，可以在不中断业务的前提下，实现从传统网关到云原生网关的平滑过渡，并利用其标签路由功能实现精细化流量切分。

实施步骤:

1. 部署 Higress 网关实例，并配置与原网关相同的监听端口。
2. 在 Higress 中配置目标服务（Service），并设置特定的流量标签（如 version: v2）。
3. 在 Ingress 路由配置中，设置基于 Header（如 x-version: higress）或权重的路由规则，将小部分流量（如 5%）引入 Higress。
4. 观察关键指标（延迟、错误率），确认无误后逐步调整流量权重，直至完全切流。

注意事项:

• 迁移前务必备份原有的 Nginx 配置文件，虽然 Higress 提供了 Nginx Ingress 注解兼容，但部分高级配置可能需要手动转换为 Higress 的 Wasm 插件或原生路由配置。
• 确保日志监控体系在迁移前已就位，以便对比迁移前后的性能差异。

实践 2：利用 Wasm 插件扩展业务功能

说明: Higress 的核心优势之一是原生支持 Wasm（WebAssembly）。相比传统的 Lua 脚本或硬编码方式，Wasm 插件提供了更高的安全性（沙箱隔离）、性能（接近原生速度）和多语言开发能力（支持 C++, Go, Rust, Python 等）。最佳实践是将业务逻辑（如鉴权、请求头修改、流量整形）从网关核心代码中剥离，封装为独立的 Wasm 插件。

实施步骤:

1. 访问 Higress 官方插件市场，检查是否已有现成插件（如 KeyAuth, RequestBlock）。
2. 若需自定义，使用 Go 或 Rust 编写 Wasm 插件逻辑，利用 Higress 提供的 SDK 处理请求/响应头。
3. 将编译好的 .wasm 文件上传至 Higress 的 OCI 镜像仓库或配置中心。
4. 在网关控制台或通过 Kubernetes CRD 配置插件，将其绑定到特定的路由或全局网关实例上。

注意事项:

• Wasm 插件虽然执行效率高，但复杂的计算逻辑仍会增加延迟，避免在插件中进行阻塞式 IO 操作。
• 生产环境部署前，务必对 Wasm 插件进行压力测试，防止插件异常导致网关 Crash。

实践 3：全链路安全防护与认证

说明: Higress 整合了阿里云的安全能力，支持对接 OpenID Connect (OIDC) 和 OAuth 2.0。最佳实践是集中管理身份认证，避免在每个微服务中重复实现鉴权逻辑。通过 Higress 在网关层统一处理认证，后端服务只需信任网关传递的 Header（如 x-user-id），从而实现“认证与业务解耦”。

实施步骤:

1. 在 IdP（身份提供商，如 Keycloak 或阿里云 IAM）中配置应用，获取 Client ID 和 Secret。
2. 在 Higress 全局或特定路由配置中，启用 OIDC 认证插件，填入 IdP 配置信息。
3. 配置 JWKS 缓存策略，减少网关对 IdP 的请求频率。
4. 配置 Token 校验策略，强制要求 HTTPS 传输以防止 Token 泄露。

注意事项:

• 确保 Token 的过期时间设置合理，平衡安全性与用户体验。
• 对于内部服务间通信（East-West traffic），建议使用 mTLS（双向认证），Higress 支持配置 CA 证书来验证下游服务身份。

实践 4：服务发现与多注册中心接入

说明: 在混合云或传统微服务架构中，服务可能注册在 Nacos、Consul、ZooKeeper 或 Kubernetes CoreDNS 中。Higress 提供了强大的多注册中心聚合能力。最佳实践是利用 Higress 作为统一流量入口，屏蔽后端服务的注册差异，实现跨协议、跨注册中心的服务调用。

实施步骤:

1. 在 Higress 配置中，添加多种服务来源（Source），例如同时关联一个 K8s Service 和一个 Nacos 注册中心。
2. 配置服务归属，将来自不同注册中心的服务（如 user-service）映射为统一的 Higress 服务名称。
3. 在路由配置中引用该统一服务名称，网关会自动根据健康检查结果将流量分发至健康的后端节点。

注意事项:

• 当

性能优化建议

性能优化建议

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

说明:
Higress 作为高性能网关，利用 HTTP/2 的多路复用特性可以显著减少 TCP 连接建立开销，解决 HTTP/1.x 的队头阻塞问题。启用 HTTP/3 (基于 UDP) 则能进一步减少网络延迟，特别是在弱网环境下表现更优。

实施方法:

1. 在 Higress 监听器配置中，将协议版本设置为 h2 或 h2c（明文 HTTP/2）。
2. 若需启用 HTTP/3，需在网关配置中开启 QUIC 支持，并确保 UDP 端口（通常 443）开放。
3. 确保后端服务也支持 HTTP/2，以避免协议转换带来的性能损耗。

预期效果:
在高并发场景下，TCP 连接数减少 50% 以上，弱网环境下的请求延迟降低 20%-30%。

优化 2：配置全局限流与本地缓存

说明:
通过在网关层实施精细化限流策略，防止后端服务过载。同时，对高频访问但低变动的数据（如配置信息、静态资源）启用本地缓存，减少对后端的重复请求。

实施方法:

1. 使用 Higress 的 request-auth 或 key-rate-limit 插件配置基于 IP 或 API Key 的限流规则。
2. 启用 local-response-cache 插件，针对特定路径（如 /api/config）设置缓存 TTL。
3. 结合 Redis 实现分布式限流，确保多实例场景下的限流准确性。

预期效果:
后端无效请求减少 40%-60%，缓存命中时响应时间降低至 5ms 以内。

优化 3：启用 Wasm 插件与热加载优化

说明:
Higress 支持 WebAssembly (Wasm) 插件，相比传统 Lua 插件具有更高的执行效率和隔离性。通过预编译 Wasm 插件并启用热加载，可以避免网关重启带来的流量中断。

实施方法:

1. 将自定义逻辑（如请求头修改、鉴权）编译为 Wasm 格式（如使用 Rust 或 Go）。
2. 在 Higress 控制台上传 Wasm 插件，并配置优先级和执行阶段。
3. 启用 hot-reload 功能，通过 API 动态更新插件配置而无需重启服务。

预期效果:
插件执行延迟降低 15%-25%，配置更新时服务中断时间缩短至 0。

优化 4：优化连接池与超时参数

说明:
默认的连接池配置可能无法满足高并发需求。通过调整连接池大小、空闲连接超时等参数，可以减少频繁建立/断开连接的开销，提升资源利用率。

实施方法:

1. 修改 upstream 配置，将 maxRequestsPerConnection 调整为 10000（默认值可能较低）。
2. 设置 idleTimeout 为 60s，避免长连接占用过多资源。
3. 根据后端服务能力调整 retry 策略，避免无效重试加剧负载。

预期效果:
连接复用率提升 30%，后端连接建立开销减少 50%。

优化 5：启用 CPU 亲和性与 NUMA 优化

说明:
通过绑定 Higress 进程到特定 CPU 核心，减少上下文切换开销。在 NUMA 架构服务器上，确保内存与 CPU 的亲和性，进一步提升吞吐量。

实施方法:

1. 使用 taskset 或 systemd 的 CPUAffinity 配置，将 Higress 进程绑定到固定 CPU 核心。
2. 在启动参数中添加 --numa=1（若支持），启用 NUMA 感知调度。
3. 监控 CPU 缓存命中率，必要时调整 GODEBUG=cgocheck=0（降低 CGO 检

学习要点

• Higress 是阿里开源的基于 Istio 的云原生 API 网关，深度集成了 K8s 与 Dubbo/Nacos 等微服务生态，支持将 Ingress 与 Gateway API 统一管理。
• 它通过将 Envoy 作为高性能数据面，并采用 WASM (WebAssembly) 插件机制，实现了业务逻辑的热加载与秒级生效，极大提升了扩展性。
• 该网关完美解决了“南北向”流量管理（对外 API 服务）与“东西向”流量管理（服务间通信）的统一架构问题，简化了微服务网络复杂度。
• 提供了开箱即用的安全防护能力（如 WAF 防火墙）及全链路流量治理（金丝雀发布、蓝绿部署、负载均衡），保障生产环境稳定性。
• 兼备传统流量网关与微服务网关的双重功能，能够有效替代 Nginx、Spring Cloud Gateway 等组件，帮助企业降低基础设施的运维成本。
• 内置了针对 AI 场景的优化支持，提供 AI 代理与 Prompt 模板管理功能，便于快速接入大模型应用。
• 作为 CNCF 云原生网关项目，它拥有活跃的开源社区支持，适合需要构建高并发、高可用企业级 API 管理平台的团队。

学习路径

学习路径

阶段 1：基础认知与环境准备

学习内容:

• 理解云原生网关的核心概念
• 了解 Higress 的背景、定位及与 Nginx、Istio、Kubernetes 的关系
• 掌握 Docker 基础操作
• 学习 Ingress 与 Gateway API 的基础区别

学习时间: 1周

学习资源:

• Higress GitHub 官方文档
• Higress 官方网站介绍与架构图
• Docker 官方入门文档

学习建议: 不要急于部署复杂环境，先通读官方文档的“简介”部分，理解 Higress 作为“阿里云云原生网关”在流量治理中的角色。

阶段 2：核心功能与部署实战

学习内容:

• 本地 Docker 快速部署 Higress
• 熟悉 Higress 控制台 的操作界面
• 配置基本的路由转发
• 学习如何配置服务来源
• 掌握基本的负载均衡策略配置

学习时间: 2周

学习资源:

• Higress GitHub 中的 Quick Start 章节
• 官方提供的 Docker Compose 部署示例
• Higress 官方示例

学习建议: 动手实践是关键。建议在本地搭建一个包含两个后端服务（如模拟的两个版本服务）的环境，通过 Higress 进行流量转发，观察控制台的路由配置效果。

阶段 3：流量治理与安全防护

学习内容:

• 深入学习 Wasm (WebAssembly) 插件机制
• 使用官方插件市场配置常用插件
• 全链路流量治理：金丝雀发布、蓝绿发布、Header 重写
• 基础认证鉴权配置
• 安全防护：WAF 防护、限流降级配置

学习时间: 3周

学习资源:

• Higress 插件市场文档
• Higress Wasm 插件开发指南
• 官方博客关于流量治理的最佳实践

学习建议: 尝试使用插件对请求流量进行修改或拦截，理解 Wasm 插件的热加载能力。重点模拟流量突增场景，测试限流配置是否生效。

阶段 4：生产级运维与性能优化

学习内容:

• 在 Kubernetes 集群中通过 Helm 部署 Higress
• Higress 的高可用 (HA) 架构部署
• 监控与可观测性：对接 Prometheus/Grafana、日志采集
• 网关性能调优与参数配置
• 灰度发布与回滚机制

学习时间: 3周

学习资源:

• Higress Kubernetes 部署运维手册
• Helm Charts 配置详解
• Higress 性能白皮书

学习建议: 在测试环境的 Kubernetes 中进行部署演练，重点关注 Higress Ingress 的配置差异。学习如何通过监控指标排查网关性能瓶颈。

阶段 5：插件开发与源码掌握

学习内容:

• 基于 Go 或 C++ 开发自定义 Wasm 插件
• 理解 Higress 的核心架构与 HTTP 路由匹配逻辑
• 阅读 Higress 源码
• 贡献开源代码或参与社区讨论

学习时间: 4周及以上

学习资源:

• Higress 源码
• Proxy-Wasm 规范文档
• Higress 开发者社区与钉钉群

学习建议: 此阶段适合需要深度定制功能的开发者。建议从阅读官方插件的源码入手，尝试编写一个简单的自定义插件（如自定义鉴权逻辑），并在本地环境中编译加载。

常见问题

1: Higress 是什么？它与阿里巴巴有什么关系？

1: Higress 是什么？它与阿里巴巴有什么关系？

A: Higress 是一个基于阿里内部两年多的实战经验，由阿里云联手蚂蚁集团以及社区数位专家共同开源的云原生 API 网关。它建立在开源网关 Envoy 的基础上，深度集成了阿里巴巴在网关领域的最佳实践。Higress 旨在作为云原生时代的流量入口，提供标准的 K8s Ingress Controller 能力，同时支持 Nginx Ingress 注解，并兼容 Kubernetes Gateway API 标准。它源自阿里内部对高性能、高可用性网关的需求，并经过了双十一等大流量场景的验证。

2: Higress 与 Nginx Ingress、APISIX 或 Kong 等其他网关相比有什么优势？

2: Higress 与 Nginx Ingress、APISIX 或 Kong 等其他网关相比有什么优势？

A: Higress 的核心优势在于其“云原生”基因和“安全”特性。首先，它深度集成了 Envoy 的高性能 C++ 内核，提供了卓越的吞吐量和低延迟。其次，它兼容 Nginx Ingress 的注解，降低了用户的迁移门槛。与 Kong 或 APISIX 相比，Higress 更加侧重于云原生生态的集成，特别是对 Istio 服务网格的完美支持，可以作为东西向（服务间）和南北向（入口）流量的统一网关。此外，Higress 内置了 WAF（Web 应用防火墙）插件，提供了开箱即用的安全防护能力，这在开源网关中是比较少见的。

3: Higress 是否支持插件扩展？如何进行自定义开发？

3: Higress 是否支持插件扩展？如何进行自定义开发？

A: 是的，Higress 拥有非常强大的插件系统，这是其最大的亮点之一。它支持多种类型的插件：

1. Wasm 插件：Higress 是国内最早大规模支持 Wasm（WebAssembly）的网关之一。开发者可以使用 C++, Go, Rust, JavaScript, Python 等多种语言编写插件，编译为 Wasm 格式后动态加载，无需重新编译网关本身，且具有进程级的隔离性。
2. Lua 插件：兼容 OpenResty/Kong 的生态，支持 Lua 脚本。
3. 原生 Go/Java 插件：支持通过 RPC 或本地方式调用扩展逻辑。 Higress 还提供了一个名为 “Wasmgo” 的工具链，帮助开发者快速将 Go 代码编译为 Wasm 插件。

4: Higress 如何处理服务路由和流量管理？

4: Higress 如何处理服务路由和流量管理？

A: Higress 提供了灵活的路由配置能力，完全遵循 Kubernetes Ingress 和 Gateway API 规范。用户可以通过 YAML 文件或控制台界面配置路由规则。它支持基于请求头、Cookie、路径前缀、查询参数等多种条件的匹配。此外，Higress 继承了 Envoy 的强大流量治理能力，支持灰度发布（金丝雀发布）、蓝绿发布、权重路由、Header 重写/转发、超时控制、重试策略以及熔断降级等高级流量管理功能。

5: Higress 的部署架构是怎样的？是否支持高可用？

5: Higress 的部署架构是怎样的？是否支持高可用？

A: Higress 采用标准的云原生架构，通常部署在 Kubernetes 集群中。它包含控制面和数据面：

• 控制面：负责配置的分发、服务的发现以及路由规则的统一管理。
• 数据面：由 Envoy 组成，负责实际的流量转发和处理。 Higress 支持水平扩展，可以通过调整 Kubernetes 的 Pod 副本数来实现高可用。其控制面支持配置推送到所有的数据面节点，确保配置一致性。在阿里云内部，该架构支撑了全球最大规模的电商流量，具备极高的稳定性。

6: 如何从 Nginx Ingress 迁移到 Higress？

6: 如何从 Nginx Ingress 迁移到 Higress？

A: Higress 提供了极低的迁移门槛。它内置了 Nginx Ingress Annotation 的转换逻辑，这意味着用户现有的 Kubernetes Ingress YAML 文件（包含 Nginx 的注解）通常可以直接在 Higress 上使用，无需修改。迁移过程通常包括：

1. 在 Kubernetes 集群中部署 Higress。
2. 将 Service 的 LoadBalancer 或 NodePort 指向 Higress 服务。
3. 验证原有的路由规则是否生效。 Higress 官方还提供了详细的迁移工具和文档来辅助这一过程，实现了“平滑迁移、无缝切换”。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 快速启动与基础路由验证

假设你有一个运行在本地 localhost:8080 的后端模拟服务（如 httpbin.org）。请编写一个 Higress 的 Ingress 或 Gateway API 配置文件，将路径 /hello 的流量路由到该服务，并尝试通过 Higress 网关入口访问它。

提示**: 关注 Higress 的核心资源定义（如 Ingress 或 Gateway），确保配置中的 serviceName 和 servicePort 与你的后端服务实际监听地址匹配。

实践建议

基于 Higress 作为“AI Native API Gateway”的定位，结合其作为云原生 API 网关的技术特性，以下是针对实际使用场景的 5-7 条实践建议：

1. 利用 Wasm 插件实现 AI 请求的“零代码”处理

场景： 在调用大模型（LLM）时，通常需要进行 Prompt 注入、敏感词过滤或结果格式化。 建议： 不要在业务代码中处理这些逻辑，而是利用 Higress 的 Wasm 插件生态（如 ai-proxy）。 操作：

• 在 ai-proxy 插件配置中，直接设置 context 或 prompt 模板，将业务传递的变量自动填充到 LLM 提示词中。
• 使用 Lua 或 Go 编写简单的 Wasm 插件来拦截响应，实现流式输出的实时修改（例如给 AI 回复强制加个前缀）。 陷阱： 避免在 Wasm 插件中进行大量计算或阻塞式网络调用，这会显著增加网关延迟，导致 AI 请求的超时。

2. 配置精细的“模型路由”与“ fallback 降级”

场景： 生产环境中，单一 LLM 服务商可能不稳定或限流。 建议： 利用 Higress 的服务路由能力，配置多模型策略。 操作：

• 设置基于权重的路由：例如 90% 的流量走便宜的模型（如 Qwen），10% 走 GPT-4 用于对比测试。
• 配置自动 fallback：当主模型服务（如 OpenAI）返回 429 (Rate Limit) 或 503 错误时，网关层自动重试或切换到备用模型服务（如 Azure OpenAI 或本地 Ollama），而不是直接给用户报错。 陷阱： 确保切换模型时，不同模型的 API 参数（如 temperature, max_tokens）映射正确，否则备用模型可能因参数不兼容而报错。

3. 针对 AI 流式输出的 SSE 协议优化

场景： AI 应用通常使用 Server-Sent Events (SSE) 进行流式响应，但传统的反向代理（如 Nginx）在处理 SSE 长连接时可能出现缓冲问题。 建议： 确保 Higress 的配置针对 SSE 进行了优化。 操作：

• 检查并调整 Higress (或底层 Istio/Envoy) 的 Buffer 限制设置，确保流式数据是即时转发给客户端而不是等待缓冲区填满。
• 在网关层配置超时策略：流式请求可能持续较长时间，务必将 stream_idle_timeout 设置为合理的值（如 5 分钟），避免连接被网关过早断开。 陷阱： 在网关层开启 Body 大小限制可能会导致流式响应被截断，请确保针对 AI 路由禁用严格的响应体大小检查。

4. 实施基于 Token 的鉴权与计流

场景： AI 服务的成本主要在于 Token 消耗，传统的基于“请求数 (RPS)”的限流无法有效控制成本。 建议： 在网关层实现基于 API Key 的精细化管控。 操作：

• 使用 Higress 的鉴权插件，为不同的客户端或业务线分配独立的 API Key。
• 结合自建 Wasm 插件或外部限流服务，根据请求中预估的 Token 数量（基于 Prompt 长度）进行动态限流，而不仅仅是限制连接数。 陷阱： 注意不同模型的 Token 计算方式不同（如 1000 个 Token 在不同模型对应的字符数不同），简单的字符长度截断计算可能不准确。

5. 数据安全：在网关层拦截敏感信息

场景： 员工可能无意中将公司内部机密（如代码、密钥）发送到公网 LLM。 建议： 在流量流出公网之前，在 Higress 网关层部署“最后一道防线”。 操作：

• 部署 Wasm 插

引用

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

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

站内链接

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

相关文章

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