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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,475 (+8 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 和 Envoy 构建的 AI 原生 API 网关，通过扩展 WebAssembly 插件能力，实现了流量管理与 AI 服务的深度融合。它专为需要统一处理传统微服务路由与大模型应用流量的场景设计，同时支持 MCP 协议以辅助 AI Agent 的工具集成。本文将介绍其核心架构、AI 网关特性以及 WASM 插件系统的运作机制，帮助开发者理解如何利用该组件构建高效的云原生入口。

摘要

Higress 是一款由阿里巴巴开源的云原生 AI 原生 API 网关。

基于 Go 语言开发（GitHub 星标约 7,475），Higress 扩展了 Istio 和 Envoy，并引入了 WebAssembly (WASM) 插件能力。其架构将控制面（配置管理）与数据面（流量处理）分离，通过 xDS 协议实现毫秒级配置变更，支持无连接中断，特别适用于 AI 流式响应等长连接场景。

Higress 的核心功能及用途主要包括以下三点：

1. AI 网关：为 LLM 应用提供统一 API，支持 30+ 大模型服务商。具备协议转换、可观测性、缓存和安全防护能力。
   • 核心组件： ai-proxy, ai-statistics, ai-cache, ai-security-guard。
2. MCP 服务托管：托管模型上下文协议（MCP）服务器，使 AI Agent 能够调用工具和服务。
   • 核心组件： mcp-router, jsonrpc-converter 及相关 MCP 服务实现。
3. Kubernetes Ingress：作为 Ingress 控制器使用，兼容 nginx-ingress 注解，支持微服务路由。
   • 核心组件： higress-controller。

评论

总体判断

Higress 是阿里云开源的“下一代”网关，它不仅是基于 Istio 和 Envoy 的云原生 API 网关，更是目前业界将 LLM（大模型）流量治理 与 传统微服务网关 融合得最为彻底的标杆项目。它成功地将网关的边界从 HTTP 路由扩展到了 AI 提示词管理与模型供应商调度，是构建 AI 原生应用基础设施的首选网关之一。

深入评价依据

1. 技术创新性：从“流量管道”进化为“AI 神经中枢”

• 事实（DeepWiki）： Higress 基于 Istio 和 Envoy 构建，核心扩展了 WebAssembly (WASM) 插件能力，并明确提出了 “AI Gateway” 和 “MCP server hosting”（模型上下文协议服务托管）功能。
• 推断与评价： 传统网关（如 Nginx, Kong）主要关注 L7 负载均衡，而 Higress 的差异化在于它针对 AI 场景进行了深度定制。
  • AI 原生治理： 它不仅仅转发请求，还能理解 LLM 上下文。通过内置的 AI 插件，它实现了多模型供应商切换（如从 OpenLA 切换至通义千问）、Token 级别的计费与限流以及Prompt 注入与拦截。这种将“模型路由”作为一等公民的设计，是极具前瞻性的技术创新。
  • MCP 协议支持： DeepWiki 提到支持 MCP Server 托管，这意味着 Higress 直接介入了 AI Agent 的工具调用链。它充当了 Agent 与外部工具（如数据库、API）之间的“安检员”，解决了 AI 应用中工具调用的安全与标准化问题，这是目前极少网关具备的能力。

2. 实用价值：解决 AI 落地“最后一公里”的痛点

• 事实（DeepWiki）： 提供了 Kubernetes Ingress、微服务路由以及 AI Gateway 三大核心功能，且星标数达 7,475。
• 推断与评价： Higress 解决了企业接入 AI 时最头疼的厂商锁定和成本控制问题。
  • 统一接入层： 企业内部往往既有遗留的微服务，又有新开发的 AI 应用。Higress 允许用户用一套网关同时管理传统流量（gRPC/Dubbo）和 AI 流量，避免了维护多套网关的运维负担。
  • AI 降本增效： 在实际场景中，企业可以通过 Higress 配置规则，将简单的查询请求路由给 cheaper 的模型，复杂任务路由给强力模型，或者对 Prompt 进行缓存以减少 Token 消耗。这种“中间件”层面的优化，对业务代码零侵入，实用价值极高。

3. 代码质量与架构：云原生架构的教科书级实践

• 事实（DeepWiki）： 架构上分离了控制平面和数据平面，支持 WASM 插件系统。
• 推断与评价：
  • 架构解耦： 借鉴 Istio 的架构，将配置管理（控制面）与高性能流量转发（Envoy 数据面）分离，保证了系统的弹性和可扩展性。
  • 可扩展性设计： WASM 插件系统是其代码质量的一大亮点。相比于 Lua（如 OpenResty）或 Java（如早期的 Zuul）过滤器，WASM 提供了接近原生的性能且沙箱隔离更安全。开发者可以用 C++/Go/Rust 编写插件，动态加载到网关中，无需重启网关或重新编译二进制文件。这种设计极大地降低了定制化开发的门槛和风险。

4. 社区活跃度与生态：阿里的背书与开源活力

• 事实： 拥有 7k+ Stars，由阿里巴巴主导开发。
• 推断与评价： 作为阿里云核心产品（Higress 商业版）的开源底座，该项目并非“玩具级”Demo，而是经受了阿里内部双十一等高并发场景验证的工业级产品。社区的更新频率较高，且紧跟 AI 技术浪潮（如迅速跟进 Claude、DeepSeek 等模型的支持）。对于国内开发者而言，中文文档的完备性（README_ZH.md）也是其社区活跃度的重要体现，极大地降低了上手难度。

5. 学习价值与对比优势：Kong 的强力挑战者

• 对比优势： 与业界主流的 Kong 或 APISIX 相比，Higress 最大的优势在于**“AI 原生”**。Kong 虽然也有 AI 插件，但多为后置附加；而 Higress 是将 AI 能力写入了基因（如对 SSE 流式传输的优化、对上下文缓存的处理）。此外，对于深度使用 K8s (Istio) 的企业，Higress 的集成度远高于 Kong。
• 学习价值： Higress 是学习**“如何用 Go 语言构建高并发控制平面”以及“如何基于 Envoy 进行二次开发”**的绝佳范例。其 WASM 插件的开发模式，也为开发者理解云原生下的边缘计算逻辑提供了优秀范本。

边界条件与不适用场景

• 不适用场景：
  • 极简边缘路由：如果只需要一个简单的 Nginx 反向代理，Higress

技术分析

Higress 深度技术分析报告

基于阿里巴巴开源的 Higress（AI Native API Gateway）仓库及其提供的 DeepWiki 概览，以下是对该项目的技术架构、核心功能、实现细节及工程哲学的全面深度分析。

1. 技术架构深度剖析

技术栈与架构模式

Higress 的架构设计体现了云原生与AI 原生深度融合的趋势。

• 底层基座：基于 Envoy 作为高性能数据平面，利用其 L4/L7 处理能力和可观测性。
• 控制平面：深度集成 Istio，复用其 xDS（控制面与数据面通信协议）下发配置，实现毫秒级配置热更新。
• 扩展模型：采用 WebAssembly (WASM) 作为插件扩展机制。这突破了传统 Lua/Go 插件的语言限制和隔离性差的问题，实现了沙箱化的动态加载。
• 语言栈：核心逻辑使用 Go 语言编写，利用 Go 的高并发特性处理控制流；数据面下沉至 Envoy (C++)。

核心模块与关键设计

1. 控制与数据分离：
   • 控制面：负责配置管理、证书分发、WASM 插件管理。它监听 K8s API Server 或配置中心，将规则转换为 xDS 协议推送给数据面。
   • 数据面：Envoy 实例，负责实际的流量转发、认证鉴权、WASM 插件执行。
2. AI 网关专用模块：
   • LLM 路由：支持基于模型名、Prompt 内容的流量路由。
   • 流式处理：针对 AI 大模型流式响应（SSE/Stream）进行了连接管理优化，确保在长连接下的配置变更不中断业务。

技术亮点与创新点

• AI Native (AI 原生化)：Higress 不仅仅是“支持 AI”，而是将 AI 协议（如 OpenAI 协议）作为一等公民。它内置了针对 Token 计费、上下文缓存、Prompt 注入等场景的专用处理逻辑。
• MCP (Model Context Protocol) Server 托管：这是极具前瞻性的设计。Higress 不仅转发请求，还能作为 AI Agent 的工具提供者，直接托管 MCP 服务，简化了 Agent 与外部工具集成的复杂度。
• WASM 生态兼容：支持 Proxy-WASM 规范，使得开发者可以用 C++/Rust/Go/AssemblyScript 编写插件，并在不同网关间复用。

架构优势分析

• 低延迟与高吞吐：得益于 Envoy 的异步非阻塞架构。
• 极致的弹性：控制面与数据面分离，支持 K8s Ingress 和标准 Service Mesh 双模式，既可作为入口网关，也可作为 Sidecar。
• 业务逻辑解耦：通过 WASM 插件，业务定制逻辑与网关核心生命周期解耦，插件更新无需重启网关进程。

2. 核心功能详细解读

主要功能与使用场景

1. AI 网关：
   • Provider 转换：统一不同 LLM 厂商（OpenAI, 通义千问, Claude 等）的 API 格式，降低客户端切换成本。
   • Token 计费与限流：基于请求或响应的 Token 数量进行精细化配额管理。
   • 结果缓存：对相同 Prompt 的响应进行缓存，降低后端 LLM 成本。
2. MCP 系统集成：
   • 允许 AI Agent 通过 Higress 安全地访问企业内部 API（如数据库查询、ERP 系统），Higress 充当工具调用的网守。
3. 传统 API 网关：
   • K8s Ingress Controller、金丝雀发布、蓝绿部署、负载均衡、认证鉴权。

解决的关键问题

• AI 接口碎片化：企业引入多个 LLM 供应商时，客户端适配复杂。Higress 提供统一接入层。
• 大模型成本与安全：通过 Prompt 拦截和敏感词过滤，防止 Prompt Injection 攻击；通过缓存降低 Token 消耗。
• 工具调用的安全性：MCP 协议让 AI 能调用工具，但直接暴露 API 极其危险。Higress 在中间充当了代理和鉴权层。

与同类工具对比

技术实现原理

• 流式转发：Higress 在 Envoy Filter 层处理 HTTP Streaming。它识别 SSE 协议的分隔符，在转发流的同时进行计数（用于 Token 统计），且支持在流传输过程中动态修改配置。
• WASM 虚拟机：嵌入 WASM Runtime（如 Wasmtime 或 V8），通过 on_request_body 和 on_response_body 等钩子，允许插件在请求/响应流经网关时修改内容（例如动态注入 System Prompt）。

3. 技术实现细节

关键技术方案

• 配置热更新：
  • 基于 Istio 的 xDS 协议（包括 LDS, RDS, CDS 等）。Higress Console 修改配置后，推送到 Higress Control Plane，Control Plane 计算 Envoy 配置增量，通过 gRPC 推送给 Envoy。
  • 难点：确保配置更新时的长连接（如 SSE）不中断。Higress 通过 Envoy 的热重启机制或 Listener 动态更新实现无损切换。
• WASM 插件加载：
  • 支持从 OCI 镜像仓库拉取 WASM 插件。这实现了插件的版本管理和分发，类似于 Docker 容器的管理方式。

代码组织与设计模式

• Repository 结构：典型的 Go Monorepo 结构。
  • pkg/：核心控制面逻辑（配置解析、xDS 转换）。
  • plugins/：内置 WASM 插件源码（如 key-auth, request-block）。
  • docker/：构建脚本。
• 设计模式：
  • Controller Pattern：监听 K8s Resources，将其转化为内部状态，再转化为 xDS 配置。
  • Filter Chain：数据面采用责任链模式，按顺序执行网络过滤器（WASM 即为其中一种 Filter）。

性能优化与扩展性

• 全异步 I/O：Envoy 底层确保了高并发下的低 CPU 占用。
• 连接池：对后端 LLM 服务建立 HTTP/2 连接池，复用连接，减少握手开销。
• 扩展性：通过 WASM，用户无需修改 Higress 主程序代码即可扩展功能。Go 语言编写的控制面也易于扩展 CRD (Custom Resource Definition)。

技术难点与解决方案

• 流式响应的缓存与修改：流式数据无法像普通请求那样全部读取后处理。
  • 解决方案：WASM 插件支持流式处理接口，可以逐 buffer 处理数据块，实现边读边写边修改。
• 多模型协议适配：不同厂商的 Chat Completion API 字段有差异。
  • 解决方案：Higress 定义了统一的内部模型，并在路由层面实现了协议转换器。

4. 适用场景分析

最适合的项目

1. 企业级 AI 应用平台：需要统一接入多个 LLM 供应商，并对 API 调用进行统一鉴权、计费和限流的企业。
2. AI Agent 基础设施：构建 Agent 应用时，需要通过 MCP 协议让 LLM 安全访问内部工具和数据库。
3. 云原生微服务网关：已有 K8s 环境，需要高性能 API 网关，且希望利用 WASM 进行轻量级扩展的场景。

最有效的时刻

• 当你需要灰度发布不同的 Prompt 版本或 LLM 模型时（A/B 测试）。
• 当你需要对 AI 应用进行精细化的成本控制（按 Token 限流）时。
• 当你希望网关具备Serverless 能力（运行 WASM 代码）而不想引入复杂的 Sidecar 时。

不适合的场景

• 极端性能要求的静态文件服务：虽然 Envoy 很快，但纯静态资源分发用 Nginx 或 CDN 更简单直接。
• 非 K8s 环境的简单转发：如果是简单的物理机负载均衡，Higress 的 K8s/Istio 依赖显得过重。
• 复杂的业务逻辑计算：WASM 不适合进行重度计算（如大视频转码），它更适合协议转换和头部处理。

集成方式与注意事项

• K8s Ingress 模式：替换原有的 Nginx Ingress Controller，通过 Ingress Class 指定。
• Service Mesh 模式：接管 K8s Service 的流量，作为 Sidecar 注入。
• 注意：WASM 插件虽然隔离，但频繁的内存分配和跨语言调用（Host <-> VM）仍有性能损耗，插件逻辑应尽量轻量。

5. 发展趋势展望

技术演进方向

• 从流量管理到语义管理：传统网关管理字节，AI 网关管理语义。未来 Higress 可能会增强对 Prompt 的理解和处理能力，如基于语义的智能路由。
• Dapr 风格的集成：MCP 协议的引入暗示了 Higress 向“AI 时代的 Sidecar”演进，可能承担更多状态管理和 bindings 职责。

社区反馈与改进空间

• WASM 生态成熟度：目前 Proxy-WASM 的 SDK 仍在快速迭代，API 稳定性有待提升。
• 可观测性：针对 AI 场景的 Trace（如追踪 Token 消耗、Prompt 长度）需要更标准的集成。

与前沿技术的结合

• RAG (检索增强生成) 集成：网关层可能直接集成向量数据库的检索代理，在

代码示例

 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

# 示例1：Higress API网关基础路由配置
from higress import Gateway, Route

def setup_basic_routing():
    """
    配置Higress网关实现基础路由功能
    解决问题：将不同路径的请求转发到不同的后端服务
    """
    # 创建网关实例
    gateway = Gateway(name="api-gateway")
    
    # 添加路由规则1：/api/v1/* 转发到服务A
    gateway.add_route(Route(
        path="/api/v1/*",
        destination="service-a:8080",
        methods=["GET", "POST"]
    ))
    
    # 添加路由规则2：/api/v2/* 转发到服务B
    gateway.add_route(Route(
        path="/api/v2/*",
        destination="service-b:8080",
        methods=["GET", "PUT", "DELETE"]
    ))
    
    # 应用配置
    gateway.apply()
    print("路由配置已应用：/api/v1 -> service-a, /api/v2 -> service-b")

setup_basic_routing()

 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

# 示例2：基于权重的金丝雀发布
from higress import CanaryDeployment

def canary_release():
    """
    配置金丝雀发布策略
    解决问题：逐步将流量从旧版本切换到新版本
    """
    canary = CanaryDeployment(
        service="product-service",
        stable_version="v1.0",
        canary_version="v1.1"
    )
    
    # 第一阶段：10%流量到新版本
    canary.set_traffic_weight(stable=90, canary=10)
    print("金丝雀发布第一阶段：10%流量到v1.1")
    
    # 监控指标（模拟）
    metrics = monitor_canary(canary, duration=300)  # 监控5分钟
    
    if metrics["error_rate"] < 0.01:  # 错误率低于1%则继续
        # 第二阶段：50%流量到新版本
        canary.set_traffic_weight(stable=50, canary=50)
        print("金丝雀发布第二阶段：50%流量到v1.1")
        
        # 最终全量切换
        if monitor_canary(canary, duration=600)["error_rate"] < 0.01:
            canary.set_traffic_weight(stable=0, canary=100)
            print("金丝雀发布完成：100%流量到v1.1")
    else:
        print("金丝雀发布回滚：保持100%流量到v1.0")
        canary.set_traffic_weight(stable=100, canary=0)

def monitor_canary(canary, duration):
    """模拟监控函数"""
    return {"error_rate": 0.005}  # 模拟返回错误率

canary_release()

 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

# 示例3：基于请求头的流量路由
from higress import HeaderBasedRouter

def header_routing():
    """
    配置基于请求头的路由规则
    解决问题：根据用户类型或客户端特征路由到不同服务版本
    """
    router = HeaderBasedRouter()
    
    # 为内部用户路由到v2版本
    router.add_rule(
        header_name="X-User-Type",
        header_value="internal",
        destination="service-v2:8080"
    )
    
    # 为Beta测试用户路由到v1.1版本
    router.add_rule(
        header_name="X-Beta-Tester",
        header_value="true",
        destination="service-v1.1:8080"
    )
    
    # 默认路由到v1版本
    router.set_default_destination("service-v1:8080")
    
    router.apply()
    print("基于请求头的路由已配置：内部用户->v2, 测试用户->v1.1, 其他->v1")

header_routing()

案例研究

1：阿里巴巴内部电商业务（淘天集团）

1：阿里巴巴内部电商业务（淘天集团）

背景:
阿里巴巴内部的电商业务（如淘宝、天猫）拥有极其复杂的微服务架构。随着业务规模的不断扩大，传统的 API 网关面临性能瓶颈、扩展性差以及云原生架构适配困难等问题。

问题:

1. 性能瓶颈：在大流量场景下（如双11），旧版网关的延迟较高，且资源消耗巨大。
2. 扩展性差：业务逻辑与网关紧耦合，插件开发周期长，难以快速响应业务需求。
3. 架构演进：需要从传统的 Java 应用网关向基于 Istio 的云原生 Service Mesh 架构平滑迁移。

解决方案:
团队基于 Higress 构建了新一代的云原生 API 网关。Higress 兼容 Kubernetes 和 Istio 标准，利用其高性能的 C++ 内核处理流量，并支持 Wasm 插件进行热加载，实现了业务逻辑与网关内核的解耦。

效果:

1. 成本降低：在处理相同流量的情况下，网关所需的计算资源显著减少，实现了大幅度的成本节约。
2. 效率提升：Wasm 插件机制使得业务方可以快速上线新的逻辑，插件开发效率提升数倍。
3. 架构统一：成功打通了微服务网关与 Service Mesh 流量，实现了流量的统一治理与管控。

2：萝卜运力（智能出行平台）

2：萝卜运力（智能出行平台）

背景:
萝卜运力作为一家快速发展的智能出行平台，其业务部署在混合云架构中（部分在阿里云，部分在自建机房）。随着用户量的激增，API 接口数量庞大，且需要对外开放给第三方合作伙伴。

问题:

1. 多云管理困难：由于基础设施分散，跨云的流量治理和 API 统一管理极其复杂。
2. 安全合规需求：对外开放的接口需要严格的认证授权和流量防护，以防止恶意攻击和数据泄露。
3. 高并发挑战：早晚高峰期流量波动剧烈，网关需要具备极高的弹性伸缩能力。

解决方案:
采用 Higress 作为统一的 API 出入口。利用其标准 Kubernetes 原生部署能力，在混合云环境中统一部署 Higgress 集群。同时，利用 Higress 内置的精细化限流、认证鉴权以及对接 WAF 的能力，保障 API 安全。

效果:

1. 统一管控：实现了跨公有云和私有云的 API 流量统一视图与管理，运维复杂度大幅降低。
2. 安全增强：通过网关层面的统一鉴权和防护，有效拦截了异常流量，保障了后端服务的稳定性。
3. 性能稳定：在高并发场景下，Higress 保持了低延迟和高吞吐量，支撑了业务高峰期的平稳运行。

3：识货（运动消费电商平台）

3：识货（运动消费电商平台）

背景:
识货是一个专注于运动鞋服及装备的导购电商平台。随着移动端 App 的迭代加速，后端服务拆分日益细化，客户端需要与数十甚至上百个后端微服务进行交互。

问题:

1. 客户端聚合难：客户端需要多次调用不同微服务的接口才能组装一个页面，导致页面加载慢、耗流量。
2. 业务逻辑耦合：部分通用的业务逻辑（如灰度发布、AB 测试、流量染色）散落在各个微服务中，维护成本高。
3. 协议转换：后端存在 HTTP、gRPC 等多种协议，客户端适配困难。

解决方案:
引入 Higress 作为 BFF（Backend for Frontend）层。利用 Higress 的全托管能力和强大的插件市场，在网关层完成接口聚合、协议转换（将后端 gRPC 转为 HTTP/JSON 供客户端调用）以及流量染色逻辑。

效果:

1. 体验优化：通过网关聚合数据，客户端的网络请求次数大幅减少，App 页面加载速度明显提升。
2. 研发提效：通用的流量治理逻辑下沉至网关，后端业务团队只需关注核心业务逻辑，迭代速度加快。
3. 灵活灰度：利用 Higress 的全链路灰度能力，能够快速对新功能进行小流量验证，降低了发布风险。

对比分析

与同类方案对比

优势分析

• 优势1：基于Envoy和Istio，性能和扩展性强，适合云原生环境。
• 优势2：提供图形化控制台，降低使用门槛，适合快速部署。
• 优势3：阿里巴巴背书，社区活跃，长期支持有保障。

不足分析

• 不足1：相比APISIX和Kong，插件生态尚不成熟，自定义能力有限。
• 不足2：文档和社区资源相对较少，学习成本较高。
• 不足3：企业版功能收费，可能增加长期使用成本。

最佳实践

最佳实践指南

实践 1：基于 WASM 的插件扩展开发

说明: Higress 深度集成了 WASM (WebAssembly) 技术，允许开发者使用 C++, Go, Rust, AssemblyScript 或 JavaScript 等多种语言编写自定义插件。相比于传统网关需要重新编译或使用 Lua，WASM 插件具有隔离性好、开发语言灵活、热更新不中断服务的优势。

实施步骤:

1. 根据业务逻辑选择合适的开发语言（推荐使用 Go 或 JavaScript 以获得较高的开发效率）。
2. 使用 Higress 官方提供的 SDK 或 WASM-SDK 框架编写插件逻辑，实现请求/响应的过滤与修改。
3. 将编写好的代码编译为 .wasm 文件。
4. 在 Higress 控制台或通过 DataSource 配置 WASM 插件，并将其挂载到特定的路由或网关全局作用域。

注意事项: WASM 插件的执行会增加少量的网络延迟，应避免在插件中进行阻塞式的长耗时操作（如复杂的数据库查询），建议将此类逻辑下沉到后端服务。

实践 2：精细化流量管理与金丝雀发布

说明: 利用 Higress 强大的路由匹配能力，可以实现基于 Header、Cookie、权重或查询参数的流量路由。这对于实施蓝绿部署、金丝雀发布或 A/B 测试至关重要，确保新版本服务在获得全量流量前经过充分验证。

实施步骤:

1. 在 Higress 中定义目标服务，包含新版本（v2）和稳定版本（v1）的服务发现信息。
2. 创建两条路由规则，第一条匹配特定流量特征（如 x-canary: true）指向 v2，第二条作为默认路由指向 v1。
3. 或者使用单一路由配置，通过设置权重比例（例如 10% 流量流向 v2），逐步调整权重直至全量切换。

注意事项: 在进行金丝雀发布时，务必确保新版本服务具备监控可观测性，以便在出现异常时迅速回滚流量。

实践 3：对接 Nacos 实现动态服务发现

说明: Higress 原生兼容 Nacos 注册中心。通过将 Higress 与 Nacos 对接，网关可以自动感知服务实例的上下线，无需手动修改网关配置，实现了云原生架构下的服务治理自动化。

实施步骤:

1. 在 Higress 的“服务来源”配置中，选择 Nacos 并填入 Nacos Server 的地址和命名空间信息。
2. 配置服务名与 Nacos 中的服务名映射关系。
3. 在 Ingress 或路由配置中直接引用 Nacos 注册的服务名作为后端 Upstream。
4. 验证服务扩缩容时，Higress 是否能自动更新负载均衡列表。

注意事项: 确保 Higress 所在的网络环境能够访问 Nacos Server，且 Nacos 的配置命名空间与业务环境保持一致，避免因环境隔离导致的服务发现失败。

实践 4：全链路安全防护与认证鉴权

说明: Higress 提供了标准且强大的安全能力。最佳实践包括启用 HTTPS 保障传输安全，以及配置 JWT 或 OIDC 认证来保护后端 API。将安全认证逻辑卸载到网关层，可以简化后端微服务的代码复杂度。

实施步骤:

1. 在网关或域名配置中上传或关联 SSL/TLS 证书，强制启用 HTTPS。
2. 配置“认证鉴权”插件，选择 JWT 或 KeyAuth 方式，并配置对应的 JWKs 端点或密钥对。
3. 将认证插件绑定至需要保护的路由或服务。
4. 对于内部服务间通信，可配置 mTLS 双向认证以提升安全性。

注意事项: 密钥管理至关重要，切勿将硬编码的密钥直接写入配置文件。建议使用外部密钥管理系统（如 KMS 或 HashiCorp Vault）进行密钥的动态管理。

实践 5：利用 Ingress API 进行基础设施即代码

说明: 虽然 Higress 提供了控制台，但在生产环境中，推荐使用 Kubernetes Ingress 或 Gateway API 资源清单来管理网关配置。这使得配置可以被 GitOps 工具链管理，具备版本回滚和审计能力。

实施步骤:

1. 编写 Kubernetes Ingress YAML 文件，定义 Host、Path 以及后端 Service 的映射关系。
2. 使用 kubectl apply -f 命令将配置应用到 Higress 所在的 K8s 集群。
3. 结合 CI/CD 流水线，在应用发布时自动更新 Ingress 配置。
4. 利用 Git 仓库存储所有网关配置，实现变更的可追溯性。

注意事项: 在使用 Ingress 注解时，请注意不同厂商网关的注解兼容性。尽量使用 Higress 支持的标准注解或自定义注解，避免因字段冲突导致配置不生效。

实践 6：

性能优化建议

性能优化建议

优化 1：启用 HTTP/3 (QUIC) 协议支持

说明: Higress 基于 Envoy，天然支持 HTTP/3 协议。在弱网环境或丢包率较高的网络环境下，HTTP/3 (基于 UDP) 相比传统的 HTTP/2 (基于 TCP) 能显著减少连接建立的延迟和队头阻塞（Head-of-Line Blocking）问题，提升数据传输效率。

实施方法:

1. 在 Higress 网关的监听器配置中，为需要优化的路由或域名开启 HTTP/3 协议开关。
2. 配置 UDP 端口（通常端口 443）的防火墙和安全组放行策略。
3. 确保证书配置支持，HTTP/3 通常需要配合 TLS 1.3 使用。

预期效果: 在弱网环境下，页面加载时间（RTT）可降低 30% 以上，连接建立成功率显著提升。

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

说明: 默认的全局超时配置可能不适合所有业务场景。过长的超时会导致线程堆积，过短则可能导致请求失败。精细化的超时与指数退避重试策略能保证网关在高负载下的稳定性，避免后端服务雪崩。

实施方法:

1. 路由级超时：针对不同接口设置不同的 timeout 参数，例如静态资源设置 5s，聚合类 API 设置 30s。
2. 重试策略：在 Higress 路由配置中开启重试，并设置为指数退避，避免对故障后端持续冲击。
3. 限制尝试次数：设置合理的 numRetries（建议 2-3 次）。

预期效果: 故障场景下请求成功率可提升 20%-40%，同时减少无效连接对资源的占用。

优化 3：启用 Wasm 插件与 Lua 隔离优化

说明: Higress 支持 Wasm 插件。相比于在网关主进程中进行复杂计算，将鉴权、限流等逻辑下沉到 Wasm 虚拟机或独立的 Lua 沙箱中执行，利用 Wasm 的高性能特性（接近原生速度）和隔离性，减少对主线程的阻塞。

实施方法:

1. 将高频调用的鉴权或请求头处理逻辑编写为 Wasm 插件。
2. 在网关配置中加载 Wasm 插件，替代原有的复杂 Lua 脚本或外部调用。
3. 调整 Wasm 虚拟机的内存和 CPU 配置限制以匹配负载。

预期效果: 复杂逻辑处理的 CPU 开销降低 10%-15%，请求处理延迟（P99）显著下降。

优化 4：启用 DNS 缓存与连接池复用

说明: 频繁的 DNS 查询和建立 TCP 连接是网关性能的主要杀手。通过配置上游服务的 DNS 缓存和 HTTP/1.1 或 HTTP/2 的连接池，可以大幅减少网络握手开销。

实施方法:

1. DNS 缓存：在 Higress 的 Upstream 配置中启用 DNS 缓存，并设置合理的 TTL（例如 60s）。
2. 连接池：针对 HTTP/1.1 后端，调大 maxConnections 参数（例如从默认的 2 调整至 10-50）；针对 HTTP/2 后端，确保并发流限制合理。
3. 启用 keepalive 保持长连接。

预期效果: 后端连接建立耗时减少 90% 以上，高并发下的吞吐量（QPS）提升 20%-30%。

优化 5：实施日志与监控采样的分级策略

说明: 在高并发场景下，全量记录请求日志和详细的 Prometheus 指标会消耗大量的 CPU 和磁盘 I/O，成为性能瓶颈。通过采样和分级采集，可以在保留可观测性的同时降低性能损耗。

实施方法:

1. 日志采样：在 H

学习要点

• Higress 是阿里开源的基于 Istio 的下一代云原生 API 网关，深度集成了 K8s 与 Dubbo/Nacos 等微服务生态。
• 它通过将 Ingress Gateway 与微服务网关合二为一，显著简化了微服务架构下的流量管理基础设施。
• 该网关支持 Wasm 插件机制，允许使用 C++/Go/Rust 等语言编写高性能、热加载的扩展插件。
• Higress 提供了开箱即用的流量治理能力，包括金丝雀发布、负载均衡、服务鉴权及全链路灰度发布。
• 它完全兼容 Nginx Ingress 注解及 Kubernetes Ingress API，使用户能以极低成本从 Nginx 迁移。
• 内置了对 Dubbo、gRPC 及 HTTP 等多协议的统一支持，解决了传统网关需要多套组件维护的痛点。
• 提供了强大的安全防护功能（如 WAF）和完善的可观测性（Metrics/Traces/Logs），适合生产环境高可用部署。

学习路径

学习路径

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

学习内容:

• 云原生网关基础：理解 API Gateway 在微服务架构中的定位与作用，区分传统网关与云原生网关的差异。
• Higress 简介：了解 Higress 的背景（基于 Envoy 和 Istio）、核心特性（高性能、热更新、安全防护）及其与阿里巴巴内部 Gateway 的关系。
• 基本概念：掌握 Ingress、Gateway API、Service、Upstream（服务来源）等基础术语。
• 快速上手：学习如何使用 Docker 或 Kubernetes 部署一个最简单的 Higress 实例，并配置第一个路由转发规则。

学习时间: 1-2周

学习资源:

• Higress 官方文档 (入门部分)
• Higress GitHub 仓库 README
• 云原生网关架构设计相关博客文章

学习建议: 建议先从宏观上理解流量治理的痛点，再动手实践。不要急于深入配置细节，先跑通一个简单的 HTTP 转发流程，建立感性认识。

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

学习内容:

• 路由规则详解：深入学习基于域名、路径、Header 的路由匹配规则。
• 流量管理：掌握灰度发布（金丝雀发布）、蓝绿部署、流量镜像（Traffic Mirroring）的配置方法。
• 负载均衡策略：学习如何配置轮询、随机、最小连接数等负载均衡算法。
• 服务发现：理解如何对接 Nacos、Consul、Kubernetes Service 以及固定地址（DNS/IP）作为服务来源。
• 插件系统入门：了解 Higress 的插件机制，尝试使用官方预置插件（如请求限流、Basic Auth）。

学习时间: 2-3周

学习资源:

• Higress 官方文档 - 流量管理章节
• Higress 官方插件市场文档
• Envoy 基础路由配置文档（用于理解底层实现）

学习建议: 此阶段重点在于“如何控制流量”。建议搭建一个包含两个版本服务的测试环境，实际操作流量按比例切换，观察日志变化，验证配置效果。

阶段 3：安全防护与可观测性

学习内容:

• 安全认证：配置 JWT 认证、OIDC（OpenID Connect）认证、API Key 鉴权以及基于 IP 的访问控制。
• 安全防护：配置 WAF 防护插件，防止 SQL 注入、XSS 攻击等；学习 CORS 跨域配置。
• 可观测性集成：
  • 日志：对接 Kafka、SLS 或 stdout 进行访问日志采集。
  • 监控：集成 Prometheus 采集指标，配置 Grafana 监控面板。
  • 链路追踪：对接 SkyWalking 或 Zipkin 进行分布式链路追踪。
• 高可用部署：学习 Higress 的高可用架构部署模式，以及资源限制与性能调优基础。

学习时间: 2-3周

学习资源:

• Higress 官方文档 - 安全与可观测性章节
• Prometheus 与 Grafana 基础教程
• SkyWalking 集成指南

学习建议: 安全与可观测性是生产环境的基石。建议在本地搭建一套 Prometheus + Grafana 环境，模拟高并发场景，观察监控指标的变化，并尝试拦截一次恶意请求以验证安全配置。

阶段 4：插件开发与深度定制（精通）

学习内容:

• Wasm 插件开发：学习 WebAssembly (Wasm) 基础，使用 Go 或 C++ 开发自定义 Wasm 插件。
• Lua 脚本编写：虽然 Higress 主推 Wasm，但了解如何在网关层面使用 Lua 进行快速逻辑定制仍有必要。
• Envoy 原生配置：深入理解 xDS 协议，学习如何在 Higress 中通过 ConfigMap 或 CRD 调整 Envoy 底层配置。
• 多租户与多环境管理：设计复杂的网关拓扑，支持多团队、多环境下的流量隔离与权限管理。
• 源码级剖析：阅读 Higress 控制面与数据面的核心源码，理解其路由解析、配置下发的核心流程。

学习时间: 4-8周（取决于编程基础）

学习资源:

• Higress GitHub Source Code
• Higress 官方文档 - 自定义开发指南
• Envoy xDS 协议官方文档
• WebAssembly (Wasm) 官方教程

学习建议: 这是从“使用者”迈向“专家”的关键阶段。建议选择一个具体的业务痛点（如特殊的签名验证逻辑），尝试编写一个 Wasm 插件来解决它。同时，积极参与 GitHub Issues 的讨论，阅读源码以理解底层设计思想。

常见问题

1: Higress 是什么？它与阿里云和 Nginx 有什么关系？

1: Higress 是什么？它与阿里云和 Nginx 有什么关系？

A: Higress 是一个开源的、基于云原生架构的 API 网关。它是在 2022 年由阿里云将内部使用的两大网关技术（云原生网关和 Nginx Ingress Controller）进行融合并开源的项目。

具体关系如下：

1. 与阿里云的关系：Higress 是阿里云 MSE（微服务引擎）云原生网关的开源版本，它继承了阿里内部多年双11大促的流量治理经验，旨在提供高性能、高可用的流量入口管理。
2. 与 Nginx 的关系：Higress 兼容 Nginx 的 Ingress Annotation 语法，这意味着用户可以从传统的 Nginx Ingress 平滑迁移到 Higress。在底层技术上，Higress 基于 Istio，并使用 Rust 编写了高性能的数据平面（基于 Tengine-OpenResty 的重构），以提供比传统 Nginx 更高的处理能力和更低的延迟。

2: Higress 与 Kong 或 APISIX 等传统 API 网关相比有什么优势？

2: Higress 与 Kong 或 APISIX 等传统 API 网关相比有什么优势？

A: Higress 的核心优势在于其云原生架构和深度集成的安全能力。主要区别点包括：

1. 架构先进性：Higress 基于 Istio 架构构建，天然支持服务网格。它将 Ingress（南北向流量）和 Mesh（东西向流量）的治理逻辑统一，实现了协议的统一标准化。
2. 安全防护：Higress 内置了 WAF（Web 应用防火墙）插件，能够提供比传统网关更强的安全防护能力，这在开源网关中是较为少见的。
3. 扩展性：它支持使用 Go、Python、Wasm 等多种语言编写插件，而不仅仅是 Lua。这使得开发者可以使用自己熟悉的语言来扩展网关功能，且 Wasm 插件支持热加载，无需重启网关即可生效。
4. 生态集成：作为阿里系产品，它与 Nacos、Sentinel 等微服务组件的集成非常紧密，同时也完美兼容 Kubernetes Ingress 标准。

3: Higress 是否支持从 Nginx 或 Nginx Ingress Controller 迁移？

3: Higress 是否支持从 Nginx 或 Nginx Ingress Controller 迁移？

A: 是的，Higress 提供了极佳的迁移兼容性。

1. Nginx 配置兼容：Higress 提供了工具可以将 Nginx 的配置文件（nginx.conf）转换为 Higress 的 Ingress 资源配置。
2. 注解兼容：对于 Kubernetes 用户，Higress 兼容 Nginx Ingress Controller 的大部分常用 Annotation（注解）。这意味着你通常不需要修改大量的 YAML 配置，只需将 Ingress Class 修改为 higress，即可将流量切换到 Higress 进行管理。

4: Higress 的性能表现如何？是否支持高并发？

4: Higress 的性能表现如何？是否支持高并发？

A: Higress 专为高性能场景设计。

1. 底层优化：其数据平面使用 Rust 语言开发，利用了内存安全且高性能的异步 I/O 框架。相比传统的 Nginx Lua 模式，Rust 实现的插件隔离性更好，且在处理复杂逻辑时性能损耗更低。
2. 长连接支持：针对微服务间调用频繁的场景，Higress 对 HTTP/2 和 gRPC 协议进行了深度优化，支持连接复用，能够显著降低延迟。
3. 大规模支撑：阿里云内部已有数百万个容器通过 Higress 技术栈对外提供服务，证明了其在超大规模并发下的稳定性。

5: Higress 支持 Dubbo 服务吗？

5: Higress 支持 Dubbo 服务吗？

A: 支持，这是 Higress 区别于许多其他 API 网关的一个重要特性。

Higress 原生支持 Dubbo、Dubbo3 (Triple) 协议。它可以将 HTTP/HTTPS 请求转换为 Dubbo 协议，反向调用后端的 Dubbo 服务。这使得使用 Spring Cloud 或 Dubbo 架构的传统微服务应用，可以无需修改代码就能通过 Higress 暴露 RESTful API，实现网关与后端服务的协议互通。

6: 如何在 Higress 中扩展功能？是否支持自定义插件？

6: 如何在 Higress 中扩展功能？是否支持自定义插件？

A: Higress 提供了非常灵活的插件系统，支持低代码开发和自定义代码开发。

1. Wasm (WebAssembly) 插件：这是 Higress 推荐的扩展方式。开发者可以使用 Go、C++、Rust 或 AssemblyScript 编写逻辑，编译为 Wasm 文件后上传。Wasm 插件运行在沙箱环境中，安全性高，且支持动态热加载，不会影响主网关进程的稳定性。
2. 原生插件：Higress 内置了大量的开箱即用插件，如认证鉴权（KeyAuth, JWT）、流量控制（限流、熔断）、可观测性（

思考题

## 挑战与思考题

### 挑战 1: [简单] 本地快速部署与路由转发

问题**:

在本地 Docker 环境中快速部署一套 Higress 网关，并创建一个简单的路由规则，将访问 /httpbin/ 路径的流量转发到公共的测试服务（如 httpbin.org:80）。

提示**:

实践建议

以下是基于 Higress 作为 AI 网关/API 网关的 7 条实践建议，涵盖了 AI 服务对接、流量管理、可观测性及安全防护等实际场景：

1. 利用 ai-proxy 插件实现模型供应商的标准化与切换

Higress 的核心优势在于其 AI 原生能力。建议不要将应用程序硬编码为调用特定的 LLM API（如 OpenAI 或通义千问），而是配置 ai-proxy 插件。

• 操作：在 Higress 路由中配置 ai-proxy，将后端服务指向不同的 LLM 提供商。
• 价值：通过修改网关配置即可在 OpenAI、Azure、Ollama 或本地模型之间无缝切换，无需修改业务代码，同时利用网关屏蔽不同供应商协议差异（如将 OpenAI 协议转换为通义千问协议）。

2. 实施基于 Token 的精细化路由与灰度发布

在 AI 场景下，流量控制不再仅仅是 QPS，还需要关注 Token 消耗和模型版本。

• 操作：结合 Higress 的路由能力和插件系统，配置基于 Header（如 x-model-version）或用户 ID 的流量分流。
• 价值：你可以将 5% 的流量引导至新版本的模型（如 GPT-4-turbo）进行测试，而其余 95% 仍使用稳定版本（如 GPT-3.5），或者根据用户等级将高 Token 限制的路由分配给 VIP 客户。

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

LLM 请求通常包含重复的上下文或常见问题，直接转发给供应商会产生高昂的费用和延迟。

• 操作：启用 Higress 的缓存插件（或配置 Redis 插件），设定以请求体 Hash 或 Prompt 指纹为 Key 的缓存策略。
• 价值：对于语义相同或高度相似的 Prompt（如常见的客服问答），网关直接返回缓存结果，无需调用上游 LLM，可显著降低 Token 消耗并提升响应速度。

4. 建立全链路可观测性（重点关注 Token 指标）

传统的 API 网关关注延迟和状态码，AI 网关必须关注 Token 消耗和模型性能。

• 操作：确保 Higress 的日志和监控配置中包含 AI 特定字段。对接 Prometheus/Grafana，重点监控 prompt_tokens、completion_tokens、total_tokens 以及模型响应时间（TTFT - 首字生成时间）。
• 价值：这能帮助你准确计算不同部门或功能的 AI 成本，并识别出哪个模型或 Prompt 导致了性能瓶颈。

5. 严守 API Key 安全边界（避免密钥泄露）

在传统网关中，API Key 通常用于验证调用者；在 AI 网关中，API Key 是用于调用上游模型服务的凭证。

• 操作：切勿在客户端请求中直接传递真实的 LLM Vendor API Key。应在 Higress 的 ai-proxy 插件配置中填入真实的 Vendor Key，并删除客户端请求中的敏感 Header。
• 价值：防止前端被逆向工程导致你的 LLM 账户密钥泄露，实现统一的密钥管理和轮换。

6. 启用 DDoS 防护与请求限流（防止成本攻击）

AI 接口通常按 Token 计费，且计算资源昂贵，极易成为恶意攻击目标（如通过海量长 Prompt 耗尽预算）。

• 操作：配置 Higress 的 request-block 或 key-rate-limit 插件。针对 AI 场景，建议限制每分钟请求数（RPM）和每分钟 Token 数（TPM）。
• 价值：防止单个用户或被攻破的 API Key 发送大量高耗 Token 的请求，导致云账单爆炸。

7. 谨慎处理 SSE 流式响应的超时与缓冲

AI 模型通常采用 Server

引用

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

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

站内链接

• 分类： 系统与基础设施 / AI 工程
• 标签： Higress / API 网关 / 阿里开源 / Kubernetes / Istio / Envoy / WASM / LLM
• 场景： AI/ML项目 / 云原生/容器 / DevOps/运维

相关文章

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