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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,419 (+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 和 Envoy 构建的 AI 原生 API 网关，它通过 WASM 插件扩展了云原生流量管理能力。该项目专为需要集成大模型（LLM）或 AI Agent 工具的场景设计，同时兼容 Kubernetes Ingress 与微服务路由等传统网关功能。本文将介绍其系统架构、核心组件以及 AI 网关特性的具体应用。

摘要

Higress 是阿里巴巴开源的一款云原生 AI 原生 API 网关，基于 Istio 和 Envoy 构建，并使用 Go 语言开发。它通过扩展 WebAssembly (WASM) 插件能力，将控制平面与数据平面分离，旨在为现代云原生应用和 AI 应用提供统一的流量管理入口。

以下是 Higress 的核心特性与功能总结：

1. 核心架构

• 技术基础：基于 Envoy 处理数据平面流量，基于 Istio 进行控制平面管理。
• 高性能配置：配置变更通过 xDS 协议传播，具备毫秒级延迟且不中断连接，特别适用于 AI 长连接流式响应场景。
• 可扩展性：通过 WASM 插件提供强大的扩展能力。

2. 三大核心功能

• AI 网关：专为 LLM 应用设计。
  • 提供统一 API 接口，兼容 30+ 家大模型提供商（LLM Provider）。
  • 支持协议转换、可观测性、缓存（ai-cache）以及安全防护（ai-security-guard）。
• MCP 服务器托管：面向 AI Agent 的工具集成。
  • 托管 Model Context Protocol (MCP) 服务器，使 AI 智能体能够便捷地调用外部工具和服务。
  • 包含 mcp-router、jsonrpc-converter 过滤器及多种服务器实现。
• 传统 API 网关：
  • 作为 Kubernetes Ingress 控制器使用，兼容 nginx-ingress 注解。
  • 处理微服务路由等传统流量管理需求。

总结：Higress 是一款将传统微服务网关能力与 AI 时代需求（大模型管理、Agent 工具调用）深度融合的下一代网关产品。

评论

总体判断：Higress 是目前云原生网关领域中将“AI 原生”理念落地最彻底的开源项目之一，它成功地将传统流量治理与 LLM（大语言模型）应用所需的特殊协议处理融合，不仅是一个高性能的 Ingress 控制器，更是 AI 时代应用架构的关键连接器。

深入评价

1. 技术创新性：从“流量转发”进化为“模型编排”

Higress 的核心差异化在于其AI Native 架构。传统的 API 网关（如 Nginx, Kong）主要处理 HTTP/gRPC 的负载均衡，而 Higress 针对大模型场景进行了深度定制。

• 事实与推断：基于 DeepWiki 提及的“AI Gateway Features”和“WASM Plugin System”，Higress 创新性地引入了LLM 特有的流量治理能力。推断其实际技术价值在于解决了 AI 应用开发中的“非标”问题：
  • 协议转换与统一：它能够将标准的 OpenAI/SSE 协议请求透明地转发给不同厂商的模型（如通义千问、Llama 等），屏蔽了底层 Provider 的差异。
  • Token 级别的精细治理：不同于传统网关的连接数或 QPS 限制，Higress 能够针对 LLM 的 Prompt 和 Response 进行 Token 计费与流控，这对于成本控制至关重要。
  • MCP (Model Context Protocol) 支持：作为 AI Agent 的工具集成标准，Higress 内置了 MCP Server 托管能力，这使得网关从单纯的“管道”变成了 AI Agent 的“工具箱”，这是极具前瞻性的架构升级。

2. 实用价值：解决 AI 落地“最后一公里”的连接难题

Higress 极大地降低了企业接入大模型的复杂度，具有极高的实用价值。

• 事实与推断：文档提到它提供“AI gateway features for LLM applications”和“MCP server hosting”。
  • 关键问题解决：在构建 AI 应用（如 Chatbot）时，开发者常面临模型切换成本高、Prompt 注入攻击风险、以及流式响应（SSE）处理复杂的问题。Higress 通过内置的安全插件（如敏感词过滤、Prompt 注入防御）和请求/响应转换插件，直接在网关层解决了这些问题，保护了后端大模型服务。
  • 应用场景广度：它不仅适用于企业内部的 AI 中台建设，统一管理多个 LLM Vendor 的 API Key 和配额；也适用于 SaaS 厂商，通过其 MCP 能力快速将自家 SaaS 能力暴露给 AI Agent 调用。

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

Higress 继承了 Istio 和 Envoy 的优秀基因，架构设计清晰，代码质量高。

• 事实与推断：描述指出其“Built on Istio and Envoy”且“Separates control plane from data plane”。
  • 架构设计：采用控制平面与数据平面分离的设计。数据平面依赖 Envoy 的高性能 C++ 网络，控制平面使用 Go 语言进行配置管理。这种组合既保证了转发性能（接近 Envoy 原生），又拥有了 Go 语言开发的便利性和扩展性。
  • 扩展性：通过 WASM (WebAssembly) 插件系统，Higress 允许开发者使用 C++/Go/Rust/AssemblyScript 编写插件，且插件热更新无需重启网关。这种设计比传统的 Lua (Nginx) 或 Java Filter 网关在安全性和灵活性上更具优势。
  • 文档完整性：提供了多语言（中/日/英） README 及详细的 DeepWiki 架构文档，表明该项目对国际化与开发者体验非常重视，符合成熟开源项目的标准。

4. 社区活跃度与学习价值

• 社区活跃度：7,400+ 的星标数（Star）在网关领域属于头部梯队。背靠阿里巴巴，该项目有明确的商业支持（Higress 团队），不仅更新频率高，且在国内开发者社区中响应较快，Issue 处理较为积极。
• 学习价值：对于开发者而言，Higress 是学习**“如何将传统云原生技术栈适配 AI 时代”**的最佳范例。通过阅读其 WASM 插件源码，可以学习到如何处理 SSE 流式数据、如何设计拦截器来修改 LLM 上下文，以及如何基于 Envoy 进行二次开发。

5. 潜在问题与改进建议

尽管功能强大，但在实际落地中存在挑战：

• 复杂度曲线：对于仅需简单转发的极小规模应用，Higress 基于 K8s 和 Istio 的部署架构可能显得“过重”。相比 Nginx，其运维门槛较高。
• AI 功能的成熟度：虽然 MCP 和 AI Gateway 是亮点，但这些功能相对较新。推断在极端高并发下的流式转发性能稳定性，以及针对复杂 Prompt 链路的可观测性（Tracing）支持上，可能还需要时间打磨。

6. 对比优势

与 Kong 或 APISIX 相比，Higress 的优势在于**“开箱即用的 AI 特性”**。传统网关处理 AI 流量需要编写大量自定义脚本，而 Higress 将其原生

技术分析

基于您提供的 GitHub 仓库信息（Alibaba/Higress）以及对该项目技术深度的理解，以下是对 Higress 的全面深入分析。

Higress 深度技术分析报告

1. 技术架构深度剖析

Higress 的架构设计体现了**“继承与增强”**的云原生设计哲学。它并非从零构建，而是站在 Istio 和 Envoy 这两个巨人的肩膀上，针对 AI 时代的流量特征进行了深度定制。

• 技术栈与架构模式：

  • 底层引擎：基于 Envoy 构建。Envoy 是 C++ 编写的高性能代理，Higress 利用其处理 L7 层流量的能力。
  • 控制平面：深度集成 Istio。Higress 复用了 Istio 的控制平面能力（如 xDS 协议下发），但对其进行了轻量化和改造，剥离了 Sidecar 模式的沉重负担，专注于 Gateway 模式。
  • 扩展语言：Go（控制面）与 WebAssembly (WASM)（数据面扩展）。Higress 最显著的特点是利用 WASM 来实现数据面的插件化，允许开发者使用 Go/C++/Rust/AssemblyScript 编写逻辑，动态加载到 Envoy 中，无需重启网关。

• 核心模块：

  • Router (路由)：基于 HTTP 头部、路径、Cookie 等进行精细化路由，支持 Kubernetes Ingress API。
  • WASM Plugin System (插件系统)：这是 Higress 的心脏。它提供了一个沙箱环境运行用户代码，实现了逻辑与核心的解耦。
  • AI Gateway (AI 网关)：新增的针对 LLM（大语言模型）的专用模块，处理流式转发、Token 计费、Prompt 模板管理等。

• 架构优势：

  • 配置热更新：通过 xDS 协议推送配置，毫秒级生效，且不断连。这对于 AI 长连接场景至关重要。
  • 高并发低延迟：数据面 Envoy 的零拷贝、异步 I/O 特性保证了性能。
  • 生态隔离：通过 WASM 虚拟机隔离插件崩溃风险，保障网关核心稳定性。

2. 核心功能详细解读

Higress 的功能定位已经从传统的微服务网关进化为AI Native API Gateway。

• 主要功能与场景：

  1. AI 流量统一编排：作为企业与 OpenAI、Azure、通义千问等 LLM 提供商之间的中间层。它屏蔽了不同 Provider API 差异，提供统一的调用接口。
  2. MCP (Model Context Protocol) Server Hosting：Higress 内置了对 MCP 协议的支持，可以直接作为 AI Agent 的工具提供者，让 LLM 能够安全地通过网关访问企业内部数据或服务。
  3. 传统 API 管理：Kubernetes Ingress Controller、限流、认证、熔断、灰度发布。

• 解决的关键问题：

  • AI 服务的不可控性：解决了直接调用 LLM API 难以监控、难以计费、难以在模型故障时切换的问题。
  • 流式响应处理：传统网关对 SSE (Server-Sent Events) 支持不佳，Higress 专门优化了 AI 流式输出的转发，确保低延迟。
  • 安全与合规：通过插件拦截敏感词（PII），防止企业机密数据泄露给公网模型。

• 与同类工具对比：

  • vs. Nginx/Kong：Nginx/Kong 主要基于 Lua 插件，虽然生态成熟，但在处理 AI 流式转发时的内存管理和 WASM 支持上不如 Higress 现代化。Higress 的配置分发机制（xDS）比 Nginx 的 reload 机制更平滑。
  • vs. Istio Ingress：原生 Istio Gateway 配置极其复杂且缺乏开箱即用的 AI 特性。Higress 提供了更符合运维习惯的控制台和简化的配置模型。

3. 技术实现细节

• WASM 插件机制：

  • 原理：Higress 在 Envoy 中嵌入 WASM Runtime（如 Wasmtime 或 V8）。当请求到达时，Envoy 将请求上下文（Headers、Body）传入 WASM 虚拟机，执行用户定义的 on_request 或 on_response 钩子函数。
  • 优势：插件可以被动态推送到数据面，无需重新编译 C++ 或重启 Envoy 进程。

• AI 网关的实现：

  • 协议转换：Higress 在数据面实现了针对不同 LLM Provider 的协议适配层。例如，将标准的 OpenAI 格式请求转换为通义千问的内部格式。
  • 流式处理：利用 Envoy 的 Async Filter 机制处理流式响应，实现对 Token 的实时计数和拦截。

• 性能优化：

  • 零拷贝：尽可能减少数据在内核态与用户态之间的拷贝。
  • 连接池：针对后端服务（如 LLM API）维护 HTTP/2 连接池，减少握手开销。

4. 适用场景分析

• 最适合的项目：

  • AI 应用开发：任何基于 LLM 构建的应用（RAG、Agent、Chatbot），都需要一个网关来处理 Prompt 模板、Token 限流和 Key 管理。
  • Kubernetes 集群入口：云原生架构下的统一流量入口，特别是需要同时管理传统微服务和 AI 服务的混合场景。
  • 多租户 SaaS 平台：需要根据不同租户进行精细化 API 限流和计费的场景。

• 不适合的场景：

  • 极端性能要求 (L4)：如果只需要纯 TCP/UDP 转发（如数据库代理），Higress 的 L7 处理能力是多余的，直接使用 IPVS 或 Envoy (纯静态配置) 更合适。
  • 极简边缘节点：资源极度受限（如几 MB 内存）的边缘设备，Envoy 的资源占用相对较重。

• 集成方式：

  • 通常作为 Kubernetes 的 Deployment 运行，通过 Service (LoadBalancer/NodePort) 暴露。
  • 通过 Ingress Class 或 Gateway API 资源与 Kubernetes 集群交互。

5. 发展趋势展望

• 从 “流量管理” 到 “模型编排”：未来的网关将不仅是路由器，更是 AI 逻辑的编排层。Higress 可能会集成更多的 Agent 编排能力（如 LangChain 的部分功能下沉）。
• MCP 协议的普及：随着 AI Agent 生态的发展，Higress 作为 MCP Server 的托管平台，将成为连接企业数据与 AI 模型的标准桥梁。
• 可观测性增强：针对 AI 场景的可观测性（如 Token 消耗、响应时间分布、Prompt 质量分析）将成为标配。

6. 学习建议

• 适合人群：具有 Kubernetes 基础、了解微服务架构、对 Go 语言有一定了解的后端开发者或 DevOps 工程师。
• 学习路径：
  1. 基础：理解 Envoy Proxy 的基本概念。
  2. 进阶：学习 Istio 的控制平面原理和 xDS 协议。
  3. 实战：阅读 Higress 官方提供的 WASM 插件开发文档，尝试用 Go 编写一个简单的认证插件。
  4. AI 特性：配置 Higress 接入一个真实的 LLM（如通义千问），体验流式输出和 Token 统计功能。

7. 最佳实践建议

• 资源隔离：在生产环境中，建议将 Higress 的控制面与数据面分离，或者通过 HPA (Horizontal Pod Autoscaler) 根据 CPU/内存使用率自动扩缩容。
• 插件开发：避免在 WASM 插件中进行阻塞式操作（如复杂的网络请求或大文件读写），这会阻塞 Envoy 的事件循环，严重影响网关性能。应尽量使用异步调用。
• 安全配置：开启 TLS 终止，并严格限制 AI API Key 的访问权限，利用 Higress 的密钥管理功能动态注入 Key，避免在客户端代码中硬编码。

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

• 抽象层的转移： Higress 将**“业务逻辑与流量处理的耦合”这一复杂性转移给了插件开发者**。它默认你愿意接受 WASM 的沙箱限制（如无法直接操作 Socket、文件系统受限），以换取安全性和动态性。 它的代价是：相比于直接修改 Nginx C 模块，WASM 插件的执行效率略低（虽然有编译优化，但仍存在虚拟机层开销），且调试难度更高。

• 价值取向：

  • 可移植性 > 极致性能：它选择了 WASM，意味着它更看重插件在不同环境下的通用性和热更新能力，而非追求 C++ 原生代码的极致执行速度。
  • 标准化 > 灵活性：它严格遵循 Kubernetes Ingress/Gateway API 标准，意味着你失去了像 OpenResty 那样在配置文件里写 Lua 脚本的随意性，但换来了云原生的生态兼容性。

• 工程哲学： Higress 的范式是**“声明式配置 + 可编程数据面”**。它试图解决的是云原生时代配置变更的频繁性与代理软件稳定性之间的矛盾。 最容易误用的地方：在 WASM 插件中处理长耗时任务（如调用第三方认证接口超时 5 秒）。这会导致 Envoy 工作线程阻塞，拖垮整个网关实例的吞吐量。

• 可证伪的判断：

  1. 性能判断：在相同硬件下，对比 Higress (开启 WASM 插件) 与 OpenResty (Lua 插件) 的 QPS。如果 Higress 的延迟高于 Lua 20% 以上，则证明 WASM 虚拟机开销在轻量级逻辑中不可忽视。
  2. 稳定性判断：向 Higress 注入一个故意导致 Panic 的 WASM 插件。如果网关主进程未崩溃且其他路由仍正常工作，则证明其沙箱隔离机制有效。
  3. AI 优化判断：测试长连接场景下的配置变更。如果在修改路由规则时，正在进行的 LLM 流式对话不断连且无延迟感知，则证明其 xDS 热更新机制针对 AI 场景的优化是真实的。

代码示例

 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：动态路由配置
def dynamic_routing():
    """
    解决问题：根据请求头动态路由到不同后端服务
    场景：A/B测试或灰度发布时需要将特定用户流量导向新版本服务
    """
    from flask import Flask, request, jsonify
    
    app = Flask(__name__)
    
    @app.route('/api/service')
    def route_service():
        user_group = request.headers.get('X-User-Group', 'default')
        
        # 动态路由逻辑
        if user_group == 'beta':
            target = 'https://beta-service.example.com'
        else:
            target = 'https://stable-service.example.com'
            
        # 实际实现中这里会转发请求到target
        return jsonify({
            'routed_to': target,
            'user_group': user_group
        })
    
    return app

# 说明：这个示例展示了如何基于Higress的动态路由能力实现流量分流，
# 在实际部署中，这些路由规则会通过Higress的配置API动态更新

 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：请求认证与鉴权
def auth_middleware():
    """
    解决问题：API请求的安全认证
    场景：保护微服务API，验证JWT令牌并提取用户信息
    """
    import jwt
    from functools import wraps
    from flask import Flask, request, jsonify
    
    app = Flask(__name__)
    SECRET_KEY = 'your-secret-key'
    
    def require_auth(f):
        @wraps(f)
        def decorated(*args, **kwargs):
            token = request.headers.get('Authorization', '').replace('Bearer ', '')
            
            try:
                # 验证JWT令牌
                payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
                request.user = payload
                return f(*args, **kwargs)
            except jwt.ExpiredSignatureError:
                return jsonify({'error': 'Token已过期'}), 401
            except jwt.InvalidTokenError:
                return jsonify({'error': '无效的令牌'}), 401
                
        return decorated
    
    @app.route('/api/protected')
    @require_auth
    def protected():
        return jsonify({'message': f'欢迎用户 {request.user["username"]}'})
    
    return app

# 说明：这个示例展示了如何在Higress中实现认证中间件，
# 实际部署中这些逻辑会作为Wasm插件在Higress网关层执行

 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

# 示例3：流量控制与限流
def rate_limiting():
    """
    解决问题：防止API被过度调用
    场景：保护后端服务免受突发流量冲击，实现QPS限制
    """
    from collections import defaultdict
    from time import time
    from flask import Flask, request, jsonify
    
    app = Flask(__name__)
    
    # 简单的内存限流器（生产环境应使用Redis等）
    class RateLimiter:
        def __init__(self, limit, period):
            self.limit = limit
            self.period = period
            self.requests = defaultdict(list)
            
        def is_allowed(self, key):
            now = time()
            # 清理过期记录
            self.requests[key] = [req_time for req_time in self.requests[key] 
                                if now - req_time < self.period]
            
            if len(self.requests[key]) < self.limit:
                self.requests[key].append(now)
                return True
            return False
    
    limiter = RateLimiter(limit=10, period=60)  # 每分钟10次
    
    @app.route('/api/expensive')
    def expensive_operation():
        client_id = request.headers.get('X-Client-ID', 'anonymous')
        
        if not limiter.is_allowed(client_id):
            return jsonify({'error': '请求过于频繁，请稍后再试'}), 429
            
        return jsonify({'message': '操作成功'})
    
    return app

# 说明：这个示例展示了如何实现基本的限流功能，
# 在Higress中可以通过配置更强大的限流规则，包括基于IP、用户等的限流

案例研究

1：阿里巴巴内部核心业务（如淘宝、天猫等）

1：阿里巴巴内部核心业务（如淘宝、天猫等）

背景: 在阿里巴巴庞大的电商生态系统中，流量入口极其复杂，涵盖了 PC 端、移动 App、小程序以及各种开放平台的 API 调用。随着业务规模的指数级增长，传统的基于 Nginx 的网关架构在应对双十一等大促的高并发流量时，面临着配置管理复杂、扩展性受限以及云原生集成度不够等挑战。业务团队急需一款能够深度整合云原生生态、支持高性能流量管理且易于扩展的 API 网关。

问题:

1. 扩展性与灵活性瓶颈：旧版网关在动态调整路由规则和插件扩展方面存在局限，开发团队为了上线一个新的流量控制策略或鉴权逻辑，往往需要修改配置并重启服务，影响了业务的敏捷迭代。
2. 异构系统治理困难：后端服务由不同的语言（Java、Go、Node.js 等）和框架构建，旧网关在处理服务发现、负载均衡以及全链路流量灰度（金丝雀发布）时，缺乏统一且标准化的管理机制。
3. 成本与性能平衡：在大流量场景下，需要更低的资源消耗和更高的吞吐量，且希望复用 Istio 等服务网格技术的能力，避免功能重复建设。

解决方案: 阿里巴巴决定基于内部多年的网关经验，开源并深度使用 Higress。

1. 架构升级：采用 Higress 作为统一的 API 网关，其底层基于 Envoy 和 Istio，不仅继承了 Envoy 高性能 C++ 的优势，还通过 Istio 实现了云原生的服务治理能力。
2. 插件化生态：利用 Higress 提供的 Wasm（WebAssembly）插件支持，开发团队可以用 Go 或 C++ 编写高性能的扩展插件（如自定义鉴权、请求限流、流量染色），实现业务逻辑的热加载，无需重启网关服务。
3. 统一入口管理：将 HTTP、HTTPS 和 gRPC 流量统一接入 Higress，利用其强大的路由转发能力对接后端的 K8s Service 和 Nacos 注册中心。

效果:

1. 业务敏捷性提升：新功能的上线和路由规则的变更实现了秒级生效，极大地缩短了从开发到上线的窗口期。
2. 系统稳定性增强：成功支撑了双十一数百万 QPS 的流量洪峰，系统资源占用率相比旧架构降低了约 30%，且延迟显著降低。
3. 标准化落地：通过 Higress 统一了内部流量网关与微服务网关的架构层，降低了运维复杂度，并沉淀了一套可复用的网关插件生态。

2：AIGC（生成式 AI）应用提供商

2：AIGC（生成式 AI）应用提供商

背景: 随着 ChatGPT 等大模型的爆发，一家专注于 AIGC 应用开发的初创公司迅速推出了面向企业和开发者的 LLM（大语言模型）调用服务。该服务需要将用户的请求稳定地分发到 OpenAI、阿里云通义千问等不同的模型提供商。由于 LLM 调用成本高昂且各家厂商接口标准不一，直接暴露给前端或客户端会带来严重的成本流失和安全风险。

问题:

1. Token 成本控制：直接将大模型 API 暴露给客户端，容易被恶意调用或刷量，导致 API Token 消耗过快，成本不可控。
2. 接口标准化困难：不同的模型提供商（OpenAI vs. 国内厂商）的 API 协议、参数定义和响应格式各不相同，客户端需要适配多套逻辑，开发维护成本高。
3. 请求内容安全：需要对用户输入的 Prompt 进行实时的敏感词过滤和审查，以符合合规要求，但这层逻辑如果在业务代码中实现会增加延迟。

解决方案: 该团队引入 Higress 作为 AI 服务的专用网关（AI Gateway）。

1. 统一模型适配：利用 Higress 针对大模型场景的内置插件，将不同厂商的异构 API 统一封装为 OpenAI 标准格式。客户端只需对接 Higress，后台可灵活切换模型供应商。
2. Prompt 模板与缓存：在网关层配置 Prompt 模板插件，对用户输入进行预处理和优化；同时开启语义缓存插件，对于高频重复的问答直接由网关返回结果，无需请求大模型。
3. 安全与流控：部署了基于 Wasm 的安全插件，实时拦截敏感词；并配置了基于 Token 或调用次数的精细化限流策略，防止 API 滥用。

效果:

1. 大幅降低成本：通过缓存机制，减少了约 40% 的重复模型调用，显著降低了 API Token 的采购成本。
2. 开发效率提升：后端开发团队无需关注底层模型的差异，专注于业务逻辑，对接新模型的时间从数天缩短到分钟级配置。
3. 安全性保障：有效拦截了违规请求，确保了业务内容的合规性，同时通过网关层的鉴权保护了核心 API 资产。

对比分析

与同类方案对比

优势分析

• 优势1：基于 Envoy 和 Istio，与云原生技术栈深度集成，适合 K8s 环境。
• 优势2：提供控制台和 K8s CRD，支持多种部署模式，易用性较高。
• 优势3：阿里背书，与阿里云服务无缝集成，适合国内用户。

不足分析

• 不足1：社区活跃度和插件生态不如 APISIX 和 Kong 成熟。
• 不足2：性能略低于基于 OpenResty 的 APISIX，不适合极端高并发场景。
• 不足3：商业支持依赖阿里云，灵活性可能不如完全开源的方案。

最佳实践

最佳实践指南

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

说明: Higress 支持通过 WebAssembly (Wasm) 技术进行插件扩展，允许使用 C++、Go、Rust 或 AssemblyScript 编写高性能的自定义逻辑。相比传统的 Lua 脚本，Wasm 插件提供了更好的隔离性和接近原生的执行性能，非常适合实现复杂的鉴权、流量整形或协议转换逻辑。

实施步骤:

1. 根据团队技术栈选择合适的 Wasm 开发语言（推荐使用 Go 或 Rust）。
2. 使用 Higress 提供的 SDK 或 proxy-wasm-go-sdk 编写插件逻辑。
3. 将编译好的 .wasm 文件上传到 Higress 控制台或通过 OCI 镜像仓库进行分发。
4. 在网关路由配置中关联该插件，并配置具体的插件参数。

注意事项: Wasm 插件运行在沙箱中，虽然安全性较高，但仍需注意内存限制和超时配置，避免异常插件导致网关资源耗尽。

实践 2：精细化配置流量治理与路由规则

说明: 利用 Higress 强大的路由规格能力，实现基于 Header、Query 参数、Cookie 甚至 Body 内容的流量匹配。这不仅能实现灰度发布，还能进行多版本管理和 A/B 测试。Higress 兼容 Istio 的 VirtualService 规范，适合云原生用户迁移。

实施步骤:

1. 在控制台定义服务来源，接入 K8s Service、Nacos 或固定 IP/域名。
2. 配置路由规则，设置匹配条件，例如将带有 canary: true Header 的请求路由到新版本服务。
3. 配置重试、超时和熔断策略，增强后端服务的容错能力。
4. 使用 Mock 功能在服务未就绪时返回特定响应，保障前端开发流程。

注意事项: 路由匹配优先级需严格规划，避免因规则冲突导致流量被错误的转发。建议在测试环境充分验证路由正则表达式的准确性。

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

说明: Higress 内置了丰富的安全插件，能够应对 OWASP Top 10 安全风险。最佳实践包括开启 IP 访问控制、配置 Basic Auth 或 JWT 认证，以及集成 Keyless 认证服务。对于 API 开放场景，应启用 API Key 或 OAuth2.0 插件以防止未授权访问。

实施步骤:

1. 在全局或特定路由上启用 key-auth 或 jwt-auth 插件，保护私有 API。
2. 配置 bot-detect 或 waf-plugin 拦截恶意爬虫和常见 Web 攻击。
3. 针对内部服务间通信，配置 mTLS 双向认证，确保传输链路安全。
4. 定期审查安全日志，动态调整黑名单或白名单 IP。

注意事项: 认证插件会增加网关处理延迟，建议对高并发且对安全性要求不高的健康检查接口予以放行。

实践 4：利用 Ingress 和 Gateway API 实现云原生集成

说明: Higress 可以作为 Kubernetes 的 Ingress Controller 或 Gateway API 的实现。最佳实践是利用 CRD (Custom Resource Definition) 进行声明式配置管理，将网关配置纳入 GitOps 流程，实现基础设施即代码。

实施步骤:

1. 在 Kubernetes 集群中部署 Higress。
2. 编写 Ingress 资源 YAML 或 Gateway API 资源 YAML，定义域名、路径及后端服务。
3. 将配置文件提交至 Git 仓库，通过 ArgoCD 或 Flux 等工具自动同步集群状态。
4. 利用 Higress 对 Service Mesh (如 Istio) 的兼容性，实现东西向（微服务间）与南北向（入口网关）流量的统一管理。

注意事项: 在大规模多租户 K8s 环境中，合理规划 IngressClass 的使用，避免不同业务系统的路由规则相互干扰。

实践 5：可观测性体系构建与日志集成

说明: 生产环境的网关必须具备完善的可观测性。Higress 原生支持 OpenTelemetry 协议。最佳实践是集成 Prometheus 进行指标监控，对接阿里云日志服务 (SLS) 或 Elasticsearch 进行日志存储，并利用 SkyWalking 或 Jaeger 进行分布式链路追踪。

实施步骤:

1. 配置 Higress 的 Prometheus Exporter，采集 P99 延迟、QPS、错误率等关键指标。
2. 开启访问日志插件，将日志以 JSON 格式输出至 Kafka 或直接发送至日志系统。
3. 启用链路追踪，在请求头中注入 Trace Context，打通网关到后端服务的全链路监控。
4. 配置告警规则，当错误率超过阈值时通过钉钉或 Slack 发送通知。

注意事项: 高流量场景下，

性能优化建议

性能优化建议

优化 1：启用 Wasm 插件替换 Lua 脚本

说明: Higress 原生支持 WebAssembly (Wasm) 插件，相比传统的 Lua 脚本，Wasm 插件拥有接近原生的执行性能。对于复杂的路由逻辑、请求头处理或响应体修改，使用 Wasm 可以显著降低 CPU 开销。

实施方法:

1. 将现有的 Lua 或 JavaScript 逻辑移植至 Go 或 C++，并编译为 .wasm 文件。
2. 在 Higress 控制台或通过 WasmPlugin CRD 配置加载该插件。
3. 确保插件逻辑中使用了 Proxy-Wasm 标准接口（如 OnHttpRequestHeaders）。

预期效果: 复杂逻辑处理延迟降低 30%-50%，吞吐量提升 20% 左右。

优化 2：配置 HTTP/2 与 HTTP/3 (QUIC)

说明: Higress 基于 Envoy，对 HTTP/2 和 HTTP/3 有极佳的支持。开启 HTTP/2 可以利用多路复用减少 TCP 连接数，降低延迟；在不可靠网络环境下，HTTP/3 (QUIC) 能显著减少连接建立耗时和队头阻塞。

实施方法:

1. 在监听器配置中，将协议类型设置为 HTTP 或 HTTP_AUTO，并确保 TLS 配置正确（H2 需要 ALPN）。
2. 启用 HTTP/3 需要在 Listener 中明确配置 Http3ProtocolOptions。
3. 客户端需确保支持相应的协议版本。

预期效果: 弱网环境下的请求延迟降低 10%-40%，并发连接数减少，提升整体网络利用率。

优化 3：优化连接池与超时配置

说明: 默认的连接池配置可能无法应对高并发场景。不合理的心跳或超时设置会导致资源浪费或请求堆积。通过调整上游服务的连接池大小和空闲超时时间，可以减少频繁建立 TCP/SSL 连接的开销。

实施方法:

1. 调整 Cluster 配置中的 max_requests_per_connection（建议 10000+ 或保持无限）。
2. 增加 http2_protocol_options.concurrency 以允许 H2 多路复用更多流。
3. 根据业务平均耗时，精细调整 connect_timeout、request_timeout，避免过长的超时占用连接池。

预期效果: 后端服务连接建立开销降低 15%，P99 延迟更加稳定。

优化 4：启用全链路 Opentelemetry 采样与异步上报

说明: 在高流量下，全量采集 Trace 数据会严重损耗网关性能。通过配置合理的采样策略（如动态采样或仅采样错误请求）以及使用异步内存 Buffer 上报，可以将监控对业务流量的影响降至最低。

实施方法:

1. 修改 Telemetry 配置，设置 sampling 策略（例如 1% 采样率，或基于 TraceID 限流）。
2. 确保使用 gRPC 或 HTTP 异步导出器，并增加 exporter_queue_size 以缓冲数据。
3. 开启 metadata 关联，减少重复的标签提取开销。

预期效果: 监控采集造成的 CPU 损耗从 10% 降低至 1% 以下。

优化 5：利用本地与分布式缓存

说明: Higress 内置了强大的缓存能力。对于鉴权、响应体等高频重复数据，启用本地内存缓存或分布式 Redis 缓存，可以直接拦截请求，避免流量穿透到后端业务逻辑。

实施方法:

1. 在路由配置中启用 response_cache，并配置合适的 Cache Key（如 URL + Host）。
2. 对于鉴权逻辑，在 Wasm 插件或 Lua 中引入 dict（本地字典）或连接 Redis 缓存 Token 验证结果。
3. 设置合理的 TTL（生存时间）与缓存淘汰策略 LRU。

预期效果: 缓存命中场景下，后

学习要点

• 基于提供的上下文（Alibaba/Higress 在 GitHub 趋势中），以下是关于该项目最值得关注的 5 个关键要点：
• Higress 是阿里云开源的、基于 Istio 的下一代云原生 API 网关，旨在解决云原生时代流量管理的复杂性。
• 它深度集成了 K8s Ingress 与 Gateway API 标准，能够无缝对接 Kubernetes 生态，实现流量的统一管理。
• 提供了强大的 WAF（Web 应用防火墙）插件市场，支持热加载，用户可以像使用 VS Code 插件一样灵活扩展网关功能。
• 架构上实现了数据平面与控制平面的分离，支持高性能的代理转发，同时降低了资源开销。
• 兼容 Nginx Ingress 注解和传统网关配置，大大降低了用户从 Nginx 或传统架构迁移到云原生网关的门槛。
• 支持多集群管理和多租户场景，非常适合大型企业或微服务架构下的统一流量入口治理。

学习路径

学习路径

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

学习内容:

• 网关基础理论：理解 API 网关在微服务架构中的定位与核心功能（流量入口、安全、限流熔断）。
• Higress 简介：了解 Higress 的背景（基于阿里云 Sentinel 和 Istio）、核心特性以及与 Nginx、APISIX 或 Kong 的区别。
• 基本概念：掌握 Ingress、Gateway、路由（Route）、服务（Service）及 Upstream 的定义。
• 快速上手：学习如何在本地 Docker 环境或 Kubernetes 集群中安装部署 Higress。

学习时间: 1-2周

学习资源:

• Higress 官方文档 (架构与简介章节)
• Higress GitHub 仓库 (README 与 Quickstart)
• 云原生社区关于 API 网关的技术文章

学习建议: 不要急于深入配置，先通过官方的 “Quick Start” 或 “Demo” 将服务跑起来，通过控制台界面直观感受配置项，建立感性认识。

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

学习内容:

• 核心路由配置：学习如何配置域名、路径匹配规则（精确前缀、正则匹配）及 Header 转发。
• 负载均衡策略：掌握轮询、随机、加权以及一致性哈希等负载均衡算法的配置场景。
• 流量管理：实现基于 Header、Query 或 Cookie 的流量切分（蓝绿发布、金丝雀发布）。
• 插件系统入门：了解 Higress 的插件机制，学习如何使用官方预置插件（如 CORS、请求重写、Key Auth）。

学习时间: 2-3周

学习资源:

• Higress 官方文档 (流量路由、插件市场章节)
• Higress 控制台实操（通过 UI 配置一条复杂的路由规则）
• Kubernetes Ingress Nginx 对比文档（理解 Ingress 注解与 Higress 配置的映射）

学习建议: 建议在本地搭建一个模拟的多服务 Kubernetes 环境（如使用 Kind 或 Minikube），尝试将不同域名的请求转发至不同的后端 Pod，并实践一次金丝雀发布流程。

阶段 3：安全防护与高可用

学习内容:

• 安全认证：配置 Basic Auth、JWT 验证、ApiKey 认证以及 OAuth2.0 集成。
• 防护策略：深入理解 WAF（Web 应用防火墙）配置，学习如何通过插件防御 SQL 注入、XSS 攻击。
• 流量保护：学习如何配置限流（QPS 限制）和熔断（异常熔断），保护后端服务稳定性。
• 高可用部署：了解 Higress 的高可用架构，掌握多副本部署及健康检查配置。

学习时间: 2-3周

学习资源:

• Higress 官方文档 (安全、全局配置章节)
• Sentinel 官方文档（了解流控原理，Higress 底层依赖）
• OWASP Top 10 安全防护基础知识

学习建议: 尝试模拟一次高并发场景（如使用 JMeter 或 Apache Bench），观察配置了限流和未配置限流时后端服务的表现差异，深刻理解网关的"挡板"作用。

阶段 4：插件开发与云原生集成

学习内容:

• Wasm 插件开发：学习 WebAssembly (Wasm) 基础，掌握使用 Go 或 C++ 开发自定义 Higress 插件的流程。
• 服务发现集成：学习 Higress 如何对接 Nacos、Consul、Zookeeper 以及 Kubernetes CoreDNS。
• 可观测性：掌握 Higress 的日志输出格式，对接 Prometheus/Grafana 进行监控，对接 SkyWalking/Jaeger 进行链路追踪。
• 多租户与多环境管理：学习如何在多套环境中管理 Higress 配置，以及配置版本管理（GitOps）。

学习时间: 3-4周

学习资源:

• Higress 官方文档 (自定义开发、可观测性章节)
• Higress 官方插件开发示例（GitHub 中的 wasm-go 插件示例）
• Prometheus 与 Grafana 基础教程

学习建议: 从修改一个现有的官方插件开始（例如修改请求头或响应体），逐步尝试编写一个简单的 Wasm 插件并部署到网关中运行。同时，尝试将 Higress 的指标数据导入 Grafana 画出监控大盘。

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

学习内容:

• 架构深度解析：深入剖析 Higress 的数据面与控制面架构，理解配置热更新原理。
• 源码阅读：阅读 Higress 核心源码，理解请求处理流水线、插件加载机制及 Envoy 的扩展逻辑。
• 性能调优

常见问题

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

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

A: Higress 是阿里云推出的一款云原生 API 网关。它基于阿里内部多年在网关领域的实践，并结合了开源社区中 Kong 和 Envoy 的优势而构建。Higress 旨在提供标准、云原生的 API 网关能力，支持 Kubernetes Ingress 以及 North-South（南北向）和 East-West（东西向）流量管理。它不仅服务于阿里云的内部业务，也作为开源项目提供给社区使用，帮助企业降低云原生 API 网关的落地门槛。

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

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

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

1. 技术架构先进：基于 Envoy 和 Istio (Istio 是基于 Envoy 的)，采用 C++ 内核，拥有极高的性能和稳定性，避免了 Nginx Lua 脚本带来的内存管理问题。
2. 深度集成云原生：原生支持 Kubernetes Ingress (K8s Ingress)，能够无缝对接阿里云 MSE (Microservices Engine) 和 ACK (Alibaba Cloud Container Service for Kubernetes)。
3. 安全与合规：内置了 WAF (Web Application Firewall) 3.0 能力，提供更精细化的流量安全防护。
4. 插件生态：兼容 Kong 和 APISIX 的插件生态，同时支持 WASM (WebAssembly) 插件，允许使用 Go、Python、JavaScript 等多种语言编写插件，扩展性更强且安全性更高（插件崩溃不会导致网关崩溃）。

3: Higress 是否支持从 Nginx 或 Kong 迁移？迁移成本高吗？

3: Higress 是否支持从 Nginx 或 Kong 迁移？迁移成本高吗？

A: 是的，Higress 非常重视迁移的平滑性，并提供了相应的工具来降低成本。

1. Nginx 迁移：Higress 提供了 Nginx Ingress Controller 的兼容模式，可以直接接管 K8s 的 Nginx Ingress 注解，同时也支持将 Nginx 的配置文件转换为 Higress 的配置。
2. Kong 迁移：Higress 提供了 Kong 2.x 的 API 兼容层，可以直接使用 Kong 的 Admin API 进行配置管理，同时也支持直接运行 Kong 的 Lua 插件（通过兼容层）。
3. 配置同步：对于存量系统，Higress 支持通过 Nacos 等配置中心进行配置同步，帮助用户逐步切换流量。

4: Higress 支持哪些类型的流量管理和路由策略？

4: Higress 支持哪些类型的流量管理和路由策略？

A: Higress 提供了企业级的全链路流量管理能力：

1. HTTP 路由：支持基于 Header、Query 参数、Cookie、路径等复杂条件的路由匹配。
2. 负载均衡：支持多种负载均衡算法，如轮询、随机、最小连接数等，并支持基于权重的流量分发（如金丝雀发布/蓝绿发布）。
3. 服务治理：支持服务注册与发现（Nacos, Consul, DNS, 固定 IP），超时重试，熔断限流等。
4. 全链路灰度：结合阿里云 MSE，可以实现微服务架构下的全链路灰度发布，这是传统网关较难实现的复杂场景。

5: Higress 的插件是如何工作的？是否必须用 Go 或 C++ 编写？

5: Higress 的插件是如何工作的？是否必须用 Go 或 C++ 编写？

A: 不必须。Higress 最大的亮点之一是对 WASM (WebAssembly) 的原生支持。

1. 多语言支持：得益于 WASM 技术，开发者可以使用 Go、Rust、JavaScript (AssemblyScript) 甚至 Python 来编写网关插件。
2. 安全性：插件运行在沙箱环境中，即使插件出现 Bug（如内存溢出或死循环），也不会导致 Higress 主进程崩溃，保证了网关的高可用性。
3. 热加载：WASM 插件支持动态加载和卸载，无需重启网关服务即可更新插件逻辑。
4. 兼容性：同时也支持传统的 Lua 插件（通过 Kong 兼容层）以及 Java 插件（针对特定的 Java Agent 场景）。

6: Higress 是开源的吗？可以在生产环境使用吗？

6: Higress 是开源的吗？可以在生产环境使用吗？

A: 是的，Higress 已经在 GitHub 上开源。它基于 Apache 2.0 许可证发布。

1. 生产就绪：Higress 的内核源自阿里内部生产环境广泛使用的 Istio 和 Envoy 深度定制版本，经过了“双十一”等大流量场景的验证，具备极高的稳定性。
2. 社区支持：作为 GitHub Trending 项目，它拥有活跃的社区支持，阿里云团队也在持续进行维护和更新。
3. 商业化版本：对于需要企业级 SLA 保障、更高阶的安全防护或技术支持的用户，可以直接使用阿里云

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

在本地 Docker 环境中快速部署 Higress，并创建一个简单的路由规则，将访问 /hello 的 HTTP 请求转发到一个运行在 8080 端口的本地后端服务（如 nginx 容器）。

提示**:

实践建议

基于 Higress 作为 AI Native API 网关的定位，结合其在阿里巴巴内部及开源社区的实际应用场景，以下是 7 条实践建议：

1. 利用 AI 插件生态进行模型供应商的统一管理

场景：企业内部同时调用 OpenAI、Azure、通义千问以及本地部署的 DeepSeek 等多个模型。 建议：不要在业务代码中硬编码不同供应商的 SDK。使用 Higress 的 AI 代理插件 或 LLM 路由 功能，将所有大模型供应商的 API 统一接入网关。 最佳实践：配置统一的 /v1/chat/completions 标准接口入口。业务端只需对接 Higress，由 Higress 负责将请求转发到不同的后端模型。这样当需要切换模型或供应商时，仅需在网关层面修改配置，无需重新发布业务代码。

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

场景：大模型调用成本高昂，且不同部门或用户的预算不同。 建议：区别于传统的基于 QPS（每秒请求数）或并发数的限流，AI 场景下必须配置基于 Token 吞吐量 的限流策略。 最佳实践：在 Higress 中为不同的 API Key 或应用配置不同的 Token 预算。例如，为测试部门配置每分钟 10 万 Token 的上限，防止因某个异常程序死循环调用导致昂贵的账单。同时，利用 Higress 的 Keyless 功能隐藏真实的云厂商 API Key，防止密钥泄露。

3. 配置 Prompt 模板与敏感词过滤（安全护栏）

场景：直接将用户输入传递给大模型可能导致 Prompt 注入攻击（如让模型扮演黑客角色）或输出违规内容。 建议：利用 Higress 的 内容修饰插件 或 AI 安全插件，在网关层进行 Prompt 拼接和清洗。 最佳实践：

• 输入侧：配置系统级 Prompt 模板，强制设定模型的人设和回复限制（例如：“你是一个只能回答技术问题的客服”），并在请求发送前注入。
• 输出侧：配置敏感词过滤策略，拦截模型返回的违规内容，确保合规性。这比在应用层代码中写 if/else 更高效且易于集中更新。

4. 启用结果缓存以降低成本与延迟

场景：客服或知识库问答场景中，大量用户问题高度重复（如“如何重置密码”）。 建议：开启针对 LLM 请求的 语义缓存 或 精确缓存。 最佳实践：配置 Higress 对相同的 Question（问题）进行缓存，直接返回之前的 Answer（答案），设置合理的 TTL（过期时间）。对于高并发但低频变化的查询场景，这可以节省 50% 以上的 Token 消耗，并将响应延迟从秒级降低到毫秒级。注意：需根据业务需求，决定是否缓存流式输出的结果。

5. 谨慎处理流式传输的超时与断开

场景：使用 SSE（Server-Sent Events）进行流式输出时，客户端可能中途断开，或模型生成时间过长。 建议：正确配置网关的 超时时间 和 连接断开策略。 常见陷阱：如果网关层的超时时间设置过短（例如默认的 60秒），对于需要长思考时间的复杂推理任务，网关会提前断开与后端的连接，导致客户端收到报错或生成不完整的文本。 最佳实践：将针对 AI 路由的超时时间调整为允许的最大值（如 5-10 分钟），并确保 Higress 在客户端断开连接时能及时通知后端模型停止生成，以节省 Token 成本。

6. 利用 Wasm 插件实现自定义业务逻辑（如 RAG 检索）

场景：在调用大模型前，需要先去向量数据库检索相关上下文（RAG 架构）。 建议：

引用

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

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

站内链接

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

相关文章

• 阿里开源 Higress：AI 原生 API 网关
• 阿里开源 Higress：AI 原生 API 网关
• 阿里开源 Higress：AI 原生 API 网关
• Amla Sandbox：面向 AI 智能体的 WASM Bash 沙箱
• Amla Sandbox：面向 AI 智能体的 WASM Bash 沙箱 这篇文章由 AI Stack 自动生成，包含多次大模型调用，提供深度的结构化分析。