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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,442 (+11 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 网关，通过云原生架构将流量管理与 AI 应用生态相结合。它不仅提供传统的微服务路由能力，更针对大语言模型（LLM）应用集成了 AI 网关特性与 MCP 服务器托管，旨在解决企业接入 AI 服务时的安全、协议转换及工具调用问题。本文将梳理其系统架构，重点介绍 WASM 插件体系及 AI 网关的核心功能，帮助开发者理解如何利用 Higress 构建高效的 AI 应用基础设施。

摘要

基于您提供的内容，以下是对 Higress 项目的简洁总结：

项目概况

Higress 是由阿里巴巴开源的一款云原生 API 网关。它基于 Istio 和 Envoy 构建，并扩展了 WebAssembly (WASM) 插件能力。该项目定位为 AI Native API Gateway（AI 原生 API 网关），旨在为云原生应用和 AI 应用提供统一的流量管理入口。

核心技术特点

• 架构设计：采用标准的控制平面与数据平面分离架构。
• 高性能：配置变更通过 xDS 协议传播，毫秒级生效且无连接中断，特别适合 AI 长连接流式响应场景。
• 可扩展性：基于 WASM 插件系统，提供了强大的扩展能力。

三大核心功能与用例

1. AI 网关

   • 功能：为大语言模型 (LLM) 应用提供统一 API，支持协议转换、可观测性、缓存和安全防护。
   • 支持范围：统一对接 30+ 家 LLM 提供商。
   • 核心组件：包含 ai-proxy（AI 代理）、ai-statistics（统计）、ai-cache（缓存）及 ai-security-guard（安全防护）等插件。

2. MCP 服务器托管

   • 功能：托管模型上下文协议 (MCP) 服务器，使 AI Agent 能够调用外部工具和服务。
   • 核心组件：包含 mcp-router、jsonrpc-converter 过滤器以及具体的 MCP 服务器实现（如 quark-search、amap-tools 等）。

3. Kubernetes Ingress

   • 功能：作为 K8s 的 Ingress 控制器，管理微服务路由。
   • 兼容性：兼容 nginx-ingress 注解。

项目状态

• 主要语言：Go
• 社区热度：GitHub 星标数超过 7,4k，活跃度较高。

评论

总体判断

Higress 是一款极具前瞻性的“AI 原生”网关，它成功打破了传统流量网关与 LLM（大语言模型）应用网关之间的壁垒。该项目并非仅仅是在 API Gateway 中增加了几个 AI 插件，而是通过将 AI 协议处理、模型提供商管理、MCP（模型上下文协议）服务托管与云原生基础设施深度融合，为构建下一代 AI Agent 应用提供了一个标准化的流量入口。

深入评价依据

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

• 事实：根据 DeepWiki，Higress 基于 Istio 和 Envoy 构建，核心功能包括 AI Gateway 特性、MCP 服务器托管以及 WASM 插件系统。
• 推断：传统网关（如 Nginx, Kong）主要处理 HTTP/gRPC 协议的负载均衡，而 Higress 的创新点在于协议层面的升级。它原生理解 LLM 协议（如 OpenAI Streaming 接口），能够处理 SSE（Server-Sent Events）流式转发，并内置了 Prompt 模板管理和路由分发逻辑。这意味着它可以在网关层直接实现“一问多模型”的路由策略（例如：简单问题走 Qwen，复杂逻辑走 GPT-4），而无需业务代码介入。此外，引入 MCP 协议支持，使其成为 AI Agent 的工具调度中心，这是目前极少网关具备的视野。

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

• 事实：项目定位为“AI Native API Gateway”，同时提供 Kubernetes Ingress 和微服务路由能力。
• 推断：在当前 AI 应用爆发期，开发者面临两个主要问题：一是模型供应商 API 不统一（切换模型需改代码），二是 LLM API 不稳定性（超时、限流）。Higress 通过统一的抽象层解决了这两个问题。它允许业务层使用标准协议调用，网关层负责适配不同厂商（阿里云、OpenAI、Anthropic 等）的 API 差异，并内置了 Token 计费、重试和熔断机制。这种“基础设施即代码”的思路，极大地降低了企业集成大模型的门槛，特别适合需要快速试错和多模型管理的 SaaS 团队。

3. 代码质量与架构：云原生高可用与可扩展性的平衡

• 事实：Higress 采用 Go 语言编写，架构上分离了控制平面与数据平面，并利用 WASM 技术实现插件扩展。
• 推断：基于 Istio/Envoy 的架构保证了其高性能与高可靠性，Envoy 的 C++ 内核处理 LLM 的长连接流式传输非常高效。而控制平面使用 Go 开发，符合云原生生态的主流选择，便于与 K8s 集成。最值得称道的是WASM 插件系统，它允许开发者使用 C++/Go/Rust/JS 等语言编写扩展逻辑，且支持热加载，无需重启网关。这种架构设计既保证了核心的稳定性，又提供了极高的灵活性，代码结构清晰，符合阿里巴巴开源项目的一贯高标准。

4. 社区活跃度与生态：背靠阿里，快速迭代

• 事实：星标数 7,442，且明确标注了 README_ZH 和 README_JP，显示其国际化意图。
• 推断：作为阿里巴巴开源的项目，Higress 并非“玩具级”项目，而是经过了阿里内部电商场景的大流量验证。其更新频率较高，紧跟 AI 技术栈的发展（如迅速支持 DeepSeek、Llama3 等新模型）。社区中对于 AI 网关特性的反馈非常活跃，文档（中英日）的完善程度也降低了非英语开发者的使用门槛，这表明其具有成为全球级开源项目的潜力。

5. 学习价值：重新定义网关的开发范式

• 推断：对于开发者而言，Higress 提供了一个极佳的学习样本，展示了如何将非 AI 基础设施进行“AI 化”改造。它展示了如何处理 SSE 流的转发与拦截（这是传统网关忽略的细节），以及如何设计插件系统来适配日益复杂的 AI 生态。学习 Higress 有助于开发者理解“服务网格”与“API 网关”融合的趋势，以及如何构建一个可观测的 AI 应用调用链路。

边界条件与不适用场景

尽管 Higress 功能强大，但并非万能：

• 极简场景不适用：如果你只是需要调用一个 LLM 接口且没有复杂的路由、鉴权或流控需求，直接使用 Python SDK 或简单的 Nginx 转发即可，引入 Higress 属于“杀鸡用牛刀”，增加了运维复杂度。
• 非 K8s 环境体验打折：虽然支持虚拟机部署，但其核心优势在于与 Kubernetes 的深度集成。在传统虚拟机或裸金属环境中，其配置和运维复杂度相对较高。
• 极致低延迟场景：对于微秒级延迟要求的传统 RPC 服务，Envoy 的内存占用和多跳代理可能仍有一定损耗，需针对性压测。

快速验证清单

1. AI 协议兼容性测试：部署 Higress，配置一个指向 OpenAI 的路由，使用 cURL 或 Postman 发送一个流式请求，验证网关能否无损转发 SSE 数据流且无明显延迟增加

技术分析

以下是对阿里巴巴开源的 Higress 项目的深度技术分析。Higress 定位为“AI Native API Gateway”，这标志着 API 网关从传统的流量治理向 AI 时代的基础设施演进。

1. 技术架构深度剖析

技术栈与架构模式 Higress 采用了典型的控制平面与数据平面分离的架构模式。

• 数据平面：深度依赖 Envoy。Envoy 是高性能的 C++ 网络代理，负责处理实际的流量转发、负载均衡以及 Wasm 插件的执行。
• 控制平面：基于 Istio 生态进行了扩展和简化。Higress 去除了 Istio 中繁重的 Sidecar 模式，专注于 Gateway（Ingress）场景。它通过 xDS 协议（包括 LDS, RDS, CDS, EDS）将配置下发到数据平面。
• 扩展层：引入 WebAssembly (WASM) 作为核心插件运行时。这是其架构中最关键的一环，允许开发者使用 C/C++/Go/Rust 等语言编写逻辑，编译为 WASM 字节码后在 Envoy 中沙箱运行。

核心模块与关键设计

1. 路由配置抽象：Higress 提出了更符合云原生生态的 Ingress API 兼容层，能够无缝对接 K8s Ingress 资源，同时也支持自定义的 CRD（如 GreeterRoute 等），实现了流量管理的标准化。
2. WASM 插件市场：架构上内置了插件管理服务，支持插件的动态上传、编译（如果源码上传）、下发和热加载。这使得网关功能的扩展无需重启网关进程。
3. MCP (Model Context Protocol) Server：针对 AI 场景，Higress 内置了 MCP 协议支持，充当 AI Agent 与外部工具（数据源、API）之间的桥梁。

技术亮点与创新点

• AI Native 理念：这是最大的创新。传统网关关注 HTTP/gRPC，Higress 原生支持 SSE（Server-Sent Events）流式转发，解决了 LLM（大模型）响应延迟高、需要流式输出的痛点。它不仅仅是透传，还能在流式传输中进行处理（如敏感词过滤、格式转换）。
• 热更新与毫秒级配置生效：基于 xDS 的增量推送机制，配置变更可以在不中断长连接（如 SSE 流）的情况下生效。
• 标准 K8s Ingress 极致兼容：在保持强大功能的同时，极力降低迁移门槛，支持直接替换 Nginx Ingress Controller。

架构优势分析

• 高性能：得益于 Envoy 的异步非阻塞 I/O 模型，Higress 能处理极高的并发连接，特别是在 AI 场景下维持大量长连接时表现优异。
• 安全性：WASM 的沙箱机制保证了插件故障不会导致网关崩溃，同时也限制了插件对底层资源的非法访问。
• 可扩展性：通过 WASM，业务逻辑可以无限扩展，不再受限于网关内置的过滤器。

2. 核心功能详细解读

主要功能与场景

1. AI 网关：
   • 统一模型接入：通过 Higress，前端应用只需调用一个标准接口，网关后端可路由至 OpenAI、通义千问、Llama 等不同模型提供商。
   • Token 管理：自动计费、Token 限流，防止模型调用失控。
   • Prompt 增强：在网关层动态修改请求头或 Body，注入系统提示词。
2. MCP Server 托管：
   • 随着大模型应用（Agent）的兴起，模型需要调用外部工具。Higress 充当这些工具的托管网关，管理认证、流控和协议转换。
3. 传统 API 网关：
   • K8s Ingress 管理、金丝雀发布、蓝绿部署、负载均衡、服务熔断与限流。

解决的关键问题

• AI 流量治理的缺失：传统网关无法理解 SSE 流，一旦截断或处理不当会导致流式输出中断。Higress 专门优化了流式数据的处理逻辑。
• 多云/多模型切换成本：开发者不想为每个模型厂商写一套 SDK。Higress 提供了统一的屏蔽层。

同类工具对比

• vs Nginx Ingress：Nginx 使用 Lua 扩展，灵活性高但性能瓶颈明显且配置复杂（尤其是流式处理）。Higress 配置更现代化，性能更强。
• vs Kong：Kong 基于 Nginx/OpenResty，插件生态丰富，但在处理超高并发 SSE 连接时，其事件循环模型不如 Envoy 高效。
• vs APISIX：同样是基于 Apache/APISIX（LuaJIT），性能强劲。Higress 的优势在于与 Istio 生态的天然融合以及对阿里云/AI 场景的深度集成。

技术实现原理

• 流式处理：利用 Envoy 的 HTTP Filter 机制，在 Buffer 模式下对流数据进行分片处理，确保低延迟转发。
• 服务发现：通过 Watch K8s API Server 获取 Service 和 Endpoint 变化，动态更新 Envoy 的集群配置。

3. 技术实现细节

代码组织结构 Higress 的后端主要采用 Go 语言编写。

• pkg/：核心逻辑，包括 xDS 转换器（将 K8s Ingress 转为 Envoy 配置）、路由匹配逻辑。
• plugins/：WASM 插件的 Go SDK 和示例代码。
• installer/：基于 Helm 的安装逻辑。
• registry/：处理服务注册中心（如 Nacos, Consul）的适配逻辑。

性能优化与扩展性

• 配置隔离：在多租户场景下，通过 Envoy 的 RDS（路由配置）进行逻辑隔离，避免配置互相污染。
• 连接池：针对后端 LLM 服务，精细调优了连接池参数，以适应长连接场景。
• WASM 扩展：使用 Proxy-WASM 标准（ABI），允许插件在不同版本的 Envoy 间复用，解决了 C++ 插件版本强绑定的问题。

技术难点与解决方案

• 难点：WASM 插件的内存开销和启动延迟。
• 方案：Higress 优化了 VM 的生命周期管理，支持插件池化复用，并利用 AOT（Ahead-of-Time）编译优化启动速度。
• 难点：K8s Ingress 标准注解与 Envoy 复杂配置的映射。
• 方案：构建了一个强大的翻译层，将复杂的 Envoy 配置抽象为简化的 CRD 或 Ingress Annotation。

4. 适用场景分析

适合使用的项目

• 大模型应用开发：任何需要接入 LLM（如 GPT-4, 文心一言）的企业应用，利用 Higress 做统一的接口网关、Token 统计和鉴权。
• Kubernetes 集群入口：需要替代 Nginx Ingress Controller，追求更高性能、更易用的配置管理（如支持 Consul/Nacos 服务发现）的场景。
• 微服务治理：需要使用 Istio 进行服务治理，但不想引入 Sidecar 模式的复杂性和性能损耗的边缘网关场景。

最有效的情况

• 当你需要统一管理多个 AI 模型供应商，并希望在网关层实现 Prompt 模板管理、敏感词过滤时，Higress 是目前市面上最成熟的解决方案之一。
• 当你需要处理高并发的 SSE 长连接流量时。

不适合的场景

• 极简静态站点：对于简单的静态资源托管，Nginx 足够且更轻量。
• 非 K8s 环境：虽然 Higress 可以在非 K8s 环境运行，但其核心价值在于与 K8s 的深度集成，脱离 K8s 会丧失大部分动态配置能力。

集成方式 主要通过 Helm Chart 部署在 K8s 集群中。配置通过 K8s CRD (Ingress, Gateway, WasmPlugin) 进行管理。

5. 发展趋势展望

技术演进方向

• 更深度的 AI 编排：从单纯的流量转发向“AI 编排层”进化，例如在网关层实现多模型调用结果的聚合、重试策略的智能化（根据模型错误率动态路由）。
• 边缘计算：利用 WASM 的轻量级特性，Higress 有可能向边缘节点下沉，成为边缘 AI 推理的入口。

社区反馈与改进空间

• 文档与生态：虽然中文文档完善，但 WASM 插件的开发门槛相对较高（需要理解 Proxy-WASM SDK），社区需要更多开箱即用的插件。
• 控制平面性能：在大规模 K8s 集群（数千 Service）下，Ingress 变更触发 xDS 全量推送的性能优化仍是持续改进的重点。

未来结合

• RAG (检索增强生成) 集成：未来可能会直接在网关层集成向量数据库的连接能力，作为 RAG 流程的第一步拦截器。

6. 学习建议

适合人群

• 具备 Kubernetes 基础的运维工程师。
• 需要构建 AI 应用基础设施的后端架构师。
• 对云原生网关、Service Mesh 技术感兴趣的开发者。

学习价值

• Envoy xDS 协议实战：通过 Higress 学习如何通过控制平面驾驭 Envoy。
• Wasm 插件开发：掌握使用 Go/Rust 编写高性能、可移植的网关插件。
• 云原生设计模式：学习如何设计 Operator 模式来管理复杂的分布式系统。

推荐路径

1. 基础：使用 Docker Desktop 或 Kind 部署 Higress 官方 Demo。
2. 实践：配置一个简单的 AI 网关，将请求转发至 OpenAI，并配置一个 Key Auth 插件。
3. 进阶：阅读官方提供的 WASM 插件示例（如 ai-proxy），尝试修改 Go 代码并部署自定义插件。

7. 最佳实践建议

如何正确使用

• 资源限制：WASM 插件虽然安全，但会消耗内存。务必在 K8s 中为 Higress 的 Pod 设置合理的 Limits 和 Requests。
• 配置隔离：生产环境中，应将不同业务域的路由配置在不同的 Namespace 或 Ingress Class 中，避免误操作。

常见问题

• 流式响应中断：检查后端服务是否正确配置了 Transfer-Encoding: chunked，并确保 Higress 的超时设置足够长。
• 插件加载失败：通常是 WASM 字节码架构不匹配（如 s390x 与 amd64）或内存溢出。

性能优化

代码示例

 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

# 示例1：使用Higress实现简单的API网关路由
from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/api/users', methods=['GET'])
def get_users():
    """模拟用户API"""
    return jsonify({
        "users": [
            {"id": 1, "name": "张三"},
            {"id": 2, "name": "李四"}
        ]
    })

@app.route('/api/products', methods=['GET'])
def get_products():
    """模拟产品API"""
    return jsonify({
        "products": [
            {"id": 101, "name": "笔记本电脑"},
            {"id": 102, "name": "无线鼠标"}
        ]
    })

if __name__ == '__main__':
    # 在实际Higress部署中，这些路由会通过网关配置转发到不同后端服务
    app.run(port=8080)

 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

# 示例2：使用Higress进行流量染色和金丝雀发布
def canary_release(request):
    """
    模拟Higress的流量染色功能
    根据请求头决定路由到新版本还是旧版本
    """
    # 获取流量标识头
    canary_header = request.headers.get('X-Canary', 'false')
    
    # 10%的流量路由到新版本
    if canary_header == 'true' or hash(request.remote_addr) % 10 == 0:
        return "新版本服务 (v2.0)"
    else:
        return "旧版本服务 (v1.0)"

# 模拟请求
class MockRequest:
    def __init__(self, headers, remote_addr):
        self.headers = headers
        self.remote_addr = remote_addr

# 测试用例
req1 = MockRequest({'X-Canary': 'true'}, '192.168.1.1')
req2 = MockRequest({}, '192.168.1.2')

print(canary_release(req1))  # 输出: 新版本服务 (v2.0)
print(canary_release(req2))  # 输出: 旧版本服务 (v1.0)

 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

# 示例3：使用Higress进行API限流
from collections import deque
import time

class RateLimiter:
    def __init__(self, rate, per):
        """
        令牌桶算法实现限流
        :param rate: 令牌生成速率
        :param per: 时间窗口(秒)
        """
        self.rate = rate
        self.per = per
        self.allowance = rate  # 当前可用令牌数
        self.last_check = time.time()
        self.request_times = deque()  # 记录请求时间戳

    def allow_request(self):
        """检查是否允许请求"""
        current = time.time()
        time_passed = current - self.last_check
        self.last_check = current
        
        # 补充令牌
        self.allowance += time_passed * (self.rate / self.per)
        if self.allowance > self.rate:
            self.allowance = self.rate
            
        # 记录请求时间
        self.request_times.append(current)
        
        # 清理过期的请求记录
        while self.request_times and self.request_times[0] < current - self.per:
            self.request_times.popleft()
            
        # 检查是否超过限流阈值
        if self.allowance < 1:
            return False
        self.allowance -= 1
        return True

# 使用示例
limiter = RateLimiter(rate=5, per=10)  # 每10秒最多5个请求

for i in range(7):
    if limiter.allow_request():
        print(f"请求 {i+1}: 允许")
    else:
        print(f"请求 {i+1}: 被限流")
    time.sleep(1)

案例研究

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

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

背景:

在阿里巴巴庞大的电商生态系统中，流量洪峰是常态（例如双11大促）。早期的流量管理依赖于 Nginx 结合自研的 Lua 脚本，但随着业务微服务化的深入，云原生架构的普及，传统的网关模式在动态配置、可观测性以及与 Kubernetes (K8s) 的深度集成上面临挑战。集团内部急需一种既能继承 Nginx 高性能，又能符合 Istio 云原生标准，且支持热更新和复杂路由逻辑的新一代网关。

问题:

1. 配置动态性差：传统 Nginx 配置变更往往需要 reload，会导致长连接闪断，影响线上用户体验。
2. 扩展性与维护成本：使用 Lua 开发复杂插件门槛较高，且缺乏标准化的插件市场，业务方定制需求响应慢。
3. 架构割裂：微服务治理框架（如 Spring Cloud、Dubbo）与 K8s Service Mesh 之间存在网络协议和配置管理的割裂，缺乏统一的流量入口。

解决方案:

阿里巴巴基于内部多年的 Nginx 内核深度优化经验，结合云原生技术栈，开源了 Higress。Higress 底层基于 C++ 修改版的 Nginx，确保了极致的高性能；上层采用 Go 语言编写控制平面，实现了与 Istio 的标准兼容。

通过 Higress，阿里实现了：

1. 热更新能力：支持配置和插件的毫秒级动态生效，无需重启进程。
2. Wasm 插件市场：引入 WebAssembly 技术，允许使用 C++、Go、Rust 等多语言编写插件，且支持插件热加载，业务开发效率提升 50% 以上。
3. 统一网关：作为 K8s Ingress 控制器，同时接管了南北向（外部流量进入）和东西向（服务间调用）的流量管理，实现了从微服务网关到 K8s Ingress 的技术栈统一。

效果:

Higress 成功支撑了阿里巴巴内部核心电商业务的平稳运行。在双11等大促场景下，单集群 QPS（每秒查询率）达到百万级别，同时 P99 延迟控制在毫秒级。通过统一的网关层，运维复杂度大幅降低，业务迭代速度显著加快，资源利用率相比传统网关方案提升了 30%。

2：某大型互联网科技公司 AI 业务落地

2：某大型互联网科技公司 AI 业务落地

背景:

随着 AIGC（生成式人工智能）和大语言模型（LLM）的爆发，该公司迅速上线了基于 LLM 的智能客服和内容生成服务。这些服务需要对外部模型提供商（如 OpenAI、阿里云通义千问等）的 API 进行调用，同时也需要对接内部自研的模型服务。

问题:

1. Token 成本高昂：大模型按 Token 计费，恶意请求或重复查询会带来巨大的成本浪费。
2. 协议转换困难：前端通常使用 HTTP/JSON，而后端某些模型服务可能使用 gRPC 或自定义协议，网关层缺乏灵活的转换和流式处理能力。
3. 提示词管理混乱：提示词硬编码在客户端或后端逻辑中，版本更新和 A/B 测试极其困难，无法快速验证哪个 Prompt 效果更好。

解决方案:

该团队部署了 Higress 作为 AI 网关。利用 Higress 针对AI场景定制的特性：

1. AI 代理与路由：通过简单的配置即可将请求转发至不同的 LLM 提供商，并支持统一的参数处理。
2. 插件化能力：
   • 使用 请求限流 插件，对单个用户或 API Key 进行精细化的请求和 Token 限制，防止成本失控。
   • 使用 请求/响应修饰 插件，在网关层动态注入或修改 System Prompt，实现了 Prompt 的集中管理和灰度发布。
3. 语义缓存：利用 Higress 的缓存插件，对相似的语义问题进行缓存，直接返回缓存结果，减少对后端大模型的调用次数。

效果:

通过引入 Higress，该公司成功构建了标准化的 AI API 网关。

1. 成本降低：通过语义缓存和流量控制，后端大模型调用成本降低了约 40%。
2. 开发效率提升：前端开发人员无需关心复杂的鉴权和协议细节，直接调用统一网关接口，AI 功能上线周期缩短了一半。
3. 稳定性增强：网关层实现了对后端模型服务的超时控制和重试机制，即使某个模型提供商宕机，也能通过 Higress 快速切换到备用提供商，保障了业务的高可用性。

对比分析

与同类方案对比

优势分析

• 优势1：深度集成阿里云服务，适合阿里云用户。
• 优势2：基于Envoy和Istio，云原生支持更好。
• 优势3：提供友好的控制台，降低使用门槛。

不足分析

• 不足1：社区和生态相比Kong和APISIX稍弱。
• 不足2：非阿里云用户可能无法充分利用其特性。
• 不足3：部分高级功能可能依赖商业版。

最佳实践

最佳实践指南

实践 1：基于 Wasm 插件实现业务逻辑扩展

说明: Higress 原生支持 WebAssembly (Wasm) 技术，允许开发者使用 C++、Go、Rust 或 AssemblyScript 等语言编写插件。相比传统网关的 Lua 脚本或硬编码方式，Wasm 插件提供了更高的隔离性、更快的执行性能以及更强的安全性，能够实现复杂的请求处理逻辑而无需修改网关核心代码。

实施步骤:

1. 根据团队技术栈选择合适的 Wasm 开发语言（推荐使用 Go 或 Rust）。
2. 编写插件逻辑，例如自定义鉴权、请求头修改或响应体替换。
3. 使用官方提供的 wasm-assembler 工具将代码编译为 .wasm 文件。
4. 在 Higress 控制台或通过 WASM 插件配置接口上传插件。
5. 在路由或网关级别配置启用该插件，并传入必要的配置参数。

注意事项: 开发时需注意 Wasm 的内存限制，避免处理过大的请求体导致内存溢出；生产环境插件建议进行充分的性能压测。

实践 2：利用 Ingress API 进行云原生流量管理

说明: Higress 兼容 Kubernetes Ingress 和 Gateway API 标准。通过使用 YAML 清单文件管理路由规则，可以实现基础设施即代码，便于版本控制和回滚。这种方式特别适合已习惯使用 K8s 原生资源的运维团队，能无缝对接现有的 CI/CD 流程。

实施步骤:

1. 定义 Ingress 或 Gateway API 资源 YAML 文件，配置 Host、Path 以及后端 Service 信息。
2. 使用 kubectl apply -f 命令将配置应用到 Higress 所在的 K8s 集群。
3. 配置 Canary（金丝雀）发布规则，通过 Header 或权重实现灰度发布。
4. 结合 K8s 的 Readiness Probe 确保流量仅路由到健康的 Pod。

注意事项: 确保 Higress Ingress Controller 已正确监听命名空间；复杂的路由配置建议使用 Gateway API 以获得更强大的表达能力。

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

说明: Higress 提供了内置的 OIDC（OpenID Connect）和 Keyless 认证支持。最佳实践包括在网关层统一处理身份验证，避免后端服务重复实现认证逻辑。同时，应配置严格的 CORS 策略和 IP 访问控制列表（ACL）以防止恶意攻击。

实施步骤:

1. 在网关全局或特定路由配置中开启 JWT 验证插件。
2. 配置 OIDC 身份提供商（如 Auth0 或 Keycloak）的 Issuer 和 JWKS 端点。
3. 对于内部服务，配置 block-list 或 allow-list 插件限制来源 IP。
4. 启用 Higress 的安全插件（如 WAF 防护）抵御 SQL 注入和 XSS 攻击。

注意事项: 密钥和凭证应存储在 K8s Secret 中，避免明文写入配置文件；定期更新依赖库以防范已知漏洞。

实践 4：构建服务高可用与容灾机制

说明: 为了保证业务连续性，必须配置主动健康检查和被动熔断机制。Higress 可以自动摘除不健康的后端实例，并在服务恢复时自动加回。结合超时重试策略，可以有效应对服务抖动和网络波动。

实施步骤:

1. 在服务来源配置中，启用主动健康检查，设置合理的检查路径（如 /health）、间隔和超时时间。
2. 配置“超时重试”策略，针对 5xx 错误或连接超时进行自动重试。
3. 设置并发连接数限制和请求队列长度，防止后端服务被压垮。
4. 在多可用区部署 Higress 网关实例，确保网关层本身的高可用。

注意事项: 重试策略需谨慎配置，避免重试风暴导致雪崩效应；对于非幂等请求（如 POST），建议仅在明确业务允许时开启重试。

实践 5：精细化流量控制与限流保护

说明: 面对突发流量或恶意攻击，通过 Higress 配置限流规则至关重要。支持基于请求速率、并发连接数或响应时间进行限流，保护后端服务稳定性。

实施步骤:

1. 识别核心业务接口和易受攻击的接口。
2. 应用 request-limit 或 concurrency-limit 插件。
3. 设置限流阈值，例如每秒 1000 个请求（QPS）或每 IP 每分钟 100 次请求。
4. 配置限流后的响应策略，如直接返回 429 状态码或自定义 JSON 报错信息。
5. 结合 Prometheus 监控指标，动态调整限流阈值。

注意事项: 限

性能优化建议

性能优化建议

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

说明: Higress 基于 Envoy 构建，原生支持 WebAssembly (Wasm)。相比于传统的 Lua 脚本，Wasm 插件通过近原生代码执行（AOT 编译）能获得更高的执行效率，且具有更好的隔离性和资源控制能力。对于复杂的路由逻辑、请求头处理或响应体修改，Wasm 的性能显著优于 Lua。

实施方法:

1. 将现有的 Lua 逻辑重构为 Go、C++ 或 Rust 编写的 Wasm 插件。
2. 在 Higress 控制台或通过 WasmPlugin CRD 加载编译好的 .wasm 文件。
3. 配置插件生效的作用域（全局或特定路由）。

预期效果: 复杂逻辑处理延迟降低 20%-50%，且能显著降低因脚本错误导致的进程崩溃风险。

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

说明: HTTP/3 基于 UDP 协议，解决了 TCP 队头阻塞问题。在弱网或丢包率较高的网络环境下，HTTP/3 能提供比 HTTP/2 更低的连接建立延迟和更好的吞吐量。作为网关，启用 HTTP/3 可以直接改善移动端客户端的访问体验。

实施方法:

1. 在 Higress 的监听器配置中启用 HTTP/3 协议。
2. 配置 UDP 端口（通常复用 443 端口或使用单独的 UDP 端口）。
3. 确保证书配置正确，因为 HTTP/3 强制要求 TLS 1.3。

预期效果: 在高丢包环境下，页面加载时间（TTFB）可减少 30% 以上，连接建立成功率提升。

优化 3：配置全链局超时与重试策略

说明: 不合理的超时和重试设置会导致大量连接处于挂起状态，耗尽网关的文件描述符和内存资源。默认的全局超时可能过长，导致后端故障时雪崩效应加剧。

实施方法:

1. 针对不同的后端服务设置合理的 timeout（建议根据 P99 耗时设置冗余）。
2. 配置 retry 策略，限制重试次数（如 2-3 次），并开启 exponential backoff（指数退避）。
3. 开启 per-try timeout，确保单次重试请求不会长时间阻塞。

预期效果: 在后端服务出现故障时，网关自身的资源占用（CPU/连接数）波动降低 50% 以上，故障恢复速度加快。

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

说明: 默认的 Envoy 配置可能会频繁进行 DNS 解析。对于高 QPS 场景，频繁的 DNS 查询会增加延迟。同时，确保网关与后端服务之间保持 HTTP/2 连接池，可以大幅减少 TCP 握手开销。

实施方法:

1. 在 Cluster 配置中调整 dns_refresh_rate，将默认的刷新频率适当调大，或配置 dns_cache。
2. 启用 HTTP/2 作为 Upstream 协议，并调整 max_requests_per_connection 参数以保持长连接。
3. 调整连接池大小（max_connections）以匹配后端处理能力。

预期效果: 减少后端服务建连开销，在短连接场景下吞吐量可提升 20%-40%。

优化 5：利用本地缓存减少后端压力

说明: 对于读多写少且对实时性要求不极高的数据（如配置信息、静态资源、用户画像），在 Higress 网关层通过本地缓存或 Redis 缓存拦截请求，可以避免流量穿透到后端业务服务。

实施方法:

1. 使用 Higress 的 local-reply 或 response-rewrite 插件配合内存缓存功能（如果支持）。
2. 或者部署一个专

学习要点

• 基于您提供的关键词（Alibaba/Higress）及来源（GitHub Trending），以下是关于 Higress 项目最有价值的 5 个关键要点总结：
• Higress 是阿里巴巴开源的一款基于 Istio 构建的下一代云原生 API 网关，旨在解决云原生时代流量管理与入口网关的碎片化问题。
• 该项目深度集成了 K8s Ingress 与 Gateway API 标准，能够作为标准 Ingress 控制器直接对接 Kubernetes 集群，实现流量的统一管控。
• Higress 提供了卓越的扩展性，支持通过 WASM (WebAssembly) 技术编写插件，使得业务逻辑的扩展更加灵活、安全且语言无关。
• 它在架构上实现了对 Nginx Ingress 的完美兼容，支持将 Nginx 配置和生态无缝迁移，降低了用户从传统架构向云原生架构迁移的门槛。
• 内置了针对微服务场景的流量治理能力，如金丝雀发布、蓝绿发布和负载均衡，同时也集成了针对 AI 服务的推理缓存与路由优化特性。
• 提供了开箱即用的控制台和丰富的 Dashboard，极大地降低了网关的运维与调试复杂度，提升了开发者体验。

学习路径

学习路径

阶段 1：入门基础与概念理解

学习内容:

• 网关基础概念：什么是 API 网关，以及它在微服务架构中的作用（流量入口、安全、协议转换）
• Envoy 基础：Higress 基于 Envoy 构建，了解 Envoy 的基本架构和术语
• Higress 核心特性：了解 Higress 的开源背景、与阿里云 MSE 的关系、以及其云原生和高性能特性
• Docker 基础：学习如何使用 Docker 运行容器，因为 Higress 通常以容器化方式部署

学习时间: 1-2周

学习资源:

• Higress 官方 GitHub 仓库 README
• Higress 官方文档（概念与快速开始部分）
• Envoy 官方文档基础部分
• Docker 官方入门教程

学习建议:

• 不要一开始就陷入配置细节，先理解“南北向流量”与“东西向流量”的区别。
• 动手实践：按照官方文档，在本地 Docker 环境下跑通一个最简单的 Higress 实例。

阶段 2：核心配置与流量管理

学习内容:

• 部署与安装：在 Kubernetes (K8s) 环境中部署 Higress（使用 Helm 或 kubectl）
• 基本网关配置：理解 Ingress API 或 Higress 自定义资源
• 路由配置：学习如何配置域名、路径匹配、Header 匹配等路由规则
• 服务发现：配置 Higness 连接到后端服务（如 K8s Service, Nacos, 固定 IP）
• 流量管理：实现灰度发布（金丝雀发布）、蓝绿部署和负载均衡策略
• 插件系统：了解 Higress 的插件市场，尝试使用现成的插件（如 JWT Auth, Request Block）

学习时间: 2-3周

学习资源:

• Higress 官方文档 - 用户指南
• Kubernetes 官方文档 - Ingress 概念
• Higress 官方示例

学习建议:

• 熟悉 YAML 配置文件是此阶段的关键。
• 建议搭建一个 Minikube 或 Kind 本地 K8s 集群进行练习。
• 尝试将一个简单的 Web 服务接入 Higress，并通过修改路由规则验证流量切换。

阶段 3：安全与可观测性

学习内容:

• 安全认证：配置 HTTPS/TLS 证书，实现 mTLS 双向认证
• 访问控制：基于 IP、Header 或 Key 的访问控制，集成 OAuth2/OIDC
• 可观测性集成：
  • 日志：集成标准日志输出
  • 指标：集成 Prometheus 收请求数、延迟等指标
  • 链路追踪：集成 SkyWalking 或 Jaeger
• WAF 防护：了解如何使用 WAF 插件防御常见 Web 攻击

学习时间: 2-3周

学习资源:

• Higress 官方文档 - 安全与可观测性章节
• Prometheus 官方文档
• SkyWalking 官方文档

学习建议:

• 安全配置往往容易导致服务不可用，建议先在测试环境验证。
• 学习如何查看 Higress 的日志来排查连接失败或 502/504 错误。

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

学习内容:

• Wasm 插件开发：学习 WebAssembly 基础，使用 Go 或 C++ 开发自定义 Higress 插件
• 高级服务治理：熔断、限流、重试机制的超时配置
• 服务网格集成：了解 Higress 如何作为 Istio 的 Ingress Gateway 使用
• 多集群管理：在多 K8s 集群环境下使用 Higress 进行流量管理
• 高可用部署：生产环境下的 Higress 部署架构与扩缩容策略

学习时间: 3-4周

学习资源:

• Higress 官方文档 - Wasm 插件开发指南
• WebAssembly (Wasm) 官方介绍
• Istio 官方文档 - Gateway 部分

学习建议:

• 如果不熟悉 C++/Go，建议从 Go 开始编写 Wasm 插件，Higress 对 Go 支持较好。
• 深入理解 Envoy 的 xDS 协议会对你理解 Higress 的底层原理有很大帮助。
• 思考如何通过插件实现业务逻辑与网关的解耦。

阶段 5：架构设计与源码研读

学习内容:

• Higress 架构设计：深入理解 Higress 的控制面与数据面分离架构
• 源码分析：阅读 Higress 核心源码，理解

常见问题

1: Higress 是什么？它与 Alibaba 有什么关系？

1: Higress 是什么？它与 Alibaba 有什么关系？

A: Higress 是一个基于阿里内部多年实践沉淀的下一代云原生 API 网关。它诞生于阿里巴巴，旨在解决云原生时代流量治理的痛点。

Higress 的前身是阿里云的 MSE 云原生网关和内部使用的 Tengine 网关。阿里巴巴将其核心代码开源，旨在为开发者提供一个统一、高效、标准化的流量入口。它继承了阿里巴巴在电商、金融等高并发场景下的网关技术经验，同时深度集成了 Istio 和 Envoy 的生态。

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

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

A: Higress 的核心优势在于其“云原生”和“标准化”的架构设计，主要区别如下：

1. 技术架构：传统网关（如 Nginx）通常基于多进程模型，扩展插件往往需要 C 语言编写或 Lua（如 OpenResty），开发门槛较高。Higress 基于 Istio 和 Envoy，采用 WASM (WebAssembly) 技术编写插件。这意味着开发者可以使用 Java, Go, Python, JavaScript 等高级语言编写业务逻辑，且插件热更新极其灵活，无需重启网关。
2. 服务网格集成：Higress 原生支持 Istio。它可以作为 Ingress Gateway 接入集群外部流量，也可以作为东西向流量网关处理服务间通信，实现了 Ingress 和 Mesh 的统一流量管理，而传统网关通常需要额外的配置才能与 Mesh 集成。
3. 安全与防护：Higress 内置了更严格的 WAF（Web应用防火墙）能力，且支持与阿里云 WAF 防护规则无缝对接，安全性针对云原生环境进行了优化。

3: Higress 是否支持从 Nginx 或 Ingress Controller (如 Nginx Ingress) 进行迁移？

3: Higress 是否支持从 Nginx 或 Ingress Controller (如 Nginx Ingress) 进行迁移？

A: 是的，Higress 提供了非常完善的迁移工具和兼容性支持，以降低用户的迁移成本。

1. Nginx 兼容：Higress 支持直接导入 Nginx 的配置格式。它内置了 Nginx 配置的转换逻辑，可以将现有的 Nginx.conf 配置转化为 Higress 的路由规则。
2. Kubernetes Ingress 注解兼容：对于 Kubernetes 用户，Higress 兼容标准的 K8s Ingress API，并且兼容 Nginx Ingress Controller 的常用注解。这意味着在大多数情况下，你只需要将 Ingress Class 修改为 Higress，即可实现无缝切换，无需修改大量的 YAML 配置文件。

4: Higress 如何处理插件开发？必须使用 Go 或 Rust 吗？

4: Higress 如何处理插件开发？必须使用 Go 或 Rust 吗？

A: 不必须。这是 Higress 最大的亮点之一，它利用 WASM 技术实现了多语言插件支持。

虽然 Higress 的核心代码是 Go 语言编写的，但在编写自定义插件（如鉴权、流量染色、请求改写等）时，开发者不需要使用 Go。Higress 提供了 WASM (WebAssembly) 运行时，允许开发者使用 JavaScript/TypeScript、Go、C++、Rust 甚至 Python 来编写插件逻辑。这使得业务开发团队能够利用他们最熟悉的语言来扩展网关功能，极大地降低了开发门槛。

5: Higress 是否支持 Dubbo 或 gRPC 等微服务协议？

5: Higress 是否支持 Dubbo 或 gRPC 等微服务协议？

A: 是的，Higress 对微服务协议有非常深入的支持，特别是针对阿里生态和云原生环境。

1. Dubbo 支持：由于出身于阿里巴巴，Higress 原生支持 Dubbo、Dubbo3 (Triple) 协议。它可以将 HTTP/HTTPS 请求转换为 Dubbo 协议调用后端服务，这对于需要从传统的 API 网关对接 Java 微服务（特别是使用 Dubbo 框架的系统）的场景非常友好。
2. gRPC 支持：Higress 原生支持 gRPC 协议的代理、负载均衡和协议转换。它支持 gRPC-Web，允许浏览器端的 JavaScript 直接调用后端的 gRPC 服务，无需进行额外的协议转换层。

6: Higress 的性能表现如何？能否应对高并发场景？

6: Higress 的性能表现如何？能否应对高并发场景？

A: Higress 具备极高的性能，能够应对企业级的高并发流量。

1. 底层性能：Higress 的数据面基于 Envoy，这是一个用 C++ 编写的高性能代理，具有极低的延迟和极高的吞吐量。
2. 优化：阿里巴巴内部对 Higress 进行了深度的内核级优化（如对 Linux 内核的调优），使其在长连接管理、SSL 加解密处理以及高 QPS 场景下的表现非常稳定。
3. 弹性伸缩：作为云原生网关，Higress 支持基于 Kubernetes 的水平扩容（HPA），可以根据流量

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 基于 Higress 的快速入门特性，请尝试在本地 Docker 环境中部署一个 Higress 网关，并配置一个简单的路由规则，将访问 /hello 的请求转发到一个模拟的后端服务（如 Nginx 默认页或一个简单的 HTTP echo 服务）。

提示**:

查阅 Higress 官方文档中的 “快速开始” 或 “Docker 部署” 章节。

实践建议

实践建议

以下是基于 Higress 作为 AI 网关和 API 网关的 6 条实践建议：

1. 利用 AI 提供者路由实现成本与延迟优化

场景：同时接入了 OpenAI、Azure OpenAI 以及国内的其他大模型厂商，需要根据业务需求灵活切换。 建议：不要将模型提供者硬编码在业务代码中。应配置 Higress 的默认模型提供者，并在特定路由或服务级别覆盖此设置。 最佳实践：对于非关键业务或测试环境，将默认模型设置为性价比高的开源模型（如 Llama 3 或 Qwen）；在生产环境或需要高逻辑准确性的路径上，指向 GPT-4 等闭源模型。利用 Higress 的路由转发能力，可以在零代码改动的情况下实现 A/B 测试对比不同模型的效果。

2. 配置 Prompt 模板与上下文管理

场景：前端直接调用大模型 API，导致 Prompt 泄露或难以统一维护系统提示词。 建议：使用 Higress 的AI 代理插件中的 prompt 字段来预置系统提示词。 最佳实践：在网关层固化“人设”和“行为准则”。例如，在网关配置中注入“你是一个客服助手，请只回答与产品相关的问题”，前端只需发送用户的原始问题，无需每次拼接完整的 Prompt。这有助于简化客户端逻辑，并便于统一迭代和修正模型的输出风格。

3. 实施语义缓存以降低 Token 消耗

场景：用户频繁提问高度相似的问题（如常见的 FAQ），每次都请求大模型 API 产生高额费用。 建议：开启 Higress 的语义缓存功能。 最佳实践：针对知识库问答或搜索增强生成（RAG）场景，配置语义缓存。当用户的提问与缓存中的问题语义相似度超过设定阈值（如 0.85）时，直接返回缓存的答案，而不再请求 LLM。 注意：不建议对创意写作或实时性要求极高的场景开启缓存，因为这会导致回答缺乏变化或信息过时。

4. 警惕上下文长度限制与 Token 计费

场景：客户端发送过长的历史对话记录，导致 API 返回 400 context_length_exceeded 错误。 建议：在 Higress 的 AI 插件配置中设置 max_tokens 或利用上下文管理功能自动截断。 最佳实践：配置 max_context_length 参数。当用户传入的历史记录超过模型限制时，网关应自动丢弃最旧的消息，保留最近的对话窗口，确保请求能被模型接受，而不是直接报错。同时，利用 Higress 的计费统计功能监控不同路由的 Token 消耗，以便优化成本。

5. 敏感信息过滤与安全防护

场景：用户尝试通过 Prompt 注入攻击套取系统指令，或提交违规内容。 建议：在 AI 代理处理之前，串联配置内容安全插件。 最佳实践：启用输入审查模块，拦截包含恶意指令（如“忽略之前的所有指令”）的请求。同时，对模型输出的内容进行审查，防止生成不当内容。Higress 支持集成阿里云内容安全或其他 moderation 服务，在网关层作为防护机制保护后端大模型。

6. 流式输出（SSE）的超时与重试策略

场景：使用流式响应时，网络波动导致连接意外中断，用户体验受影响。 建议：合理配置后端服务的超时时间，并理解 SSE 的重试机制。 最佳实践：由于大模型生成回答可能需要较长时间（特别是处理长文档时），务必将 Higress 的 requestTimeout 设置得比模型最大生成时间要长（例如设置为 60s 或更高）。对于流式请求，确保客户端能够处理 SSE 格式的数据帧。 注意：不建议在网关层开启针对流式响应的“自动重试”，因为这可能会导致客户端收到重复或错乱的数据。

引用

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

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

站内链接

• 分类： 系统与基础设施 / 开源生态
• 标签： Higress / API 网关 / AI Native / 阿里开源 / Istio / Envoy / WASM / LLM
• 场景： 大语言模型 / 云原生/容器 / DevOps/运维

相关文章

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