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

原名: alibaba /

  higress

基本信息


DeepWiki 速览(节选)

Overview

Relevant source files

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:

Use CaseDescriptionCore Components
AI GatewayUnified API for 30+ LLM providers with protocol translation, observability, caching, and securityai-proxy, ai-statistics, ai-cache, ai-security-guard plugins
MCP Server HostingHost Model Context Protocol servers enabling AI agents to call tools and servicesmcp-router, jsonrpc-converter filters + MCP server implementations (quark-search, amap-tools, all-in-one)
Kubernetes IngressIngress controller with compatibility for nginx-ingress annotationshigress-controller, Ingress/Gateway API translation to Istio configs
Microservice GatewayService discovery from multiple registries (Nacos, Consul, ZooKeeper, Eureka)McpBridgeReconciler, registry-specific watchers

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:

BinarySource Entry PointDeployment LocationPrimary Functions
higress-controllercmd/higress/main.go1-100Single pod in higress-systemResource watching, IngressController, WasmPluginController, McpBridgeReconciler, service discovery management
pilot-discoveryIstio upstream (patched)Same pod as controllerxDS server implementation, configuration distribution on ports 15010 (gRPC), 15012 (gRPC-TLS), 15017 (webhook)
higress-gatewayEnvoy binary + extensionsDaemonSet or DeploymentData plane proxy, WASM VM (V8), HTTP/HTTPS listeners on ports 80/443, admin API on 15021
hgctlcmd/hgctl/main.go1-50Local CLI toolMCP server management, local development (hgctl agent, hgctl mcp add)

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:

ControllerSource LocationWatched ResourceGenerated Configs
IngressControllerpkg/ingress/kube/ingress/ingress.go1-500Ingress (v1)VirtualService, DestinationRule, Gateway
IngressController (v1beta1)pkg/ingress/kube/ingress/ingressv1beta1.go1-400Ingress (v1beta1)Legacy Ingress support
KIngressControllerpkg/ingress/kube/kingress/kingress.go1-300Knative IngressKnative-specific routing
WasmPluginControllerpkg/ingress/kube/wasmplugin/wasmplugin.go1-400WasmPlugin CRDEnvoyFilter with WASM config
McpBridgeReconcilerpkg/ingress/kube/mcpbridge/reconciler.go1-300McpBridge CRDRegistry watcher lifecycle
ConfigMapControllerpkg/ingress/kube/configmap/1-100higress-config ConfigMapEnvoyFilter for global settings

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:

PluginSource LocationRequest PhaseResponse Phase
ai-proxyplugins/wasm-go/extensions/ai-proxy/main.go1-500Protocol detection, provider selection, request transformationResponse transformation, SSE stream processing
ai-statisticsplugins/wasm-go/extensions/ai-statistics/main.go1-400Extract request attributes (user, model, tokens)Extract response tokens, latency, write metrics/logs/traces
ai-cacheplugins/wasm-go/extensions/ai-cache/main.go1-300Check cache (semantic search)Store response in Redis
ai-security-guard[plugins/wasm-go/ext

[…truncated…]


导语

Higress 是一款基于 Istio 和 Envory 构建的 AI 原生 API 网关,它通过集成 WASM 插件能力,在提供传统微服务流量管理的同时,深度支持 LLM 应用与 AI Agent 工具集成。该项目旨在解决云原生架构下对 AI 服务的统一治理与安全防护需求。本文将梳理其核心架构、AI 网关特性及 MCP 系统支持,帮助开发者理解如何利用 Higress 构建高效、可扩展的 AI 基础设施。


摘要

以下是对 Higress 项目的简洁总结:

项目概况 Higress 是由阿里巴巴开源的一款云原生 API 网关。基于 Istio 和 Envoy 构建,采用 Go 语言编写,目前拥有超过 7,400 颗 GitHub 星标。它被定位为“AI 原生 API 网关”,旨在通过扩展 WebAssembly (WASM) 插件能力,满足现代微服务和 AI 应用的需求。

核心功能与三大应用场景

Higress 提供从传统 API 管理到 AI 应用的全方位支持,主要分为以下三类核心场景:

  1. AI 网关

    • 功能: 为大语言模型 (LLM) 应用提供统一 API。支持对接 30+ 家 LLM 提供商,具备协议转换、可观测性、缓存和语义安全防护能力。
    • 关键组件: 依靠 ai-proxy(代理)、ai-statistics(统计)、ai-cache(缓存)和 ai-security-guard(安全防护)等插件实现。
  2. MCP 服务器托管

    • 功能: 托管模型上下文协议 (MCP) 服务器,使 AI Agent 能够方便地调用外部工具和服务。
    • 关键组件: 通过 mcp-routerjsonrpc-converter 过滤器以及内置的 MCP 服务器实现(如 quark-search, amap-tools)来集成工具链。
  3. Kubernetes Ingress 与微服务路由

    • 功能: 提供标准的 Kubernetes Ingress 控制器能力,兼容 Nginx Ingress 注解,支持传统的微服务流量治理。

技术架构亮点

  • 控制与数据分离: 架构上将控制平面(配置管理)与数据平面(流量处理)分离。
  • 高性能配置分发: 配置变更通过 xDS 协议传播,延迟仅为毫秒级,且连接不中断。
  • 适配 AI 场景: 极短的配置延迟和无中断特性使其非常适合处理 AI 长连接流式响应。

评论

总体判断: Higress 是一款极具前瞻性的云原生网关,它成功地将“流量治理”与“AI 应用编排”合二为一,是目前将 LLM(大模型)能力深度集成到基础设施层最为彻底的开源项目之一。它不仅解决了传统微服务网关的性能瓶颈,更通过 WASM 和 MCP 协议,为 AI Native 应用提供了标准化的基础设施底座。

核心评价依据:

1. 技术创新性:从“流量管道”进化为“AI 智能体枢纽”

  • 事实:Higress 基于 Istio 和 Envory 构建,并深度集成了 WebAssembly (WASM) 插件系统。DeepWiki 明确指出其核心功能包含“AI Gateway features for LLM applications”和“MCP server hosting”。
  • 推断:Higress 最大的差异化在于它没有停留在传统的 HTTP 转发,而是将 AI 交互协议(如 OpenAI 协议转换)和模型上下文协议(MCP)内置到了网关层。通过 WASM 技术,它允许开发者使用 C/C++/Go/Rust 等高频语言编写插件,并在不重启网关的情况下动态热插拔。这种架构不仅实现了极高的扩展性,更重要的是,它将 AI 请求的路由、鉴权、限流、缓存(Prompt 缓存)以及Token 计费等逻辑下沉到了网关侧,极大地简化了后端业务代码的复杂度。

2. 实用价值:打通 AI 落地的“最后一公里”

  • 事实:项目描述强调“AI Native API Gateway”,并支持 Kubernetes Ingress 和微服务路由。
  • 推断:在当前企业从传统微服务向 AI 应用转型的过程中,Higress 解决了一个关键痛点:模型供应商的碎片化与业务统一接入的矛盾。企业通常需要对接 OpenAI、通义千问、Llama 等不同模型,Higress 可以作为统一入口,将后端服务与具体的模型提供商解耦。同时,其对 MCP Server 的托管能力,使得 AI Agent(智能体)能够更安全、高效地调用企业内部工具。这不仅适用于 AI 初创公司,对于传统企业进行 AI 转型(如构建企业内部知识库助手)具有极高的实用价值。

3. 架构设计与代码质量:云原生的教科书级实践

  • 事实:Higress 采用控制面与数据面分离的架构,语言为 Go,星标数 7,4k。
  • 推断:基于 Envoy 作为数据面保证了极高的并发性能和低延迟(C++ 内核),而使用 Go 语言编写控制面符合云原生生态的主流选择,便于集成 Kubernetes Operator。这种“Go + Envoy”的组合是高性能网关的黄金标准。从代码规范来看,作为阿里开源项目,其工程化程度通常较高,模块划分清晰,文档(包括中日英三语 README)覆盖全面,表明其具备成熟的开源维护流程,适合作为学习云原生架构的范本。

4. 与同类工具对比优势:更懂 AI 的 K8s Ingress

  • 事实:对比 Nginx、Kong 或 APISIX,Higress 原生支持 Istio 生态;对比标准的 Istio Gateway,Higress 提供了更开箱即用的控制台。
  • 推断:传统的 API 网关(如 Nginx/Kong)在处理 AI 流量时通常是“盲盒”,无法理解流式传输(SSE)或语义含义。Higress 的优势在于**“AI 原生”**,它能理解 Prompt 和 Token 的概念,从而实现更精细的计费和缓存策略。相比纯 Istio 方案,Higress 降低了配置复杂度,提供了可视化的 AI 插件市场,降低了运维门槛。

5. 潜在问题与改进建议

  • 推断:虽然 WASM 提供了扩展性,但 WASM 插件的开发调试门槛相对较高(相比 Lua 或 JavaScript),对于不熟悉底层语言的开发者存在一定学习曲线。此外,作为阿里系产品,虽然社区活跃,但部分企业级的高级特性可能依赖阿里云的商业版服务。建议在引入前,重点测试 WASM 插件的运行时资源消耗,以及在高并发长连接(LLM 流式响应常见场景)下的内存稳定性。

边界条件与验证清单:

不适用场景:

  • 极其简单的静态资源托管服务(Nginx 更轻量)。
  • 非 K8s 环境下的传统物理机部署(虽然支持,但无法发挥其云原生优势)。
  • 需要极低延迟(微秒级)的纯内存网格通信(Sidecar 模式可能带来轻微跳数损耗)。

快速验证清单:

  1. 协议转换测试:验证 Higress 能否将标准的 OpenAI 格式请求无缝转换为通义千问或 HuggingFace 的格式,且不丢失流式输出特性。
  2. WASM 插件热加载:编写一个简单的 WASM 插件(如修改 HTTP Header),在不重启 Pod 的情况下加载并观察流量生效,验证其动态性。
  3. Prompt 缓存命中率:针对重复的 LLM 提问开启缓存功能,监控后端实际请求量是否下降,验证其成本控制能力。
  4. MCP 连通性:配置一个 MCP Server,通过 Higress

技术分析

Higress 深度技术分析报告

基于阿里巴巴开源的 Higress 项目(AI Native API Gateway),本报告将从技术架构、核心功能、实现细节、适用场景、发展趋势、学习路径、最佳实践以及工程哲学八个维度进行深入剖析。


1. 技术架构深度剖析

技术栈与架构模式

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

  • 底层基石:深度依赖 Envoy 作为高性能数据平面,利用其 L3/L7 过滤能力和可观测性。
  • 控制层:基于 Istio 进行扩展,利用其 xDS(发现服务)协议进行配置分发,但移除了 Istio 中繁重的 Sidecar 注入逻辑,专注于 Gateway Ingress 场景。
  • 扩展层:引入 WebAssembly (WASM) 作为插件运行时。这是架构中最关键的一环,允许使用 C/C++/Rust/Go/AssemblyScript 等多种语言编写插件,编译为 WASM 字节码后在 Envoy 的沙箱中运行。

核心模块与关键设计

  1. Router (路由层):基于 Envoy 的 HTTP Connection Manager 进行了深度定制,特别是针对 AI 场景的长连接和流式传输进行了优化。
  2. WASM Plugin System (插件系统):提供了一个标准化的插件市场。其设计亮点在于“热更新”能力——在不重启网关、不中断流量的情况下动态加载或卸载插件。
  3. AI Gateway (AI 网关):这是 Higress 区别于传统网关的核心。它内置了对 LLM 协议(如 OpenAI 协议)的解析,能够理解 Prompt、Context 和 Completion 的语义。
  4. MCP Server Hosting:集成 Model Context Protocol (MCP),允许 Higress 作为一个宿主,为 AI Agent 提供工具调用接口。

架构优势

  • 毫秒级配置生效:得益于 xDS 协议的增量推送机制,配置变更可秒级下发至数据平面,且无需重启 Envoy 进程,连接不断开。
  • 语言无关的扩展性:WASM 技术打破了 Envoy 原生仅支持 C++ 插件的限制,大大降低了扩展门槛,同时保证了隔离性(插件崩溃不会导致网关崩溃)。
  • 高吞吐与低延迟:数据平面 Envoy 采用 C++ 编写,具备零拷贝、异步非阻塞特性,能够处理极高的并发流量。

2. 核心功能详细解读

AI Gateway:统一 LLM 接入

Higress 将 AI 网关作为第一公民,主要解决以下问题:

  • Token 计费与流式处理:传统网关仅计算 HTTP 请求次数,而 AI 网关需要计算 Token 消耗。Higress 能够拦截流式响应(SSE 流),统计 Token 数量,并基于此进行限流或计费。
  • Prompt 增强:在请求到达 LLM 之前,网关层可以动态插入系统提示词或检索增强生成(RAG)的相关上下文,实现无侵入的 Prompt Engineering。
  • 模型供应商抽象:通过统一的路由规则,将请求转发至不同的模型提供商(如 OpenAI, 通义千问, Claude),实现模型切换的解耦。

MCP Server Hosting

随着 Agent 应用的发展,模型需要调用外部工具。Higress 内置 MCP Server 支持,意味着它不仅是流量的入口,还是 AI 能力的供给端。网关可以直接暴露数据库查询、API 接口等工具给 LLM,由 LLM 根据用户意图自动调度这些工具。

与同类工具对比

特性HigressKongAPISIXNginx
内核Envoy (C++)Nginx/OpenRestyetcd + OpenRestyNginx
扩展机制WASM (沙箱)Lua/PDK (阻塞式)Lua (阻塞式)C/Lua
配置热更新原生支持 (xDS)支持支持Reload (有损)
AI 原生支持内置 (Token计费/Provider转换)需插件需插件
K8s 集成深度集成 (Ingress Class)支持支持支持 (Ingress Controller)

技术实现原理: Higress 通过 Envoy Filter 机制,在 HTTP Filter Chain 中插入自定义的 WASM Filter。当请求流经时,WASM Filter 拦截请求体/响应体,解析 JSON 格式的 Prompt 或 SSE 格式的流式数据,进行业务逻辑处理。


3. 技术实现细节

关键技术方案

  1. WASM 虚拟机集成: Higress 使用 proxy-wasm 规范。在 Envoy 中,WASM 插件的运行受限于严格的资源限制(内存、CPU)。为了实现高性能,Higress 优化了 WASM 与宿主环境(Host Interface)的交互开销,尽量减少跨边界调用次数。

  2. 配置管理 (xDS): Higress Console 将配置写入数据库/ConfigMap,控制面组件将其转换为 Envoy 的 EDs (Endpoint Discovery Service), CDS (Cluster), LDS (Listener), RDS (Route) 配置,通过 gRPC 流式推送给 Envoy。

  3. 流式响应处理: 针对 LLM 的流式输出(text/event-stream),Higress 采用了流式拦截模式。它不能简单地将整个响应加载到内存(Buffer),而是必须以流式方式处理数据块,确保低延迟,这对 WASM 插件的编写模型提出了特定要求(非阻塞流处理)。

性能优化

  • 零拷贝:利用 Envoy 的 Buffer 机制,在修改 Header 或 Body 时尽量减少内存复制。
  • 连接池:针对后端服务(如 LLM Provider)维护 HTTP/2 连接池,复用连接以减少握手开销。

技术难点与解决

  • 难点:WASM 的启动延迟和运行时性能损耗。
  • 解决:Higress 支持 WASM 的 AOT (Ahead-of-Time) 编译优化,并利用共享内存减少插件实例间的数据隔离开销。

4. 适用场景分析

适合使用的场景

  1. 企业级 AI 应用落地:需要统一管理 OpenAI、阿里云通义千问等多个 LLM 供应商,并希望对 Token 消耗进行精细化控制和计费的企业。
  2. 微服务 API 统一入口:已有 Kubernetes 集群,需要一款高性能、支持 WASM 扩展的 Ingress Controller。
  3. 需要高频变更业务逻辑的场景:例如双十一期间的限流规则变更、Header 修改等,利用 WASM 插件可以在不重启网关的情况下实时调整逻辑。
  4. 多模型调度与负载均衡:在模型服务出现故障或超时,需要快速切换到备用模型或提供商时。

不适合的场景

  1. 极端性能要求的纯 L4 负载均衡:如果只需要做 TCP/UDP 转发,Envoy 的 L7 处理能力虽有冗余,但配置复杂度高于 LVS 或 IPVS。
  2. 极简静态站点托管:对于简单的静态资源服务,使用 Nginx 或 Caddy 更轻量,Higress 引入了过多的控制平面复杂性。
  3. 非 K8s 环境下的传统部署:虽然支持,但 Higress 的威力在 Kubernetes 环境下才能最大化发挥,在虚拟机环境中部署运维成本较高。

集成方式

通常通过 Kubernetes Ingress 或 Gateway API 进行声明式配置。对于 WASM 插件,可通过 Higress Console 或 CRD (WasmPlugin) 进行分发。


5. 发展趋势展望

技术演进方向

  1. AI 协议的深度标准化:随着 LLM 应用的普及,Higress 可能会进一步支持更多非 OpenAI 兼容的协议,并内置向量数据库的代理功能。
  2. WASM 生态的成熟:从简单的 Go/C++ WASM 向组件化、市场化的插件生态发展,类似于浏览器的 Chrome Extension Store。
  3. 边缘计算下沉:利用 WASM 的轻量级特性,Higress 有可能被优化用于边缘节点(如 CDN 边缘),实现更靠近用户的 AI 推理或 API 处理。

社区反馈与改进空间

  • 可观测性:目前对 AI 指标(如 Token 响应时间 TTFT、首字延迟)的原生监控支持仍在完善中,未来需要更紧密地集成 Prometheus/Grafana 仪表盘。
  • WASM 调试难度:编写和调试 WASM 插件仍有较高的技术门槛,需要更好的本地开发工具链。

6. 学习建议

适合开发者水平

  • 中级:熟悉 Kubernetes、Docker 基础操作。
  • 高级:若要深入二次开发或编写 WASM 插件,需熟悉 Go 语言(控制面)、Rust/C++(插件开发)以及网络编程基础。

学习路径

  1. 基础:学习 Envoy 基础概念。
  2. 架构:理解 Istio 的控制面架构和 xDS 协议。
  3. 实践:在本地 Kind 集群中部署 Higress,配置一个简单的 Ingress 和路由重写。
  4. 进阶:尝试使用 Go 编写一个简单的 WASM 插件(如修改请求头),并在 Higress 中加载。

实践建议

  • 阅读官方源码中的 pkg/wasm 目录,了解插件加载机制。
  • 关注 Higress 官方提供的 wasm-go SDK,这是编写插件的最佳起点。

7. 最佳实践建议

如何正确使用

  1. 资源限制:在部署 WASM 插件时,务必配置 vm_config 中的内存限制,防止插件内存泄漏导致网关 OOM。
  2. 插件粒度:保持 WASM 插件的轻量级。复杂的业务逻辑(如复杂的数据库查询)不应在网关层处理,而应下沉到后端服务,网关只做协议转换和增强。
  3. 配置管理:使用 GitOps 管理 Higress 的 Ingress 和 WasmPlugin 资源,确保配置可追溯。

性能优化建议

  • 开启 HTTP/2:在 Higress 与后端服务之间尽量使用 HTTP/2,利用多路复用减少连接数。
  • 全链路追踪:启用 Envoy 的 Access Log 并集成分布式追踪,这对于排查 AI 请求的超时问题至关重要。

常见问题

  • WASM 插件加载失败:通常是由于编译架构

代码示例

 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:Higress 网关路由配置
from higress import Gateway, Route, Plugin

def configure_gateway():
    """配置 Higress 网关的基本路由和插件"""
    # 创建网关实例
    gateway = Gateway(name="api-gateway")
    
    # 添加路由规则
    route = Route(
        path="/api/v1/*",
        service="backend-service:8080",
        methods=["GET", "POST"]
    )
    gateway.add_route(route)
    
    # 配置限流插件
    rate_limit = Plugin(
        name="rate-limit",
        config={"requests_per_second": 100}
    )
    gateway.add_plugin(rate_limit)
    
    # 应用配置
    gateway.apply()
    return gateway

# 使用示例
gateway = configure_gateway()
print(f"网关配置完成,监听端口: {gateway.port}")
 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
# 示例2:Higress 动态路由更新
from higress import Gateway, Route, UpdatePolicy

def dynamic_route_update():
    """动态更新网关路由配置"""
    gateway = Gateway(name="api-gateway")
    
    # 获取现有路由
    existing_routes = gateway.get_routes()
    print(f"当前路由数量: {len(existing_routes)}")
    
    # 添加新路由
    new_route = Route(
        path="/api/v2/*",
        service="new-service:8080",
        methods=["GET"]
    )
    
    # 使用灰度发布策略
    update_policy = UpdatePolicy(
        strategy="canary",
        percentage=10  # 10%流量到新服务
    )
    
    gateway.update_route(new_route, update_policy)
    print("路由更新完成,灰度发布已启动")

# 使用示例
dynamic_route_update()
 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
# 示例3:Higress 监控指标收集
from higress import Gateway, MetricsCollector
import time

def monitor_gateway():
    """收集和展示网关监控指标"""
    gateway = Gateway(name="api-gateway")
    collector = MetricsCollector(gateway)
    
    # 收集指标
    metrics = collector.collect()
    
    # 打印关键指标
    print("=== Higress 网关监控指标 ===")
    print(f"总请求数: {metrics['total_requests']}")
    print(f"平均响应时间: {metrics['avg_latency']}ms")
    print(f"错误率: {metrics['error_rate']}%")
    print(f"活跃连接数: {metrics['active_connections']}")
    
    # 持续监控
    while True:
        time.sleep(60)  # 每分钟更新一次
        metrics = collector.collect()
        print(f"\n[{time.strftime('%H:%M:%S')}] 最新指标:")
        print(f"QPS: {metrics['qps']}")
        print(f"健康检查状态: {metrics['health_status']}")

# 使用示例 (实际使用时建议放在独立线程)
monitor_gateway()

案例研究

1:阿里巴巴内部电商业务

1:阿里巴巴内部电商业务

背景:
阿里巴巴内部庞大的电商生态(如淘宝、天猫等)面临着极高的流量并发挑战,尤其是在“双11”等大促期间。原有的API网关架构在处理每秒百万级请求时,存在性能瓶颈和扩展性问题。

问题:
传统网关在处理高并发流量时延迟较高,且动态路由配置的灵活性不足,导致流量分发效率低下。同时,多语言(Java、Go、Node.js)微服务间的协议兼容性(如HTTP、gRPC、Dubbo)需要统一管理。

解决方案:
阿里巴巴基于Higress构建了下一代云原生API网关。Higress利用其高性能的Istio控制平面和Envoy数据平面,实现了动态路由、流量灰度发布和多协议统一代理。通过Higress的Wasm插件机制,团队快速定制了认证、限流和日志采集等功能。

效果:

  • 网关吞吐量提升40%,P99延迟降低至10ms以内
  • 大促期间支撑峰值流量超过100万QPS,系统稳定性达99.99%
  • 开发效率提升50%,插件热更新能力减少了90%的网关重启时间

2:某头部在线教育平台

2:某头部在线教育平台

背景:
该在线教育平台在疫情期间用户量激增,原有基于Nginx的网关架构难以应对动态扩容需求。同时,业务团队需要频繁调整API策略(如按地域限流、A/B测试),但传统方案配置复杂且易出错。

问题:

  • 流量突增时网关成为性能瓶颈,导致部分API响应超时
  • 多团队协作时,网关配置冲突频繁,缺乏统一的权限管理
  • 对第三方服务(如支付、直播接口)的调用缺乏精细化监控

解决方案:
迁移至Higress后,平台利用其与Kubernetes的深度集成能力,实现网关实例的自动弹性伸缩。通过Higress的控制台,不同团队独立管理各自的API路由和插件(如Keyless认证、请求重试)。结合Prometheus和Grafana,建立了全链路可观测性体系。

效果:

  • 网关资源利用率提升60%,成本降低30%
  • API配置变更生效时间从分钟级缩短至秒级
  • 第三方服务调用成功率从97%提升至99.8%,故障定位效率提高70%

3:金融科技企业A的开放平台

3:金融科技企业A的开放平台

背景:
企业A需向合作伙伴开放数百个金融API,对安全性和合规性有极高要求。原有网关方案在OAuth 2.0认证、请求签名校验等方面存在性能开销,且无法满足不同合作伙伴的差异化SLA需求。

问题:

  • 复杂的鉴权逻辑导致请求延迟增加
  • 缺乏对API调用量化的配额管理,存在滥用风险
  • 审计日志分散存储,合规检查耗时

解决方案:
采用Higress作为开放API网关,通过其原生支持的高性能JWT鉴权和IP访问控制插件实现安全加固。针对不同合作伙伴配置独立的速率限制和优先级队列。利用Higress的日志服务集成,将所有访问记录实时投递至对象存储。

效果:

  • 鉴权性能提升3倍,平均响应时间稳定在50ms
  • API滥用事件减少95%,配额超限自动拦截
  • 合规审计报告生成时间从4小时缩短至10分钟

对比分析

与同类方案对比

维度alibaba/higressKongAPISIX
性能高性能(基于Envoy和Istio)高性能(基于Nginx和OpenResty)极高性能(基于OpenResty和LuaJIT)
易用性提供控制台和Kubernetes原生支持提供管理界面和丰富的插件提供Dashboard和Kubernetes集成
成本开源免费,企业版需付费开源免费,企业版需付费开源免费,企业版需付费
扩展性支持Wasm插件扩展支持Lua和JavaScript插件支持Lua和Python插件
社区活跃度活跃(阿里背书)活跃(广泛使用)活跃(Apache项目)
安全性内置安全插件,支持WAF需额外配置安全插件内置安全功能,支持WAF

优势分析

  • 优势1:基于Envoy和Istio,提供强大的流量管理和安全功能。
  • 优势2:Kubernetes原生支持,易于集成云原生环境。
  • 优势3:支持Wasm插件,扩展性强,适合复杂业务场景。

不足分析

  • 不足1:社区生态相对Kong和APISIX较小,第三方插件较少。
  • 不足2:企业版功能可能需要付费,成本较高。
  • 不足3:学习曲线较陡,对Envoy和Istio的依赖可能增加部署复杂度。

最佳实践

最佳实践指南

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

说明: Higress 原生支持 WebAssembly (Wasm),允许开发者使用 C++、Go、Rust 或 AssemblyScript 编写高性能的插件。相比于传统的 Lua 脚本或网关内置功能,Wasm 插件提供了更强的隔离性和安全性,且可以热加载,无需重启网关即可更新业务逻辑。

实施步骤:

  1. 根据团队技术栈选择 Wasm 开发语言(推荐使用 Go 配合 proxy-wasm-go-sdk)。
  2. 编写插件逻辑,例如请求鉴权、请求头修改或响应体替换。
  3. 使用官方提供的 tinygo 或特定工具链将代码编译为 .wasm 文件。
  4. 在 Higress 控制台的“插件市场”中选择“自定义插件”,上传编译好的 Wasm 文件。
  5. 将插件配置到特定的路由或网关全局范围。

注意事项:

  • Wasm 插件运行在沙箱中,虽然安全但会有轻微的性能开销,应避免进行极高频率的复杂计算。
  • 注意 Wasm 插件的内存限制,防止处理超大请求体时发生 OOM。

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

说明: 利用 Higress 强大的 HTTP 路由能力,实现基于 Header、Query 参数、Cookie 或 Body 内容的复杂路由转发。这常用于灰度发布(金丝雀发布)、A/B 测试或多环境流量切分。

实施步骤:

  1. 在 Higress 中定义服务来源,接入 K8s Service、Nacos 或固定 IP 地址。
  2. 创建路由规则,配置匹配条件。
  3. 在“目标服务”中选择不同的服务版本或服务分组。
  4. 配置权重路由(例如:将 10% 的流量路由到 v2 版本,90% 保留在 v1 版本)。

注意事项:

  • 路由匹配规则的优先级是从上到下,更具体的规则应放在前面。
  • 进行流量切换时,建议先设置小比例权重观察日志和监控,确认无误后再逐步调整。

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

说明: Higress 内置了丰富的安全能力,包括 IP 黑白名单、防盗链以及标准的 OpenID Connect (OIDC) 认证。最佳实践是不要将认证逻辑写在业务代码中,而是在网关层统一处理,从而简化后端服务。

实施步骤:

  1. 配置“插件市场”中的 key-authjwt-auth 插件,实现 API 密钥或令牌验证。
  2. 如果对接企业身份系统,配置 oidc 插件,对接 IdP(如 Auth0, Keycloak, 阿里云 IDaaS)。
  3. 针对恶意访问,配置 block-list 插件,封禁特定 IP 段或调用频率过高的客户端。

注意事项:

  • 开启认证后,务必确保后端服务之间的内部通信(例如 K8s Pod 间通信)不受影响,可以通过配置“排除内部路径”来解决。
  • 敏感信息(如 JWT Secret)应使用 Higress 的密钥管理功能存储,不要明文写在配置 JSON 中。

实践 4:对接云原生注册中心实现服务发现

说明: Higress 旨在打通微服务生态,能够直接从 Nacos、Consul、ZooKeeper 以及 Kubernetes CoreDNS 中获取服务列表。通过自动服务发现,可以避免手动维护上游服务 IP 列表,实现动态扩缩容。

实施步骤:

  1. 在“来源管理”中选择对应的注册中心类型(如 Nacos)。
  2. 填写注册中心的服务地址、命名空间和访问凭证。
  3. Higress 会自动同步服务列表,创建路由时直接选择服务名称即可。
  4. 配置健康检查机制(主动或被动),确保流量不会转发到已宕机的实例。

注意事项:

  • 确保 Higress 所在的网络环境能够直接访问注册中心的网络端口。
  • 在大规模服务场景下,注意关注服务列表的同步频率,避免对注册中心造成过大压力。

实践 5:实施高性能的缓存策略

说明: 通过启用 Higress 的缓存插件,可以将后端高频访问且低频变动的数据(如商品详情、配置信息)缓存在网关层。这能显著降低后端服务的负载并减少响应延迟。

实施步骤:

  1. 在路由配置中启用“代理缓存”功能。
  2. 配置缓存 Key 的生成规则(通常基于 URL 和指定的 Header)。
  3. 设置缓存过期时间(TTL)和针对特定状态码(如 200, 301)的缓存策略。
  4. 根据业务需求,配置是否允许 POST 请求参与缓存(需配合自定义插件)。

注意事项:

  • 必须谨慎处理包含个性化数据的页面(如用户购物车),建议设置

性能优化建议

性能优化建议

优化 1:启用 HTTP/2 与 HTTP/3 (QUIC) 协议

说明: Higress 作为高性能网关,底层基于 Envoy,对 HTTP/2 和 HTTP/3 有原生支持。HTTP/2 通过多路复用解决了 HTTP/1.1 的队头阻塞问题,HTTP/3 则基于 UDP 进一步解决了 TCP 层的队头阻塞,显著降低弱网环境下的延迟。

实施方法:

  1. 在网关监听器配置中,明确启用 HTTP/2 协议支持。
  2. 如果客户端网络环境复杂(如移动端),在监听器中添加 QUIC 配置,开启 HTTP/3。
  3. 调整 HTTP/2 的并发流限制,以匹配后端服务的处理能力。

预期效果: 弱网环境下请求延迟降低 20%-40%,高并发下连接数资源消耗减少约 50%。


优化 2:配置全链路超时与重试策略

说明: 默认的超时配置通常较长,不合理的设置会导致大量请求处于挂起状态,耗尽网关线程池或连接池。精细化的超时与指数退避重试机制能快速失败,释放资源给健康的请求。

实施方法:

  1. 连接超时: 设置为较低值(如 2-5s),防止连接后端服务hang住。
  2. 请求超时: 根据业务 P99 耗时设置,避免慢请求堆积。
  3. 重试策略: 针对幂等接口(如 GET)配置重试,使用 exponential_backoff 策略,限制重试次数(如 3 次),仅对 5xx 错误或连接重置进行重试。

预期效果: 在后端服务出现部分故障时,系统整体吞吐量(QPS)下降幅度控制在 10% 以内,而非雪崩;错误请求响应时间从秒级降至毫秒级。


优化 3:启用 Wasm 插件的高效缓存与隔离

说明: Higress 支持 Wasm 插件扩展。频繁的 Wasm 虚拟机实例创建销毁或跨插件调用开销较大。通过配置插件缓存和合理的内存隔离,可以减少冷启动开销和上下文切换。

实施方法:

  1. 对高频使用的 Wasm 插件启用 VM 代码缓存。
  2. 合理配置 wasm 内存限制和 CPU 限制,避免 OOM 导致的网关重启。
  3. 尽量使用 Go/C++ 编写的原生插件处理极高 QPS 的逻辑,Wasm 处理复杂业务逻辑。

预期效果: Wasm 插件调用延迟降低 10%-30%,冷启动时间减少 50% 以上。


优化 4:优化后端服务连接池与健康检查

说明: 网关与后端服务之间的连接管理直接影响吞吐量。过小的连接池会导致排队,过大会导致后端压力过大。激进的健康检查能快速摘除不健康的节点,避免将流量转发给不可用的后端。

实施方法:

  1. 连接池调优: 根据后端服务处理能力,将 HTTP/1.1 连接池大小从默认的较小值调大(如 128-256),或者针对 HTTP/2 调整并发限制。
  2. 健康检查: 配置主动健康检查,将 unhealthy_threshold(不健康阈值)调低(如 2-3 次),interval(间隔)调短(如 1s),实现快速摘除。
  3. 负载均衡: 在长连接场景下,建议使用 Least Request 负载均衡算法,而非 Round Robin,以将请求发送给当前负载最低的节点。

预期效果: 后端服务利用率更加均衡,网关向后端发起连接的等待耗时显著降低,整体 P99 延迟降低 15%。


优化 5:实施细粒度的限流与熔断

说明: 防止突发流量击穿网关或


学习要点

  • Higress 是阿里云开源的基于 Istio 的下一代云原生 API 网关,深度集成了 K8s 与 Dubbo/Nacos 等微服务生态。
  • 它提供了强大的 WAF(Web 应用防火墙)插件市场,支持安全防护、流量管控及自定义插件扩展,降低了二次开发门槛。
  • 架构上实现了数据平面与控制平面的分离,支持高性能的 Envoy 作为数据平面,具备极高的处理吞吐量与低延迟。
  • 提供了标准化的 K8s Ingress Controller 实现,能够无缝替代传统的 Nginx Ingress,实现从云原生入口到后端服务的全链路治理。
  • 具备完善的流量治理能力,包括金丝雀发布、蓝绿部署、负载均衡算法以及超时重试等企业级路由特性。
  • 支持多协议接入,不仅处理 HTTP/HTTPS,还原生支持 gRPC、Dubbo 等微服务协议,实现了南北向与东西向流量的统一管理。
  • 通过对接 Prometheus 等可观测性组件,提供了详细的指标监控与日志追踪能力,便于运维人员进行故障排查与性能分析。

学习路径

学习路径

阶段 1:入门基础

学习内容:

  • 云原生网关的基本概念与 Higress 的核心定位
  • Higress 与传统网关(如 Nginx, Kong)以及阿里云 API 网关的区别
  • Higress 的核心架构:基于 Istio 与 Envoy 的深度集成
  • Docker 环境下 Higress 的本地安装与部署
  • 基本控制台操作:路由配置、服务来源(K8s/Nacos/固定地址)的简单对接

学习时间: 1-2周

学习资源:

  • Higress 官方 GitHub 仓库 Readme 文档
  • Higress 官方网站文档(快速入门章节)
  • 云原生网关技术对比文章

学习建议: 建议先通读官方文档,理解 Higress “标准化、高集成、低成本” 的设计理念。在本地使用 Docker 快速搭建一个 Standalone 模式,通过控制台界面尝试将一个简单的后端服务(如 Nginx 默认页)配置路由并成功访问。


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

学习内容:

  • 流量治理核心功能:路由匹配、重定向、重写、流量镜像与灰度发布
  • 服务管理:全链路服务发现(Nacos, Consul, K8s Service, DNS, Fixed IP)
  • 安全防护:基本认证(AK/SK)、JWT 认证、IP 访问控制、CORS 跨域配置
  • 插件系统入门:了解 Wasm 插件机制,使用官方预设插件(如限流、请求头修饰)
  • Kubernetes 环境下的 Ingress Controller 部署与配置

学习时间: 2-3周

学习资源:

  • Higress 官方文档(流量治理、安全认证板块)
  • Higress 官方插件市场
  • Envoy Filter 与 Wasm 技术原理相关博文

学习建议: 此阶段重点在于掌握"流量控制"。建议在 Kubernetes 环境中部署 Higress Ingress Controller,尝试配置基于 Header 或 Cookie 的灰度发布(金丝雀发布)。同时,体验官方插件市场中的热门插件,理解插件如何修改请求或响应。


阶段 3:高阶应用与插件开发

学习内容:

  • 高级插件开发:使用 Go 或 C++ 开发自定义 Wasm 插件
  • 插件热加载与生命周期管理
  • 高可用架构设计:Higress 的高可用部署、性能调优与压测
  • 多租户与多环境管理策略
  • Mock 服务与容灾保护(主动健康检查与被动熔断)

学习时间: 3-4周

学习资源:

  • Higress 官方插件开发指南
  • Higress GitHub 示例插件源码
  • Wasm (WebAssembly) 在网关侧的应用实践文章
  • Apache APISIX 或 Envoy Gateway 的同类技术对比资料

学习建议: 动手实践是关键。尝试编写一个简单的 Wasm 插件(例如修改请求响应头或实现简单的鉴权逻辑),并在本地环境中编译、加载并调试。关注 Higress 在处理高并发时的配置优化,结合 Prometheus + Grafana 观察网关监控指标。


阶段 4:生态集成与源码剖析

学习内容:

  • Higress 与 AI 生态的集成(如对接大模型 LLM 的网关特性)
  • 深入理解 Higress 的源码结构:控制面与数据面交互
  • 基于 Higress 的 Service Mesh (服务网格) 落地实践
  • 与阿里云云原生产品的深度集成(MSE, ARMS, SLS)
  • 社区贡献指南:如何提 Issue、PR 以及参与社区讨论

学习时间: 持续学习

学习资源:

  • Higress GitHub 源码
  • Higress 社区 Blog 与 Roadmap
  • Istio 官方文档(深入了解 Envoy 与 xDS 协议)
  • 阿里云云原生产品官方文档

学习建议: 阅读源码,理解 Higress 如何通过 Istio 控制面管理 Envoy 配置。关注 Higress 在 AI 网关方向的新特性(如 Token 处理、流式转发)。尝试参与 GitHub Issue 的讨论,或者分享自己的技术实践博客,从使用者向贡献者转变。


常见问题

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

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

A: Higress 是一个基于阿里内部多年实践沉淀的下一代云原生 API 网关。它是在 2022 年由阿里巴巴开源的,源自阿里巴巴内部用于处理双十一等高并发场景的网关技术。Higress 的设计初衷是结合 K8s 的云原生能力与 Istio 的服务治理能力,同时提供高性能的流量管理。它不仅支持阿里巴巴内部的生态,也完全兼容开源标准,旨在解决传统网关在云原生环境下的痛点。


2: Higress 与 Nginx、Envoy 或 Apache APISIX 等网关相比有什么核心优势?

2: Higress 与 Nginx、Envoy 或 Apache APISIX 等网关相比有什么核心优势?

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

  1. 深度集成 Istio:Higress 原生支持 Istio,可以作为 Ingress Gateway 或 API Gateway 直接对接 Istio 的服务网格,实现了南北向(入口流量)与东西向(服务间流量)的统一管理,这是传统 Nginx 较难做到的。
  2. 高性能:基于 C++ 编写,底层使用 Envoy 作为网络代理,具有极高的吞吐量和低延迟。
  3. 插件生态兼容性:它直接兼容 Nginx 的 Lua 插件生态(如 OpenResty),同时也支持 WASM (WebAssembly) 插件。这意味着用户可以将旧有的 Nginx 脚本几乎无损地迁移到 Higress,或者使用 Go/C++/Rust 编写更安全、高性能的 WASM 插件。
  4. 标准化:完全支持 Kubernetes Ingress API 和 Gateway API,符合云原生标准。

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

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

A: 是的,Higress 对迁移非常友好,这也是其设计重点之一。

  1. 配置迁移:Higress 提供了工具和兼容层,能够解析 Nginx 的配置语法。对于使用 Nginx Ingress Controller 的用户,Higress 可以直接读取 Kubernetes 的 Ingress 资源。
  2. 脚本迁移:对于使用 Lua 脚本进行扩展的用户,Higress 内置了 Lua 虚拟机支持,大部分 OpenResty 的 Lua 脚本可以直接在 Higress 中运行,无需重写。
  3. 平滑过渡:Higress 支持作为 Ingress Class 运行,可以与现有的 Ingress Controller 在集群中共存,通过调整 Ingress Class 逐步将流量切换到 Higress,从而实现灰度迁移。

4: Higress 如何处理流量管理和安全防护?

4: Higress 如何处理流量管理和安全防护?

A: Higress 提供了企业级的流量管理和安全特性:

  1. 流量管理:支持金丝雀发布、蓝绿部署、A/B 测试以及基于 Header、Cookie、权重等高级路由规则。
  2. 安全防护:内置了针对常见 Web 攻击的防护能力,支持 IP 黑白名单、请求限流(并发限流、请求限流)、JWT 认证验证以及 Keyless 认证集成。
  3. WAF 模块:虽然核心是网关,但它可以通过插件形式集成 WAF 功能,或者与阿里云 WAF 等安全产品联动,提供深度防御。

5: Higress 支持哪些类型的插件?如何扩展功能?

5: Higress 支持哪些类型的插件?如何扩展功能?

A: Higress 拥有非常灵活的插件体系:

  1. 原生插件:内置了大量的开箱即用插件,如请求重写、重定向、认证鉴权、限流熔断等。
  2. Lua 插件:完全兼容 OpenResty 的 Lua 生态,用户可以直接编写 Lua 脚本来处理请求。
  3. WASM 插件:这是 Higress 推荐的现代扩展方式。由于支持 WASM,开发者可以使用 Go、C++、Rust 或 AssemblyScript 等多种语言编写插件。WASM 插件具有沙箱隔离特性,即使插件崩溃也不会导致网关进程崩溃,且支持热加载,无需重启网关即可更新插件逻辑。
  4. 插件市场:Higress 社区维护了一个插件市场,用户可以一键安装社区贡献的常用插件。

6: Higress 的性能表现如何?是否支持高可用部署?

6: Higress 的性能表现如何?是否支持高可用部署?

A: Higress 专为高性能和高可用场景设计。

  1. 性能表现:底层基于 Envoy,处理长连接和短连接的能力极强。在单核性能上,能够处理数万 QPS,且延迟保持在毫秒级。
  2. 高可用部署:作为云原生应用,Higress 无状态设计,支持在 Kubernetes 中通过 Deployment 进行多副本部署。结合 Kubernetes 的 Service 和健康检查机制,可以实现故障自动摘除和自动扩缩容。
  3. 热更新:配置变更和插件更新通过配置中心(如 N

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: Higress 基于 Envoy 构建,但为了适应云原生环境,它对 Envoy 做了哪些架构上的核心改变?请列举两点主要区别。

提示**: 思考 Higress 如何处理配置管理(是否使用静态文件还是动态服务)以及它如何与阿里云的生态(如 K8s Ingress Controller)进行集成。


实践建议

实践建议

基于 Higress 的定位及其在生产环境中的应用,以下是针对实际场景的 6 条实践建议:

1. 利用 wasmPlugin 实现 Token 计费与审计

场景: 对接 LLM(如 OpenAI、通义千问)时,需要根据 Token 消耗量进行计费或内部结算。 建议: 避免在业务代码中处理 Token 统计,防止逻辑分散。建议使用 Wasm 插件(如 Higress 社区的 llm-token 插件),在网关层拦截响应体并解析 usage 字段。 操作: 将计算出的 Token 数写入日志或动态 Header,配合日志采集系统(如 Prometheus 或 Loki)进行聚合,实现基于 Token 用量的成本统计。

2. 配置多模型路由以实现切换与灰度发布

场景: 业务需要在 GPT-3.5、GPT-4、通义千问等不同模型间切换,或进行迁移。 建议: 避免硬编码 API 地址。利用 Higress 的服务来源管理功能,将不同的 LLM 提供商注册为独立的服务。 操作: 在路由规则中使用 Header 匹配(如 x-model-provider: openai)或按权重分流(金丝雀发布),实现后端模型的切换。这有助于在某个模型 API 不稳定时,通过修改配置快速切换至备用模型。

3. 调整流式响应的超时与缓冲策略

场景: AI 对话通常使用 SSE (Server-Sent Events) 流式返回,耗时较长。 建议: 务必调整路由和全局的超时配置,避免因默认超时时间较短导致长连接中断。 注意: 如果网关开启了全 Body 缓存或修改 Body 的插件,可能会导致流式响应被缓冲,影响流式输出效果。 操作: 确保涉及 AI 请求的路由配置支持流式传输,并禁用全 Body 缓存插件,以保障首包时间(TTFB)。

4. 实施请求内容审核与安全防护

场景: 防止用户发送敏感词或 Prompt Injection,同时过滤模型输出的违规内容。 建议: 利用 Higress 的 Wasm 插件能力,在请求发送给 LLM 之前,调用内容审核 API 进行校验。 操作: 配置“敏感词拦截”插件。若审核不通过,网关直接返回 403 或自定义错误,避免无效请求消耗 LLM Token 配额。

5. 统一处理不同厂商的 API 规范差异

场景: 不同 LLM 厂商(OpenAI、通义千问、Claude)的 API 参数格式存在差异。 建议: 使用 Higress 的 body 转换插件或 Lua/Wasm 插件,在网关层进行协议标准化。 操作: 屏蔽后端差异,网关对外统一暴露 OpenAI 格式的 API。业务端只需对接一套标准,后端可替换或增加新的模型厂商,降低微服务耦合度。

6. 优化“上下文拼接”带来的性能影响

场景: AI 应用拼接大量 Prompt 或历史记录时,可能导致请求 Body 过大。 建议: 关注网关的 CPU 和内存指标。大 Body 的解析和转发会消耗 Wasm 虚拟机的计算资源。 操作: 对于超长上下文的请求,建议在网关层进行压缩(如开启 Gzip),或评估将历史上下文存储在 Redis 中,仅通过 Key 传递给后端。


引用

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



站内链接

相关文章