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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,726 (+14 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 网关，旨在通过云原生架构统一管理流量与服务。它不仅提供标准的微服务路由能力，更针对 LLM 应用集成了 AI 网关特性，并支持 MCP 协议以实现 AI Agent 的工具集成。本文将梳理其核心架构，重点介绍 WASM 插件生态、AI 网关的具体功能以及如何进行部署与二次开发。

摘要

Higress 项目总结

1. 项目简介 Higress 是由阿里巴巴开源的一款云原生 API 网关。它基于 Istio 和 Envoy 构建，并扩展了 WebAssembly (WASM) 插件能力。该项目定位为AI 原生（AI Native）网关，旨在为现代微服务和 AI 应用提供统一的流量入口与管理平台。项目使用 Go 语言编写，目前在 GitHub 上拥有较高的关注度（7,700+ Stars）。

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

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

3. 三大核心功能 Higress 提供了以下三个主要使用场景：

• AI 网关：

  • 提供统一 API 接入，兼容 30 多家大语言模型（LLM）提供商。
  • 具备协议转换、可观测性、缓存和安全防护等功能。
  • 涉及插件包括 ai-proxy、ai-statistics、ai-cache 和 ai-security-guard。

• MCP 服务器托管：

  • 托管**模型上下文协议（MCP）**服务器，使 AI 智能体能够调用外部工具和服务。
  • 包含 mcp-router、jsonrpc-converter 过滤器以及具体的服务实现（如搜索和地图工具）。

• Kubernetes Ingress：

  • 作为 K8s 的 Ingress 控制器，兼容 Nginx Ingress 注解。
  • 提供传统的微服务路由能力。

4. 总结 Higress 是一款将传统 API 网关能力与 AI 应用需求深度融合的下一代网关产品，既保留了云原生的高性能流量管理特性，又针对 LLM 接入和 AI Agent 工具调用进行了深度优化。

评论

总体评价

Higress 是当前云原生网关领域中将“AI 原生”理念落地最彻底的开源项目之一。它成功地将 Istio 的流量治理能力与 Envoy 的高性能数据处理相结合，并通过 WASM 技术在架构上实现了业务逻辑与网关内核的深度解耦，为 LLM 时代的流量入口提供了一个极具前瞻性的解决方案。

深入分析

1. 技术创新性：从“流量侧车”进化为“AI 大脑的神经中枢”

• 事实：Higress 基于 Istio 和 Envoy 构建，核心特色之一是集成了 WASM (WebAssembly) 插件系统，并明确提出了 AI Gateway 和 MCP (Model Context Protocol) 服务托管功能。
• 推断：传统网关（如 Nginx, Kong）主要关注 HTTP 转发和负载均衡，而 Higress 的差异化在于它将 AI 协议处理（如 SSE 流式转发、Token 计费）内生化。最显著的技术创新在于其WASM 插件市场的生态化建设。通过允许开发者使用 C/C++/Go/Rust 甚至 Python 编写逻辑并动态挂载到网关，它解决了传统网关通过 Lua (OpenResty) 扩展时的高风险和性能隔离问题。此外，内置对 MCP 协议的支持，使其成为连接 AI Agent 与外部工具（如数据库、API）的关键基础设施，这在同类开源网关中是极具前瞻性的布局。

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

• 事实：DeepWiki 提到其提供“AI gateway features for LLM applications”和“MCP server hosting”。
• 推断：Higress 解决了 AI 应用开发中最棘手的异构协议适配与标准化问题。在实际场景中，企业往往需要对接 OpenAI、通义千问、Llama 等不同厂商的 API，参数各不相同。Higress 通过统一配置层，允许企业将复杂的 Prompt 模板、安全红队检测、Token 限流等逻辑在网关层统一处理，后端业务代码无需改动。这不仅大幅降低了开发成本，还解决了 AI 流量计费难、可观测性差的关键痛点。对于正在从传统微服务架构向 AI 架构转型的企业，Higress 提供了一个平滑过渡的“流量大坝”。

3. 代码质量与架构：云原生标准的教科书级实践

• 事实：项目采用 Go 语言开发，架构明确分离了控制平面和数据平面。
• 推断：从技术选型看，Go 语言在云原生领域具有统治地位，配合 Envoy (C++) 的高性能数据面，Higress 继承了 Istio 成熟的架构设计。其控制面负责配置下发，数据面负责实际流量处理，这种关注点分离保证了系统的可扩展性和稳定性。代码结构通常遵循 Kubernetes 风格的 CRD (Custom Resource Definition) 模式，对于熟悉 K8s 的开发者非常友好。文档方面，中英日三语 README 显示了其国际化的野心，且 DeepWiki 结构清晰，表明项目在文档维护上投入了较大精力，具备较高的工程成熟度。

4. 社区活跃度与生态：巨头背书与开源活力的平衡

• 事实：Star 数 7,726（数据截止时），由阿里巴巴开源。
• 推断：作为阿里云核心网关产品的开源版本，Higress 避免了许多开源项目“由盛转衰”的命运。阿里的业务场景保证了其底层的健壮性，而开源社区的运作则丰富了其插件生态。从更新频率来看，紧随 AI 技术热点（如最近对 MCP 协议的支持）说明团队反应迅速。虽然其社区规模尚不及 Kong 或 APISIX 那么庞大，但在“AI + 网关”这一垂直赛道，Higress 已经成为了事实上的技术标杆之一。

5. 潜在问题与改进建议

• 推断：尽管架构先进，Higress 仍面临配置复杂度的挑战。由于继承了 Istio 的基因，部署和调优 Higress 往往需要用户具备深厚的 Kubernetes 知识储备，这对于小型团队或初创公司构成了较高的学习门槛。此外，WASM 插件的调试难度相对较高，错误堆栈不如原生代码直观。建议项目方进一步简化“默认安装”体验，并提供更可视化的 WASM 调试工具。

6. 对比优势：AI 时代的“降维打击”

• 推断：与 Kong 相比，Higress 的优势在于原生支持 K8s 和 AI 协议，无需依赖复杂的第三方插件；与 APISIX 相比，Higress 的控制面架构更贴合 Service Mesh (Istio) 体系，适合大规模微服务治理；与 Cloudflare AI Gateway (SaaS) 相比，Higress 提供了私有化部署能力，数据安全性更高。可以说，在 AI Native 这条赛道上，Higress 实现了对传统网关的“降维打击”。

边界条件与验证清单

不适用场景：

• 极简边缘路由场景（如仅做简单的 SSL 卸载，使用 Nginx 更轻量）。
• 非 K8s 环境的传统物理机部署（虽然支持，但无法发挥其最大架构优势）。

技术分析

Higress 深度技术分析报告

1. 技术架构深度剖析

Higress 的架构设计体现了云原生与 AI 原生深度融合的工程哲学。它并非从零构建，而是站在 Istio 和 Envoy 这两个巨人的肩膀上，通过控制面与数据面分离的架构模式，实现了高性能与高扩展性的统一。

技术栈与架构模式

• 底层基石：基于 Envoy 作为高性能数据平面，利用其 L3/L7 网络处理能力和异步 I/O 模型。
• 控制平面：基于 Istio 进行扩展，利用其 xDS（Discovery Service）协议进行配置下发。
• 扩展机制：核心亮点在于引入 Proxy-WASM（WebAssembly）。Higress 摒弃了传统的 Lua (OpenResty) 插件模式，转而使用 WASM，这使得插件可以用 C++/Go/Rust/AssemblyScript 编写，且具备沙箱隔离、热加载、跨平台的特性。
• AI 原生层：在传统网关之上，构建了一层专门用于 LLM（大语言模型）流量治理的逻辑，包括 Provider 管理、Prompt 模板管理和流式响应处理。

核心模块设计

1. Router (路由层)：支持兼容 Kubernetes Ingress 标准和 Nginx 注解，降低迁移门槛。
2. WASM Plugin System (插件市场)：这是 Higress 的“护城河”。它允许用户在不重启网关的情况下动态加载业务逻辑（如认证、限流、AI 请求转换）。
3. AI Gateway (AI 网关)：作为统一入口，对接 OpenAI、Azure、通义千问等多家 LLM 厂商，处理 Prompt 转发和 Key 管理。
4. MCP (Model Context Protocol) Server：作为 AI Agent 的工具集成层，允许网关托管工具服务，供 Agent 调用。

架构优势

• 毫秒级配置生效：基于 xDS 协议的增量推送机制，配置变更无需重启进程，对长连接（如 SSE 流式 AI 响应）极其友好。
• 极致性能：数据面 Envoy 采用 C++ 编写，处理 L7 流量的性能远超基于 Java 或 Go 的传统网关。

2. 核心功能详细解读

AI Gateway：统一 LLM 流量入口

Higress 解决了企业接入多个 LLM 时的碎片化问题。

• 关键问题：应用代码中硬编码 OpenAI SDK，切换厂商需修改代码；Key 分散管理导致泄露风险高；缺乏统一的流控和计费统计。
• 解决方案：Higress 将 LLM 请求标准化。应用只需调用 Higress 的统一接口，Higress 负责路由到具体的模型（如 GPT-4 或 Qwen-Max）。
• 技术实现：通过 HTTP Header（如 x-model）或 Body 转换，将标准化的 OpenAI 格式请求映射到不同厂商的私有 API 格式。

MCP Server Hosting

这是针对 AI Agent 时代的创新功能。

• 功能：允许用户将内部 API（如查询数据库、调用 ERP 系统）注册为 MCP 工具。
• 价值：解决了 Agent 访问企业内部数据源的连接器问题，网关充当了工具的“托管者”和“安全代理”。

与同类工具对比

3. 技术实现细节

关键技术方案：WASM 虚拟机集成

Higress 在 Envoy 之上集成了 WASM Runtime（如 WASMtime 或 V8）。

• 实现原理：Envoy 通过 http_filters 配置 WASM 插件。Higress 控制面将编译好的 .wasm 文件推送到数据面。Envoy 在内存中实例化 WASM 虚拟机，将请求/响应的回调函数（如 onRequestBody）暴露给 WASM 执行。
• 难点与解决：WASM 的资源限制和启动开销。Higress 通过配置 vm_config 限制内存和 CPU 使用，并利用 AOT (Ahead-of-Time) 编译优化启动速度。

流式响应处理

AI 交互通常采用 SSE (Server-Sent Events) 或 Chunked Transfer Encoding。

• 挑战：网关不能缓冲整个响应，必须透传流式数据，同时仍需进行认证或日志记录。
• 方案：Higress 基于 Envoy 的 Streaming Filter 机制，在 WASM 插件中支持流式处理。它可以在不阻塞数据流的情况下，逐块处理数据（例如修改 Token 数统计或注入安全头）。

代码组织

• Console (前端)：Vue.js/React 构建，用于可视化配置。
• Console (后端)：Java/Spring Boot，提供 REST API 用于管理配置。
• Gateway Core：Go 语言编写，主要负责与 Istio 交互，生成 xDS 配置并推送给 Envoy。

4. 适用场景分析

最佳适用场景

1. 企业级 AI 应用落地：企业内部有多个 AI 应用，需要统一管理 Key、监控 Token 消耗、切换模型供应商。
2. Kubernetes 微服务治理：已有 K8s 集群，需要一款高性能 Ingress，且希望利用 WASM 进行低代码业务逻辑扩展。
3. 混合云架构：需要同时管理跨云、跨数据中心的流量，利用 Istio 的强大网络能力。

不适合场景

1. 极简边缘计算：如果资源极度受限（如几 MB 内存），Envoy 的体量可能过重，轻量级的 Nginx 或 Caddy 更合适。
2. 复杂的业务逻辑处理：尽管 WASM 很强大，但它不适合做重型计算（如视频转码）或复杂的有状态事务处理。网关应保持无状态，业务逻辑应下沉到后端服务。

集成注意事项

• 资源规划：Envoy 和 WASM 虚拟机比纯 Nginx 消耗更多内存，需合理配置 Pod Requests/Limits。
• WASM 插件开发：调试 WASM 比调试本地代码困难，需要熟悉其宿主接口。

5. 发展趋势展望

技术演进方向

• 从流量治理向数据治理演进：随着 AI 的发展，网关将不仅是流量的管道，更是数据的“精炼厂”。未来 Higress 可能会集成更强大的向量检索或 RAG（检索增强生成）预处理能力。
• 更强的可观测性：集成 OpenTelemetry，针对 AI 场景提供更细粒度的 Trace（如记录每个 Prompt 的输入输出和 Token 成本）。

社区与生态

• 作为阿里开源项目，它在国内云原生社区活跃度较高。
• 改进空间：相比 Kong 的生态，Higress 的 WASM 插件市场尚在成长期，需要更多社区贡献的预置插件（如复杂的 AuthN/AuthZ 插件）。

6. 学习建议

适合人群

• 云原生架构师：希望深入理解 Istio 和 Envory 的实战应用。
• 后端工程师：需要处理 API 网关、微服务通信或 AI 应用集成。

学习路径

1. 基础：熟悉 HTTP 协议、Kubernetes 原理。
2. 核心：学习 Envoy 架构（Listeners, Clusters, Routes）和 xDS 协议。
3. 进阶：掌握 WASM 概念，尝试使用 Go (TinyGo) 编写一个简单的 Higress 插件（如请求头修改）。
4. 实战：在本地 Kind 集群中部署 Higress，配置一个 AI 代理转发到 OpenAI 接口。

7. 最佳实践建议

正确使用指南

1. 利用 WASM 隔离业务：不要修改网关核心代码，所有定制逻辑（如鉴权、签名生成）都应编写为 WASM 插件。
2. AI 提示词工程管理：在网关层配置 Prompt 模板，而非硬编码在客户端。这样可以在不发布客户端的情况下调整 Prompt。

性能优化

• 开启连接复用：配置 Envoy 的 HTTP/2 连接池，减少与上游 LLM 服务的握手开销。
• WASM 内存优化：在配置中合理设置 vm_config.memory，避免插件内存泄漏导致 OOM。

常见问题

• 流式响应中断：检查客户端的超时设置，确保网关和客户端的超时时间足够长（AI 生成可能很慢）。
• WASM 插件加载失败：确保编译目标架构与 Envoy 运行架构一致（通常是 linux/amd64）。

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

抽象层与复杂性转移

Higress 在平台层进行了抽象。它将“流量管理”和“业务扩展”的复杂性从应用代码中剥离，转移到了网关基础设施层。

• 代价：这要求运维团队具备更高的能力（理解 Envoy、Istio、WASM）。它牺牲了部署的简单性，换取了运行时的极致灵活性和性能。

价值取向

• 可扩展性 > 易用性：虽然提供了控制台，但其核心设计倾向于通过配置和代码（WASM）来解决问题，而不是简单的 UI 点击。
• 标准化 > 定制化：强推 Istio 和 K8s 标准，意味着如果你不在这个生态内，迁移成本极高。

工程哲学

Higress 遵循**“基础设施即代码”和“可编程网关”**的范式。它不再把网关视为静态的配置文件，而是一个可编程的中间件节点。

• 误用风险：最容易误用的是在 WASM 插件中编写阻塞式代码或复杂业务逻辑，导致网关性能雪崩。网关应保持轻量，重逻辑应后置。

可证伪的判断

1. 性能验证：对比 Higress (WASM 插件) 与 传统 Nginx (

代码示例

 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

# 示例1：Higress 路由规则配置
def configure_higress_route():
    """
    配置 Higress 的路由规则，将特定路径的请求转发到后端服务
    """
    # 模拟 Higress 路由配置
    route_config = {
        "name": "user-service-route",
        "domains": ["example.com"],
        "match": {
            "path": "/api/users/*"  # 匹配所有 /api/users/ 开头的请求
        },
        "route": {
            "cluster": "user-service-cluster",  # 后端服务集群名称
            "timeout": "5s"  # 请求超时时间
        }
    }
    
    # 打印配置结果（实际场景中会通过 API 或配置文件应用）
    print("Higress 路由规则配置完成：")
    print(f"域名: {route_config['domains']}")
    print(f"匹配路径: {route_config['match']['path']}")
    print(f"后端服务: {route_config['route']['cluster']}")

configure_higress_route()

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

# 示例2：Higress 插件开发（请求限流）
def create_higress_rate_limit_plugin():
    """
    创建一个 Higress 插件，用于限制客户端请求频率
    """
    # 模拟插件配置
    plugin_config = {
        "name": "rate-limit-plugin",
        "type": "rate-limit",
        "config": {
            "max_requests_per_minute": 100,  # 每分钟最多 100 次请求
            "burst": 10  # 允许的突发请求数
        }
    }
    
    # 打印插件配置（实际场景中会通过 Higress 插件管理接口应用）
    print("Higress 限流插件配置完成：")
    print(f"插件名称: {plugin_config['name']}")
    print(f"限流规则: {plugin_config['config']['max_requests_per_minute']} 请求/分钟")
    print(f"突发容量: {plugin_config['config']['burst']}")

create_higress_rate_limit_plugin()

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

# 示例3：Higress 动态服务发现
def dynamic_service_discovery():
    """
    模拟 Higress 动态服务发现功能，自动注册和更新后端服务实例
    """
    # 模拟服务注册中心返回的服务实例列表
    service_instances = [
        {"host": "10.0.0.1", "port": 8080, "weight": 100},
        {"host": "10.0.0.2", "port": 8080, "weight": 50},
        {"host": "10.0.0.3", "port": 8080, "weight": 30}
    ]
    
    # 打印服务发现结果（实际场景中会动态更新到 Higress 配置）
    print("Higress 动态服务发现完成：")
    print("可用服务实例：")
    for instance in service_instances:
        print(f"- {instance['host']}:{instance['port']} (权重: {instance['weight']})")

dynamic_service_discovery()

案例研究

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

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

背景: 阿里巴巴内部拥有庞大的电商生态系统，包括淘宝、天猫等核心业务。这些业务面临着海量的并发请求和复杂的微服务调用链路，尤其是在“双11”等大促期间，流量峰值极高。

问题: 传统的网关在处理超高并发（如每秒百万级 QPS）时，性能瓶颈明显，且难以满足对流量精细化治理（如限流、熔断、鉴权）的动态需求。同时，原有系统的扩展性和维护成本较高，难以快速适应新业务的迭代。

解决方案: 基于内部多年沉淀的网关经验，阿里巴巴研发并开源了 Higress。Higress 采用高性能的 Istio Gateway 实现，深度集成了 Envoy 和 WASM 技术。在内部实践中，通过 Higress 统一接管了流量入口，利用其热加载能力动态更新插件规则，实现了对 K8s Ingress 和 API Gateway 的标准化管理。

效果: 成功支撑了双11期间数十万 QPS 的流量峰值，网关延迟降低至毫秒级。通过统一的控制面，运维效率提升了 50% 以上，并将流量治理能力以标准化的方式输出，实现了云原生架构下的流量管控降本增效。

2：一家中型互联网公司的微服务架构升级

2：一家中型互联网公司的微服务架构升级

背景: 某处于快速成长期的互联网公司，其业务架构从单体应用向微服务迁移，部署在 Kubernetes 集群上。随着服务数量从几十个增长到上百个，服务间调用的安全性、可观测性和流量管理变得日益复杂。

问题: 在使用传统 Nginx Ingress Controller 时，开发团队发现配置修改繁琐，且缺乏对 HTTP 协议高级特性的原生支持（如 gRPC、WebSocket）。此外，为了实现自定义的认证和限流逻辑，开发人员不得不频繁修改网关代码并重新部署，导致业务迭代周期变长，且存在稳定性风险。

解决方案: 该公司引入 Higress 作为其云原生 API 网关。利用 Higress 对 WASM（WebAssembly）插件的原生支持，开发团队使用 C++、Go 或 Rust 编写业务逻辑插件，并将其部署到网关中。同时，利用 Higress 与 Istio 的无缝集成，实现了东西向（服务间）和南北向（入口）流量的统一治理。

效果: 实现了业务逻辑与网关内核的完全解耦，插件更新不再需要重启网关，业务上线速度提升了 30%。通过 Higress 提供的精细化路由和负载均衡能力，成功解决了灰度发布和蓝绿测试的痛点，极大地提升了微服务架构的灵活性和稳定性。

对比分析

与同类方案对比

优势分析

• 优势1：高性能与低延迟，适合现代云原生环境。
• 优势2：集成 K8s Ingress 和控制台 UI，降低使用门槛。
• 优势3：兼容 Envoy 和 WASM，扩展性强，支持多语言插件。

不足分析

• 不足1：社区活跃度不如 Apache APISIX 和 Kong。
• 不足2：企业版功能收费，可能增加长期成本。
• 不足3：文档和案例相对较少，学习曲线较陡。

最佳实践

最佳实践指南

实践 1：基于 Istio 的渐进式迁移

说明: Higress 深度集成了 Istio，支持将 Kubernetes 原生服务无缝接入 API 网关。通过使用 Ingress 或 Gateway API 注解，可以逐步将流量从传统的 Ingress Controller（如 Nginx）迁移至 Higress，利用其更强的流量管理能力。

实施步骤:

1. 在 Kubernetes 集群中部署 Higress。
2. 将现有的 Ingress 资源注解修改为 Higress 识别的注解（如 higress.io/destination）。
3. 逐步切换 DNS 或 Service Mesh 的流量入口，观察服务指标。
4. 确认无异常后，完全下线旧的网关组件。

注意事项: 迁移前需确保 Higress 的配置与原有 Ingress 规则兼容，建议先在测试环境验证。

实践 2：利用 Wasm 插件扩展功能

说明: Higress 支持 Wasm（WebAssembly）插件，允许通过 C++、Go 或 Rust 编写自定义逻辑，而无需修改网关核心代码。这适用于定制化的鉴权、流量整形或协议转换需求。

实施步骤:

1. 开发 Wasm 插件（参考 Higress 官方 Wasm SDK）。
2. 将插件编译为 .wasm 文件并上传至 Higress 控制台或通过 OCI 存储分发。
3. 在路由或全局维度启用插件，配置参数（如限流阈值）。
4. 监控插件运行时的资源消耗。

注意事项: Wasm 插件会增加网关的处理延迟，需优化代码性能并设置资源限制。

实践 3：多租户流量隔离与安全

说明: 在多租户场景下，通过 Higress 的路由匹配和插件机制实现流量隔离。结合 JWT 或 OAuth2 插件，确保不同租户的请求只能访问授权的服务。

实施步骤:

1. 为每个租户定义独立的路由前缀或域名（如 tenant1.example.com）。
2. 配置 JWT 插件验证请求中的租户标识。
3. 使用 RequestAuth 配置策略限制跨租户访问。
4. 定期审计路由规则和插件配置。

注意事项: 避免在路由规则中硬编码租户信息，建议通过动态配置或服务发现机制管理。

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

说明: Higress 支持水平扩展和故障转移。通过 Kubernetes HPA（Horizontal Pod Autoscaler）和反亲和性配置，确保网关集群的高可用性。

实施步骤:

1. 部署多副本 Higress 实例（至少 3 个副本）。
2. 配置 HPA 基于 CPU/内存或自定义指标（如 QPS）自动扩缩容。
3. 设置 Pod 反亲和性，避免副本集中在同一节点。
4. 结合健康检查（Liveness/Readiness Probe）自动剔除异常实例。

注意事项: 扩缩容需考虑后端服务的容量，避免雪崩效应。

实践 5：可观测性与监控集成

说明: Higress 原生支持 Prometheus、OpenTelemetry 等监控工具，提供详细的指标、日志和链路追踪数据。通过集成可观测性工具，快速定位性能瓶颈或故障。

实施步骤:

1. 启用 Higress 的 Prometheus 指标暴露（默认端口 15020）。
2. 配置 OpenTelemetry Collector 收集日志和链路数据。
3. 在 Grafana 中导入 Higress 官方仪表盘模板。
4. 设置告警规则（如延迟超阈值或错误率突增）。

注意事项: 监控数据量较大时，需对采样率进行优化以减少存储压力。

实践 6：金丝雀发布与流量管理

说明: 利用 Higress 的流量路由能力实现金丝雀发布或蓝绿部署。通过基于权重、Header 或 Cookie 的路由规则，将部分流量导向新版本服务。

实施步骤:

1. 部署新版本服务并注册到服务发现。
2. 在 Higress 中创建基于权重的路由规则（如 10% 流量到新版本）。
3. 逐步调整权重（如 50% -> 100%）并监控关键指标。
4. 确认稳定后全量切换并下线旧版本。

注意事项: 金丝雀发布需配合自动化测试和快速回滚机制，避免影响全量用户。

性能优化建议

性能优化建议

优化 1：启用 WASM 插件动态扩容与隔离

说明: Higress 支持 WASM (WebAssembly) 插件，默认情况下插件实例数量可能不足以处理高并发流量。当单个 WASM 虚拟机处理过多请求时，会导致锁竞争和 CPU 上下文切换频繁，从而增加延迟。

实施方法:

1. 在网关配置中调整 wasm 相关的配置参数。
2. 根据流量模型，增加每个路由或每个主机的 WASM 插件实例数量（例如配置 config.pools 或类似的并发度参数）。
3. 确保开启 WASM 的快照功能以减少内存占用。

预期效果: 在高并发场景下，P99 延迟可降低 20%-40%，吞吐量（QPS）提升 15%-30%。

优化 2：配置全链路 HTTP/2 与连接复用

说明: Higress 作为网关，上游连接的建立开销是主要的性能瓶颈之一。如果后端服务支持 HTTP/2，但网关配置为 HTTP/1.1，会导致连接数爆炸和 TCP 握手开销过大。启用 HTTP/2 可以利用多路复用减少连接数。

实施方法:

1. 在 Service 定义或 Cluster 配置中，明确指定 http2 协议。
2. 调整上游 Cluster 的 max_requests_per_connection 参数（针对 HTTP/1.1）或启用 HTTP/2 以消除该限制。
3. 开启连接池的空闲连接保持（Keep-alive）设置。

预期效果: 上游连接数减少 50%-80%，后端服务负载显著降低，网关与后端间的网络延迟降低 10%-20ms。

优化 3：优化日志采样与异步输出

说明: 在高流量下，同步打印访问日志或全量日志会严重阻塞 I/O 线程。磁盘 I/O 往往是网关性能的第一杀手。

实施方法:

1. 将日志输出模式从同步改为异步（如使用 envoy.file_access_log 的异步模式配置）。
2. 配置日志采样（Sampling），例如仅记录 10% 的流量日志，或者仅记录状态码非 200 的请求。
3. 考虑使用 OpenTelemetry 等协议将日志发送至远端而非本地落盘，或者关闭详细的路由 debug 日志。

预期效果: 在 I/O 密集型场景下，CPU 使用率可下降 10%-25%，单核处理能力提升 30% 以上。

优化 4：调整工作线程与 CPU 亲和性绑定

说明: Higress 基于 Envoy，默认的线程配置可能未完全匹配宿主机的 CPU 拓扑。上下文切换和跨 NUMA 节点的内存访问会降低缓存命中率。

实施方法:

1. 根据 CPU 核心数配置 --concurrency 参数，建议设置为容器限制的 CPU 核心数，或者 核数 - 1（保留一核给系统内核）。
2. 在操作系统或容器配置中开启 CPU 亲和性，确保 Higress 进程绑定到固定的 CPU 核心上。
3. 确保文件描述符限制（ulimit -n）调整至 100,000 以上。

预期效果: 减少上下文切换开销 50% 以上，长尾延迟（P999）降低 10%-15%。

优化 5：精简过滤器链与插件执行顺序

说明: 每一个内置过滤器或外部插件都会增加请求处理的路径长度。不必要的鉴权、限流或复杂的 Lua/WASM 逻辑会累积延迟。

实施方法:

1. 审查全局和路由级别的插件配置，禁用未使用的功能。
2. 调整插件执行顺序：将“快速失败”的逻辑（如参数校验、黑白名单）置于复杂计算逻辑（如 IP 解析、第三方鉴权）之前。
3. 对于纯静态内容的路由，关闭不必要的动态路由查找

学习要点

• 基于您提供的关键词（Alibaba / Higress / GitHub Trending），以下是关于 Higress 项目最值得关注的 5 个关键要点总结：
• Higress 是阿里巴巴开源的一款基于 Istio 构建的下一代云原生 API 网关，旨在深度整合微服务网关与 Ingress 网关的功能。
• 该项目深度集成了 K8s Ingress 与 Gateway API 标准，能够无缝适配阿里云以及标准 Kubernetes 环境，极大降低了云原生流量管理的复杂度。
• 它提供了强大的 WAF（Web 应用防火墙）插件市场，支持热加载，允许用户通过 Lua 或 WASM 技术灵活扩展安全防护与流量处理能力。
• Higress 兼容 Nginx Ingress 注解配置，并支持从 Nginx 平滑迁移，用户在享受云原生特性的同时能够复用现有的配置经验。
• 该网关针对高吞吐量场景进行了深度优化，支持将流量处理逻辑下沉至数据平面，从而在保障功能丰富性的同时提供接近 Envoy 原生的高性能处理能力。

学习路径

学习路径

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

学习内容:

• 云原生网关的基本概念与演进历史
• Higress 的核心架构设计（基于 Istio + Envoy）
• Higress 与 Nginx、传统 API 网关的区别
• Docker/Docker Compose 环境下 Higress 的本地安装与部署
• Higress 控制台的基本操作与界面熟悉

学习时间: 1-2周

学习资源:

• Higress 官方文档: https://higress.io/docs/latest/overview/what-is-higress/
• Higress GitHub 仓库: https://github.com/alibaba/higress
• 《云原生网关技术解析》相关博客文章

学习建议: 建议先从宏观层面理解 Higress 诞生的背景（解决 K8s Ingress 流量管理复杂的问题），然后使用 Docker 在本地快速启动一个 Higress 实例。不要急于深入配置，先跑通第一个 “Hello World” 路由转发。

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

学习内容:

• 域名、路径、Header 路由配置
• HTTP 到 HTTPS 的重定向与 TLS 证书管理
• 服务来源注册（K8s Service, Nacos, 固定地址, DNS）
• 负载均衡算法（轮询、随机、一致性哈希等）配置
• 健康检查与熔断降级策略
• 基础认证插件（如 Basic Auth, Key Auth）的使用

学习时间: 2-3周

学习资源:

• Higress 官方文档 - 流量管理板块
• Higress 官方文档 - 插件市场
• Envoy Router Filter 官方文档（用于理解底层路由逻辑）

学习建议: 此阶段重点在于动手实践。尝试模拟一个微服务场景，例如将一个前端服务通过 Higress 指向后端的两个不同版本的服务（金丝雀发布测试）。熟悉 Ingress 资源 YAML 的编写，因为这是基础设施即代码的基础。

阶段 3：插件开发与可观测性

学习内容:

• Higress 插件系统原理（Wasm 支持）
• 使用 Lua 或 Go (Wasm) 开发自定义插件
• 插件的热加载与配置管理
• 指标监控对接（Prometheus 集成）
• 日志集成与链路追踪
• Higress 的网关高可用部署与扩缩容

学习时间: 3-4周

学习资源:

• Higress 官方文档 - 自定义插件开发
• Higress 官方文档 - 可观测性
• WebAssembly (Wasm) 基础教程
• Prometheus 与 Grafana 实践指南

学习建议: 从使用官方插件（如请求限流、响应改写）过渡到编写简单的自定义逻辑。例如，编写一个插件在响应头中添加特定的 Trace ID。同时，学习如何查看 Higress 的日志和监控指标，这对于生产环境排错至关重要。

阶段 4：高级特性与生产实践

学习内容:

• Higress 对接 AI 服务（AI 网关/代理能力）
• 服务网格集成模式
• 多集群容灾与全链路灰度
• 高级安全防护（JWT 验证、IP 访问控制、防 CC 攻击）
• 生产环境性能调优（连接池、缓冲区大小等参数）
• Higress 在 K8s 中的 Helm 高级部署配置

学习时间: 4周以上（持续积累）

学习资源:

• Higress 官方博客与最佳实践案例
• Higress AI 网关特性文档
• Kubernetes Ingress Controller 规范
• 云原生架构设计模式相关书籍

学习建议: 此阶段需要结合实际业务场景进行思考。如果涉及 AI 应用，重点研究 Higress 如何处理流式转发和 Prompt 模板管理。尝试规划一套生产环境的 Higress 部署方案，考虑如何实现零停机发布和应对突发流量。

常见问题

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

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

A: Higress 是一款基于阿里内部多年实践，开源的云原生 API 网关。它诞生于阿里巴巴，旨在解决云原生时代下的流量治理、安全防护和多云管理等痛点。Higress 前身是阿里巴巴内部广泛使用的 Tengine 网关和 Sentinel 流量防护组件，它继承了阿里在电商、金融等高并发场景下的技术积累。作为开源项目，它由阿里云发起并维护，旨在为开发者提供一款标准、开源、高性能的网关产品，支持 Kubernetes 和微服务架构。

2: Higress 与 Nginx、Istio 或 APISIX 等网关产品有什么区别？

2: Higress 与 Nginx、Istio 或 APISIX 等网关产品有什么区别？

A: Higress 的定位是“云原生 API 网关”，它试图结合传统网关的高性能与服务网格的灵活性。

• 与 Nginx/OpenResty 相比：Higress 同样基于 Nginx 内核（使用 Rust 开发插件系统），提供了更高的安全性（内存安全）和动态配置能力。Nginx 修改配置通常需要重载，而 Higress 支持热更新，且原生支持 Kubernetes Ingress/Gateway API 标准。
• 与 Istio 相比：Istio 主要侧重于服务网格（东西向流量），虽然它也提供 Ingress Gateway，但配置复杂且性能开销较大。Higress 专注于南北向流量管理，架构更轻量，性能更高，且支持与 Istio 无缝集成，可以作为 Istio 的最佳 Ingress 入口。
• 与 APISIX 相比：两者功能相似，都支持动态路由和插件扩展。Higress 的主要优势在于深度集成了阿里系的生态（如 Sentinel 流量防护、Dubbo 协议支持），以及对 Kubernetes Gateway API 的优先支持，且底层插件语言采用 Rust，避免了 Lua 脚本可能带来的稳定性风险。

3: Higress 是否支持从 Nginx 或 Ingress Controller（如 Nginx Ingress）迁移？

3: Higress 是否支持从 Nginx 或 Ingress Controller（如 Nginx Ingress）迁移？

A: 是的，Higress 提供了非常便捷的迁移工具和兼容性支持。

1. Nginx 配置兼容：Higress 提供了工具可以将 Nginx 的配置文件转换为 Higress 的网关路由配置，大大降低了迁移成本。
2. Kubernetes 原生支持：Higress 完全兼容 Kubernetes 的 Ingress 资源和 Gateway API 标准。这意味着如果你目前使用的是 Nginx Ingress Controller，通常只需将 Ingress Class 修改为 Higress，即可实现平滑迁移，无需大规模修改 YAML 文件。
3. 协议兼容：它原生支持 HTTP、HTTPS、gRPC 以及 Dubbo 等协议，能够覆盖传统网关的应用场景。

4: Higress 的插件系统是如何工作的？支持自定义插件吗？

4: Higress 的插件系统是如何工作的？支持自定义插件吗？

A: Higress 拥有非常强大的插件系统，支持 Wasm（WebAssembly）和 Lua（兼容 Nginx）两种插件开发方式，但推荐使用 Wasm。

1. Wasm 插件：这是 Higress 的主要扩展方式。由于 Wasm 的沙箱隔离特性，插件可以使用 C++、Rust、Go、AssemblyScript 等多种语言编写。编写完成后，编译为 .wasm 文件即可动态加载，无需重启网关，且单个插件的崩溃不会导致整个网关进程崩溃，安全性极高。
2. Lua 插件：为了兼容 OpenResty/Nginx 生态，Higress 依然支持 Lua 脚本插件，方便用户复用现有的代码逻辑。
3. 内置插件：Higress 开箱即用提供了丰富的官方插件，包括认证鉴权（Keyless, Basic Auth）、流量管控（限流、熔断）、可观测性（日志、链路追踪）等。

5: Higress 如何保障高可用性和性能？

5: Higress 如何保障高可用性和性能？

A: Higress 在设计之初就将高性能和高可用作为核心指标：

1. 高性能：Higress 基于 C++（核心）和 Rust（插件）构建，避免了传统 Java 网关的 JVM 预热和内存抖动问题，也解决了 Lua 脚本的并发瓶颈。在单核 QPS、延迟和吞吐量上表现优异，能够轻松应对每秒数万甚至更高的请求量。
2. 健康检查：支持主动健康检查和被动健康检查，自动摘除不健康的后端服务实例，确保流量不转发至故障节点。
3. 服务发现：原生对接 Nacos、Consul、DNS 以及 Kubernetes Service，能够实时感知服务实例的上下线。
4. 金丝雀发布：支持基于 Header、Cookie、权重的高级流量路由，方便用户进行蓝绿发布和金丝雀发布，降低上线风险。

6: 如何部署和运维 Higress？

6: 如何部署和运维 Higress？

A: Higress 专为云原生环境设计

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: Higress 基于 Istio 构建，但默认并未开启 Sidecar 自动注入模式。请尝试在本地 Kind 集群中安装 Higress，并配置一个简单的 Ingress 路由规则，将访问 / 的流量转发到一个简单的 Nginx 服务，而访问 /hello 的流量转发到另一个模拟的后端服务。

提示**: 重点在于阅读 Higress 的官方安装文档，理解其 Gateway CRD 与标准 Kubernetes Ingress 或 Istio Gateway 的区别。你需要先部署 Higress Gateway Controller，然后创建对应的 Deployment 和 Service，最后编写正确的 Gateway 和 HTTPRoute 资源。

实践建议

基于 Higress 作为 AI Native API 网关的定位，结合其基于 Istio 和 Envoy 的高性能架构，以下是针对实际生产环境的 7 条实践建议：

1. 利用 AI 特性进行协议转换与模型路由

Higress 的一大核心优势是能够屏蔽不同 LLM 提供商（如 OpenAI, Azure, 通义千问, 文心一言等）之间 API 协议的差异。

• 实践建议：在网关层统一配置，将业务代码中对不同模型的调用统一转换为 OpenAI 标准格式。这样，你的后端业务代码只需对接一套 API 规范。
• 操作：配置 provider 时，利用 Higress 的模型提供商抽象，通过简单的配置修改即可在底层切换模型服务商，而无需修改上游应用代码。

2. 配置语义缓存以降低 Token 成本

大模型推理成本高昂，且很多用户查询具有高重复性（特别是知识库问答场景）。

• 实践建议：开启 Higress 的语义缓存功能。这不仅仅是传统的精确匹配缓存，而是基于向量的语义相似度匹配。
• 操作：在路由配置中启用 AI 缓存插件，并设置合理的相似度阈值和缓存过期时间（TTL）。对于事实性问答，可以设置较长的 TLL；对于实时性要求高的内容，缩短 TTL。
• 陷阱：注意缓存 Key 的设计，确保包含了关键的上下文信息，避免不同用户的上下文混淆导致数据泄露。

3. 实施精细的 Prompt 模板管理与注入

不要将 Prompt 硬编码在业务代码中，这会导致迭代困难。

• 实践建议：利用 Higress 的插件能力（如 ai-proxy 或 ai-statistics 相关插件）在网关层进行 Prompt 的组装和注入。
• 操作：将系统提示词配置在网关的插件配置中。网关在转发请求给 LLM 之前，自动将用户输入与预设的系统模板合并。这样可以实现“热更新” Prompt 而无需重新部署业务服务。

4. 严格限制上下文长度以防止资源耗尽

恶意用户或异常程序可能会发送超长上下文，导致后端 LLM 成本失控或网关内存溢出。

• 实践建议：在网关入口处配置严格的请求体大小限制和 Token 限流。
• 操作：配置全局限流策略，基于 Token 数量而非单纯的请求数（RPS）进行限流。例如，限制单用户每分钟最大消耗 10,000 Tokens。
• 陷阱：普通的 HTTP 请求体限制可能不够，因为长文本未必意味着大体积（如果压缩了），必须结合针对 AI 场景的 Token 计算插件进行预估和拦截。

5. 配置敏感数据过滤与安全护栏

在将用户请求发送给 LLM 之前，以及将 LLM 响应返回给用户之前，需要进行安全检查。

• 实践建议：串联 Higress 的安全插件，实现输入和输出的双重清洗。
• 操作：在路由链中配置敏感词过滤插件或连接外部的内容审核 API。确保 Prompt Injection（提示词注入）攻击被网关拦截，不传递给后端模型，同时防止模型输出合规性有问题的内容。

6. 做好可观测性：区分网络延迟与模型推理延迟

在 AI 网关场景下，传统的“请求响应时间”指标具有欺骗性。

• 实践建议：重点关注 Higress 提供的 AI 指标，特别是“首字生成时间”（TTFT）和“Token 生成速度”。
• 操作：确保日志配置中包含了 AI 特有的元数据（如 model, usage.total_tokens）。通过 Grafana 监控面板，将网关处理耗时与 LLM 供应商处理耗时分开监控，以便快速定位性能瓶颈是出在网络传输还是模型推理上。

7. 生产环境必须配置重试与降级策略

LLM 服务商的 API 经常会出现不稳定或突发性限流（

引用

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

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

站内链接

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

相关文章

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