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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,448 (+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 是一款基于 Istio 和 Envoy 构建的 AI 原生 API 网关，通过集成 WASM 插件能力，实现了对云原生流量管理与大模型应用场景的统一支持。它不仅提供传统的微服务路由和 Kubernetes Ingress 管理，还内置了 AI 网关特性与 MCP 服务托管功能，能够有效简化 LLM 应用的接入与工具调用流程。本文将深入剖析其系统架构，并重点介绍核心组件、部署方式以及针对 AI 场景的增强功能。

摘要

基于您提供的 GitHub 仓库信息及 DeepWiki 文档片段，以下是关于 Higress 的简洁总结：

1. 项目概况

• 定义：Higress 是一个云原生 API 网关，也是一款 AI 原生（AI Native）网关。
• 基础架构：基于 Istio 和 Envoy 构建，利用 WebAssembly (WASM) 插件系统进行扩展。
• 开发语言：Go。
• 热度：目前拥有超过 7,000 星标。

2. 核心功能与主要用途 Higress 主要服务于以下三大核心场景：

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

3. 架构优势

• 控制面与数据面分离：架构清晰，配置管理（控制面）与流量处理（数据面）解耦。
• 高性能配置分发：配置变更通过 xDS 协议传播，延迟为毫秒级，且连接不中断。
• 长连接友好：非常适合 AI 流式响应等需要保持长连接的场景。

总结：Higress 是一款将传统微服务网关能力与 AI 时代需求（LLM 统一接入、Agent 工具集成）深度融合的开源网关，旨在为云原生应用和 AI 应用提供统一、高效的流量入口管理。

评论

总体评价

Higress 是目前云原生网关领域中将流量治理与AI原生应用基础设施结合得最为彻底的开源项目之一。它不仅继承了基于 Envoy/Istio 的高性能流量处理基因，更通过内置 WASM 插件市场和 AI 网关特性，解决了大模型时代应用落地中的协议转换与安全管控痛点，是构建现代化 AI 应用入口的强力候选方案。

深入分析依据

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

• 事实：Higress 基于 Istio 和 Envoy 构建，并深度集成了 WebAssembly (WASM) 插件系统。其核心定位明确为“AI Native API Gateway”，提供了针对 LLM 的专用特性以及 MCP (Model Context Protocol) 服务器托管能力。
• 推断：传统网关（如 Nginx,早期的 Kong）主要关注 HTTP/TCP 转发，而 Higress 的差异化在于它将 AI 调用视为一等公民。通过 WASM 技术，它实现了控制平面与数据平面的逻辑解耦，允许开发者使用 C++/Go/Rust/AssemblyScript 编写高性能插件而无需重启网关。更重要的是，它内置了对 LLM 协议（如 OpenAI 格式）的统一处理，使得后端可以无缝切换不同模型提供商，这种**“模型侧车”模式**是极具前瞻性的架构创新。

2. 实用价值：解决 AI 落地中的“最后一公里”连接与安全

• 事实：DeepWiki 提及 Higress 提供了 MCP 服务器托管能力，以及 Kubernetes Ingress 和微服务路由等传统网关功能。
• 推断：在当前 AI 应用爆发期，企业面临两大痛点：一是模型 API 的密钥泄露风险，二是多模型切换的改造成本。Higress 通过作为统一 AI 网关，在企业内部屏蔽了后端模型差异，实现了集中式的密钥管理与鉴权（解决安全问题）；同时，其对 MCP 的支持意味着它不仅仅是一个流量入口，更是 AI Agent 的工具调度中心，极大地降低了 Agent 接入外部服务的复杂度。对于已有 K8s 架构的企业，它可以在不引入额外组件的情况下接管流量，实用价值极高。

3. 代码质量与架构：云原生标准的工业化实践

• 事实：项目由阿里巴巴主导，使用 Go 语言编写，星标数 7k+。文档结构清晰，覆盖了从核心架构、构建部署到开发指南的全方位内容。
• 推断：作为阿里云核心产品（Higress 开源版）的底层实现，其代码架构遵循了严格的云原生标准。控制平面与数据平面分离的设计保证了系统的可扩展性。Go 语言的使用保证了控制面在处理配置分发时的高并发性能。文档的多语言支持（含中英日）及其对 DeepWiki 的集成，表明该项目具备高度的工程化成熟度，适合作为企业级基础设施进行二次开发。

4. 社区活跃度与学习价值：头部厂商背书的生态标杆

• 事实：GitHub 星标增长迅速，且明确由阿里巴巴维护。
• 推断：在开源网关领域，有顶级大厂背书是项目生命力的保障。相比于个人项目，Higress 的迭代速度与稳定性更有保障。对于开发者而言，研究 Higress 的源码是学习**“如何基于 Envoy 构建上层控制平面”以及“如何设计 WASM 插件生态”**的绝佳范例。其 AI 网关的实现逻辑，也为开发者理解如何将传统中间件进行 AI Native 改造提供了重要的参考范本。

5. 潜在问题与改进建议

• 推断：虽然功能强大，但基于 Envoy 和 Istio 的架构使得部署复杂度相对较高（通常需要 K8s 环境），对于仅有简单转发需求的小型团队可能存在“杀鸡用牛刀”的问题。此外，AI 网关领域的竞争日益激烈（如专门做 LLM Gateway 的初创项目），Higress 需要在 AI 特性（如 Prompt 模板管理、Token 级别的流式处理优化）上保持快速迭代，避免被垂直领域的轻量级工具分流。

边界条件与验证清单

不适用场景：

• 边缘计算或资源极度受限的嵌入式环境。
• 仅需极其简单的反向代理，且不需要动态配置或 AI 功能的场景。
• 非 Kubernetes 环境下的传统虚拟机部署（虽然支持，但无法发挥最大 K8s 编排优势）。

快速验证清单：

1. WASM 插件热加载测试：在网关运行时，上传一个修改响应头的 WASM 插件，验证是否无需重启进程即可生效。
2. AI 协议转换验证：配置一个路由，将客户端发送的 OpenAI 格式请求转发至非 OpenAI 兼容的模型接口（如通义千问或 Ollama），检查网关是否自动完成了协议适配。
3. MCP 服务连通性：配置一个标准的 MCP 工具（如文件读取），通过 Higress 暴露给 AI 客户端，验证 Agent 是否能通过网关成功调用该工具。
4. 高并发稳定性指标：使用压测工具模拟 10k QPS 的 LLM 流式请求，观察 CPU/内存占用及连接建立延迟，确认 Envoy

技术分析

以下是对阿里巴巴开源的 Higress 仓库的深入技术分析。

Higress 深度技术分析报告

1. 技术架构深度剖析

技术栈与架构模式

Higress 的核心定位是 “AI Native API Gateway”。它建立在 云原生 的基石之上，采用了典型的 控制平面与数据平面分离 的架构模式。

• 底层基石：深度集成 Envoy 作为高性能数据平面，利用 Istio 的控制平面能力（主要是 xDS 协议下发机制）。
• 技术栈：主要使用 Go 语言开发控制平面和配置管理逻辑，利用 C++ (Envoy) 处理核心网络流量，插件扩展采用 WebAssembly (WASM)（通常为 Rust 或 C++ 编译，也可用 Go/AssemblyScript）。
• 架构模式：
  • Istio 扩展模式：Higress 并非从零造轮子，而是作为一个 Ingress Gateway 或 API Gateway 接入 Istio 体系。它复用了 Istio 的配置监听和分发机制，但针对 API 网关的高性能和易用性进行了深度定制。
  • WASM 插件化：这是其架构的核心。它将业务逻辑（如鉴权、限流、AI 请求转换）与核心网关解耦，通过 WASM 虚拟机动态加载，实现了热插拔。

核心模块与关键设计

1. Router (路由层)：基于域名、路径、Header 等进行 HTTP/HTTPS 路由匹配，支持流量灰度发布。
2. WASM Plugin System (WASM 插件系统)：允许开发者编写 .wasm 文件并在运行时注入到 Envoy 中。这解决了传统 Lua 插件（如 OpenResty）在隔离性和安全性上的痛点。
3. AI Gateway (AI 网关层)：这是 Higress 最新的核心模块。它不仅仅是透传流量，还内置了对 LLM（大语言模型）协议的处理能力。
4. MCP (Model Context Protocol) Server：支持作为 MCP 服务器托管，为 AI Agent 提供工具调用接口。

技术亮点与创新点

• 毫秒级配置推送：基于 Istio 的 xDS 协议，配置变更可实现秒级甚至毫秒级生效，且无需重启网关进程，特别适合 AI 流式响应中的长连接场景，避免连接中断导致的用户体验下降。
• AI 原生集成：不同于传统网关需要手写脚本处理 LLM 的请求体，Higress 内置了主流 LLM 提供商的协议转换，实现了“一次开发，多处调用”的标准化。
• Kubernetes 原生：完全兼容 K8s Ingress API，降低了 K8s 用户的使用门槛。

架构优势分析

• 高性能：数据平面基于 Envoy，具备非阻塞 I/O 和 L4/L7 负载均衡能力，吞吐量极高。
• 安全性：WASM 插件运行在沙箱中，崩溃不会导致网关主进程崩溃，且提供了内存隔离。
• 可扩展性：通过 WASM，开发者可以用 Rust/C++/Go 编写复杂逻辑，无需修改网关核心代码。

2. 核心功能详细解读

主要功能与使用场景

1. AI 网关：
   • 功能：统一管理 OpenAI, Azure, Anthropic, 通义千问等 LLM 的 API Key；提供 Token 计费、限流、请求/响应重写（如将 Prompt 模板注入请求体）。
   • 场景：企业内部统一接入多个大模型，控制成本，防止 Key 泄露。
2. MCP 服务器托管：
   • 功能：允许将内部服务注册为 AI Agent 的工具。
   • 场景：AI Agent 需要查询数据库或调用内部 API 时，Higress 提供标准化的 MCP 协议暴露。
3. 传统 API 网关：
   • 功能：认证鉴权（OIDC, API Key）、流量控制（QPS 限流）、金丝雀发布。
   • 场景：微服务架构下的流量入口管理。

解决的关键问题

• LLM 碎片化问题：解决了应用层需要适配不同 LLM 厂商 SDK 的问题，Higress 将其统一为标准 OpenAI 协议或自定义协议。
• AI 流式传输的稳定性：传统网关在处理流式（SSE）时，配置变更往往导致连接断开。Higress 的控制平面架构保证了长连接的稳定性。
• 插件扩展的隔离性：解决了 Nginx/Lua 插件中一个插件崩溃导致整个网关不可用的风险。

与同类工具对比

技术实现原理

• AI 协议转换：通过 WASM 插件拦截 HTTP 请求，解析 Body，根据 Header 识别目标厂商，动态重组请求体格式（例如将通义千问的格式转为 OpenAI 格式），响应时再逆向转换。
• 流式处理：利用 Envoy 的 Async Message Filter 机制，在流式传输过程中逐块处理数据，实现无感知的日志记录或内容审核。

3. 技术实现细节

关键技术方案

• xDS 协议优化：Higress 对 Istio 的控制平面进行了“剪枝”，去除了 Sidecar 注入等非网关必需的组件，仅保留 Gateway 相关的配置下发逻辑，减轻了控制面的负担。
• WASM 虚拟机集成：集成了 Wasmtime 或 V8 引擎。在 Envoy 的 Filter Chain 中，WASM Filter 被插入到 HTTP Filter 阶段。Go 侧负责将 .wasm 文件通过 gRPC 流式推送到 Envoy。

代码组织结构

• pkg/：核心业务逻辑，包含配置解析、路由匹配、Dubbo/HTTP 协议转换。
• plugins/：内置 WASM 插件的源码（如 Key Auth, JWT Auth）。
• router/：路由规则引擎，支持基于内容的路由。
• bootstrap/：Envoy 的启动配置模板生成逻辑。

性能优化与扩展性

• 零拷贝：在 Envoy 层面处理网络数据，尽量减少内核态与用户态的数据拷贝。
• 连接池：对后端服务（Upstream）维护 HTTP/2 连接池，复用连接以减少握手开销，这对频繁请求 LLM 接口至关重要。
• 水平扩展：无状态设计，可以通过 K8s HPA (Horizontal Pod Autoscaler) 根据 CPU 或 QPS 指标自动扩容 Pod。

技术难点与解决方案

• 难点：WASM 的冷启动延迟和内存开销。
• 方案：Higress 支持 WASM 插件的预加载和缓存机制。同时，通过限制单个插件的内存上限（Memory Limit）防止 OOM。
• 难点：AI 上下文长度过长导致的网关内存压力。
• 方案：采用流式转发，不在网关层缓存完整的 Response Body，而是“透传”数据，保持内存占用恒定。

4. 适用场景分析

适合的项目

1. AI 应用开发：特别是需要同时接入多个 LLM 厂商（如国内大模型 + OpenAI）的 SaaS 应用。
2. 微服务架构：基于 Kubernetes 的微服务体系，需要统一的流量入口和治理能力。
3. 企业级 API 管理：需要精细化的访问控制、流量监控和插件定制的中大型企业。

最有效的情况

• 当你的业务涉及 AI Agent 开发，需要将内部 HTTP 服务封装为 MCP 工具时。
• 当你需要对 LLM 的调用进行 成本控制（如限制单用户 Token 数）时。

不适合的场景

• 极简静态站点：对于只需要简单反向代理的场景，Higress 的架构过于重，Nginx 更合适。
• 非 K8s 环境：虽然支持二进制部署，但其威力在 K8s 中才能完全发挥，在虚机或物理机部署运维复杂度较高。

集成方式与注意事项

• Ingress 模式：作为 K8s Ingress Controller 部署，通过 Ingress 资源配置路由。
• Gateway API 模式：支持更现代的 Gateway API CRD。
• 注意：WASM 插件若涉及复杂计算（如加解密），会显著增加 CPU 负载，建议将重逻辑卸载到外部服务（Golang Service）通过 gRPC 调用，而非全部写在 WASM 中。

5. 发展趋势展望

技术演进方向

• 更强的 AI 路由能力：基于请求内容的智能路由。例如，根据 Prompt 的语义自动判断路由到“便宜模型”还是“昂贵模型”。
• 可观测性增强：针对 AI 场景的 Trace，自动记录 Token 消耗、首字生成时间（TTFT）等关键指标。

社区反馈与改进空间

• 文档与生态：虽然代码质量高，但相比 Kong 或 APISIX，WASM 插件的开发文档和第三方插件市场尚需丰富。
• 控制面性能：在大规模路由（如 10,000+ 规则）场景下，Istio 的控制面压力较大，Higress 需持续优化配置分发的性能。

与前沿技术结合

• eBPF：未来可能在 L3/L4 层面引入 eBPF 替代部分 iptables 逻辑，进一步提升网络转发性能。
• Rust：随着 WASM 生态的成熟，Rust 编写的高性能插件将成为主流。

6. 学习建议

适合的开发者

• 具备 Go 语言基础的后端工程师。
• �

代码示例

 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

# 示例1：Higress 网关路由配置
def configure_higress_route():
    """
    配置 Higress 网关的路由规则
    解决问题：将不同路径的请求转发到不同的后端服务
    """
    from higress import Gateway
    
    # 创建网关实例
    gateway = Gateway()
    
    # 配置路由规则
    gateway.add_route(
        path="/api/v1/*",  # 匹配所有 /api/v1/ 开头的请求
        service="user-service",  # 转发到用户服务
        methods=["GET", "POST"],  # 允许的HTTP方法
        plugins=["auth", "rate-limit"]  # 启用认证和限流插件
    )
    
    gateway.add_route(
        path="/api/v2/*",
        service="order-service",
        methods=["GET", "POST", "PUT"],
        plugins=["auth"]
    )
    
    return gateway

# 使用示例
gateway = configure_higress_route()
gateway.start()  # 启动网关

 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

# 示例2：Higress 插件开发
def custom_auth_plugin():
    """
    开发自定义认证插件
    解决问题：实现基于 JWT 的身份验证
    """
    from higress import Plugin
    
    class JWTAuthPlugin(Plugin):
        def __init__(self):
            super().__init__("jwt-auth")
        
        def process_request(self, request):
            # 从请求头获取 JWT token
            token = request.headers.get("Authorization", "")
            
            # 验证 token
            if not self.validate_token(token):
                return {"status": 401, "body": "Unauthorized"}
            
            # 将用户信息注入请求头
            user_info = self.decode_token(token)
            request.headers["X-User-Id"] = user_info["user_id"]
            
            # 继续处理请求
            return None
        
        def validate_token(self, token):
            # 实际项目中应实现真实的 JWT 验证逻辑
            return token.startswith("Bearer ")
        
        def decode_token(self, token):
            # 实际项目中应实现真实的 JWT 解析逻辑
            return {"user_id": "12345"}
    
    return JWTAuthPlugin()

# 使用示例
auth_plugin = custom_auth_plugin()
gateway.register_plugin(auth_plugin)

 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

# 示例3：Higress 流量管理
def traffic_splitting():
    """
    配置灰度发布流量分割
    解决问题：将部分流量导向新版本服务进行测试
    """
    from higress import Gateway
    
    gateway = Gateway()
    
    # 配置流量分割规则
    gateway.add_traffic_split(
        path="/api/v3/*",
        services={
            "stable": 90,  # 90% 流量到稳定版
            "canary": 10   # 10% 流量到金丝雀版
        },
        split_by="user_id",  # 基于用户ID进行流量分割
        canary_condition=lambda headers: headers.get("X-Beta-User") == "true"
    )
    
    return gateway

# 使用示例
gateway = traffic_splitting()
gateway.start()

案例研究

1：阿里巴巴内部电商业务体系

1：阿里巴巴内部电商业务体系

背景: 在阿里巴巴庞大的电商生态系统中，微服务架构极其复杂，涉及成千上万的服务实例。随着业务从单体架构向云原生架构演进，传统的 Nginx+Lua 网关方案在维护成本、扩展性和云原生适配方面逐渐显露出瓶颈。

问题: 原有的 API 网关面临以下挑战：

1. 扩展性受限：在应对大促流量洪峰时，配置热更新和动态扩容的灵活性不足。
2. 功能割裂：流量管理与安全防护（WAF）往往分离，导致配置复杂且存在性能损耗。
3. Kubernetes 适配困难：在云原生环境下，需要更高效的 Ingress Controller 来管理南北向流量。

解决方案: 阿里基于内部在 Nginx、Envoy 和 MOSN（主要服务网格代理）的深厚积累，开源了 Higress。Higress 遵循 Ingress/Gateway API 标准，深度集成了 Envoy 的高性能，并针对阿里云生态进行了优化。它将 API 网关与 K8s Ingress Controller 的能力合二为一。

效果:

1. 性能提升：基于 Envoy 的高性能架构，显著降低了请求延迟，提升了吞吐量。
2. 统一管理：实现了从 K8s Ingress 到 API 网关的统一配置管理，极大降低了运维复杂度。
3. 生态兼容：完美兼容阿里云现有生态，支持一键对接 WAF 防护和日志服务，实现了流量的全链路治理和安全防护。

2：萝卜运力（RoboTaxi）基础设施平台

2：萝卜运力（RoboTaxi）基础设施平台

背景: 萝卜运力作为一家领先的自动驾驶出行服务公司，其业务高度依赖微服务架构来处理车辆调度、订单分发和海量实时数据。随着业务在全国多地的扩张，对 API 网关的稳定性、安全性和云原生适配能力提出了极高要求。

问题: 在引入 Higress 之前，团队面临以下痛点：

1. 协议支持单一：业务中存在大量 gRPC 服务，原有网关对 gRPC 的支持和协议转换不够完善。
2. 认证鉴权复杂：多端（App、车载终端、管理后台）接入，需要复杂的认证逻辑，传统网关配置繁琐。
3. 插件生态封闭：难以快速开发自定义插件来满足自动驾驶业务特有的流量控制和安全逻辑。

解决方案: 萝卜运力将基础设施迁移至基于 Higress 的云原生网关体系。利用 Higress 原生支持 gRPC 和 Dubbo 的能力，解决了服务间通信问题。同时，利用 Higress 的 Wasm 插件市场，快速实现了针对特定业务逻辑的流量拦截和修改。

效果:

1. 协议无缝互通：完美解决了 gRPC 服务对外暴露时的协议转换问题，提升了前后端交互效率。
2. 安全增强：通过 Higress 的插件机制实现了精细化的访问控制，有效保障了车辆与云端通信的安全性。
3. 开发效率提升：开发人员可以使用 Go 或 C++ 编写 Wasm 插件，无需重启网关即可动态下发配置，大幅提升了迭代速度。

3：DeepFlow 可观测性平台集成

3：DeepFlow 可观测性平台集成

背景: DeepFlow 是一款开源的云原生可观测性平台，旨在解决微服务架构下的网络监控和故障排查难题。在为用户提供服务时，DeepFlow 需要采集和处理海量的网络流量数据。

问题: 在混合云和容器环境下，流量管理极其复杂：

1. 流量可视化困难：传统网关难以提供细粒度的流量日志，导致故障排查时缺乏上下文。
2. 服务注册发现：在 K8s 环境中，服务频繁上下线，网关需要能够实时感知服务变化。
3. 高可用性要求：作为监控底座，网关本身不能成为单点故障或性能瓶颈。

解决方案: DeepFlow 采用 Higress 作为其云原生网关，利用 Higress 对 Istio 和 Kubernetes 的深度集成能力。Higress 不仅作为流量入口，还配合 DeepFlow 实现了流量的深度可观测性。通过 Higress 的日志插件，将详细的 API 请求信息推送给 DeepFlow 进行分析。

效果:

1. 全链路可观测：结合 Higress 的日志能力和 DeepFlow 的分析能力，实现了从 API 网关到微服务内部的全链路监控。
2. 自动化运维：Higress 自动监听 K8s Service 变化，实现了零配置变更的流量路由，减少了人工干预。
3. 高吞吐保障：Higress 的高性能处理能力确保了即使在海量监控数据上报时，网关依然保持低延迟和高可用。

对比分析

与同类方案对比

优势分析

• 深度集成云原生：与Istio和Kubernetes无缝集成，适合微服务架构。
• 高性能：基于Envoy和Istio优化，提供低延迟和高吞吐量。
• 灵活扩展：支持Wasm和Lua插件，满足定制化需求。
• 企业级支持：阿里提供企业版和技术支持，适合大规模部署。

不足分析

• 学习曲线：对Kubernetes和Istio不熟悉的用户可能需要时间适应。
• 依赖性：强依赖Kubernetes环境，非容器化部署可能受限。
• 社区规模：相比Kong和APISIX，社区规模和插件生态稍小。

最佳实践

最佳实践指南

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

说明: Higress 基于 Istio 与 Envoy 构建，原生支持 WebAssembly (Wasm)。通过 Wasm 插件，开发者可以使用 C++、Go、Rust 或 AssemblyScript 等语言编写自定义逻辑（如自定义认证、流量整形、响应修改），而无需修改网关核心代码或重新编译镜像。这极大地提升了网关的灵活性和迭代速度。

实施步骤:

1. 确定业务需求，判断是否需要自定义处理逻辑（如特殊的 Header 转换、对接第三方 Auth 系统）。
2. 使用 Higress 官方提供的 wasm-go 等 SDK 开发插件逻辑。
3. 将编译好的 .wasm 文件上传至 Higress 控制台或通过 OCI 镜像仓库进行分发。
4. 在网关控制台配置插件规则，指定生效的路由范围和参数。

注意事项: 开发 Wasm 插件时需注意内存管理与性能开销，避免阻塞主线程导致请求延迟增加。

实践 2：精细化流量路由与服务治理

说明: 利用 Higress 强大的路由能力实现基于权重、Header、Cookie 或 URL 参数的流量分流。这常用于蓝绿发布、金丝雀发布以及 A/B 测试场景。同时，结合服务发现（Nacos, Consul, Kubernetes DNS）实现自动化的服务注册与健康检查。

实施步骤:

1. 配置服务来源，将 Higress 与注册中心（如 Nacos）或 Kubernetes Service 关联。
2. 创建路由规则，配置匹配条件（如 /api/v1 或特定 Header）。
3. 设置多版本服务的流量权重（例如：将 10% 的流量路由到 v2 版本）。
4. 配置超时、重试及熔断策略，以增强系统的容错能力。

注意事项: 在进行金丝雀发布时，务必确保新旧版本的数据兼容性，并配置详细的监控指标以便快速回滚。

实践 3：全面的安全防护与认证鉴权

说明: Higress 提供了从网络层到应用层的多重安全防护。除了基础的 HTTPS/TLS 终止外，还支持主流认证协议（如 OIDC、Keycloak、JWT）以及 IP 黑白名单限制。对于 API 接口，建议启用高精度的访问控制，防止未授权访问。

实施步骤:

1. 在网关配置证书，开启 HTTPS，并配置 HTTP 到 HTTPS 的自动跳转。
2. 启用并配置 jwt-auth 插件或 opa 插件以实现统一的身份认证。
3. 配置 IP 访问控制插件，限制特定网段的访问。
4. 针对后端服务配置严格的 CORS 策略，防止跨域攻击。

注意事项: 定期轮换 TLS 证书和 JWT 密钥；避免在 URL 或日志中泄露敏感的 Token 信息。

实践 4：对接 AI 大模型与 Prompt 管理

说明: Higress 提供了专门针对 AI 服务的插件（如 ai-proxy、ai-statistics），能够作为 AI 大模型（LLM）的统一网关。它支持将客户端请求转发至不同的模型提供商（如 OpenAI, Azure, 通义千问等），并统一处理 Prompt 模板、Token 计费和上下文缓存。

实施步骤:

1. 配置后端服务地址指向 LLM 提供商的 API Endpoint。
2. 配置 ai-proxy 插件，设定目标模型名称和 API Key。
3. 定义 Prompt 模板，在网关层对用户输入进行预处理或增强。
4. 配置流式响应处理，确保端到端的流式传输体验。

注意事项: 注意监控 Token 消耗量以控制成本；确保 Prompt 模板中不包含敏感指令注入风险。

实践 5：全链路可观测性与监控集成

说明: 为了确保微服务架构的稳定性，必须建立完善的可观测性体系。Higress 原生支持集成 Prometheus、SkyWalking 和 OpenTelemetry，能够采集详细的访问日志、指标和链路追踪数据，帮助快速定位性能瓶颈或故障点。

实施步骤:

1. 在 Higress 全局配置中开启 Prometheus Metrics 或 OpenTelemetry Tracing。
2. 配置日志采集（如关联 SLS 或 Elasticsearch），定义自定义的日志格式（包含 Trace ID, Upstream Response Time 等）。
3. 集成 Grafana 或自建监控平台，导入 Higress 官方 Dashboard。
4. 设置关键指标（如 4xx/5xx 错误率、请求延迟 P99）的告警规则。

注意事项: 在高并发场景下，日志采样率需合理配置，避免海量日志对存储和网关性能造成压力。

实践 6：高性能配置与资源调优

说明: Higress 的性能受限于底层 Envoy 的

性能优化建议

性能优化建议

优化 1：启用高性能 HTTP/3 (QUIC) 协议

说明: Higress 基于 Envoy 和 Istio 构建，底层网络栈支持 QUIC 协议。在弱网环境或高丢包率场景下，HTTP/3 相比 HTTP/2 能显著减少连接建立延迟和队头阻塞（Head-of-Line Blocking）问题，大幅提升吞吐量。

实施方法:

1. 在 Higress 网关的监听器配置中，启用 HTTP/3 协议支持。
2. 配置 UDP 端口（通常端口 443）的防火墙和安全组放行策略。
3. 调整 QUIC 协议参数，如 max_concurrent_streams 和 initial_idle_timeout。

预期效果: 在弱网环境下，请求延迟降低 30%-50%，连接建立成功率提升。

优化 2：配置 WASM 插件的本地缓存与预编译

说明: Higress 的核心优势之一是支持 WASM (WebAssembly) 插件扩展。然而，每次请求即时加载或编译 WASM 代码会带来巨大的 CPU 开销。通过启用 AOT (Ahead-Of-Time) 编译和代码缓存，可以消除这一瓶颈。

实施方法:

1. 在部署 WASM 插件时，确保启用 enable_aot 或相关预编译选项。
2. 配置网关的 wasm 过滤器，将常用的插件代码缓存至内存，避免重复从磁盘或网络加载。
3. 移除生产环境插件中不必要的调试日志和 console.log 输出。

预期效果: WASM 插件执行延迟降低 60%-80%，CPU 利用率显著下降。

优化 3：优化全链路超时与重试策略

说明: 默认的超时和重试策略往往过于保守，导致后端服务在处理高并发时堆积大量无效请求。精细化的超时控制可以快速释放连接资源，防止雪崩效应。

实施方法:

1. 根据业务 P99.9 耗时，合理设置 routeTimeout 和 upstreamTimeout，避免默认的无限等待。
2. 配置指数退避的重试策略，限制最大重试次数（建议 2-3 次），并对非幂等请求（如 POST）禁用重试。
3. 启用请求镜像或熔断机制，在检测到后端响应延迟突增时自动熔断。

预期效果: 后端服务无效负载减少 20%-40%，系统整体可用性提升。

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

说明: 频繁的 DNS 解析和建立新的 TCP 连接会消耗大量资源。Higress 作为网关，通常连接固定的后端服务地址，通过配置严格的 DNS 缓存和 HTTP 连接池，可大幅减少网络握手开销。

实施方法:

1. 在 Cluster 配置中，将 dns_refresh_rate 设置为较长的间隔（如 60s 或更长）。
2. 增大 HTTP 连接池大小，确保 max_connections 足以应对峰值流量，避免频繁建立连接。
3. 启用 HTTP/2 协议与后端服务通信，利用多路复用减少连接数。

预期效果: 网关与后端建连开销降低 90%，网关内存占用更加平稳。

优化 5：实施精细化日志采样与异步上报

说明: 在高流量场景下，同步记录详细的访问日志会严重阻塞 I/O 线程。通过日志采样和异步上报，可以在保留关键观测性数据的前提下，最小化日志对吞吐量的影响。

实施方法:

1. 配置 Access Log 的采样率（例如 log_sampler: 100 表示每 100 个请求记录 1 条）。
2. 使用 OpenTelemetry 或类似协议，将日志和 Tracing 数据改为异步批量发送。
3. 仅在错误日志中记录完整的 Request/Response Body，正常日志仅记录关键元数据。

学习要点

• 根据提供的上下文（Alibaba/Higress 在 GitHub 趋势中），以下是关于该项目的关键要点总结：
• Higress 是阿里云开源的基于 Istio 的下一代云原生 API 网关，旨在解决云原生架构下的流量管理问题。
• 它深度集成了 K8s Ingress 与 Gateway API 标准，能够无缝替代 Nginx Ingress Controller 并提供更强大的功能。
• 该项目将 Envoy 作为高性能数据面，在提供极高吞吐量的同时显著降低了资源消耗与延迟。
• Higress 原生支持 WASM (WebAssembly) 技术，允许开发者使用 C++/Go/Rust 等语言编写插件来灵活扩展网关业务逻辑。
• 它提供了开箱即用的流量治理能力，包括负载均衡、灰度发布、限流熔断以及服务安全防护。
• 作为一站式网关，它同时支持南北向（流量入口）和东西向（服务间）流量管理，简化了微服务架构的网络拓扑。

学习路径

学习路径

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

学习内容:

• 云原生网关的基本概念与 Higress 的定位
• Higress 的核心架构与组件（Ingress Controller, Gateway）
• 基础术语：路由、服务、插件、Upstream
• 容器化基础：Docker 和 Kubernetes 简要复习
• Higress 与传统网关（如 Nginx, APISIX）的区别

学习时间: 1-2周

学习资源:

• Higress 官方文档 (架构介绍)
• Higress GitHub 仓库 README
• 云原生网关入门视频教程

学习建议: 重点理解 Higress 基于 Istio 和 Envoy 的技术底座，但不要一开始就陷入底层代码细节。建议先在本地或 Docker 环境中运行一个 Standalone 版本的 Higress，通过官方提供的 QuickStart 示例跑通第一个流量转发流程。

阶段 2：生产部署与流量管理

学习内容:

• 在 Kubernetes 集群中部署 Higress（Helm 安装与配置）
• Ingress API 与 Gateway API 的使用
• 核心流量管理功能：域名路由、路径匹配、Header 路由、权重分流（金丝雀发布）
• 负载均衡策略与健康检查配置
• 服务发现集成（Nacos, Consul, K8s Service）
• TLS/HTTPS 证书管理与配置

学习时间: 2-3周

学习资源:

• Higress 官方文档 - 部署与流量管理章节
• Kubernetes Ingress 官方文档
• Higress 官方示例库

学习建议: 动手搭建一个 K8s 测试集群（可使用 Minikube 或 Kind），尝试编写 YAML 文件来定义路由规则。重点练习如何将外部流量通过 Higress 导入集群内部服务，并模拟一次蓝绿发布或金丝雀发布过程。

阶段 3：插件开发与安全防护

学习内容:

• Higress 插件系统原理（Wasm 插件与 Lua 插件）
• 使用官方插件市场（认证鉴权、限流熔断、请求头修改）
• 自定义 Wasm 插件开发（使用 Go 或 C++ 编写，AssemblyScript 编译）
• 安全防护：配置 IP 访问控制、Basic Auth、JWT 鉴权、Keyless 认证
• 全链路安全：对接 WAF 防护与 Bot 检测

学习时间: 3-4周

学习资源:

• Higress 官方文档 - 插件开发指南
• Envoy Wasm 官方文档
• Higress GitHub Plugin 仓库源码

学习建议: 从使用现有的官方插件解决具体问题开始（例如使用 Key Rate Limit 插件限制 API 调用频率）。随后，尝试编写一个简单的 Wasm 插件（例如修改请求响应头），理解插件的生命周期和数据处理流程。

阶段 4：高级特性与生态集成

学习内容:

• Higress 对接 AI 服务（与大模型模型 LLM 的集成与 Prompt 管理）
• 服务治理：全链路灰度、超时重试、故障注入
• 高可用与性能调优：网关资源限制、QPS 压测与优化
• 可观测性集成：对接 Prometheus/Grafana 监控、SkyWalking/Zipkin 链路追踪
• 多集群管理与多租户支持

学习时间: 3-4周

学习资源:

• Higress 官方博客与最佳实践案例
• Prometheus 与 Grafana 官方文档
• Higress AI 网关特性文档

学习建议: 关注 Higress 在 AI 领域的最新特性，尝试配置一个简单的 AI 代理网关。同时，深入学习如何通过 Prometheus 监控大流量下的网关性能指标（如 P99 延迟、成功率），并据此调整配置参数。

阶段 5：源码剖析与架构设计

学习内容:

• Higress 源码结构分析（Control Plane 与 Data Plane 交互）
• Envoy 扩展机制深度解析
• 自定义 Controller 开发
• 参与开源社区贡献（PR 提交流程）
• 企业级网关架构设计（跨云容灾、多级网关设计）

学习时间: 持续学习

学习资源:

• Higress GitHub 源码
• Istio 源码分析相关书籍或文档
• CNCF 云原生社区技术分享

学习建议: 阅读源码时，建议从核心的 XDS 协议推送逻辑和路由匹配逻辑入手。尝试在本地编译调试 Higress，并修复一个简单的 Bug 或添加一个文档中缺失的小功能，以此作为精通的标志。

常见问题

1: Higress 是什么？它与 Nginx 或 Kong 有什么区别？

1: Higress 是什么？它与 Nginx 或 Kong 有什么区别？

A: Higress 是一款基于阿里内部通用的流量网关和 Istio 开源项目构建的云原生 API 网关。它旨在为云原生架构提供统一的流量入口，集成了动态路由、安全防护、服务治理等功能。

与 Nginx 相比，Higress 支持热更新配置，无需重启进程即可生效，且原生支持 Kubernetes Ingress 和 Gateway API。与 Kong 相比，Higress 深度集成了 Istio 生态，可以更方便地实现服务网格内的流量管理与南北向（入口）流量的统一，同时它基于阿里内部多年的生产实践，在性能和高可用性上经过大规模验证。

2: Higress 与 Istio 的关系是什么？它是否可以替代 Istio 的 Ingress Gateway？

2: Higress 与 Istio 的关系是什么？它是否可以替代 Istio 的 Ingress Gateway？

A: Higress 与 Istio 保持着紧密的兼容关系。从架构上看，Higress 可以被视为 Istio Ingress Gateway 的增强版或替代品。它复用了 Istio 的数据平面组件 Envoy，并对其进行了深度优化。

虽然标准的 Istio Ingress Gateway 功能强大，但在配置管理、协议转换（如 Dubbo 转 HTTP）以及对接阿里云内部生态方面存在一定的局限性。Higress 在保持 Istio 标准 API 兼容的同时，提供了更友好的控制台、更丰富的插件扩展能力以及更高的性能稳定性，特别适合作为 Kubernetes 集群的统一流量入口。

3: 如何在 Kubernetes 集群中快速安装 Higress？

3: 如何在 Kubernetes 集群中快速安装 Higress？

A: Higress 提供了非常简便的安装方式，主要通过 Helm 进行部署。在确保你已经拥有一个可用的 Kubernetes 集群（版本通常要求 1.19+）并配置好 kubectl 和 helm 命令行工具后，可以执行以下步骤：

1. 添加 Higress 的 Helm 仓库： helm repo add higress.io https://higress.io/helm-charts
2. 更新仓库： helm repo update
3. 执行安装命令（通常安装在 higress-system 命名空间下）： helm install higress higress.io/higress -n higress-system --create-namespace

安装完成后，Higress 的控制台和服务组件将自动部署，你可以通过端口转发或 LoadBalancer 暴露的方式访问控制台。

4: Higress 支持哪些类型的路由配置？是否支持 Dubbo 服务？

4: Higress 支持哪些类型的路由配置？是否支持 Dubbo 服务？

A: Higress 提供了极其灵活的路由配置能力，主要支持以下几种方式：

1. Kubernetes Ingress API: 兼容标准的 K8s Ingress 资源定义，方便从旧网关迁移。
2. Istio Gateway API: 支持 VirtualService、Gateway 等 Istio CRD，适合复杂的灰度发布和流量治理场景。
3. 自定义 CRD: 提供了 IngressRoute 等自定义资源，以支持更高级的功能。

特别值得注意的是，Higress 原生支持 Dubbo 服务。作为阿里系产品，它能够理解 Dubbo 协议，支持将 HTTP/HTTPS 请求转换为 Dubbo 协议调用后端服务，这对于微服务架构中同时存在 Spring Cloud (HTTP) 和 Dubbo 服务的混合场景非常有用。

5: Higress 的插件机制是如何工作的？能否编写自定义插件？

5: Higress 的插件机制是如何工作的？能否编写自定义插件？

A: Higress 采用插件化架构来扩展网关功能。它支持 Wasm (WebAssembly) 技术和 Lua 脚本编写插件。

1. Wasm 插件: 这是 Higress 推荐的扩展方式。Wasm 插件具有沙箱隔离、高性能、热加载（无需重启网关）以及跨语言编写（如 C++, Go, Rust, AssemblyScript 等）的优势。用户可以编写自定义逻辑来实现鉴权、限流、请求/响应修改等功能。
2. Lua 插本: 继承了 OpenResty 的生态，支持使用 Lua 编写脚本，适合轻量级的逻辑处理。

Higress 提供了一个插件市场，内置了许多常用插件（如 Keyless 认证、请求头修改等）。同时，用户可以开发自己的 Wasm 插件并通过控制台上传或配置引用，实现高度定制化的业务逻辑。

6: Higress 如何保证高可用性和性能？

6: Higress 如何保证高可用性和性能？

A: Higress 在设计之初就考虑了大规模生产环境的需求，主要通过以下方式保证高可用和性能：

1. 底层优化: 基于 Envoy C++ 内核，相比纯 Java 网关具有更高的并发处理能力和更低的资源消耗。
2. 热更新: 配置变更通过控制台下发给数据平面，Envoy 可以通过 xDS 协议动态更新配置，无需重启进程，从而保证流量不中断。
3. 健康检查: 自动对接 Kubernetes 的服务发现，实时摘除不健康的 Pod 实例，将

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在本地 Docker 环境中快速部署 Higress，并配置一个简单的路由转发规则，将访问 /httpbin/ 路径的流量转发到公共测试服务 httpbin.org。

提示**:

需要查阅 Higress 的官方 Docker 镜像启动命令，注意端口映射（默认 80/443）。

实践建议

基于 Higress 作为 “AI Native API Gateway” 的定位，结合其作为云原生 API 网关的特性，以下是 6 条针对实际生产环境的实践建议：

1. 利用 WASM 插件实现 AI 请求的精细化处理

• 场景：你需要对发送给 LLM（如 OpenAI, 通义千问等）的 Prompt 进行修改（如注入企业上下文、敏感词过滤），或者对返回结果进行脱敏，但不想修改网关核心代码或重启网关。
• 建议：编写 Go 或 C++ 的 WASM 插件挂载到 AI 路由上。利用 Higress 对 WASM 的高性能支持，在网关层直接处理流式响应的首尾数据，实现无侵入的业务逻辑增强。
• 陷阱：避免在 WASM 插件中进行密集的 CPU 计算或阻塞式网络 I/O 调用，这会显著拉大 AI 请求的 TTFB（首字节时间）。

2. 配置语义化负载均衡与多模型容错

• 场景：你的应用同时接入了多个 LLM 提供商（例如同时使用阿里云通义千问和 Azure OpenAI），希望在某个提供商限流或宕机时自动切换，而不需要修改客户端代码。
• 建议：在 Higress 中配置服务来源，将不同厂商的 API 定义为不同的服务，并在一条路由规则下配置多个目的地。利用 Higress 的主动健康检查能力，当主模型服务不可用时，自动将流量切换到备用模型服务。
• 最佳实践：结合 Higress 的标签路由功能，根据 HTTP Header（如 x-model-provider）将特定用户流量引流到特定的模型版本，实现灰度发布。

3. 针对流式传输的超时与缓冲策略调优

• 场景：AI 应用通常使用 Server-Sent Events (SSE) 或流式响应，默认的网关超时配置可能导致连接过早断开。
• 建议：显式将路由的超时时间设置得较长（例如 5 分钟或更长），并确保网关的 Idle Timeout（空闲超时）配置允许长连接保持。同时，开启 Higress 的全链路透传能力，确保 Transfer-Encoding: chunked 头不被网关错误修改。
• 陷阱：不要在网关层开启过大的 Body Buffer（缓冲），AI 的流式响应通常是无限流，试图缓冲整个响应会导致网关内存溢出（OOM）。

4. 实施基于 Token 或请求成本的速率限制

• 场景：调用 LLM API 成本高昂，且不同模型的 Token 单价不同，传统的基于 QPS（每秒请求数）限流无法有效控制成本。
• 建议：虽然网关主要处理 HTTP 层，但建议结合 Higress 的插件生态，编写或配置基于请求体估算的限流策略。例如，解析请求中的 max_tokens 参数，结合预设的单位成本，计算“每分钟最大消费额度”进行限流。
• 最佳实践：对 API Key 进行精细化的权限管理，不同的 API Key 绑定不同的配额插件配置，防止内部某个应用的异常消耗影响全局。

5. 建立可观测性：重点关注延迟与 Token 消耗

• 场景：排查为什么用户感觉回答慢，是因为模型生成慢，还是网关转发慢？
• 建议：确保开启 Higress 的 Access Log 并对接 Prometheus/Grafana。重点监控 upstream_latency（上游模型耗时）与 request_duration（网关总耗时）的差值。
• 最佳实践：利用 Higress 的日志插件，在响应头中注入元数据（如 x-ai-tokens-used, x-model-version），这样后端业务系统可以直接从 Header 中统计成本，而无需解析响应体。

6. 安全防护：防止 Prompt 注入与 Key 泄露

• 场景：将 AI API 暴露给公网或前端直接

引用

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

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

站内链接

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

相关文章

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