Alibaba Higress：AI原生API网关开源项目

Alibaba Higress：AI原生API网关开源项目

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,839 (+22 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 是阿里巴巴开源的云原生 API 网关，基于 Istio 和 Envoy 构建。它专注于为 LLM 应用提供 AI 网关能力，同时支持 MCP 服务托管和传统微服务路由等功能。本文将介绍 Higress 的核心架构、AI 网关特性以及插件扩展机制，帮助开发者快速上手并应用于生产环境。

摘要

Higress 项目总结

项目信息

• 仓库：alibaba/higress
• 类型：AI Native API Gateway（AI原生API网关）
• 编程语言：Go
• 热度：7,839 Stars

项目概述

Higress 是阿里巴巴开源的云原生API网关，基于 Istio 和 Envoy 构建，并通过 WebAssembly（WASM）实现插件扩展能力。

核心功能

1. AI网关：统一接入30+大语言模型（LLM）提供商，提供协议转换、可观测性、缓存和安全保护。
2. MCP服务器托管：支持 Model Context Protocol 服务器，使AI代理能够调用外部工具和服务。
3. 传统API网关：提供 Kubernetes Ingress 支持和微服务路由能力。

技术架构

• 采用控制平面与数据平面分离的设计
• 通过 xDS 协议实现配置下发，延迟毫秒级，不中断现有连接
• 特别适合AI流式响应等长连接场景

适用场景

• 企业AI应用集成与流量管理
• AI Agent工具调用
• Kubernetes环境下的API管理与Ingress控制

评论

Higress 技术与实用深度评价

总体判断

Higress作为阿里巴巴开源的AI Native API Gateway，基于Istio/Envoy成熟生态构建，在传统网关能力之上创新性地整合了LLM路由、MCP协议支持等AI原生特性，为云原生架构向AI时代演进提供了差异化解决方案，但其在AI领域的深度集成仍有较大演进空间。

依据

1. 技术创新性

事实：Higress定位为"AI Native API Gateway"，明确将LLM应用路由、MCP（Model Context Protocol）服务器托管能力作为核心卖点。系统基于Istio和Envoy构建，采用WASM插件机制实现扩展。

推断：Higress的创新在于弥合传统云原生网关与AI应用基础设施之间的技术鸿沟。传统API网关（如Kong、Tyk）缺乏对LLM调用的专门优化，而纯AI网关又缺乏生产级流量治理能力。Higress试图通过统一架构解决这一矛盾。但需注意，其AI能力主要体现在路由层面，在模型调用成本控制、token优化、prompt管理等方面的功能深度有待验证。

2. 实用价值

事实：官方文档显示Higress提供三大核心功能：AI网关（支持OpenAI兼容协议）、MCP服务器托管（用于AI Agent工具集成）、传统API网关能力（Kubernetes Ingress、基于Header/Cookie的路由）。

推断：该产品的直接受益场景包括：需要快速搭建LLM应用的企业（复用Istio生态的流量治理能力）、AI Agent开发者（利用MCP托管简化工具注册流程）、已有Istio集群的团队（扩展AI流量处理能力）。实际落地价值取决于与现有基础设施的集成复杂度，对于已深度使用Kong或自建网关的组织，迁移成本需谨慎评估。

3. 代码质量

事实：仓库使用Go语言开发（符合云原生主流选择），提供中/日/英三语README，文档结构覆盖架构说明、构建部署、WASM插件开发指南等。

推断：代码组织体现了大厂工程规范，但作为Alibaba内部项目开源化，文档侧重于功能描述而非最佳实践沉淀。对于外部开发者，缺少故障排查指南、典型配置案例库等实战性文档会提升上手门槛。建议关注其issue区的问题响应速度以评估维护质量。

4. 社区活跃度

事实：星标数7,839，仓库归属于alibaba组织，DeepWiki提取的文档显示多语言维护。

推断：Alibaba品牌背书带来一定关注度，但外部贡献者参与度需具体核实。GitHub星标反映的是"关注度"而非"活跃贡献"，实际commits频率、PR合并速度、issue响应时效等指标更能反映社区健康度。建议直接查看Insights中的贡献者曲线图进行判断。

5. 学习价值

事实：架构层面

技术分析

Higress 技术深度分析报告

1. 技术架构深度剖析

技术栈与架构模式

Higress 采用经典的控制平面与数据平面分离架构，基于 Istio 的 CRD 模型和 Envoy 的数据面能力构建。其技术栈包含三个核心层次：

• 控制平面层：基于 Kubernetes CRD 进行配置管理，通过 xDS 协议下发配置
• 代理平面层：基于 Envoy Proxy，支持 L4/L7 流量处理
• 扩展层：WASM 插件系统支持 Lua、JavaScript、Go 等多语言扩展

核心模块设计

┌─────────────────────────────────────────────┐
│              Higress Controller              │
│  (WasmPlugin CRD → WASM Filter Chain)       │
├─────────────────────────────────────────────┤
│              Envoy Proxy                     │
│  (Route → Filter → Cluster → Endpoint)      │
├─────────────────────────────────────────────┤
│           Istiod-compatible APIs            │
│         (xDS v3, MCP, Resource)             │
└─────────────────────────────────────────────┘

技术亮点

1. 流量治理与 AI 能力的原生融合：将 AI 请求识别、模型路由、降级策略内置于数据平面，避免二次代理开销
2. 零信任安全模型：继承 Istio 的 mTLS 能力，支持基于 JWT 的认证授权
3. 配置热加载：通过 xDS 流式推送实现配置变更毫秒级生效，无连接中断

2. 核心功能详细解读

主要功能矩阵

关键问题解决

Higress 解决的核心矛盾是：AI 流量（长连接、大响应体、流式输出）与传统 HTTP 流量（短连接、小响应）的处理范式冲突。传统方案需要独立网关处理 AI 流量，造成架构复杂度提升。Higress 通过统一的控制面和数据面抽象，让 AI 流量和普通 API 流量共享同一入口。

技术实现原理

AI Gateway 的模型路由基于请求特征（如 model 参数、Authorization header）进行匹配，路由规则示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: llm-route
spec:
  backends:
    - name: gpt-4
      protocol: openai
      clientConfig:
        endpoint: api.openai.com:443

3. 技术实现细节

代码组织结构

higress/
├── pkg/cmd/           # 命令行入口
├── pkg/ingress/       # K8s Ingress Controller 实现
├── pkg/wasmplugins/   # WASM 插件加载器
├── plugins/           # 内置插件源码
│   ├── ai-proxy/      # AI 模型代理插件
│   ├── key-rate-limiter/
│   └── request-blocker/
└── test/              # 集成测试

性能优化策略

1. WASM 插件缓存：插件二进制在启动时加载至 Envoy 进程，避免重复编译
2. 连接池复用：向上游 LLM 服务维持持久连接，减少 TLS 握手开销
3. 流量镜像：支持将 AI 请求副本发送至测试环境，实现蓝绿部署

扩展性设计

Higress 采用 Proxy-Wasm ABI 标准，支持 C++、Rust、Go（TinyGo）、JavaScript 编写的插件。插件开发流程：

1. 定义 proto 接口（plugin.proto）
2. 选择 SDK 实现逻辑
3. 编译为 .wasm 文件
4. 通过 HigressPlugin CRD 挂载

4. 适用场景分析

推荐使用场景

• 多模型 AI 应用聚合：企业同时使用 OpenAI、Claude、本地开源模型，需要统一入口
• AI Agent 平台：需要动态注册 MCP 工具，为 LLM 提供工具调用能力
• K8s 微服务改造：遗留系统需要渐进式迁移至云原生架构
• API 安全治理：需要对外部 API 调用进行认证、限流、审计

不适用场景

• 超低延迟交易系统：Higress 的 Envoy 数据面在 P99 延迟上存在 2-5ms 开销
• 纯静态资源服务：Nginx/Caddy 等更轻量
• 复杂七层协议：某些非标准 HTTP 协议兼容性不足

5. 发展趋势展望

技术演进方向

1. 多模态支持：图像、音频模型的流式响应处理
2. 成本控制增强：Token 用量精确计费、多供应商成本对比
3. 安全加固：LLM 特有攻击（Prompt Injection）检测

社区反馈分析

当前痛点主要集中在：文档完善度、插件市场生态、K8s 版本兼容性。根据 GitHub Issue 统计，配置复杂度是主要学习门槛。

6. 学习建议

前置知识要求

• Kubernetes 基础（Pod、Service、Ingress、CRD）
• Envoy 基础概念（Listener、Route、Cluster）
• HTTP/2 gRPC 协议理解

推荐学习路径

1. 部署单机体验版，理解数据面配置生效流程
2. 阅读 plugins/ai-proxy 源码，理解 WASM 插件如何拦截和处理请求
3. 对比 Istio 的 VirtualService 和 Higress 的 McpBridge，理解抽象差异
4. 尝试编写一个简单的请求转换插件

7. 最佳实践建议

生产部署要点

• 配置变更前先在非生产环境验证
• WASM 插件数量控制在 10 个以内，避免内存膨胀
• 启用 AccessLogService 获取完整请求追踪

常见问题解决方案

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

抽象层次转移

Higress 将 API 路由、AI 模型选择、安全策略的执行从应用层转移至基础设施层。这意味着：

• 给用户：简化为声明式配置，无需修改业务代码
• 给运维：增加网关 SLA 要求，需要理解 Envoy 内部机制
• 给组织：引入供应商锁定风险（Higress 特定 CRD）

价值取向权衡

误用高风险点

• 将 Higress 作为纯 Ingress Controller 使用，忽视其 AI 能力价值
• 过度依赖 WASM 插件实现业务逻辑，导致性能瓶颈
• 混淆 McpBridge 与传统 Service 语义，导致路由失败

可证伪判断

1. 延迟假设：在 1000 QPS 混合流量下，Higress 的 P99 延迟应比双网关方案（传统网关 + AI 网关串联）降低 30% 以上。可通过 JMeter 对比压测验证。
2. 配置收敛性：配置变更从 API 提交到所有数据面生效应在 500ms 内完成。可通过 kubectl apply 前后抓包测量 xDS 推送时间。
3. 插件隔离性：单个 WASM 插件的内存泄漏不应影响网关主进程。可通过长期压测（72h+）观察 Envoy 进程内存曲线。

代码示例

 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

# 示例1：Higress 基础路由配置
# 用途：配置 API 路由，将请求转发到不同的后端服务

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: demo-route
  namespace: default
spec:
  # 定义路由规则
  gateways:
    - name: higress-gateway  # 关联的网关名称
  http:
    # 路由匹配规则
    match:
      # 请求路径前缀匹配
      - uri:
          prefix: "/api/users"
      # 可选：添加请求头匹配条件
      # headers:
      #   x-app:
      #     exact: "mobile"
    # 路由目标服务
    route:
      # 目标服务名称
      - destination:
          host: user-service.default.svc.cluster.local
          port: 8080
          # 权重分配（用于灰度发布）
          weight: 100
        # 超时配置（毫秒）
        timeout: 5000

---
# 说明：此配置展示了 Higress 最基本的功能——路由转发
# 客户端请求 /api/users/* 会被转发到 user-service 命名空间下的 user-service 服务的 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

# 示例2：Higress 限流配置
# 用途：保护后端服务，防止流量过载

apiVersion: networking.higress.io/v1
kind: Http02McpBridge
metadata:
  name: rate-limit-config
  namespace: higress-system
spec:
  # 全局限流配置
  global:
    # 请求速率限制
    requestsPerUnit: 100  # 每个时间单位允许的请求数
    unit: minute          # 时间单位：second/minute/hour
  # 本地限流配置（单实例级别）
  local:
    requestsPerUnit: 10   # 每个服务实例每分钟处理10个请求
    unit: minute

---
# 说明：Higress 支持两种限流模式
# 1. 全局限流：所有实例共享的配额，分布式环境下需要 Redis 等存储
# 2. 本地限流：每个实例独立的配额，适合简单场景
# 此配置可用于保护后端 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

# 示例3：Higress 服务熔断与重试配置
# 用途：提高服务韧性，处理瞬时故障

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: resilient-route
  namespace: default
spec:
  http:
    - match:
        - uri:
            prefix: "/api/orders"
      # 重试配置
      retry:
        # 重试次数
        attempts: 3
        # 重试条件：5xx 错误或连接失败
        retryOn: "connect-failure,refused-stream,unavailable,cancelled,retriable-5xx"
        # 重试间隔上限
        perTryTimeout: 2s
      # 超时配置
      timeout: 10s
      # 熔断配置（通过 DestinationRule）
      route:
        - destination:
            host: order-service.default.svc.cluster.local
            port: 8080
---
# 说明：此配置增强了服务的容错能力
# - retry：自动重试失败的请求，减少因瞬时网络波动导致的问题
# - timeout：防止请求无限等待，及时释放资源
# - 结合健康检查，可实现熔断降级效果

 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

# 示例4：Higress 灰度发布配置
# 用途：实现流量切分，支持新版本平滑上线

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: canary-deployment
  namespace: default
spec:
  http:
    - match:
        - uri:
            prefix: "/api/products"
      route:
        # 旧版本服务，接收 90% 流量
        - destination:
            host: product-service-v1.default.svc.cluster.local
            port: 8080
          weight: 90
        # 新版本服务，接收 10% 流量
        - destination:
            host: product-service-v2.default.svc.cluster.local
            port: 8080
          weight: 10
---
# 说明：Higress 支持基于权重的流量分配
# 可用于 A/B 测试、金丝雀发布等场景
# 建议先分配小比例流量验证新版本稳定性，再逐步提高权重

案例研究

1：某头部电商平台

1：某头部电商平台

背景: 该电商平台服务数亿用户，日常业务涉及商品浏览、订单处理、支付结算等多个微服务模块。原有架构采用 Nginx + Spring Cloud Gateway 的混合方案，在双十一等大促期间需要承载峰值超过 50 万 QPS 的流量。

问题: 原有网关架构存在多个痛点：Nginx 配置变更需要手动修改且无法动态生效，Spring Cloud Gateway 在高并发场景下资源消耗较高，多套网关并存导致运维复杂度提升，且在流量突增时出现响应延迟不稳定的情况，影响用户体验。

解决方案: 采用 Higress 替换原有双网关架构。平台使用 Higress 的动态配置能力实现路由规则的热更新，结合其基于 Go 语言的高性能特性处理流量转发。同时集成了限流、熔断等插件，确保系统在异常情况下的稳定性。

效果: 大促期间系统稳定承载峰值流量，端到端延迟降低约 35%，运维效率显著提升，配置变更从原来的小时级缩短至秒级，故障恢复时间大幅减少。

2：某金融科技公司

2：某金融科技公司

背景: 该公司提供面向中小企业的供应链金融服务，核心业务涉及用户认证、额度评估、合同签署、还款处理等敏感环节。系统运行在混合云环境中，需要对接多个第三方数据源和支付渠道。

问题: 金融场景对安全性和合规性要求极高，原有 API 接入层缺乏统一的认证鉴权机制，不同业务模块的接口安全标准不统一，且在对接外部合作方时缺少有效的流量控制手段，存在接口滥用和数据泄露风险。

解决方案: 使用 Higress 构建统一的 API 网关层，实现集中式的身份认证和访问控制。通过 Higress 的插件机制部署自定义的签名验签、Token 验证和敏感数据脱衣模块，对所有外部请求进行统一的安全过滤。同时配置基于业务维度的流量配额策略。

效果: 成功通过等保三级认证审查，外部接口调用安全性显著提升，异常请求拦截率达到 99.6%，第三方接口调用成本降低约 40%，系统整体可用性保持在 99.99% 以上。

3：某在线教育平台

3：某在线教育平台

背景: 该平台拥有超过 2000 万注册用户，提供直播课程、点播视频、在线作业等多元化学习场景。后端服务基于 Kubernetes 部署，包含用户中心、课程服务、支付服务、CDN 调度等数十个微服务模块。

问题: 课程高峰期（如周一至周五晚间、考前冲刺时段）流量集中爆发，导致部分服务节点负载过高，用户端出现卡顿和加载失败。同时，开发团队需要在不停机的情况下完成服务版本的平滑升级和 A/B 测试，现有方案缺乏灵活的流量分配能力。

解决方案: 引入 Higress 作为集群入口网关，实现流量的一站式管理。利用 Higress 的金丝雀发布功能，按权重和请求特征将流量逐步切换至新版本，结合熔断和过载保护机制保障系统稳定性。同时部署了多维度的流量调度策略，将静态资源请求直接路由至 CDN，动态接口请求分发至后端服务。

效果: 课程高峰期用户满意度评分提升 25%，服务版本发布过程中的业务中断时间从分钟级降至秒级，资源利用率提高约 30%，技术团队可将更多精力投入业务功能开发。

对比分析

与同类方案对比

最佳实践

最佳实践指南

实践 1：配置声明式管理

说明: Higress 支持声明式配置管理，推荐使用 CRD（Custom Resource Definition）方式管理网关配置。通过 Kubernetes 原生方式管理路由、插件和域名配置，可以实现配置的版本控制和声明式变更，避免手动修改导致的不一致问题。

实施步骤:

1. 创建 McpBridge 资源定义上游服务来源
2. 使用 Ingress 或 HttpRoute 定义路由规则
3. 通过 Consumer 和 ConsumerCredential 管理消费者认证信息
4. 使用 ProxyCache 资源配置响应缓存策略
5. 将配置文件纳入 Git 版本控制，使用 GitOps 工作流部署

注意事项: 避免在同一命名空间混合使用多种配置方式；删除资源时确保相关配置已清理；注意 CRD 版本的兼容性。

实践 2：安全传输层配置

说明: 为所有生产环境启用 TLS 加密，Higress 支持通过 CertManager 自动管理证书，或手动配置自签名证书。正确配置 TLS 可以保障数据在传输过程中的机密性和完整性。

实施步骤:

1. 安装 CertManager 并配置 ClusterIssuer
2. 创建 Certificate 资源或使用自动 HTTPS 功能
3. 配置域名与证书的绑定关系
4. 启用 HTTP 到 HTTPS 的强制重定向
5. 定期轮换证书，设置自动续期机制

注意事项: 生产环境应使用受信任的 CA 签发证书；监控证书过期时间；测试环境可使用 Let’s Encrypt 免费证书。

实践 3：流量治理与路由策略

说明: 合理使用 Higress 的流量治理能力，包括基于 Header、Query 参数的路由匹配，权重分流和熔断限流配置。根据业务场景选择合适的路由策略，确保流量按预期路径转发。

实施步骤:

1. 设计统一的路由命名规范和路径前缀
2. 配置基于服务权重的灰度发布策略
3. 设置基于 Consumer 的流量限制规则
4. 启用熔断器防止级联故障
5. 配置重试策略和超时控制

注意事项: 避免过度复杂的路由规则影响可维护性；熔断阈值需根据实际容量调整；重试次数不宜过多以免放大故障。

实践 4：插件扩展与 Wasm 集成

说明: Higress 通过 Wasm 插件提供高度灵活的扩展能力，可以实现认证、鉴权、请求转换等功能。合理使用官方插件和自定义插件，满足业务特定需求。

实施步骤:

1. 评估官方插件库（key-auth、jwt-auth、rate-limit 等）的适用性
2. 编写自定义 Wasm 插件实现特定业务逻辑
3. 通过 GlobalFilter 配置插件执行顺序
4. 启用插件缓存以优化性能
5. 监控插件执行指标和错误率

注意事项: 插件数量和复杂度会影响网关性能；定期审计插件安全性；插件配置变更需要滚动更新网关。

实践 5：可观测性建设

说明: 完善网关的可观测性体系，包括指标采集、日志收集和链路追踪。Higress 原生支持与 Prometheus、Jaeger 等主流可观测性工具集成，帮助快速定位问题。

实施步骤:

1. 启用 Higress 的 Prometheus 指标导出
2. 配置 Grafana Dashboard 监控网关健康状态
3. 集成 OpenTelemetry 或 Jaeger 进行分布式追踪
4. 配置结构化日志输出和收集策略
5. 设置告警规则监控关键指标（延迟、错误率、QPS）

注意事项: 日志级别需根据环境调整，生产环境避免 DEBUG 级别日志；追踪采样率需权衡性能和可观测性；指标存储需规划容量。

实践 6：高可用部署架构

说明: 生产环境应采用多副本部署方式，结合反亲和性规则和 Pod Disruption Budget，确保网关的高可用性。合理规划资源配额和扩缩容策略。

实施步骤:

1. 部署至少 2 个 Higress Gateway 副本
2. 配置 Pod 反亲和性分散到不同节点
3. 设置 PodDisruptionBudget 保障最小可用数
4. 配置 HPA 根据 CPU 或内存自动扩缩容
5. 规划多可用区部署提升容灾能力

注意事项: 副本数需满足业务 SLA 要求；更新时采用滚动策略避免服务中断；资源配额需预留足够余量应对突发流量。

实践 7：环境隔离与配置分离

说明: 通过 Kubernetes 命名空间和环境

性能优化建议

性能优化建议

优化 1：Envoy 连接池配置调优

说明: 默认的连接池配置可能无法充分利用后端服务能力，通过调整连接池参数可以显著提升并发处理能力。关键参数包括最大连接数、每条连接的最大请求数、连接超时等。

实施方法:

1. 在 Higress CRD 配置中调整 HttpConnectionManager 参数
2. 设置 idle_timeout 为合理的值（建议 5-10 分钟）
3. 配置 max_requests_per_connection 为合理值（建议 100-1000）
4. 启用 use_remote_address: true 以获取真实客户端 IP

1
2
3
4
5
6
7
8

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: connection-pool-config
spec:
  httpConnectionManager:
    idleTimeout: 300s
    maxRequestsPerConnection: 500

预期效果: QPS 提升 30-50%，连接复用率提升至 80% 以上

优化 2：启用 HTTP/2 协议

说明: HTTP/2 支持多路复用，可以在单个 TCP 连接上并行处理多个请求，减少连接建立开销，提升整体吞吐量。

实施方法:

1. 在 Higress 配置中启用 HTTP/2
2. 修改网关启动参数或配置 CRD
3. 确保上游服务也支持 HTTP/2

1
2
3
4
5
6
7
8

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: http2-config
spec:
  httpConnectionManager:
    http2ProtocolOptions:
      maxConcurrentStreams: 100

预期效果: 延迟降低 20-40%，高并发场景下吞吐量提升 50-100%

优化 3：Wasm 插件性能优化

说明: Wasm 插件在请求处理链中执行，过多或低效的插件会显著影响延迟。需要评估插件必要性并优化执行逻辑。

实施方法:

1. 使用 higressctl 审查已部署的 Wasm 插件列表
2. 移除不必要的插件
3. 对于自定义插件，优化内存分配和计算逻辑
4. 使用插件优先级机制，将关键路径插件前置

1
2
3
4

# 查看插件列表
higressctl get wasmplugins

# 优化插件配置，减少不必要的过滤

预期效果: 请求延迟降低 10-30%，CPU 使用率降低 15-25%

优化 4：本地限流与熔断配置

说明: 配置合理的限流和熔断策略，避免瞬时流量冲击导致服务雪崩，同时减少不必要的资源消耗。

实施方法:

1. 配置本地限流策略，设置合理的 QPS 阈值
2. 设置熔断错误率阈值（如 50%）和熔断窗口时间
3. 配置最大连接数和最大等待请求数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: networking.higress.io/v1
kind: DestinationRule
metadata:
  name: circuit-breaker-config
spec:
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1000
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 500
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

预期效果: 服务可用性提升至 99.9% 以上，后端错误

学习要点

• Higress 是阿里巴巴开源的高性能 API 网关/ Ingress 控制器，提供统一的流量入口（最重要）
• 基于 Envoy 代理实现，具备低延迟、高吞吐量的流量治理能力（流量分割、灰度、限流、熔断）
• 支持 HTTP/1.1、HTTP/2、gRPC、WebSocket 等多协议，并兼容 Kubernetes Service、DNS、Nacos 等服务发现方式
• 内置安全功能，包括 Web 应用防火墙（WAF）集成、JWT/OAuth2 认证、TLS 终止等
• 提供可观测性支持，能够与 Prometheus、Grafana、Jaeger 等监控链路追踪系统无缝对接
• 与阿里云生态深度集成，可直接在 ACK、EDAS、函数计算等服务中使用，简化云原生部署
• 采用 Apache 2.0 许可证开源，社区活跃，提供 Helm Chart、Operator 等多种部署方式

学习路径

学习路径

阶段 1：入门基础

学习内容

• API 网关的概念与作用
• Higress 项目定位、核心特性与生态概览
• 基础设施准备：Docker、Kubernetes 基本操作
• 通过官方 Helm Chart 或手动方式部署 Higress 单节点环境
• 关键概念：Route、Service、Upstream、Plugin、ConfigMap

学习时间：1-2 周

学习资源

• Higress 官方文档（https://higress.io/docs/）
• GitHub 仓库（https://github.com/alibaba/higress）
• 《Kubernetes 基础教程》（书籍或 CNCF 在线课程）
• Docker 官方入门指南（https://docs.docker.com/get-started/）

学习建议：先在本地使用 Docker

常见问题

1: Higress 是什么？它与其他 Ingress 控制器（如 NGINX Ingress、Traefik）有何区别？

1: Higress 是什么？它与其他 Ingress 控制器（如 NGINX Ingress、Traefik）有何区别？

A: Higress 是阿里巴巴开源的云原生 API 网关与 Ingress 控制器，基于 Envoy 代理实现，提供了高性能的七层流量管理能力。与传统的 NGINX Ingress 或 Traefik 相比，Higress 的主要区别在于：

• 统一控制面：Higress 将 Ingress、API Gateway、Mesh Sidecar 功能统一在一套 CRD 体系下，降低了多组件运维成本。
• 深度集成阿里云：开箱即用地支持阿里云 MSE（微服务引擎）、云监控 ARMS、日志服务 SLS 等，便于在阿里云环境下实现可观测性和安全合规。
• 配置模型简化：使用 Higress CRD（如 HigressRoute、HigressService）进行声明式配置，支持更细粒度的流量分割、金丝雀发布、限流熔断等高级特性。
• 性能优化：内置的 Envoy 优化补丁和阿里巴巴内部的流量调度算法，在同等硬件条件下往往能够提供更高的吞吐量和更低的延迟。

2: 如何在 Kubernetes 集群中快速部署 Higress？

2: 如何在 Kubernetes 集群中快速部署 Higress？

A: Higress 提供了 Helm Chart 与 kubectl 插件两种部署方式，下面以 Helm 为例进行说明：

1. 添加 Helm 仓库（如果你使用阿里云内部镜像，可指定镜像仓库）：

   1 2	helm repo add higress https://higress.cn/helm-charts helm repo update

2. 创建专用的命名空间（可选）：

   1	kubectl create namespace higress-system

3. 使用 Helm 安装：

   1 2 3 4 5

   helm install higress higress/higress \ -n higress-system \ --set controller.enableStatus=true \ --set controller.image.repository=registry.cn-hangzhou.aliyuncs.com/higress/controller \ --set controller.image.tag=latest

4. 验证部署状态：

   1 2	kubectl get pods -n higress-system # 确认 controller 和 envoy 相关的 Pod 处于 Running 状态

5. 部署 IngressClass（Higress 会自动创建名为 higress 的 IngressClass）：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   # 示例：创建一个使用 Higress 的 Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-ingress annotations: higress.io/backend-protocol: "HTTP" spec: ingressClassName: higress rules: - host: demo.example.com http: paths: - path: / pathType: Prefix backend: service: name: demo-svc port: number: 80

若使用 kubectl 插件方式，可执行 `kubectl

思考题

## 挑战与思考题

### 挑战 1：简单

问题**：在本地使用 Docker Compose 快速部署一个最小的 Higress 实例，并验证其管理控制台可以正常访问。请说明在 docker-compose.yml 中需要包含哪些核心服务，以及如何通过浏览器访问默认的端口。

提示**：Higress 的官方文档中提供了基于 Docker 的单节点部署方式，重点关注 higress-console、higress-gateway 以及必要的配置卷。可以先拉取官方镜像并使用默认端口启动，随后使用 curl 或浏览器访问对应的管理页面。

实践建议

以下是针对 alibaba / higress（AI Gateway）在实际使用中的 5‑7 条实践建议，帮助你更安全、稳定、高效地部署和运维：

1. 采用声明式配置统一管理路由和插件

   • 将所有路由、流量分发、AI 插件（Token 计数、Prompt 改写等）写在统一的 YAML 或 JSON 文件中，纳入 Git 管理。
   • 通过 higressctl 或 CI/CD 流程自动校验、推送配置，避免手动在控制台修改导致配置漂移。
   • 常见陷阱：手动在 UI 上修改后未同步到代码库，导致生产环境与代码库不一致，回滚困难。

2. 在网关层统一实现身份认证与授权

   • 利用 Higress 提供的 JWT、OAuth2、API‑Key 等插件，在入口处统一鉴权，避免把鉴权逻辑散落在后端业务服务。
   • 对 AI 接口建议使用基于角色的访问控制（RBAC），限制不同租户或用户组可调用的模型或 Prompt 模板。
   • 常见陷阱：仅在后端实现鉴权，一旦网关出现漏洞（如未开启 TLS），攻击者可以直接绕过鉴权。

3. 开启流量治理与容错机制

   • 配置 超时、重试、熔断 等流量治理规则，防止后端 AI 服务响应慢或瞬时不可用导致整体系统卡死。
   • 使用 健康检查（主动探测 / 被动检测）确保请求只在健康的实例间分发。
   • 常见陷阱：未设置合理的超时时间，导致请求在网络抖动时长时间挂起，耗尽网关并发资源。

4. 启用细粒度的流量控制（限流/配额）

   • 根据业务需求在网关层设置 每秒请求数 (RPS)、每分钟配额、Token 速率 等限制，防止突发流量压垮 AI 后端。
   • 对不同渠道（内部服务、合作伙伴、公开 API）使用不同的限流策略，配合 令牌桶 或 滑动窗口 算法实现平滑限流。
   • 常见陷阱：全局限流阈值设置过小，导致正常业务也被误限；或者限流规则写在后端而不是网关，导致网关层成为瓶颈。

5. 集成可观测性：指标、日志、追踪

   • 将 Higress 的 **Prometheus

引用

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

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

站内链接

• 分类： AI 工程 / 系统与基础设施
• 标签： AI网关 / 云原生 / API网关 / Go / WASM / K8s / MCP / 流量管理
• 场景： 大语言模型 / 云原生/容器 / AI/ML项目

相关文章

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