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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,530 (+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 插件，在提供微服务流量管理的基础上，新增了针对大模型应用的 AI 网关与 MCP 服务托管功能。本文将介绍其系统架构、核心组件及应用场景，帮助读者了解如何利用 Higress 构建高效、可扩展的网关服务。

摘要

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

1. 项目简介

Higress 是由阿里巴巴开源的、云原生 AI 原生 API 网关。它基于 Istio 和 Envoy 构建，使用 Go 语言编写。该项目旨在为云原生应用和 AI 大模型应用提供统一的流量入口和管理能力。

2. 核心架构

Higress 采用了控制面与数据面分离的架构：

• 技术扩展：通过 WebAssembly (WASM) 插件机制扩展功能，这使得它具有极高的灵活性和扩展性。
• 高性能配置：配置变更通过 xDS 协议传播，延迟仅为毫秒级，且不中断连接。这一特性使其非常适用于需要长连接的 AI 流式响应 场景。

3. 三大核心功能与用途

Higress 的主要应用场景覆盖了从传统微服务到前沿 AI 领域的需求：

1. AI 网关

   • 功能：提供统一接口对接 30+ 家大语言模型（LLM）服务商。
   • 特性：具备协议转换、可观测性（统计）、缓存及安全防护能力。
   • 关键组件：ai-proxy、ai-statistics、ai-cache、ai-security-guard 等插件。

2. MCP 服务器托管

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

3. Kubernetes Ingress

   • 功能：作为 K8s 的 Ingress 控制器，管理集群入口流量。
   • 兼容性：兼容 nginx-ingress 的注解，便于用户迁移。

4. 总结

Higress 是一款将传统 API 网关能力与 AI 服务治理深度融合的下一代网关产品，既满足了微服务架构的流量管理

评论

总体判断

Higress 是一款基于 Envoy 和 Istio 构建的新一代云原生 API 网关，其核心差异化在于将“AI 网关”作为一等公民原生集成，而非简单的插件堆砌。它成功地将传统流量治理与大模型（LLM）流量处理进行了统一架构融合，是当前云原生网关领域向 AI Native 方向演进中极具竞争力的技术方案。

深度评价依据

1. 技术创新性：基于 WASM 的统一架构与 AI 原生化

• 事实： 官方描述明确指出 Higress 基于 Istio 和 Envoy，并扩展了 WebAssembly (WASM) 插件能力。DeepWiki 中特别强调了其“AI Native API Gateway”的定位，提供 AI 网关特性、MCP 服务器托管以及传统 API 网关功能。
• 推断： Higress 的最大技术创新在于控制平面与数据平面的解耦与重组。利用 Envoy 的高性能数据平面处理 LLM 的长连接与流式传输，同时利用 Istio 的控制平面思想管理配置。其引入 WASM 插件机制解决了传统网关（如 Nginx Lua）插件开发难、安全性差、隔离性弱的问题。更重要的是，它原生支持 MCP (Model Context Protocol)，这是目前连接 AI Agent 与外部工具的前沿协议标准，表明其技术栈紧跟 AI 生态的最前沿，而非仅仅做 Token 转发。

2. 实用价值：统一流量入口与成本优化

• 事实： README 提及它同时支持 Kubernetes Ingress、微服务路由以及 AI 网关功能。DeepWiki 提到它集成了 AI Gateway 特性和 MCP 系统。
• 推断： 在企业落地中，Higress 解决了架构碎片化的痛点。许多团队现在面临“两套网关”的局面：一套 K8s Ingress 处理微服务流量，一套 AI 网关（如 One/Gateway）处理大模型调用。Higress 允许企业用一套基础设施同时管理传统 RPC/RESTful 流量和 LLM 流量。此外，通过内置的 Prompt 模板管理和 Token 统计，它能直接帮助企业监控和优化 AI 调用成本，具有极高的实用价值。

3. 代码质量与架构：云原生标准与扩展性

• 事实： 项目使用 Go 语言编写（星标数 7,530），架构上明确分离了控制平面和数据平面。文档中详细列出了 Core Architecture、WASM Plugin System 等章节。
• 推断： 基于 Envoy（C++）作为数据面保证了极致的高性能，而使用 Go 语言编写控制面符合云原生生态的标准操作，便于集成 K8s Operator。架构设计上，WASM 的引入使得代码扩展性极强，开发者可以用 C++/Go/Rust/AssemblyScript 编写插件而无需重启网关。文档的完备性（包含中英日文）显示了阿里系项目国际化的野心与工程规范。

4. 社区活跃度：阿里背书与生态共建

• 事实： 星标数超过 7,500，由阿里巴巴开源。
• 推断： 作为阿里内部通用的网关方案（支撑了淘宝、天猫等高并发场景），其代码经过了极端流量的验证，成熟度极高。虽然开源社区的热度可能不如某些纯 AI 初创公司的产品，但其企业级维护的稳定性是普通开源项目无法比拟的。社区活跃度主要来源于国内云原生开发者群体，对于国内用户而言，中文文档和响应速度是巨大优势。

5. 学习价值：理解 AI 时代的流量治理

• 事实： DeepWiki 提供了 Development Guide 和 WASM Plugin System 的详细说明。
• 推断： 对于开发者而言，Higress 是学习**“云原生网关 + AI 应用层”**结合的最佳实践案例。通过研究其源码，可以深入理解如何处理 SSE（Server-Sent Events）流式转发、如何实现 LLM 的语义路由（Semantic Routing）以及如何设计可插拔的 AI 插件市场。

边界条件与验证清单

不适用场景：

• 边缘计算/嵌入式网关： 基于 Envoy 的架构资源占用较高，不适合部署在资源受限的边缘设备或 IoT 网关中。
• 极简静态站点： 仅需简单的静态文件托管或极低流量的反向代理，使用 Nginx 或 Caddy 更为轻量。
• 非 K8s 环境的强依赖： 虽然 Higress 支持虚拟机部署，但其最大的价值在于 K8s 生态，如果基础设施完全脱离容器化，运维复杂度可能过高。

快速验证清单：

1. LLM 流式转发延迟测试： 部署 Higress 并配置 OpenAI 兼容接口，使用 wrk 或自定义脚本测试流式响应的首字节响应时间（TTFB），对比直连 API 的损耗（应低于 10ms）。
2. WASM 插件动态加载验证： 编写一个简单的 Go WASM 插件（例如修改请求头），在不重启 Higress Pod 的情况下通过控制台/Console 动态加载并生效，验证热更新能力。
3. MCP 协议兼容性检查： 如果有 AI Agent 需求，尝试配置 Higress 作为 MCP Server，验证

技术分析

Higress 深度技术分析报告

基于阿里巴巴开源的 Higress（AI Gateway | AI Native API Gateway）仓库及提供的 DeepWiki 片段，以下是对该项目的全面深入分析。

1. 技术架构深度剖析

技术栈与架构模式

Higress 采用了云原生 的技术栈，其核心构建于 Istio 和 Envoy 之上。

• 底层引擎：使用 Envoy 作为高性能数据平面，利用其 L7 处理能力和可扩展性。
• 控制平面：基于 Istio 进行了深度的定制和裁剪。Higress 并没有直接使用 Istio 庞重的控制平面，而是剥离并重构了其配置管理和流量分发逻辑，使其更轻量、更适合 API 网关场景。
• 编程语言：Go。控制平面由 Go 编写，利用其高并发特性处理配置推送；数据平面 Envoy 为 C++，但 Higress 极大地依赖 WebAssembly (WASM) 来编写扩展插件，允许开发者使用 C++, Go, Rust, JavaScript 等语言编写逻辑。

核心模块与设计

1. 控制平面：
   • 负责 Ingress/API Gateway 配置的解析（如 Kubernetes Ingress YAML 或自定义 Gateway CRD）。
   • 通过 xDS 协议 将配置下发至数据平面。
   • 亮点：配置变更通过 xDS 秒级下发，且支持热更新，无需重启数据平面，这对长连接（如 AI 流式响应）至关重要。
2. 数据平面：
   • 处理实际流量，执行路由、负载均衡、WASM 插件逻辑。
3. WASM 插件系统：
   • 这是 Higress 的核心抽象层。它将业务逻辑（如鉴权、限流、AI 请求转换）封装为 WASM 模块，实现了逻辑与网关内核的解耦。

架构优势

• 高可用性与热更新：基于 Envoy 的架构天然支持热重启和配置平推，在 AI 流式输出场景下，配置变更不会中断正在进行的 LLM 对话。
• 生态隔离：通过 WASM 虚拟机运行插件，即使插件崩溃也不会导致网关崩溃，安全性远高于传统的 Lua 脚本嵌入。

2. 核心功能详细解读

主要功能与场景

根据描述，Higress 定位为 “AI Native API Gateway”，主要功能分为三层：

1. 传统 API 网关：Kubernetes Ingress 管理、微服务路由、负载均衡、鉴权、限流。
2. AI 网关：
   • 统一 LLM 接入：将 OpenAI, Azure, 通义千问, HuggingFace 等不同厂商的 API 统一为标准协议。
   • 提示词管理：在网关层进行 Prompt 模板化和注入，无需修改后端应用。
   • Token 计费与限流：基于 Token 数量而非单纯的请求数进行限流和计费统计。
3. MCP (Model Context Protocol) 系统集成：作为 AI Agent 的工具托管中心，允许大模型安全地调用外部工具/API。

解决的关键问题

• AI 供应商锁定：通过统一适配层，业务代码只需调用 Higress，Higress 负责对接不同模型厂商，切换模型只需改配置。
• Token 成本与安全：在网关层截获请求，实现敏感词过滤（通过 WASM 插件）和 Token 预算控制，防止后端应用被刷爆。
• MCP 协议落地：解决了 Agent 如何安全、标准化地连接外部数据源的问题，Higress 充当 MCP Server 的代理。

与同类工具对比

• VS Nginx/Kong：Higress 基于 Envoy，配置下发机制（xDS）比 Nginx 的 reload 机制更平滑，更适合云原生和长连接场景。Kong 主要基于 Nginx/OpenResty，虽然也有 WASM 支持，但 Higress 原生对 Kubernetes 和 Istio 生态集成更深。
• VS 传统 Istio Ingress：Higress 专为网关场景优化，去掉了 Istio 中沉重的 Sidecar 注入复杂性，配置更简单，性能损耗更低。

3. 技术实现细节

关键技术方案

• WASM (WebAssembly)：Higress 利用 Envoy 的 WASM 能力。当请求进入时，Envoy 会加载指定的 WASM 滤镜。这允许用户编写 Go 代码，编译为 .wasm 文件，上传至 Higress，网关即可动态加载执行。
• xDS 协议优化：Higress 实现了增量 xDS 推送。在 AI 场景中，配置可能频繁变更（如调整 Prompt 模板），Higress 确保只推送变更的部分，减少网络开销和 CPU 消耗。

代码组织与设计模式

• CRD 驱动：作为 Kubernetes Ingress Controller，Higress 监听 Ingress, Gateway, WasmPlugin 等 CRD 资源。
• 适配器模式：在 AI 网关功能中，针对不同 LLM 厂商（OpenAI vs 通义千问），采用适配器模式将差异化的请求参数（如 model 字段命名、流式传输格式）转换为统一的内部格式。

性能优化

• 零拷贝：Envoy 本身的高性能特性被保留。
• 连接池：针对 LLM 接口通常耗时较长的特点，Higress 可能优化了上游连接池的保持策略，避免频繁握手带来的延迟。

4. 适用场景分析

最适合的场景

1. 企业级 AI 应用落地：企业内部需要对接多个大模型，希望统一管理 API Key、监控 Token 消耗，并对 Prompt 进行统一治理。
2. 微服务/Kubernetes 环境：技术栈基于 K8s，需要一个高性能、支持热更新的 Ingress Controller。
3. AI Agent 开发：需要利用 MCP 协议让 LLM 访问内部数据或工具，Higress 可以作为这些工具的安全网关。

不适合的场景

1. 极简单体应用：如果只是一个简单的静态网站或单体应用，使用 Nginx 足矣，Higress 的 K8s 依赖和架构过于厚重。
2. 极致边缘计算：虽然 WASM 很轻量，但 Envoy 本身的内存占用相对较高（通常几十 MB 起步），在资源极度受限的 IoT 设备上可能不如轻量级边缘代理。

集成方式

通常部署为 Kubernetes 的 DaemonSet 或 Deployment，通过 Service (LoadBalancer/NodePort) 暴露流量入口。

5. 发展趋势展望

演进方向

• AI 原生深化：未来将更深度集成模型路由（根据问题复杂度自动路由到不同大小的模型）和语义缓存。
• RAG (检索增强生成) 编排：网关可能会内置向量数据库连接能力，在请求到达 LLM 前自动进行上下文检索。

社区与改进

• 文档与易用性：对于非 Go/C++ 开发者，WASM 插件的开发调试仍有门槛，需要更强大的 CLI 工具和 IDE 插件支持。
• MCP 生态：随着 MCP 协议的普及，Higress 作为 MCP Host 的能力将是其差异化竞争的关键。

6. 学习建议

适合人群

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

学习路径

1. 基础：熟悉 Envoy 代理基本概念（Listener, Route, Cluster）。
2. 实践：在本地 Kind/Minikube 集群部署 Higress，配置一个简单的 AI 代理转发至 OpenAI。
3. 进阶：尝试使用 Go 编写一个简单的 WASM 插件（例如修改 HTTP Header），编译并在 Higress 中加载。

7. 最佳实践建议

正确使用指南

• 资源隔离：在生产环境中，建议将 AI 流量的处理与普通微服务流量分开，使用不同的 Gateway 资源或独立的 Higress 实例，以免 AI 长连接占用过多连接池影响普通业务。
• WASM 插件管理：不要在网关上进行繁重的业务计算。WASM 插件应保持轻量（如 Header 转换、简单的 Token 校验），复杂的业务逻辑仍应下沉至后端服务。

性能优化

• 开启 HTTP/2：AI 接口通常使用 HTTP/2 进行流式传输，确保 Higress 到后端 LLM 服务的连接开启 HTTP/2。
• 超时配置：AI 请求响应时间较长，务必调整 Higress 的路由超时时间，避免网关过早断开连接。

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

抽象层与复杂性转移

Higress 在“流量管理”这一抽象层上，将业务逻辑的定制性与基础设施的高性能进行了剥离。

• 复杂性转移：它将流量控制的复杂性从应用代码转移到了基础设施层，同时通过 WASM 将扩展的复杂性从 C++ 内核转移到了高级语言。
• 代价：这种分层要求运维团队必须理解云原生和 Envoy 的概念，提升了运维门槛。

价值取向

• 可扩展性与安全性：Higress 牺牲了部分“原生 C++”的极致性能，换取了 WASM 带来的动态扩展性和沙箱隔离安全性。
• 标准化与灵活性：它试图在标准 K8s Ingress（标准化）和复杂的业务路由（灵活性）之间寻找平衡。

工程哲学

Higress 的范式是**“配置即代码，插件即微服务”**。它将网关不仅仅视为路由器，而是视为一个分布式的逻辑执行节点。

• 误用风险：最容易误用的是将网关当作业务服务器，在 WASM 插件中编写过长、阻塞式的代码（如数据库查询），这会直接阻塞 Envoy 的事件循环，导致整个网关性能雪崩。

可证伪的判断

1. 性能判断：在启用 10 个以上的复杂 WASM 插件时，Higress 的长连接 P99 延迟增加幅度应显著低于基于 Lua 的 Kong 网关。
2. 稳定性判断：当一个 WASM 插件因逻辑错误崩溃时，Higress 的数据平面应继续运行并处理其他流量，且该插件应能被网关自动重启或隔离，而不会导致整个 Pod 重启。
3. **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

# 示例1：使用Higress实现简单的流量路由
from flask import Flask, request, jsonify

app = Flask(__name__)

# 模拟两个后端服务
@app.route('/service_a')
def service_a():
    return jsonify({"service": "A", "message": "这是服务A的响应"})

@app.route('/service_b')
def service_b():
    return jsonify({"service": "B", "message": "这是服务B的响应"})

# 模拟Higress的网关路由功能
@app.route('/gateway/<path:path>')
def gateway(path):
    # 根据请求头中的User-Agent进行简单路由
    user_agent = request.headers.get('User-Agent', '')
    
    if 'mobile' in user_agent.lower():
        # 移动端请求路由到服务A
        return service_a()
    else:
        # 其他请求路由到服务B
        return service_b()

if __name__ == '__main__':
    app.run(debug=True)

 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

# 示例2：实现简单的限流功能
from flask import Flask, request, jsonify
from collections import defaultdict
import time

app = Flask(__name__)

# 简单的内存限流器
class RateLimiter:
    def __init__(self):
        self.requests = defaultdict(list)
    
    def is_allowed(self, client_id, limit=5, window=60):
        now = time.time()
        # 清理过期记录
        self.requests[client_id] = [
            req_time for req_time in self.requests[client_id]
            if now - req_time < window
        ]
        # 检查是否超过限制
        if len(self.requests[client_id]) >= limit:
            return False
        self.requests[client_id].append(now)
        return True

limiter = RateLimiter()

@app.route('/api/data')
def get_data():
    client_id = request.remote_addr
    if not limiter.is_allowed(client_id):
        return jsonify({"error": "请求过于频繁，请稍后再试"}), 429
    return jsonify({"data": "这是受保护的API数据"})

if __name__ == '__main__':
    app.run(debug=True)

 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

# 示例3：实现服务发现和负载均衡
from flask import Flask, request, jsonify
import random

app = Flask(__name__)

# 模拟服务注册表
service_registry = {
    "user-service": [
        {"host": "user1.example.com", "port": 8001},
        {"host": "user2.example.com", "port": 8002},
        {"host": "user3.example.com", "port": 8003}
    ],
    "order-service": [
        {"host": "order1.example.com", "port": 9001},
        {"host": "order2.example.com", "port": 9002}
    ]
}

# 简单的负载均衡器
class LoadBalancer:
    @staticmethod
    def get_service_instance(service_name):
        instances = service_registry.get(service_name, [])
        if not instances:
            return None
        # 随机选择一个实例（实际生产环境应使用更复杂的算法）
        return random.choice(instances)

@app.route('/service/<service_name>')
def proxy_service(service_name):
    instance = LoadBalancer.get_service_instance(service_name)
    if not instance:
        return jsonify({"error": "服务不可用"}), 503
    
    # 模拟转发请求到选定的服务实例
    return jsonify({
        "message": f"请求已转发到 {service_name}",
        "target": f"{instance['host']}:{instance['port']}"
    })

if __name__ == '__main__':
    app.run(debug=True)

案例研究

1：某头部电商平台大促保障

1：某头部电商平台大促保障

背景: 该电商平台在每年的双11和618大促期间，流量会呈现数十倍的爆发式增长。原有的基于 Nginx 的网关架构在应对每秒百万级 QPS（Queries Per Second）时，配置变更繁琐，且缺乏对 Dubbo、gRPC 等微服务协议的原生支持，导致研发和运维效率在大促备战期间极其低下。

问题:

1. 传统网关在处理高并发流量时延迟较高，且资源利用率不均衡。
2. 业务逻辑变更需要频繁修改网关配置甚至重启服务，影响大促期间的系统稳定性。
3. 缺乏一站式的流量治理和安全防护能力，需要额外集成 WAF 和限流熔断组件，增加了系统复杂度。

解决方案: 引入阿里云 Higress 作为统一的 API 网关。利用 Higress 的高性能 Istio 数据面，将流量入口与后端微服务打通。通过其插件市场能力，实现了对请求参数的校验、流量整形以及对接入的第三方 API 进行统一认证。同时，利用 Higress 对云原生架构的深度支持，实现了服务的平滑迁移和蓝绿发布。

效果:

1. 成功支撑了大促期间峰值流量超过 200万 QPS，P99 延迟降低了 40%。
2. 运维效率显著提升，配置变更实现了秒级生效，无需重启网关服务。
3. 统一了流量治理底座，将原有的多套网关体系收敛为一套，降低了约 30% 的服务器资源成本。

2：某大型跨国企业 SaaS 平台

2：某大型跨国企业 SaaS 平台

背景: 该企业为全球客户提供 SaaS 服务，其系统架构包含遗留的 Java EE 系统和现代化的 Spring Cloud 微服务，以及部署在 AWS 和阿里云上的混合云环境。由于业务遍及多个国家，需要对接大量外部的第三方支付和物流 API。

问题:

1. 遗留系统与现代微服务之间的协议转换（如 SOAP 转 REST）非常痛苦，开发人员需要编写大量胶水代码。
2. 混合云环境下，跨云调用 API 存在严重的网络延迟和安全风险，且缺乏统一的流量观测能力。
3. 对接第三方 API 时，缺乏统一的标准来处理鉴权、限流和超时重试，导致系统稳定性受上游服务商影响较大。

解决方案: 部署 Higress 作为混合云架构下的统一 API 出入口。利用 Higress 强大的协议转换能力，无缝连接后端遗留系统与前端应用。针对第三方 API 接入，使用了 Higress 的全生命周期管理功能，配置了精细化的后端服务超时、重试和熔断策略。同时，开启 Higress 的 WAF 防护功能，保障跨云数据传输的安全。

效果:

1. 实现了混合云流量的统一管控，跨云调用的成功率从 99.5% 提升至 99.95%。
2. 通过内置的协议转换插件，节省了开发团队约 60% 的适配工作量，加速了新业务上线速度。
3. 建立了统一的 API 资产目录，使得不同团队能够清晰地看到和管理所有对外接口，极大提升了运维和审计效率。

3：AIGC 应用开发者平台

3：AIGC 应用开发者平台

背景: 一家专注于生成式 AI 应用的初创公司，需要构建一个面向企业用户的 LLM（大语言模型）网关。其业务需要对接 OpenAI、Claude 以及国内多家大模型厂商的 API，并根据用户请求的复杂度智能地将请求路由到不同的模型以优化成本。

问题:

1. 各大模型厂商的 API 接口定义不统一（参数、格式各异），集成成本极高。
2. 直接将 API Key 暴露给前端存在极大的密钥泄露风险。
3. 无法根据 Prompt 的 Token 数量和用户等级进行灵活的计费和流量控制，导致成本难以控制。

解决方案: 基于 Higress 构建了企业专属的 AI 网关。利用 Higress 的 ai-proxy 插件，屏蔽了不同模型厂商的接口差异，统一了客户端调用协议。在后端服务配置中，设置了基于内容的路由规则，将简单的对话请求路由至低成本模型，将复杂分析请求路由至高精度模型。同时，利用 Higress 的请求头处理能力，在网关层统一添加鉴权信息，屏蔽了上游模型的 API Key。

效果:

1. 实现了“一次开发，接入多家模型”，新接入一个模型厂商的时间从 3 天缩短至 30 分钟。
2. 杜绝了 API Key 泄露的风险，所有上游密钥均在网关层加密管理。
3. 通过智能路由和并发限制，在保证用户体验的前提下，将大模型调用的 Token 成本降低了约 45%。

对比分析

与同类方案对比

优势分析

• 优势1：高性能架构，基于 Rust 和 Go 开发，适合高并发场景。
• 优势2：阿里巴巴背书，社区活跃，国内支持较好。
• 优势3：提供可视化控制台，配置简单，适合快速上手。

不足分析

• 不足1：相比 Kong 和 APISIX，插件生态相对较少。
• 不足2：商业支持需付费，成本较高。
• 不足3：文档和社区资源不如 Kong 和 APISIX 丰富。

最佳实践

最佳实践指南

实践 1：基于 Envoy 的深度定制与扩展

说明: Higress 基于 Envoy 构建，利用其 C++ 高性能内核，通过 WASM (WebAssembly) 技术实现了插件的热加载和动态扩展。这使得开发者可以使用 C++、Go、Rust、AssemblyScript 等多种语言编写网关插件，而无需重新编译或重启网关进程。

实施步骤:

1. 评估业务逻辑，确定是否需要自定义鉴权、流量整形或协议转换逻辑。
2. 使用 Go 或 Rust 编写 WASM 插件，利用 Higress 提供的 SDK 处理请求/响应头。
3. 将编译好的 WASM 文件上传至 Higress 控制台或通过 OCI 镜像仓库进行动态加载。
4. 在控制台配置插件路由规则，将特定流量引入 WASM 插件处理。

注意事项: 编写 WASM 插件时需注意内存限制和执行超时设置，避免阻塞主网关线程。

实践 2：服务发现与 Nacos 集成

说明: Higress 原生集成了 Nacos、Consul 等注册中心，能够自动感知服务实例的上下线。相比传统的 Ingress Controller，它无需依赖 Kubernetes Service 对象，而是直接对接注册中心，减少了网络跳转，降低了延迟。

实施步骤:

1. 在 Higress 中配置来源类型，选择 Nacos 或 Consul 作为服务来源。
2. 填写注册中心的 Server 地址、命名空间和访问凭据。
3. 创建 Ingress 路由时，Service 名称直接填写注册中心中的服务名。
4. 配置服务版本标签或子集，以实现基于权重的蓝绿或金丝雀发布。

注意事项: 确保 Higress 所在的网络环境能够直接访问注册中心的网络端口，避免跨网络访问导致的连通性问题。

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

说明: Higress 提供了内置的 WAF（Web应用防火墙）插件，支持针对 OWASP Top 10 攻击的防护。同时，它支持与云原生的网关认证体系（如 OIDC、JWT）无缝集成，实现对 API 的细粒度访问控制。

实施步骤:

1. 在网关全局或特定路由下启用 WAF 插件。
2. 根据业务需求配置防御规则（如 SQL 注入、XSS 攻击检测模式）。
3. 配置认证插件（如 KeyAuth 或 JWT），限制非法 API 调用。
4. 开启日志采集，将安全事件对接至 SIEM 系统进行审计。

注意事项: WAF 规则的开启可能会增加轻微的处理延迟，建议在生产环境压测后开启严格的拦截模式。

实践 4：Dubbo 与 gRPC 协议的无缝转换

说明: 不同于传统的 Nginx Ingress 仅处理 HTTP 流量，Higress 深度集成了 Dubbo、gRPC 等微服务协议。它可以将 HTTP/JSON 请求自动转换为 Dubbo 或 gRPC 请求，实现后端服务的零改造接入，特别适合进行微服务架构的 HTTP 网关化改造。

实施步骤:

1. 在服务来源中引入 Nacos 中的 Dubbo 或 gRPC 服务。
2. 在路由配置中，选择目标服务的服务名和方法名。
3. 配置协议转换映射，定义 HTTP 请求参数如何映射到 RPC 方法的入参。
4. 测试连通性，确保 JSON 结构与 Protobuf 或 Java 对象结构匹配。

注意事项: 复杂的嵌套对象转换需要仔细校验 JSON Schema，否则可能导致序列化错误。

实践 5：精细化的流量管理与灰度发布

说明: Higress 继承了 Istio 和 Envoy 的流量管理能力，支持基于 Header、Cookie、权重的高级路由。这允许用户在不修改业务代码的情况下，实现全链路的灰度发布和 A/B 测试。

实施步骤:

1. 准备两个版本的服务实例（如 v1 和 v2）。
2. 创建一条 Ingress 规则，配置多个目标服务（Service）。
3. 为不同的服务设置不同的权重（例如 90% 流量指向 v1，10% 指向 v2）。
4. 或者配置 Header 匹配规则，让特定用户（如内部员工）访问 v2 版本。

注意事项: 灰度发布过程中，应保持 Session 一致性（如基于 Header 的路由），避免用户在版本间频繁切换导致体验异常。

实践 6：高可用部署与性能调优

说明: 基于 Envoy 的 Higress 具备极高的性能吞吐量。在生产环境中，需要合理配置其资源限制与连接池，以应对高并发流量，并确保网关自身的高可用。

实施步骤:

1. 将 Higress 部署为 Kubernetes Deployment，

性能优化建议

性能优化建议

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

说明: Higress 基于 Envoy，天然支持 HTTP/3 协议。在弱网环境或丢包率较高的网络下，HTTP/3 基于 UDP 协议，能够避免 TCP 队头阻塞问题，显著降低连接建立延迟和提升传输吞吐量。

实施方法:

1. 在 Higress 网关监听器配置中，开启 HTTP/3 开关。
2. 配置 UDP 端口（通常复用 443 端口或指定新端口）并在防火墙放行。
3. 确保证书配置支持，HTTP/3 强制要求 TLS 1.3。

预期效果: 在弱网环境下，页面加载速度和API响应延迟可降低 20%-40%，连接建立成功率显著提升。

优化 2：配置全链路超时与熔断策略

说明: 默认的超时配置通常较长，不合理的超时会导致线程池（或连接池）被长时间占用，导致雪崩效应。通过精细化的超时控制和熔断，可以快速失败，释放资源给健康的请求。

实施方法:

1. 连接超时: 建议设置为 3-5 秒，避免长时间握手中。
2. 请求超时: 根据业务 P99.9 耗耗时设置，建议不超过 10 秒。
3. 熔断策略: 配置连续 5xx 错误的熔断阈值（如 50% 错误率），触发熔断后直接返回，不再转发后端。

预期效果: 后端服务故障时，网关自身吞吐量下降幅度控制在 10% 以内（相比无熔断可能导致的完全不可用），平均响应延迟（RT）减少 50ms+。

优化 3：启用 Wasm 插件的热插拔与隔离

说明: Higress 极大的优势在于支持 Wasm 插件。相比于 Lua，Wasm 提供了更好的性能和隔离性。将复杂的鉴权、限流逻辑下沉到 Wasm 插件中，利用其沙箱特性防止业务逻辑崩溃影响网关核心，同时利用 AOT 编译提升执行效率。

实施方法:

1. 将高频调用的认证、签名校验逻辑编写为 Wasm 插件。
2. 在网关路由配置中关联特定 Wasm 插件。
3. 利用 Wasm 的内存隔离特性，限制单个插件的内存和 CPU 使用配额。

预期效果: 相比于将逻辑放在外部服务调用（如 gRPC 鉴权），网络往返延迟减少 5-10ms；相比于传统 Lua 脚本，复杂逻辑处理 CPU 消耗可降低 30%-50%。

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

说明: 频繁的 DNS 查询和 TCP 握手会消耗大量资源。Higress (Envoy) 内置了动态 HTTP 连接池和 DNS 缓存。确保这些配置处于最优状态，可以大幅减少后端服务的负载和网络握手开销。

实施方法:

1. 连接池配置: 根据后端服务能力，适当上调 HTTP/2 或 HTTP/1.1 的连接池大小（例如从默认的 100 调整至 256）。
2. DNS 缓存: 确保开启 DNS 缓存，并将 TTL 设置为合理的值（如 60s），避免每次请求都进行 DNS 解析。
3. Keep-alive: 确保与后端服务开启 Keep-Alive，减少 TIME_WAIT 状态的连接堆积。

预期效果: 后端服务连接数减少 40%-60%，网关 CPU 消耗降低 10%-20%，长连接模式下请求处理延迟降低 2-5ms。

优化 5：实施精细化速率限制

说明: 滥用流量或突发流量会击穿网关。利用 Higress 的内置限流功能（基于 Token Bucket 算法

学习要点

• 基于提供的来源信息（GitHub Trending 上的 Alibaba Higress），以下是关于该项目的关键要点总结：
• Higress 是阿里巴巴开源的一款基于 Istio 的云原生 API 网关，旨在解决云原生时代流量治理与入口管理的复杂性问题。
• 该项目深度集成了 K8s Ingress 与 Gateway API 标准，能够无缝对接 Kubernetes 生态，实现从传统微服务向云原生架构的平滑迁移。
• 它内置了对高并发流量的优化处理能力，继承了阿里巴巴在电商大促场景下的网关稳定性实践，具备企业级的高可用性能。
• Higress 提供了强大的 WAF（Web 应用防火墙）插件市场，支持安全防护、流量镜像、流量染色等丰富的扩展功能。
• 该网关支持将 Nacos、Consul 等注册中心的服务直接透传至 K8s，有效打通了微服务与容器化网络之间的服务发现壁垒。
• 架构设计上实现了数据面与控制面的分离，支持热更新插件配置，可以在不重启服务的情况下动态调整流量管理策略。

学习路径

学习路径

阶段 1：基础概念与环境认知

学习内容:

• 网关基础：理解 API 网关在微服务架构中的定位、核心功能（流量入口、安全、协议转换）。
• 技术背景：了解 Higress 的技术构成（基于 Envoy、Istio），以及它与 Nginx、Kong、APISIX 的区别。
• 核心概念：掌握 Ingress、Gateway、路由、服务、插件等基础术语。
• 部署方式：学习如何在本地 Docker 环境或 Kubernetes 集群中部署 Higress。

学习时间: 1-2周

学习资源:

• Higress 官方 GitHub 仓库 README
• Higress 官方文档 - “快速开始” 章节
• 云原生网关技术对比文章

学习建议: 先跑通官方提供的 Quick Start 示例。如果你不熟悉 Kubernetes，建议先补充 Minikube 或 Kind 的基础知识，因为 Higress 运行在 K8s 环境中。

阶段 2：核心功能与流量治理

学习内容:

• 路由配置：学习域名路由、路径匹配、Header 匹配等流量分发规则。
• 服务来源：掌握如何对接 Nacos、Consul、固定地址（IP/DNS）以及 K8s Service。
• 流量治理：学习全局限流、熔断降级、负载均衡算法的配置。
• 安全防护：配置 Basic Auth、Key Auth 认证，以及 CORS 和 IP 访问控制。
• 控制台使用：使用 Higress 控制台（Console）进行配置与调试。

学习时间: 2-3周

学习资源:

• Higress 官方文档 - “流量治理” 与 “安全” 板块
• Higress 官方示例仓库
• Envoy 基础文档（用于理解底层代理机制）

学习建议: 结合具体场景进行练习。例如，模拟一个后端服务，配置基于 URL 参数的灰度发布，或者配置限流规则，并使用 Postman 或 curl 进行验证。

阶段 3：插件开发与高级扩展

学习内容:

• 插件系统：理解 Higress 的插件模型（Wasm 插件与 Lua 插件）。
• 内置插件：使用官方提供的插件（如 JWT 鉴权、请求/响应重写、Skywalking 等）。
• 自定义插件（Wasm）：学习使用 Go 或 C++ 开发 Wasm 插件，实现自定义的业务逻辑（如签名校验、请求体修改）。
• 插件配置：掌握插件的热加载机制、插件执行顺序以及插件级别的配置传递。

学习时间: 3-4周

学习资源:

• Higress 官方文档 - “插件市场” 与 “自定义开发” 章节
• Higress Plugin Samples (GitHub)
• WebAssembly (Wasm) 基础教程

学习建议: 建议从修改一个现有的简单插件开始，例如修改一个请求头插件，将其编译成 Wasm 并在 Higress 中加载运行。理解 Wasm 的沙箱特性及其与 Envoy 的交互方式。

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

学习内容:

• 可观测性：集成 Prometheus/Grafana 进行监控指标采集，配置日志服务（如 SLS、ELK）对接 Access Log。
• 高可用部署：学习 Higress 的高可用架构，控制面与数据面的分离部署。
• 性能调优：理解连接池配置、缓冲区大小调整、Wasm 插件性能影响分析。
• 网关安全：配置 WAF 防护（对接 ModSecurity），以及 TLS/HTTPS 证书管理。
• 版本升级与迁移：学习 Higress 的版本升级流程，以及从 Nginx/Ingress NGINX 迁移到 Higress 的策略。

学习时间: 2-4周

学习资源:

• Higress 官方文档 - “运维指南” 板块
• Kubernetes 网络与存储最佳实践
• Higress 性能测试报告

学习建议: 关注生产环境的稳定性。尝试进行压测（使用 JMeter 或 Hey），观察 CPU 和内存消耗，并根据监控数据调整 Pod 副本数和资源限制。学习如何排查 502/504 等常见网关错误。

阶段 5：架构精通与源码研读

学习内容:

• 架构原理：深入分析 Higress 的控制面与数据面架构。
• 源码分析：研读 Istio 控制面适配代码与 Envoy 数据面扩展逻辑。
• 源码贡献：参与 GitHub Issue 讨论与代码贡献。

常见问题

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

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

A: Higress 是一个基于阿里内部多年实践沉淀的下一代云原生网关。它建立在 Envoy 和 Istio 等开源项目之上，旨在提供高性能、可扩展且易于管理的 API 网关功能。Higress 由阿里巴巴集团开源，并捐赠给了 CNCF（云原生计算基金会）作为孵化项目。它结合了阿里在电商、金融等高并发场景下的网关经验，支持 Kubernetes Ingress、API 管理以及微服务治理。

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

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

A: Higress 的主要优势在于其云原生架构和深度集成能力。

1. 性能与资源：基于 C++ 编写的 Envoy 内核，具有极高的吞吐量和低延迟，且资源占用相对较低。
2. 标准化：原生支持 Kubernetes Ingress API 和 Gateway API，易于集成 K8s 生态。
3. 安全与防护：内置了针对 WAF（Web 应用防火墙）的插件，能够更好地防范 SQL 注入、XSS 等常见攻击，且集成了阿里云的安全能力。
4. 可观测性：默认集成了 Prometheus、OpenTelemetry 等监控链路追踪标准，提供了更强大的流量观测能力。
5. 插件生态：兼容 Nginx 的 Lua 插件（通过 WASM 支持），同时也支持 Go、Python、Rust 等语言编写插件，扩展性更强。

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

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

A: 是的，Higress 非常注重迁移的便利性。

1. Nginx 兼容：Higress 提供了 Nginx 配置转换工具，可以帮助用户将现有的 Nginx 配置转换为 Higress 的配置。
2. Ingress 兼容：Higress 完全实现了 Kubernetes Ingress 规范，因此可以直接替换标准的 Nginx Ingress Controller，通常只需修改 Ingress Class 即可。
3. 注解支持：为了降低迁移门槛，Higress 兼容了大量常见的 Nginx Ingress Annotations，使得迁移后的配置改动最小化。

4: Higress 如何处理插件扩展？是否支持 WASM？

4: Higress 如何处理插件扩展？是否支持 WASM？

A: 插件扩展是 Higress 的核心特性之一。Higress 原生支持 WebAssembly (WASM) 技术。

1. WASM 支持：通过 WASM，用户可以使用 C++、Go、Rust、AssemblyScript 甚至 JavaScript/TypeScript 编写网关插件。这些插件运行在沙箱环境中，安全性高，且支持热加载，无需重启网关即可更新插件逻辑。
2. Lua 兼容：为了兼容旧有的 Nginx 生态，Higress 也支持 Lua 脚本（通过 WASM 运行时），使得原有的 Lua 脚本可以平滑迁移。
3. 插件市场：Higress 提供了官方插件市场，包含了常见的认证、流量控制、可观测性插件，用户可以一键安装。

5: Higress 的部署方式有哪些？是否支持非 K8s 环境？

5: Higress 的部署方式有哪些？是否支持非 K8s 环境？

A: Higress 最理想的运行环境是 Kubernetes，但也支持其他环境。

1. Kubernetes (推荐)：这是 Higress 的主战场。通过 Helm Chart 或 Operator 可以一键部署在 K8s 集群内，接管 Ingress 流量。
2. Docker/虚拟机：虽然主要面向云原生，但 Higress 也可以通过 Docker 方式在非 K8s 环境中运行，作为传统的 API 网关使用。
3. 混合部署：支持在云上（ACK）和线下（IDC）进行混合云部署，统一管理流量。

6: Higress 是否支持服务网格 流量治理？

6: Higress 是否支持服务网格 流量治理？

A: 是的，Higress 与 Istio 有着紧密的联系。

1. 定位：Higress 可以作为 Istio 的数据平面组件替代品，利用其高性能的 Envoy 内核处理南北向流量（入口流量）。
2. 集成：它可以与 Istio 控制平面集成，实现金丝雀发布、蓝绿部署、流量镜像、全链路灰度发布等复杂的微服务治理功能。
3. 独立使用：即使不部署完整的 Istio，Higress 自身也提供了丰富的 HTTP/gRPC 路由和负载均衡能力，足以应对大多数微服务治理场景。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在本地 Docker 环境中快速部署 Higress，并创建一个简单的路由规则，将访问 /hello 的请求转发到一个模拟的后端服务（如 httpbin.org）。

提示**: 参考 Higress 官方文档的快速开始部分，使用 Docker Compose 进行部署，并了解如何创建一个简单的 Ingress 路由。

实践建议

基于 Higress 作为 AI Native API 网关的定位，结合其云原生架构与 AI 流量管理的特性，以下是 6 条实践建议：

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

场景：需要对大模型（LLM）的请求或响应进行实时修改，例如注入系统提示词、过滤敏感词或重新格式化输出。 建议：不要编写自定义 Sidecar 服务来处理这些逻辑，这会增加延迟。应使用 Higress 的 Wasm (WebAssembly) 插件能力。你可以用 Go 或 C++ 编写插件，将其编译为 .wasm 文件并直接上传到网关。 最佳实践：利用官方的 ai-proxy 插件作为基础，通过修改配置或编写简单的 Wasm 逻辑来实现 Prompt 模板化管理，确保上游模型服务只接收纯净的参数。

2. 配置基于 Token 的流式响应处理

场景：大模型应用通常采用流式传输（SSE）以降低首字生成延迟（TTFT）。 建议：在配置路由或服务时，务必开启对流式响应的支持，并检查网关的超时设置。AI 请求可能长达数十秒甚至数分钟，传统的 HTTP 网关超时配置（如默认 60 秒）会导致连接中断。 常见陷阱：未正确处理 SSE 协议的分帧，导致客户端无法完整接收生成的内容。确保 Higress 的全链路（网关到上游模型、网关到下游客户端）都支持 Chunked Transfer Encoding。

3. 实施模型供应商的抽象与热切换

场景：业务初期使用 OpenAI，后期想切换至通义千问或自研模型，或者需要根据成本在多个模型间做负载均衡。 建议：不要在应用代码中硬编码模型 API 地址。在 Higress 中配置服务来源，将不同的 LLM 提供商注册为不同的服务或服务版本。通过路由规则或 Header 转发，动态决定请求指向哪个模型。 最佳实践：使用 Higress 的“多活”或“灰度发布”功能，根据请求中的特定 Header（如 x-model-provider）将流量按百分比切分到不同的模型服务商，实现平滑迁移和 A/B 测试。

4. 设置针对 AI 流量的并发与速率限制

场景：AI 推理成本高昂，且上游 API 通常有严格的 RPM（每分钟请求数）或 TPM（每分钟 Token 数）限制。 建议：配置细粒度的限流策略。不同于传统 API 的 QPS 限制，AI 网关更关注请求的耗时和并发连接数。 操作：针对特定 API 路径配置基于“请求头 API Key”或“用户 ID”的限流。如果上游服务（如 Azure OpenAI）返回 429 Too Many Requests，确保 Higress 配置了正确的重试策略（指数退避），而不是立即报错给用户。

5. 建立可观测性以追踪 Token 消耗与成本

场景：AI 应用的计费模式基于 Token，传统的 HTTP 日志无法统计实际产生的成本。 建议：开启 Higress 的日志采集，并重点关注响应体中的 usage 字段（通常包含 prompt_tokens, completion_tokens）。 最佳实践：配置 Access Log 将 Token 计数提取出来作为独立的日志字段，或者对接 Prometheus/Grafana。通过监控每个 API Key 或每个用户的 Token 消耗速率，及时发现异常消耗（如恶意循环调用）。

6. 敏感信息脱敏与安全防护

场景：用户可能通过 Prompt 注入攻击试图获取系统指令，或在对话中提交隐私数据。 建议：在网关层部署安全插件。利用 Wasm 插件在请求转发前检查 Prompt 内容，拦截包含恶意指令的请求；在响应返回给用户前，过滤掉模型可能泄露的内部系统提示词。 常见陷阱：直接将客户端的 Key 转发给上游。如果上游是按 Key 计

引用

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

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

站内链接

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

相关文章

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