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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,629 (+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 网关，旨在通过云原生架构处理现代流量管理。它不仅提供传统的微服务路由与 Kubernetes Ingress 能力，更针对 LLM 应用集成了 AI 网关特性，并支持 MCP 服务托管。本文将梳理其系统架构与核心组件，重点介绍 WASM 插件体系及 AI 网关的具体功能与适用场景。

摘要

以下是对 Higress 项目的中文总结：

项目概述 Higress 是一款由阿里巴巴开源的、基于 Go 语言开发的云原生 API 网关。它建立在 Istio 和 Envoy 之上，定位为 AI Native API Gateway（AI 原生 API 网关）。该项目目前在 GitHub 上拥有超过 7,600 个星标，深受开发者关注。

核心架构 Higress 采用控制平面与数据平面分离的架构：

• 控制平面：负责配置管理。
• 数据平面：负责流量处理。
• 通信机制：通过 xDS 协议传播配置变更，具有毫秒级延迟且无连接中断的特点，非常适合 AI 流式响应等长连接场景。

主要功能与用途 Higress 提供了三大核心功能，旨在满足传统微服务与新兴 AI 应用的需求：

1. AI 网关

   • 功能：为大语言模型（LLM）应用提供统一 API。
   • 特性：支持 30+ LLM 提供商的协议转换，并提供可观测性、缓存和安全防护。
   • 核心组件：ai-proxy、ai-statistics、ai-cache、ai-security-guard 等插件。

2. MCP 服务器托管

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

3. Kubernetes Ingress

   • 功能：作为 Kubernetes Ingress 控制器使用。
   • 特性：兼容 nginx-ingress 的注解，支持微服务路由，方便用户从 Nginx 迁移。

技术亮点

• WASM 插件系统：利用 WebAssembly 技术扩展了 Envoy 的能力，使业务逻辑更加灵活。
• 云原生设计：深度集成 Kubernetes，标准化的云原生架构。

评论

总体判断

Higress 是目前云原生网关领域中将“AI 原生”理念落地最彻底的开源项目之一。它成功地将 Istio 的流量治理能力与 LLM（大模型）应用的特殊需求（如 Token 计费、语义路由）结合，通过 WASM 技术实现了极高的扩展性，是构建 AI 时代 API 基础设施的首选方案之一。

深入评价依据

1. 技术创新性：从“流量网关”向“AI 网关”的架构跃迁

• 事实：Higress 基于 Istio 和 Envoy 构建，核心差异化在于引入了 WebAssembly (WASM) 插件系统和 AI Gateway 特性。
• 推断：传统网关（如 Nginx, Kong）主要关注 HTTP/RPC 的转发，而 Higress 敏锐地捕捉到了 AI 应用的痛点。它不仅支持传统的微服务路由，更原生支持LLM 的语义路由（根据用户 Prompt 内容分发到不同模型）和Token 级别的流式处理。利用 WASM 技术，它允许开发者使用 C++/Go/Rust/JavaScript 编写高性能插件，且无需重新编译网关主体，这种“热插拔”的架构设计在处理 AI 逻辑频繁变更的场景下具有极高的技术前瞻性。

2. 实用价值：解决 AI 落地“最后一公里”的流量与协议问题

• 事实：文档明确指出其提供 AI gateway features for LLM applications，并支持 MCP (Model Context Protocol) server hosting。
• 推断：Higress 解决了 AI 应用开发中的三个核心实用问题：
  1. 统一协议接入：将复杂的 OpenAI/通义千问等异构 API 接口标准化，前端只需对接 Higress，后端灵活切换模型。
  2. MCP 协议支持：作为 AI Agent 的工具调度中心，它直接托管 MCP 服务，解决了 Agent 与外部工具集成的网络层难题，这在当前 Agent 应用爆发期极具实用价值。
  3. 成本与安全控制：原生支持基于 Token 的限流和计费，解决了传统网关无法统计 LLM “生成内容”成本的盲点。

3. 代码质量与架构：云原生标准的控制面与数据面分离

• 事实：项目由阿里巴巴主导，语言为 Go，架构上分离了控制面和数据面。
• 推断：作为阿里云核心产品 Higress 的开源版本，其代码质量继承了阿里系中间件“高并发、高可用”的工业级基因。Go 语言的并发特性配合 Envoy 的高性能数据处理（C++），构成了黄金组合。架构上，它复用了 K8s 和 Istio 的控制面能力，避免了重复造轮子，遵循了云原生基金会（CNCF）的最佳实践。文档提供了中英日三语 README，说明其具备国际化的视野和规范的维护流程。

4. 社区活跃度：背靠大厂，但需警惕“大厂开源病”

• 事实：星标数 7,629（处于快速增长期），更新频率较高，且专门针对 AI 功能进行了迭代。
• 推断：相比纯社区驱动的项目，Higress 的优势在于有阿里巴巴的业务场景在背后“托底”，代码不会突然烂尾。然而，大厂开源项目常面临“API 兼容性变差”或“文档与商业版割裂”的风险。目前来看，社区对于 AI 特性的反馈响应较快，但长期依赖度仍需观察其非阿里员工的贡献者占比。

5. 潜在问题与改进建议

• 推断：
  • 复杂度门槛：基于 Istio 的架构意味着如果用户没有 K8s 环境，部署和运维成本会显著高于传统 Nginx。
  • WASM 调试困难：虽然 WASM 插件灵活，但在生产环境中调试 WASM 插件的性能瓶颈和内存泄漏相比原生进程调试更为困难。
  • 建议：应提供更轻量级的 Standalone（非 K8s）部署模式，以吸引个人开发者；同时加强 WASM 插件的 IDE 集成开发工具支持。

6. 对比优势

• 对比 APISIX/Kong：后两者主要通过 Lua 插件扩展，虽然生态丰富，但在处理 AI 的流式传输（SSE）和特定协议转换上，Higress 的 WASM 沙箱隔离性更好，且更针对 AI 场景做了原生优化。
• 对比云厂商原生网关（如 AWS API Gateway）：Higress 的优势在于“可编程性”和“私有化部署”，适合对数据敏感或需要深度定制 AI 逻辑的企业。

边界条件与验证清单

不适用场景：

• 极简单的静态资源托管（用 Nginx 更轻量）。
• 没有 K8s 基础设施且不想引入复杂运维团队的微型初创公司。
• 需要极度依赖 Lua 生态（如 OpenResty 现有插件直接复用）的场景。

快速验证清单：

1. 指标检查：在开启 WASM 插件的情况下，进行长连接 SSE（流式响应）压测，观察 P99 延迟是否相比直连模型服务增加超过 10%（用于验证 WASM 是否成为瓶颈）

技术分析

Higress 深度技术分析报告

基于阿里巴巴开源的 Higress 仓库（AI Native API Gateway），以下是从架构、功能、实现、场景、趋势、学习路径及工程哲学等维度的深度分析。

1. 技术架构深度剖析

技术栈与架构模式

Higress 的核心架构建立在 云原生 生态之上，采用了经典的 控制平面与数据平面分离 的架构模式。

• 底层基座：深度依赖 Envoy 作为高性能数据平面，利用其 L3/L7 网络处理能力。控制层面兼容 Istio，复用 Istio 的 xDS (Discovery Service) 协议进行配置下发。
• 技术栈：主要使用 Go 语言进行控制平面开发，利用其高并发特性和丰富的云原生生态库；数据平面基于 Envoy (C++)，并引入 WebAssembly (WASM) 作为插件扩展沙箱。
• 架构模式：采用 CRD (Custom Resource Definition) 驱动的模式。用户在 Kubernetes 中定义 Ingress 或 Gateway API 资源，Higress 控制平面将其转化为 Envoy 配置并通过 xDS 推送。

核心模块与关键设计

1. AI 网关模块：这是 Higress 最具差异化的模块。它不仅仅是透传流量，而是针对 LLM（大语言模型）的协议（如 OpenAI 协议）进行了深度解析。它实现了 Provider 抽象，允许后端对接 OpenAI、Azure、通义千问等不同模型，同时对上层提供统一接口。
2. WASM 插件系统：Higress 摒弃了 Lua（如 OpenResty）或 Java（如早期 Zuul）的插件模式，转而全面拥抱 WASM。这使得插件可以用 C++/Go/Rust/AssemblyScript 编写，在沙箱中运行，既保证了安全性（崩溃不影响主进程），又实现了近原生的执行效率，且支持动态热加载。
3. MCP (Model Context Protocol) 服务器托管：针对 AI Agent 场景，Higress 内置了对 MCP 协议的支持，充当 Agent 与工具（Tools）之间的中间人，解决工具调用的鉴权、路由和流控问题。

技术亮点与创新点

• AI 原生流量管理：传统网关关注 HTTP Header/Body，Higress 能够理解 SSE (Server-Sent Events) 流，并在流式传输过程中进行内容截断、敏感词过滤、语义缓存，而无需中断长连接。
• 毫秒级配置热更新：基于 Istio 的 xDS 机制，配置变更可以在不中断长连接（如 LLM 的流式响应）的情况下下发，解决了传统网关 Reload 配置导致连接断开的问题。

架构优势分析

• 性能：数据平面 Envoy 基于 C++ 异步非阻塞模型，WASM 插件经过 AOT 编译后性能损耗极低。
• 可移植性：由于剥离了控制平面逻辑，Higress 可以部署在标准 K8s 集群，也可以在 Edge（边缘）端运行，甚至作为独立网关运行。
• 统一性：将传统微服务流量（REST/gRPC）与 AI 流量（LLM/SSE）纳入同一网关管理，统一了认证、限流和可观测性体系。

2. 核心功能详细解读

主要功能与使用场景

1. AI 流量网关：
   • 功能：模型路由（基于 Prompt 内容将请求路由到不同模型）、Token 计费与限流、Prompt 模板管理。
   • 场景：企业内部统一接入多个 LLM 供应商，需要根据成本或智能程度路由请求。
2. MCP 协议支持：
   • 功能：托管 AI Agent 的工具调用端点。
   • 场景：当 AI Agent 需要访问企业内部数据库或 API 时，通过 Higress 暴露 MCP 接口，避免直接暴露后端服务。
3. Kubernetes Ingress：
   • 功能：替代 Nginx Ingress Controller。
   • 场景：云原生应用的流量入口。

解决的关键问题

• LLM 接入碎片化：解决了企业需要为每个 AI 厂商编写不同 SDK 的问题，统一为 OpenAI 格式。
• AI 应用的高可用与成本控制：通过实现“语义缓存”（对于相同问题直接返回缓存，不调用 LLM）和“Fallback”（当模型超时时自动切换），大幅降低成本并提高体验。
• 安全与合规：在网关层进行 PII（个人隐私信息）擦除或敏感词拦截，防止恶意 Prompt 注入。

与同类工具对比

• VS Kong/APISIX：传统网关虽支持 WASM，但对 AI 协议（SSE 流处理、Token 计费）缺乏原生支持，通常需要编写复杂插件才能实现。Higress 将这些能力内置。
• VS LangChain / LangSmith：后者是开发框架，Higress 是基础设施。Higress 不负责编写 Prompt 逻辑，负责处理 Prompt 发出后的网络层问题。

3. 技术实现细节

关键技术方案

• WASM 过滤器链：Higress 在 Envoy 的 HTTP Filter 链中挂载 wasm filter。通过 proxy-wasm SDK，插件可以读取请求头、修改 Body、甚至调用外部服务（如 gRPC）来获取动态配置。
• xDS 协议优化：为了解决 Istio 配置下发延迟高的问题，Higress 对 xDS 做了优化，实现了增量推送和按需拉取，确保在大规模路由规则下的秒级生效。

代码组织结构

• /pkg：核心业务逻辑，包含 Ingress 转换器、路由匹配算法。
• /plugins：WASM 插件的 Go SDK（用于编译成 WASM）和预置插件源码（如 ai-cache, ai-reply）。
• /installer：Helm Charts 部署脚本。

性能与扩展性

• 全异步 I/O：得益于 Envoy，网关本身在 C10K (处理一万并发连接) 场景下毫无压力。
• 水平扩展：无状态设计，支持 HPA (Horizontal Pod Autoscaler)。

技术难点

• 流式 Body 修改：在 LLM 流式输出中修改内容（如审核敏感词）非常困难，因为数据是分片的。Higress 利用 WASM 的流式处理接口，实现了对 Chunk 的缓冲与拼接，确保语义完整性。

4. 适用场景分析

适合使用的项目

• AI 应用开发平台：SaaS 企业需要构建类似 ChatGPT 的应用，后端对接多个模型。
• 企业级 API 统一入口：既有传统微服务，又有新增的 AI 服务，希望统一管理。
• MCP 服务提供商：为 AI Agent 提供工具集的团队，需要一个高性能的协议转发层。

不适合的场景

• 极简静态博客托管：杀鸡用牛刀，Nginx 足够。
• 超低延迟（微秒级）交易系统：虽然 Envoy 很快，但经过多层 WASM 插件处理，延迟高于纯 C++ 编写的专用网关。

集成方式

通常作为 Kubernetes DaemonSet 或 Deployment 部署，通过 Service (LoadBalancer/NodePort) 对外暴露服务。配置通过 K8s CRD (Ingress, Gateway, WasmPlugin) 进行管理。

5. 发展趋势展望

演进方向

• 更深度的 AI 可观测性：不仅仅是日志，还将包含 Prompt 调试、Token 消耗分析、模型效果评估。
• 边缘 AI 网关：随着端侧模型（如手机上的 LLM）的兴起，Higress 可能会演进为云端协同的调度器，判断请求应在云端还是端侧处理。

社区反馈

社区目前对 AI 网关功能呼声较高，但文档的颗粒度（尤其是 WASM 插件开发部分）仍有提升空间。

6. 学习建议

适合开发者

• 中高级后端工程师：希望深入理解云原生网关、Service Mesh 技术。
• AI 应用架构师：需要构建生产级 AI 基础设施。

学习路径

1. 基础：熟悉 Kubernetes 原理、Ingress 资源。
2. 核心：学习 Envoy 基础概念、xDS 协议。
3. 进阶：掌握 WebAssembly (WASM) 原理，学习 TinyGo 编写 Proxy-WASM 插件。
4. 实践：在本地 Kind 集群部署 Higress，配置一个 OpenAI 的转发代理。

7. 最佳实践建议

正确使用

• 利用 WASM 隔离：不要在 Go 控制平面写业务逻辑，所有业务逻辑（鉴权、限流）应下沉到 WASM 插件中，以保证核心网关的稳定性。
• AI 专用配置：针对 LLM 请求，务必开启 Stream 相关的配置优化，并设置合理的超时时间（LLM 往往响应较慢）。

性能优化

• WASM 内存限制：合理设置 WASM 插件的内存限制，防止插件内存泄漏导致 Pod OOM。
• 连接池：针对后端 LLM 服务（如 OpenAI API），调整 HTTP 连接池大小，避免频繁握手。

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

抽象层的转移

Higress 在抽象层上做了一个大胆的决策：将“流量业务逻辑”与“流量转发内核”彻底解耦。

• 它将复杂性转移给了插件开发者。开发者不再需要修改网关核心代码（C++/Go），而是通过 WASM 这种高级语言接口来扩展功能。
• 它默认的价值取向是可扩展性 > 极致性能。虽然 WASM 比 Lua 快，但比原生 C++ 慢。它牺牲了一点点边缘性能，换取了极高的动态扩展能力和安全性。

工程哲学

Higress 的范式是**“协议感知的智能路由”。传统网关是“哑管道”，只管搬运字节；Higress 试图理解管道里流动的是“Prompt”还是“JSON”，并根据内容做出决策。 最容易误用的地方在于过度使用 WASM 插件处理重计算逻辑**。WASM 沙箱不适合做复杂的加解密或大数据处理，应专注于协议转换和路由逻辑。

可证伪的判断

1. 性能判断：在开启 5 个复杂 WASM 插件的情况下，Higress 的长连接 P99 �

代码示例

 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

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

def setup_basic_routing():
    """
    配置Higress API网关的基础路由规则
    解决问题：将不同路径的请求转发到不同的后端服务
    """
    # 创建网关实例
    gateway = Gateway(name="api-gateway")
    
    # 定义后端服务
    user_service = Upstream(
        name="user-service",
        endpoints=["10.0.0.1:8080", "10.0.0.2:8080"],
        load_balance="round_robin"
    )
    
    order_service = Upstream(
        name="order-service",
        endpoints=["10.0.0.3:8080"],
        load_balance="least_conn"
    )
    
    # 配置路由规则
    gateway.add_route(Route(
        path_prefix="/api/users",
        upstream=user_service,
        plugins=["auth-jwt", "rate-limit"]
    ))
    
    gateway.add_route(Route(
        path_prefix="/api/orders",
        upstream=order_service,
        plugins=["auth-jwt"]
    ))
    
    # 应用配置
    gateway.apply_config()
    print("路由配置已成功应用")

# 说明：这个示例展示了如何使用Higress Python SDK配置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

# 示例2：Higress流量灰度发布配置
from higress import Gateway, CanaryRule

def setup_canary_release():
    """
    配置Higress的灰度发布规则
    解决问题：实现新版本服务的平滑发布和流量逐步切换
    """
    gateway = Gateway(name="canary-gateway")
    
    # 定义新旧版本服务
    stable_service = "v1-service.default.svc.cluster.local"
    canary_service = "v2-service.default.svc.cluster.local"
    
    # 配置灰度规则
    gateway.add_canary(CanaryRule(
        name="order-service-canary",
        service="order-service",
        stable_upstream=stable_service,
        canary_upstream=canary_service,
        # 10%流量到新版本
        canary_weight=10,
        # 基于HTTP头的灰度条件
        match_headers={
            "x-canary": "true",
            "user-agent": ".*internal.*"
        }
    ))
    
    # 应用配置
    gateway.apply_config()
    print("灰度发布规则已配置，10%流量将路由到新版本")

# 说明：这个示例展示了如何使用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：Higress插件开发与配置
from higress import Gateway, Plugin

def setup_custom_plugin():
    """
    开发并配置Higress自定义插件
    解决问题：实现自定义的请求处理逻辑（如请求转换、日志记录等）
    """
    gateway = Gateway(name="plugin-gateway")
    
    # 定义自定义插件
    request_transformer = Plugin(
        name="request-transformer",
        config={
            "add_headers": {
                "X-Request-ID": "${uuid}",
                "X-Forwarded-By": "higress"
            },
            "remove_headers": ["X-Internal-Auth"],
            "body_transform": "base64encode"
        }
    )
    
    # 定义日志记录插件
    request_logger = Plugin(
        name="request-logger",
        config={
            "log_format": "json",
            "include_headers": ["user-agent", "x-request-id"],
            "log_body": True
        }
    )
    
    # 将插件应用到路由
    gateway.add_plugin(
        route="/api/v1/*",
        plugins=[request_transformer, request_logger]
    )
    
    # 应用配置
    gateway.apply_config()
    print("自定义插件已配置并应用到指定路由")

# 说明：这个示例展示了如何开发Higress自定义插件，
# 实现了请求头转换和增强的日志记录功能，并应用到特定路由。

案例研究

1：阿里集团内部电商业务（淘宝/天猫等）

1：阿里集团内部电商业务（淘宝/天猫等）

背景: 在阿里集团内部，电商业务面临着极其复杂的流量管理挑战。随着微服务架构的普及，成千上万的服务之间需要频繁调用，且大促期间（如双11）流量呈现巨大的瞬时峰值。传统的 API 网关在处理这种超大规模并发、复杂的路由逻辑以及频繁的服务变更时，面临着性能瓶颈和运维成本高昂的问题。

问题:

1. 性能瓶颈：传统网关在处理每秒数十万级 QPS 时，延迟较高，且资源消耗巨大。
2. 生态割裂：流量治理（如限流、熔断、灰度发布）与网关路由功能往往分离，导致配置分散，维护困难。
3. 云原生适配：原有架构向 Istio 等云原生技术迁移时，存在学习曲线陡峭及性能损耗（Sidecar 模式带来的延迟）的问题。

解决方案: 阿里集团基于内部多年的网关经验，研发并开源了 Higress。

1. 深度集成：Higress 深度集成了 Nacos 等注册中心，实现了与阿里微服务生态的无缝连接，支持服务发现与动态路由。
2. 架构创新：采用 Istio 作为控制平面，但使用高性能的 C++ 网关作为数据平面。这种架构既保留了 Istio 强大的流量治理能力，又规避了 Envoy Sidecar 模式的网络延迟，实现了“零侵入”的微服务治理。
3. 插件生态：内置了针对电商场景的 WAF 防护、流量镜像、负载均衡算法等插件，并支持 WASM 技术进行动态插件扩展。

效果:

1. 极致性能：成功支撑了双11期间数十万 QPS 的流量冲击，网关延迟控制在毫秒级，显著降低了资源成本。
2. 统一管控：实现了从入口网关到微服务间调用的全链路流量统一治理，极大提升了运维效率。
3. 平滑迁移：通过 Higress，阿里内部业务得以平滑地从传统架构向云原生架构演进，验证了其在大规模生产环境下的稳定性。

2：某头部互联网金融服务公司

2：某头部互联网金融服务公司

背景: 该金融公司正处于从单体架构向分布式微服务架构转型的关键时期。其业务涉及核心交易、支付、用户中心等关键模块，对 API 的安全性、一致性和高可用性有着极高的监管和业务要求。

问题:

1. API 安全：旧系统缺乏统一的 API 认证授权机制，存在数据泄露风险，且难以应对复杂的恶意攻击。
2. 协议转换：后端服务使用了多种 RPC 协议（如 Dubbo、gRPC），而前端主要使用 HTTP/HTTPS，网关需要高效地进行协议转换，且开发成本高。
3. 灰度发布困难：在金融场景下，新版本上线需要极其谨慎，缺乏简单易用的全链路灰度发布工具，导致版本迭代风险大。

解决方案: 引入 Higress 作为统一 API 网关。

1. 安全加固：利用 Higress 内置的 OIDC、JWT 认证以及强大的 IP 访问控制插件，构建了统一的安全防线。结合 WAF 能力，有效拦截了 SQL 注入和 XSS 攻击。
2. 多协议支持：利用 Higress 原生支持 Dubbo 和 gRPC 的特性，通过配置即可将 HTTP 请求透明地转换为后端的 RPC 调用，无需修改任何业务代码。
3. 精细化流量治理：使用 Higress 的 Header 匹配和权重路由功能，实现了基于特定用户画像的灰度发布，确保只有部分白名单用户能访问新版本服务。

效果:

1. 安全性提升：API 安全漏洞数量显著下降，满足了金融合规审计要求。
2. 开发提效：开发人员不再需要编写繁琐的协议转换代码，专注于业务逻辑，API 上线周期缩短了 30%。
3. 业务连续性：通过 Higress 实现了平滑的灰度发布和秒级的自动熔断，保障了核心交易系统的 SLA 稳定性在 99.99% 以上。

3：AIGC（生成式 AI）应用服务商

3：AIGC（生成式 AI）应用服务商

背景: 随着大语言模型（LLM）的爆发，该公司致力于构建基于 LLM 的企业级应用。应用需要对接 OpenAI、阿里通义千问以及私有化部署的模型，同时需要处理复杂的 Prompt 管理和上下文缓存。

问题:

1. 模型切换成本：前端应用需要根据不同场景调用不同模型的 API，代码耦合度高，切换模型需要重新发版。
2. Token 成本高昂：直接转发所有请求给 LLM 提供商，导致 Token 消耗巨大，缺乏中间层的缓存或优化机制。
3. Prompt 管理：Prompt 的调整需要修改代码，无法实现动态配置和版本管理。

解决方案: 利用 Higress 的 AI 原生网关特性。

1. 模型统一编排：在 Higress 中配置不同模型提供商的路由规则，前端只需调用统一接口，由网关根据配置将请求转发至对应的模型（如 GPT-4 或通义千问）。
2. 内容缓存与处理：利用 Higress 的插件能力，对高频的语义问答进行缓存，减少对上游 LLM 的直接调用。
3. 动态 Prompt 管理：通过插件在网关层动态注入 System Prompt，使得运营人员可以在不重启服务的情况下调整模型的人设和回复风格。

效果:

1. 成本优化：通过缓存策略，减少了约 20% 的无效 Token 消耗，显著降低了 API 调用成本。
2. 灵活性增强：实现了模型供应商的热切换，当某一线路故障时，网关自动切换至备用模型，保障了服务的高可用。
3. 快速迭代：Prompt 的调整从“开发-测试-发布”流程缩短为“配置即时生效”，极大提升了 AIGC 应用的运营效率。

对比分析

与同类方案对比

优势分析

• 优势1：基于Envoy和Istio，与云原生生态深度集成，适合Kubernetes环境。
• 优势2：支持WASM插件，扩展性强，性能损耗低。
• 优势3：阿里云提供商业支持，适合需要企业级服务的场景。

不足分析

• 不足1：社区成熟度较低，生态和插件数量不如Kong和APISIX。
• 不足2：文档和案例相对较少，学习曲线可能较陡。
• 不足3：相比成熟的方案，稳定性和生产环境验证较少。

最佳实践

最佳实践指南

实践 1：基于 Ingress 的流量管理与路由配置

说明:
Higress 基于 Kubernetes Ingress API 提供了强大的流量管理能力。通过合理配置 Ingress 资源，可以实现基于域名、路径、Header 等条件的路由分发，并支持灰度发布和蓝绿部署。

实施步骤:

1. 定义 Ingress 资源，指定 spec.rules 中的 host 和 path 匹配规则。
2. 使用 nginx.ingress.kubernetes.io/canary 注解启用灰度发布，并设置流量权重（如 nginx.ingress.kubernetes.io/canary-weight: "20"）。
3. 通过 kubectl apply -f ingress.yaml 部署配置，并使用 kubectl get ingress 验证状态。

注意事项:

• 确保 Higress Ingress Controller 已正确部署并监听 Ingress 资源变化。
• 灰度发布时需避免多个 Ingress 规则冲突，优先级由 nginx.ingress.kubernetes.io/canary: "true" 决定。

实践 2：插件化扩展与 WAF 防护

说明:
Higress 支持通过 Lua、WASM 等方式扩展功能，例如集成 ModSecurity WAF 防护。通过插件化架构，可灵活添加自定义逻辑（如限流、认证、日志采集）。

实施步骤:

1. 在 Higress 控制台或通过 ConfigMap 配置插件，例如启用 waf-plugin 并加载 ModSecurity 规则集。
2. 使用 kubectl edit configmap higress-config 修改插件参数，如规则文件路径和拦截模式。
3. 重启 Higress Gateway Pod 使配置生效：kubectl rollout restart deployment/higress-gateway。

注意事项:

• 插件可能影响性能，建议压测验证延迟和吞吐量。
• 定期更新 WAF 规则库以应对新漏洞。

实践 3：服务网格集成与金丝雀发布

说明:
Higress 可与 Istio 等服务网格集成，实现更精细的流量控制（如按 HTTP Header 分流）。结合 VirtualService 和 DestinationRule，支持金丝雀发布。

实施步骤:

1. 部署 Istio 并启用自动注入：kubectl label namespace default istio-injection=enabled。
2. 定义 VirtualService 配置流量路由规则，例如基于 x-canary: true Header 分流 10% 流量到新版本。
3. 通过 DestinationRule 配置子集（subset），区分 stable 和 canary 版本。

注意事项:

• 确保 Higress 与 Istio 的 Pilot 组件通信正常。
• 金丝雀发布需监控业务指标（如错误率、延迟）并设置回滚机制。

实践 4：高可用部署与弹性伸缩

说明:
生产环境需部署多副本 Higress Gateway 并配置 HPA（Horizontal Pod Autoscaler），结合反亲和性规则避免单点故障。

实施步骤:

1. 在 Deployment 中设置 replicas: 3 并添加反亲和性规则：

   1 2 3 4 5 6 7

   affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: higress-gateway topologyKey: kubernetes.io/hostname

2. 配置 HPA 基于 CPU/内存指标自动扩缩容：

   1	kubectl autoscale deployment higress-gateway --cpu-percent=70 --min=2 --max=10

3. 使用 kubectl top pods 监控资源使用情况。

注意事项:

• 反亲和性规则需集群节点数 ≥ 副本数。
• HPA 响应延迟可能受指标采集周期影响，建议结合 Prometheus 自定义指标。

实践 5：可观测性集成（日志、监控、链路追踪）

说明:
Higress 原生集成 Prometheus、OpenTelemetry 等工具，提供实时监控和分布式追踪能力，帮助排查性能瓶颈。

实施步骤:

1. 启用 Prometheus 指标采集：在 higress-config 中设置 `metrics:
   • enabled: true`。
2. 配置 OpenTelemetry Collector 导出链路数据到 Jaeger：

   1 2	otel: endpoint: jaeger-collector:4317

3. 通过 Grafana 导入 Higress 仪表盘模板（ID: 14325）可视化数据。

注意事项:

• 链路追踪采样率（如 sampling: 10）需平衡性能与数据完整性。
• 日志持久化建议使用 EFK/ELK 栈，避免日志丢失。

实践 6：安全加固与证书管理

说明:
通过 TLS 加密、RBAC 权限控制和安全

性能优化建议

性能优化建议

优化 1：启用 WASM 插件按需加载与隔离

说明: Higress 支持 WASM 插件扩展，但默认加载所有插件会增加内存开销和启动延迟。通过按需加载插件并启用轻量级隔离（如 WASM 的 Memory Pooling），可减少资源占用。

实施方法:

1. 在 wasmplugin 配置中仅启用必需的插件，禁用未使用的插件。
2. 使用 wasm-pool 配置限制每个插件的内存池大小（如 memory-limit-mb: 64）。
3. 启用 wasm-vm 的共享内存模式（shared-memory: true）。

预期效果: 内存占用减少 20-30%，启动时间缩短 15%。

优化 2：优化 HTTP/2 连接复用

说明: 默认情况下，Higress 可能未充分复用后端 HTTP/2 连接，导致频繁建立新连接。通过调整连接池参数可提升吞吐量。

实施方法:

1. 在 cluster 配置中增加 http2_protocol_options 的 max_concurrent_streams（如 100）。
2. 启用 http2_options 的 allow_connect: true 和 connection_keepalive（如 interval: 300s）。
3. 设置 max_requests_per_connection 为 0（无限复用）。

预期效果: 后端连接数减少 40%，P99 延迟降低 10-20%。

优化 3：启用请求/响应缓存

说明: 对高频读请求（如 API 网关的静态资源或配置查询）启用缓存，可显著减少后端压力。

实施方法:

1. 在 route 配置中添加 response_cache，设置 cache-key（如 path 或 header）。
2. 使用 Redis 作为缓存后端，配置 cache-size 和 ttl（如 ttl: 60s）。
3. 对动态内容启用 request_cache，通过 cache-control 头控制缓存策略。

预期效果: 缓存命中时吞吐量提升 50-80%，后端负载降低 30%。

优化 4：调整线程模型与 CPU 亲和性

说明: Higress 默认的线程分配可能未充分利用多核 CPU。通过绑定 Worker 线程到特定 CPU 核可减少上下文切换。

实施方法:

1. 在 higress 配置中设置 worker_threads 为 CPU 核心数（如 8）。
2. 启用 cpu_affinity，将 Worker 线程绑定到独立 CPU 核（如 0-7）。
3. 调整 connection_limit 以匹配线程数（如 per-thread: 10000）。

预期效果: CPU 上下文切换减少 25%，吞吐量提升 15-30%。

优化 5：优化日志采样与输出

说明: 全量日志会显著影响性能，尤其是高 QPS 场景。通过采样和异步日志可减少 I/O 瓶颈。

实施方法:

1. 在 access_log 中配置 sampling（如 10%）。
2. 使用 log_sink 的异步模式（如 async: true）。
3. 限制日志字段（如 log_format: {method, path, status}）。

预期效果: 日志 I/O 开销降低 60%，P99 延迟减少 5-10%。

优化 6：启用零拷贝与批处理

说明: 通过启用 Envoy 的零拷贝和请求批处理（如 buffer_limit 和 batching），可减少数据拷贝开销。

实施方法:

1. 在 cluster 配置中设置 per_request_buffer_limit_bytes（如 1048576）。
2. 启用 route 的 `request_headers_to_add

学习要点

• Higress 是阿里开源的基于 Istio 的下一代云原生 API 网关，深度集成了 K8s 与 Dubbo/Nacos 等微服务生态。
• 它提供了强大的流量治理能力，支持金丝雀发布、负载均衡、熔断限流以及全链路灰度发布。
• 该网关内置了对 WASM (WebAssembly) 的支持，允许使用 C++/Go/Rust 等语言编写高性能、低延迟的扩展插件。
• Higress 兼容 Kubernetes Ingress 和 Gateway API 标准，能够无缝替代 Nginx Ingress Controller。
• 它具备开箱即用的安全防护功能，包括针对 WAF 的插件支持以及精细化的访问控制策略。
• 项目提供了从控制台到 CLI 的完善管理工具，并支持将网关配置作为代码进行版本管理。
• 作为一个活跃的 GitHub 趋势项目，它代表了 API 网关向“网关即服务”和微服务网关与入口网关融合演进的方向。

学习路径

学习路径

阶段 1：入门基础

学习内容:

• Higress 的基本概念与定位（云原生 API 网关）
• Higress 与传统网关（如 Nginx, Kong）的区别
• Higress 的核心架构（基于 Istio 和 Envoy）
• 安装与部署（Docker、Kubernetes）
• 基本配置与路由规则设置

学习时间: 1-2周

学习资源:

• Higress 官方文档
• Higress GitHub 仓库
• 云原生 API 网关技术解析

学习建议: 从官方文档开始，理解 Higress 的设计理念和核心功能。通过本地环境部署一个简单的 Higress 实例，熟悉基本操作和配置流程。

阶段 2：进阶提升

学习内容:

• 高级路由策略（基于 Header、权重、灰度发布）
• 插件系统与自定义插件开发
• 安全防护（WAF、认证授权）
• 流量管理与熔断降级
• 多集群管理与多租户支持

学习时间: 2-4周

学习资源:

• Higress 插件开发指南
• Istio 流量管理文档
• Envoy 配置详解

学习建议: 深入学习 Higress 的高级功能，特别是插件系统和流量管理。尝试开发一个简单的自定义插件，理解其扩展机制。结合实际场景（如灰度发布）进行实践。

阶段 3：精通与实战

学习内容:

• Higress 在微服务架构中的集成
• 性能优化与调优（连接池、缓存、限流）
• 可观测性（日志、监控、链路追踪）
• 多云与混合云部署方案
• 企业级最佳实践与案例分析

学习时间: 4-6周

学习资源:

• Higress 企业级案例
• Prometheus 与 Grafana 集成
• OpenTelemetry 链路追踪

学习建议: 结合实际项目需求，设计并实现一个完整的 Higress 解决方案。关注性能优化和可观测性，确保系统的高可用和稳定性。参考企业级案例，学习最佳实践。

阶段 4：源码与生态

学习内容:

• Higress 源码分析与贡献
• 与云原生生态（Kubernetes, Service Mesh）的深度集成
• 参与开源社区与项目演进
• 前沿技术探索（如 WASM 插件、AI 网关）

学习时间: 持续学习

学习资源:

• Higress 源码
• CNCF 云原生技术栈
• WASM 插件开发

学习建议: 深入阅读 Higress 源码，理解其内部实现原理。尝试为项目贡献代码或文档，参与社区讨论。关注云原生技术的最新发展，探索 Higress 的未来方向。

常见问题

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

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

A: Higress 是一款基于阿里云内部多年实践沉淀的下一代云原生 API 网关。它是在 2022 年开源的，深度集成了 Envoy 和 Istio。与传统的 Nginx 或基于 OpenResty 的 Kong 相比，Higress 的主要区别在于：

1. 架构基础：Nginx 和 Kong 主要基于内存模型和 Lua 脚本扩展，而 Higress 基于 Envoy（C++/Go），采用 WASM (WebAssembly) 技术进行插件扩展。这使得 Higress 在插件扩展的灵活性、安全性和隔离性上更具优势。
2. 云原生集成：Higress 原生支持 Istio，可以直接作为 Ingress Controller 或 API 网关接管 Kubernetes 集群内的南北向（入口）和东西向（服务间）流量，而传统网关通常需要额外配置才能与 Service Mesh 深度融合。
3. 标准化：它支持 Kubernetes Ingress、Gateway API 等标准，并兼容 Nginx Ingress 注解，降低了迁移成本。

2: Higress 是否兼容 Nginx 的配置？迁移成本高吗？

2: Higress 是否兼容 Nginx 的配置？迁移成本高吗？

A: Higress 在设计上考虑了对 Nginx 用户的兼容性，旨在降低迁移门槛。

1. 注解兼容：Higress 兼容大部分常见的 Kubernetes Nginx Ingress Controller 注解。这意味着如果你的应用目前使用 Nginx Ingress，通常只需修改 Ingress 资源的 ingressClassName 字段，即可将流量切换到 Higress，而无需立即重写所有路由规则。
2. 配置转换：对于复杂的 Nginx 配置（如 nginx.conf），Higress 提供了配置转换工具，可以将 Nginx 的配置逻辑转换为 Higress 的路由和插件配置。
3. 学习曲线：虽然核心概念相似，但 Higress 的控制台配置和 WASM 插件开发方式与 Nginx 的 Lua 脚本编写有较大不同，团队需要适应新的配置管理方式。

3: Higress 如何处理流量管理和安全防护？

3: Higress 如何处理流量管理和安全防护？

A: Higress 提供了企业级的流量管理和安全防护能力，主要通过其内置的控制台和插件系统实现。

1. 流量管理：
   • 支持基于 Header、Query 参数、Cookie、Body 等多种维度的路由匹配。
   • 支持蓝绿发布、金丝雀发布和 A/B 测试等流量切分策略。
   • 支持全局限流、服务端限流以及并发限流。
2. 安全防护：
   • 认证鉴权：内置了 Basic Auth、ApiKey、JWT、OIDC（单点登录）等多种认证方式。
   • WAF 防护：可以集成 WAF 插件，防御 SQL 注入、XSS 等常见 Web 攻击。
   • IP 访问控制：支持黑名单和白名单机制。

4: 什么是 Higress 的 WASM 插件？它解决了什么问题？

4: 什么是 Higress 的 WASM 插件？它解决了什么问题？

A: WASM (WebAssembly) 插件是 Higress 核心的扩展机制之一。

1. 解决的问题：在传统的 API 网关（如 Kong 或早期的 Nginx）中，开发自定义插件通常需要使用 Lua 语言（如 OpenResty）。Lua 插件存在隔离性差（一个插件崩溃可能导致整个网关崩溃）、性能瓶颈以及开发调试困难等问题。
2. Higress 的优势：Higress 支持 WASM，允许开发者使用 C++、Go、Rust、JavaScript/TypeScript 等通用编程语言编写插件。这些插件会被编译成 WASM 字节码，运行在沙箱环境中。
   • 安全性：插件崩溃不会导致网关进程崩溃。
   • 灵活性：开发者可以使用自己熟悉的语言编写逻辑，无需学习 Lua。
   • 热加载：WASM 插件可以在不重启网关的情况下动态加载、更新或卸载。

5: Higress 支持哪些服务发现方式？能否对接非 Kubernetes 的服务？

5: Higress 支持哪些服务发现方式？能否对接非 Kubernetes 的服务？

A: Higress 设计为云原生的，但也具备对接传统架构的能力。

1. Kubernetes：原生支持 Kubernetes Service 服务发现，自动监听 Pod 和 Endpoints 的变化。
2. Nacos / Consul / Eureka：Higress 内置了对主流注册中心的支持。通过配置注册中心源，Higress 可以将后端服务动态注册为网关的上游服务，实现微服务架构下的流量转发。
3. 固定地址 / DNS：对于非云原生的传统服务，支持通过配置固定的 IP 地址或域名（DNS 解析）作为后端服务。

6: Higress 的性能表现如何？能否

6: Higress 的性能表现如何？能否

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 快速体验与流量转发

在本地 Docker 环境下快速部署 Higress。配置一个简单的 Ingress 路由，将访问 http://localhost/hello 的流量转发到一个现有的后端服务（如 httpbin.org 或 nginx 容器），并验证请求成功返回。

提示**: 参考 Higress 官方文档的 “快速开始” 章节。你需要编写一个 Kubernetes Ingress 资源文件（或在控制台配置），重点关注 spec.rules 中的 host 和 path 配置，以及 backend 的服务名称与端口。

实践建议

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

1. 利用 AI 插件生态实现零代码集成

Higress 内置了对 LLM（如 OpenAI, Azure, 通义千问等）的支持，并通过插件市场提供了 Prompt 优化、结果缓存等能力。

• 具体操作：在网关层面直接配置路由，将前端请求转发至 LLM Provider，而不是在业务后端代码中调用 SDK。使用 ai-proxy 插件来统一管理不同厂商的 API Key 和路由策略。
• 最佳实践：将 Prompt 模板和模型参数的维护权交给网关。例如，通过配置插件修改 System Prompt，可以在不重新发布业务服务的情况下实时调整 AI 行为。
• 常见陷阱：避免在网关侧处理过于复杂的 Prompt 逻辑（如包含大量上下文的拼接），这可能会增加网关的内存消耗和延迟，复杂的 Prompt 工程仍建议在业务服务侧预处理。

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

传统的 API 网关通常基于 QPS（每秒请求数）或并发数进行限流，但在 AI 场景下，成本和延迟主要取决于 Token 数量。

• 具体操作：配置针对特定 AI 路由的限流规则。如果 Higress 版本支持，尝试设置基于 Token 生成速率或消耗量的限流策略；若不支持，可结合请求体大小（作为 Token 量的粗略估算）进行限制。
• 最佳实践：为不同的用户或 API Key 设置不同的 Token 配额，防止个别用户通过大量 Prompt 消耗导致 API 账单激增或服务不可用。
• 常见陷阱：仅限制 QPS 无法防止长文本攻击。一个包含 10k Token 的请求虽然 QPS 只有 1，但可能瞬间打爆后端模型的处理能力或导致极高的费用。

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

AI 请求的显著特点是“高延迟”和“高成本”。对于问答类场景，大量重复的问题会重复产生 Token 消费。

• 具体操作：启用 Higress 的 ai-cache 或类似的缓存插件。配置基于向量或基于精确匹配的缓存策略，将 LLM 的响应结果缓存在网关层（Redis 或内存）。
• 最佳实践：针对“知识库问答”类高频重复问题设置较长的缓存时间（TTL），对于“创意写作”类需求设置较短或不缓存。
• 常见陷阱：注意缓存 Key 的设计。如果用户提问包含时间戳或随机 ID，会导致缓存命中率极低。建议对请求体进行标准化处理（去除无意义字符）后再生成缓存 Key。

4. 建立多模型供应商的容灾与路由机制

依赖单一的 LLM 供应商存在服务中断或配额耗尽的风险。

• 具体操作：在 Higress 中配置多个服务来源，例如同时配置 OpenAI 和通义千问的后端服务。利用 ai-proxy 插件的重试或路由规则，实现主备切换。
• 最佳实践：根据业务需求配置路由：例如将高复杂度请求路由给 GPT-4，将简单闲聊请求路由给成本更低的小模型或国产模型，以实现成本优化。
• 常见陷阱：不同厂商的 API 格式（尤其是流式传输 SSE 的格式）可能存在细微差异。在切换供应商时，务必在测试环境验证网关的响应转换是否兼容前端解析逻辑。

5. 优化 SSE 流式传输的超时与缓冲配置

AI 交互通常采用 Server-Sent Events (SSE) 流式返回，以提供打字机效果。这与传统的短 HTTP 请求不同。

• 具体操作：检查网关及上游服务的超时设置。对于流式请求，网关的超时时间应设置得足够长（或设置为流式不超时），并确保网关不会缓冲整个响应才发送给客户端。

引用

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

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

站内链接

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

相关文章

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