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

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

原名: alibaba /

  higress

基本信息

• 描述: 🤖 AI 网关 | AI 原生 API 网关
• 语言: Go
• 星标: 7,600 (+9 stars today)
• 链接: https://github.com/alibaba/higress
• DeepWiki: https://deepwiki.com/alibaba/higress

DeepWiki 速览（节选）

Overview

Relevant source files

• README.md
• README_JP.md
• README_ZH.md

Purpose and Scope

This document provides a comprehensive overview of Higress, an AI Native API Gateway built on Istio and Envoy. It covers the system’s architecture, core components, and primary use cases. For detailed information about specific subsystems, refer to the Core Architecture (page 2), Build and Deployment (page 3), WASM Plugin System (page 4), AI Gateway Features (page 5), MCP System (page 6), and Development Guide (page 7) sections.

What is Higress

Higress is a cloud-native API gateway that extends Istio and Envoy with WebAssembly (WASM) plugin capabilities. The system provides three core functions: AI gateway features for LLM applications, MCP server hosting for AI agent tool integration, and traditional API gateway capabilities including Kubernetes Ingress and microservice routing.

The architecture separates control plane (configuration management) from data plane (traffic processing). Configuration changes propagate through the xDS protocol with millisecond latency and no connection disruption, making it suitable for long-connection scenarios such as AI streaming responses.

Primary Use Cases:

Production Validation:

Higress originated at Alibaba to address Tengine reload issues affecting long-connection services and insufficient gRPC/Dubbo load balancing. Within Alibaba Cloud, it supports core AI applications including Tongyi Qianwen (通义千问), Tongyi Bailian model studio, and PAI platform. The system handles hundreds of thousands of requests per second with 99.99% availability guarantees.

Sources: README.md30-52

Core Architecture

Higress implements a control plane and data plane separation derived from Istio’s architecture. The control plane watches Kubernetes resources and generates Envoy configurations distributed via xDS protocol. The data plane processes traffic through Envoy proxies extended with WASM plugins.

System Components and Binaries

Component Deployment Diagram:

Binary and Process Mapping:

Key Process Communication:

The controller and pilot run in the same pod and communicate via localhost gRPC on port 15051. The controller implements multiple Kubernetes controllers (pkg/ingress/kube/) that watch different resource types and update an in-memory cache (pkg/ingress/kube/common/cache.go). The cache state is pushed to pilot, which converts it to xDS configurations (Listener Discovery Service, Route Discovery Service, Cluster Discovery Service, Endpoint Discovery Service) and streams them to all gateway instances.

Sources: README.md32 Diagram 2 from provided architecture diagrams

Configuration Flow and Controller Architecture

Configuration Update Sequence:

Controller Registry and Responsibilities:

The controller implements the informer pattern for multiple resource types:

The central cache (pkg/ingress/kube/common/cache.go) maintains in-memory state for all Istio resources and provides atomic updates to prevent partial configuration states. Configuration changes propagate to pilot within milliseconds, significantly faster than nginx-ingress reload times (reported 10x improvement).

Sources: README.md108-116 Diagram 2 from provided architecture diagrams

Key Capabilities

AI Gateway Features

AI gateway functionality is implemented through a pipeline of WASM plugins that process requests and responses for LLM providers. The plugins support protocol translation, observability, caching, and security.

AI Plugin Pipeline:

[…truncated…]

导语

Higress 是一款基于 Istio 和 Envoy 构建的 AI 原生 API 网关，它通过 WASM 插件扩展了云原生流量管理能力。该项目旨在解决 LLM 应用接入、AI Agent 工具集成（MCP）以及微服务路由等混合场景下的流量治理与安全问题。本文将为您梳理其核心架构，并重点介绍 AI 网关特性与插件系统的具体实现。

摘要

基于您提供的 DeepWiki 节选内容，以下是对 Higress 的简洁总结：

项目概述 Higress 是阿里巴巴开源的一款云原生 AI 原生 API 网关。它基于 Istio 和 Envoy 构建，使用 Go 语言编写，通过集成 WebAssembly (WASM) 插件能力，提供了一套标准化的 API 管理、流量治理及 AI 应用集成方案。

核心架构与特性

• 架构设计：采用控制平面与数据平面分离的架构。配置变更通过 xDS 协议传播，具备毫秒级延迟和零连接中断的特性，特别适配 AI 长连接流式响应场景。
• 技术栈：原生云原生，兼容 Kubernetes Ingress，并支持 WASM 插件系统以进行灵活扩展。

三大核心功能

1. AI 网关：
   • 提供统一 API 接入 30 多家大语言模型（LLM）提供商。
   • 包含协议转换、可观测性、缓存和安全防护（Security Guard）。
2. MCP 服务器托管：
   • 托管模型上下文协议（MCP）服务器，使 AI Agent 能够调用外部工具和服务。
   • 包含 mcp-router、jsonrpc-converter 等过滤器及多种工具实现（如地图搜索等）。
3. 传统 API 网关：
   • 作为 Kubernetes Ingress 控制器运行，支持微服务路由。
   • 兼容 nginx-ingress 注解，便于用户迁移。

总结 Higress 不仅是一个传统的微服务网关，更是一个专为 AI 时代设计的入口网关，旨在解决 LLM 应用接入、Agent 工具调用以及云原生流量治理的统一需求。

评论

总体评价 Higress 是一款极具前瞻性的云原生网关，它成功地将云原生流量治理与AI原生应用网关的需求深度融合。作为阿里开源的标杆项目，它不仅继承了 Istio/Envoy 的稳定性，更通过 WASM 和对 LLM 协议的深度适配，解决了大模型时代流量管理的痛点，是目前将“传统微服务网关”与“AI 网关”结合得最落地的产品之一。

核心评价依据

1. 技术创新性：从“流量转发”进化为“模型编排”

• 事实：DeepWiki 明确指出 Higress 基于 Istio 和 Envoy 构建，并具备 “AI Gateway Features” 和 “WASM Plugin Capabilities”。
• 推断：Higress 的核心技术壁垒在于它没有重新发明轮子，而是通过扩展 Envoy 的能力来处理 AI 流量。传统的 API 网关（如 Nginx）无法理解 LLM 的语义（如 Token 计费、流式传输截断、上下文缓存），而 Higress 在数据面直接集成了对 AI 协议的处理。它利用 WASM (WebAssembly) 插件系统，允许开发者使用 C++/Go/Rust 等语言编写高性能插件，这种架构既保持了 Envoy 的高吞吐，又赋予了网关处理 AI 逻辑（如敏感词过滤、Prompt 注入）的灵活性，这是对传统网关架构的一种降维打击。

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

• 事实：文档中提到其核心功能包括 “MCP server hosting for AI agent tool integration” 和 “LLM applications” 支持。
• 推断：在当前 AI 应用开发中，开发者面临两个巨大痛点：一是如何安全地暴露模型接口（鉴权、限流），二是如何让 Agent 调用外部工具。Higress 直接内置了对 MCP (Model Context Protocol) 的支持，这意味着它不仅能做网关，还能作为 Agent 的“工具托管中心”。这使得开发者无需为 AI 应用单独搭建一套认证和工具管理系统，极大地降低了 AI 应用的落地门槛，应用场景从传统的微服务网关无缝扩展至 RAG（检索增强生成）和 Agent 编排领域。

3. 代码质量与架构：云原生控制面的教科书级实现

• 事实：仓库采用 Go 语言开发，星标数 7,600+，且明确分离了控制面与数据面。
• 推断：Higress 的架构设计非常符合云原生理念。控制面负责配置管理（兼容 K8s Ingress/Gateway API），数据面由 Envoy 处理流量。这种关注点分离使得系统具备极高的扩展性。代码层面，作为阿里系开源项目，其代码规范性极高，且 README 提供了多语言版本（中/日/英），说明其对国际化和开发者体验有较高要求。它将复杂的 Istio 配置“平民化”，通过 CRD 或控制台 UI 让用户无需精通 Envoy 配置即可上手，这是工程化成熟度高的体现。

4. 社区活跃度与生态：背靠阿里，连接 CNCF 生态

• 事实：Star 数达到 7,600+，且由阿里巴巴主导。
• 推断：在网关领域，这是一个相当高的关注度，证明了市场对其认可度。背靠阿里巴巴，意味着该项目经过了双11等超大规模流量的验证，稳定性有保障。同时，它积极拥抱 CNCF 标准（如 Gateway API），避免了厂商锁定风险。社区反馈通常集中在 AI 特性的迭代速度上，目前看来更新频率较快，紧跟 LLM 市场的变化（如支持 OpenAI 兼容接口等）。

5. 对比优势与潜在问题

• 对比优势：相比于 Kong 或 APISIX，Higress 最大的优势在于“AI 原生”。传统网关虽然也能通过插件支持 AI，但 Higress 是将 AI 能力（Token 限流、模型路由）写进了基因里。相比于 LangServe 等 Python 框架自带的网关，Higress 的性能（基于 Go/Envoy）要高出几个数量级，更适合生产环境。
• 潜在问题：引入了 Istio 和 Envoy 的复杂度。对于没有 K8s 基础或仅需要简单转发的中小团队来说，Higress 的运维心智负担较重。此外，AI 功能的快速迭代可能导致文档滞后于代码，需要用户具备一定的源码阅读能力。

边界条件与验证清单

不适用场景：

• 极简单的流量转发（如 Nginx 一行配置解决），无需引入 Higress。
• 非 K8s 环境下的传统虚拟机部署，虽然支持但无法发挥其云原生最大价值。
• 对资源消耗极度敏感的边缘计算环境（Envoy 内存占用相对较高）。

快速验证清单：

1. AI 协议兼容性测试：部署后，直接配置一个指向 OpenAI 或通义千问的路由，验证其是否支持 SSE（Server-Sent Events）流式响应的无损转发，以及 Header（如 x-api-key）的透传是否正常。
2. WASM 插件热加载：编写一个简单的 Go WASM 插件（例如修改响应头），在不重启 Higress Pod 的情况下加载插件，并观察流量是否立即

技术分析

Higress 深度技术分析报告

基于您提供的 GitHub 仓库信息（alibaba/higress）及 DeepWiki 概览，以下是对 Higress 作为“AI Native API Gateway”的深度技术分析。

1. 技术架构深度剖析

Higress 的架构设计体现了**“控制平面与数据平面分离”**的云原生设计理念，并在其上进行了针对 AI 场景的深度扩展。

• 技术栈与架构模式：

  • 底层基石：基于 Envoy 作为高性能数据平面，利用 Istio 的强大控制面能力（通过 xDS 协议进行配置分发）。
  • 扩展机制：采用 WebAssembly (WASM) 作为核心插件扩展机制。这允许开发者使用 C/C++、Go、Rust、AssemblyScript 甚至 JavaScript/TypeScript 编写逻辑，并在 Envoy 的沙箱中运行，既保证了灵活性，又避免了原生插件崩溃导致网关崩溃的风险。
  • 架构模式：典型的 Istio Gateway 模式。Higress 充当 Ingress Controller，接管 Kubernetes 集群的南北向流量，同时具备服务网格中的东西向流量管理能力。

• 核心模块：

  • Control Plane (控制面)：负责配置管理、WASM 插件的生命周期管理、证书管理以及与 Kubernetes API Server 的交互。
  • Data Plane (数据面)：基于 Envoy，负责实际的流量转发、负载均衡、WASM 插件执行以及 AI 请求的特殊处理（如 SSE 流式转发）。
  • MCP Server Hosting：这是一个针对 AI Agent 的创新模块，允许网关直接托管模型上下文协议服务，作为 AI 智能体的工具提供者。

• 技术亮点与创新点：

  • AI Native (AI 原生化)：不仅仅是支持 HTTP，而是针对 LLM（大语言模型）的协议（如 OpenAI 协议）进行了深度适配。它理解 AI 的流式响应，并能在网关层进行语义层面的处理（如敏感词过滤、Prompt 注入、结果缓存）。
  • 毫秒级配置热更新：利用 xDS 协议的增量推送机制，配置变更无需重启 Pod，且不丢连接，这对长连接场景至关重要。

• 架构优势：

  • 低延迟：数据平面 Envoy 采用 C++ 编写，配合 WASM 的近原生执行速度，极低的开销适合高并发 AI 推理请求。
  • 可移植性：WASM 插件一次编写，随处运行，不依赖特定 OS 或 CPU 架构。

2. 核心功能详细解读

Higress 的核心功能可以概括为“传统网关能力的增强”与“AI 时代的新基座”。

• 主要功能与场景：

  1. AI 网关：
     • 统一模型接入：将 OpenAI、Azure、通义千问、HuggingFace 等不同厂商的 API 统一为标准接口，前端应用无需关心模型供应商的切换。
     • Token 管理与计费：在网关层精确统计 Prompt Tokens 和 Completion Tokens，便于成本核算。
     • 流式代理：完美支持 SSE (Server-Sent Events) 流式转发，确保 AI 生成的“打字机效果”无延迟透传。
  2. MCP 服务器托管：
     • 场景：AI Agent 需要调用外部工具（如查询数据库、读取文件）。MCP (Model Context Protocol) 是一种标准。
     • 功能：Higress 可以作为 MCP Server 的宿主，将传统的 REST API 转换为 AI Agent 可调用的 MCP 工具，极大简化了 Agent 的工具链集成。
  3. 传统 API 网关：Kubernetes Ingress、金丝雀发布、负载均衡、认证鉴权。

• 解决的关键问题：

  • AI 模型的 Vendor Lock-in (厂商锁定)：通过统一接入层，企业可以在不同模型间无缝切换，甚至实现 A/B 测试。
  • AI 调用的可观测性缺失：传统网关只看 HTTP 码，Higress 能感知“模型错误”或“内容审查失败”。
  • Prompt 安全：在请求到达模型前，利用 WASM 插件进行 Prompt 注入防御或敏感信息过滤。

• 与同类工具对比：

  • vs Nginx/Kong：传统网关对 AI 的 SSE 支持需要复杂的脚本配置，且缺乏对 Token 的原生理解。Higress 天生支持。
  • vs Istio Ingress：Istio 原生 Ingress 配置极其复杂（需要 Gateway + VirtualService + DestinationRule），Higress 提供了更符合 K8s Ingress 标准的简化模型，并内置了 AI 特性。

3. 技术实现细节

• 关键方案：

  • WASM 插件系统：Higress 使用 proxy-wasm 规范。它通过 http_filter 在 Envoy 的请求处理链中插入钩子。
  • AI 流式处理：在处理 SSE 时，网关不能缓冲整个响应。Higress 的数据面必须具备 Streaming Body Processing 能力，即一边接收上游模型的流式数据块，一边推送给下游客户端，同时在此过程中允许插件对数据块进行实时修改（如替换敏感词）。

• 代码组织：

  • Go：主要用于控制平面，处理 CRD (Custom Resource Definition) 的校验、翻译以及配置下发到 Envoy。
  • C++/Rust/Go (WASM)：插件逻辑。Higress 官方提供了大量开箱即用的 WASM 插件（如 Keyless 认证、请求限流）。

• 性能优化：

  • 零拷贝：Envoy 本身的高性能特性被完整保留。
  • 连接池：针对 AI 推理服务通常建立长连接，减少握手开销。

• 技术难点：

  • 流式数据的上下文关联：在 AI 对话中，如果插件需要基于历史对话做鉴权（如：用户已用完额度），如何在流式响应中断开连接是一个难点。Higress 需要在 WASM VM 的内存中维护状态，或者通过 Redis 外部存储来管理有状态的会话。

4. 适用场景分析

• 最适合的项目：

  • 企业级 AI 应用落地：特别是需要对接多个 LLM 厂商，且对成本、安全有严格要求的场景。
  • 微服务架构的 AI 化改造：原有架构使用 K8s 和 Istio，现在需要引入 AI 功能，Higress 是最平滑的过渡方案。
  • AI Agent 开发平台：需要为 Agent 提供统一工具接口（MCP）的场景。

• 最有效的情况：

  • 当你需要对 AI 请求进行细粒度控制（如：特定 Prompt 路由到特定模型，或者对 Prompt 进行改写）时。
  • 当你需要统一保护后端模型服务，避免直接暴露公网时。

• 不适合的场景：

  • 极简个人项目：如果只是简单的 Demo，直接调用 API 更省事，引入 Higress 增加了运维复杂度。
  • 极高吞吐量的纯静态文件分发：虽然 Higress 基于 Envoy 很快，但针对静态资源缓存，专门的 CDN 或 Nginx 缓存配置可能更轻量。

• 集成方式：

  • Kubernetes Helm：标准的生产级部署方式。
  • Docker Standalone：适合开发测试。

5. 发展趋势展望

• 技术演进：

  • 从“流量转发”到“语义路由”：未来的网关将不仅根据 URL 路由，而是根据 Prompt 的意图路由（例如：数学问题路由到逻辑推理模型，创作问题路由到通用模型）。
  • 更强的可观测性：集成 LLM 专用的 Tracing 协议（如 OpenTelemetry for LLM），追踪 Token 消耗和模型推理时间。

• 社区与改进：

  • 作为阿里开源项目，国内社区活跃度高。改进空间在于 WASM 插件的生态丰富度（目前主要集中在基础功能，AI 领域的复杂插件如 RAG 检索增强网关插件仍需社区贡献）。

• 前沿结合：

  • RAG (检索增强生成) 网关化：未来可能看到 Higress 直接内置向量数据库检索能力，在请求到达 LLM 前自动挂载上下文。

6. 学习建议

• 适合开发者：

  • 具备 Kubernetes 基础的后端工程师。
  • 需要构建 AI 基础设施的架构师。
  • 对云原生网关和 Envoy 感兴趣的开发者。

• 学习路径：

  1. 基础：理解 Kubernetes Ingress 和 Service 概念。
  2. 核心：学习 Envoy 的基本概念（Listener, Route, Cluster）。
  3. 进阶：学习 WASM (WebAssembly) 基础，尝试使用 Higress 官方提供的 Go SDK 编写一个简单的 WASM 插件（如修改请求头）。
  4. 实战：部署 Higress，配置一个指向 OpenAI 的路由，并开启“Token 统计”插件。

• 实践建议：

  • 先使用官方预置插件解决通用问题，避免重复造轮子。
  • 在本地搭建 Kind (Kubernetes in Docker) 环境进行调试，避免直接在生产环境试错。

7. 最佳实践建议

• 正确使用：

  • 资源隔离：AI 流量通常持续时间长、连接占用高。建议将 AI 网关与普通业务网关分开部署，或者使用独立的 Envoy 实例组，以免长连接阻塞短连接的高并发业务。
  • 插件热加载：充分利用 WASM 插件的热更新能力，实现业务逻辑的动态变更，而不需要重启网关 Pod。

• 常见问题：

  • 超时配置：AI 推理可能很慢。务必将网关的路由超时时间设置得足够长（如 5分钟），并开启流式响应以避免客户端超时。
  • WASM 内存限制：复杂的 AI 处理逻辑（如本地向量检索）在 WASM 中可能受限于内存限制，此时应考虑将复杂逻辑下沉到外部服务（通过 gRPC/HTTP 调用），网关仅做透传和聚合。

• 性能优化：

  • 开启 HTTP/2：后端连接模型服务时，优先使用 HTTP/2 以利用多路复用。
  • **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
31
32
33

# 示例1：Higress 网关路由配置
def configure_higress_route():
    """
    配置 Higress 网关的路由规则
    解决问题：将不同路径的请求转发到不同的后端服务
    """
    # 模拟 Higress 路由配置
    route_config = {
        "apiVersion": "networking.higress.io/v1",
        "kind": "HigressRoute",
        "metadata": {
            "name": "example-route"
        },
        "spec": {
            "hosts": ["api.example.com"],  # 匹配的域名
            "rules": [
                {
                    "path": "/v1/users",  # 匹配的路径
                    "backend": "user-service:8080",  # 转发的后端服务
                    "timeout": "10s"  # 超时时间
                },
                {
                    "path": "/v1/products",
                    "backend": "product-service:8080",
                    "timeout": "15s"
                }
            ]
        }
    }
    return route_config

# 说明：这个示例展示了如何配置 Higress 网关的路由规则，
# 将不同 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
36
37
38
39

# 示例2：Higress 流量管理
def manage_higress_traffic():
    """
    实现 Higress 的流量管理功能
    解决问题：控制不同版本的流量分配（灰度发布）
    """
    # 模拟流量管理配置
    traffic_config = {
        "apiVersion": "traffic.higress.io/v1",
        "kind": "TrafficPolicy",
        "metadata": {
            "name": "canary-release"
        },
        "spec": {
            "service": "payment-service",  # 目标服务
            "versions": [
                {
                    "name": "v1",  # 稳定版本
                    "weight": 90  # 90% 流量
                },
                {
                    "name": "v2",  # 新版本
                    "weight": 10  # 10% 流量（灰度）
                }
            ],
            "matchRules": [
                {
                    "headers": {  # 基于请求头的流量路由
                        "x-canary": "true"
                    },
                    "destination": "v2"
                }
            ]
        }
    }
    return traffic_config

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

# 示例3：Higress 安全防护
def setup_higress_security():
    """
    配置 Higress 的安全防护功能
    解决问题：防止常见 Web 攻击（如 SQL 注入、XSS）
    """
    # 模拟安全配置
    security_config = {
        "apiVersion": "security.higress.io/v1",
        "kind": "SecurityPolicy",
        "metadata": {
            "name": "web-security"
        },
        "spec": {
            "waf": {  # Web 应用防火墙配置
                "enabled": True,
                "mode": "blocking",  # 拦截模式
                "rules": [
                    {
                        "type": "SQL_INJECTION",  # SQL 注入防护
                        "action": "BLOCK"
                    },
                    {
                        "type": "XSS",  # XSS 攻击防护
                        "action": "BLOCK"
                    },
                    {
                        "type": "RATE_LIMIT",  # 速率限制
                        "threshold": 100,  # 每分钟请求数
                        "action": "THROTTLE"
                    }
                ]
            },
            "jwt": {  # JWT 认证配置
                "enabled": True,
                "issuer": "auth.example.com",
                "audiences": ["api.example.com"]
            }
        }
    }
    return security_config

# 说明：这个示例展示了如何配置 Higress 的安全防护功能，
# 包括 WAF 防护、速率限制和 JWT 认证，保护 API 安全。

案例研究

1：某大型互联网公司微服务架构升级

1：某大型互联网公司微服务架构升级

背景: 该公司原有业务基于 Spring Cloud 微服务架构，随着业务规模扩张，服务数量超过 500 个，跨语言（Java/Go/Python）服务调用频繁，原有网关在性能和扩展性上遇到瓶颈。

问题:

• 传统网关在处理高并发流量（峰值 10万 QPS）时延迟显著增加
• 不同编程语言的服务需要重复实现鉴权、限流等逻辑，维护成本高
• 云原生转型过程中，需要与 Kubernetes 深度集成

解决方案:

• 部署 Higress 作为统一 API 网关
• 通过 Higress 的 WASM 插件机制实现多语言通用的流量治理
• 结合 Nacos 实现服务发现与动态配置

效果:

• 网关吞吐量提升 300%，P99 延迟降低 60%
• 流量治理规则统一管理，研发效率提升 40%
• 成功支撑双 11 期间 50万 QPS 的流量峰值

2：某电商平台多租户 SaaS 系统改造

2：某电商平台多租户 SaaS 系统改造

背景: 该平台为 200+ 企业客户提供独立电商系统，原架构中每个租户独立部署网关实例，资源利用率低且运维复杂。

问题:

• 租户间流量隔离困难，存在互相影响风险
• 新增租户需要手动配置网关，交付周期长达 3 天
• 不同租户的定制化需求（如特殊限流规则）难以灵活支持

解决方案:

• 基于 Higress 构建多租户网关集群
• 开发租户标签路由插件实现流量隔离
• 通过 Higress 的配置管理 API 实现租户自助式网关配置

效果:

• 单集群支持 200+ 租户，资源成本降低 70%
• 租户开通时间从 3 天缩短至 2 小时
• 定制化需求通过插件市场快速满足，客户满意度提升 35%

3：某金融科技公司 API 生态建设

3：某金融科技公司 API 生态建设

背景: 该公司需要开放 100+ 个金融 API 给合作伙伴，对安全性和可观测性有严格监管要求。

问题:

• 原有网关无法满足金融级安全标准（如 mTLS、细粒度权限控制）
• 缺乏完整的 API 调用审计链路
• 第三方接入流程复杂，影响合作效率

解决方案:

• 部署 Higress 并集成金融安全插件
• 启用全链路 Tracing 和访问日志审计
• 开发开发者门户与 Higress 对接，实现自助式 API 申请

效果:

• 通过金融安全认证，获得合规资质
• API 调用异常检测响应时间从小时级降至分钟级
• 合作伙伴接入效率提升 60%，API 调用量增长 200%

对比分析

与同类方案对比

优势分析

• 优势1：深度集成Kubernetes和Istio，适合云原生环境。
• 优势2：支持Wasm插件，扩展性强且性能损耗低。
• 优势3：提供免费的控制台，降低运维复杂度。

不足分析

• 不足1：相比Kong和APISIX，社区生态和第三方插件较少。
• 不足2：文档和案例可能不如成熟方案丰富。
• 不足3：对非Kubernetes环境的支持可能不如传统方案灵活。

最佳实践

最佳实践指南

实践 1：基于 WASM 实现插件化扩展

说明: Higress 基于 Istio 与 Envoy 构建，其核心优势之一在于深度集成了 WASM (WebAssembly)。通过使用 WASM 插件，用户可以使用 C++、Go、Rust 或 JavaScript 等高级语言编写自定义逻辑，而无需修改网关核心代码或重新编译镜像。这极大地提升了扩展的灵活性和安全性。

实施步骤:

1. 根据业务需求选择合适的 WASM 开发语言（推荐使用 Go 或 AssemblyScript）。
2. 利用 Higress 官方提供的 SDK 或工具链编写插件逻辑（如请求头修改、流量整形等）。
3. 将编译好的 WASM 文件上传至 Higress 控制台或通过 OCI 存储进行管理。
4. 在网关配置中，将特定路由或全局网关关联到该 WASM 插件。

注意事项:

• WASM 插件运行在沙箱中，虽然隔离性好，但频繁的内存拷贝可能会带来微小的性能损耗，需避免在高频路径中进行复杂计算。

实践 2：服务来源的统一接入与管理

说明: Higress 设计为云原生 API 网关，能够同时接管 Kubernetes 集群内服务（Service）和注册中心（如 Nacos, Consul, ZooKeeper）中的服务。最佳实践是利用 Higress 的服务来源（Service Source）管理功能，将异构基础设施的服务统一纳入网关管理，实现混合云或多集群架构下的流量统一调度。

实施步骤:

1. 在 Higress 控制台的“服务来源”页面，配置对应的注册中心（如 Nacos）连接信息。
2. 对于容器环境，确保 Higress Ingress Controller 已正确配置以自动发现 Kubernetes Services。
3. 创建 Ingress 路由时，直接引用已注册的服务名称，无需手动维护服务 IP 列表。

注意事项:

• 当使用非 K8s 注册中心时，请确保 Higress 所在网络能够直接访问注册中心节点，避免网络分区导致服务发现失败。

实践 3：利用配置即代码实现版本控制

说明: 为了避免控制台误操作和便于审计，应将 Higress 的路由、插件和证书配置视为代码进行管理。Higress 支持通过 Kubernetes CRD (Custom Resource Definition) 或 Terraform 进行配置管理。这使得配置变更可回滚、可审计，并易于集成 CI/CD 流程。

实施步骤:

1. 导出当前 Higress 的资源配置为 YAML 文件。
2. 将这些 YAML 文件存入 Git 仓库。
3. 建立流水线，通过 kubectl apply 或 Terraform 命令将仓库中的配置自动应用到 Higress 环境。
4. 配置变更必须通过 Pull Request 流程审核。

注意事项:

• 使用 CRD 模式部署时，需注意 Higress 的版本兼容性，升级前请检查 CRD 的变更日志。

实践 4：精细化流量治理与安全防护

说明: 除了基本的路由转发，应充分利用 Higress 提供的流量治理能力。这包括配置全局限流（保护后端服务）、基于 IP 或用户的访问控制（黑/白名单）以及 CORS 跨域设置。对于生产环境，建议开启 WAF（Web Application Firewall）插件以防御常见的 Web 攻击（如 SQL 注入、XSS）。

实施步骤:

1. 在“安全防护”或“插件”市场中，搜索并启用 WAF 插件。
2. 配置全局限流策略，针对关键 API 设置每秒请求数（QPS）阈值。
3. 针对内部管理接口，配置 IP 访问控制列表（ACL），仅允许特定网段访问。
4. 启用 Basic Auth 或 JWT 认证插件，对公开 API 进行鉴权。

注意事项:

• 限流配置应根据后端服务的实际容量进行压测后设定，避免配置过严导致正常流量被拒绝。

实践 5：金丝雀发布与蓝绿部署

说明: Higress 原生支持基于权重的流量路由，是实现微服务灰度发布的最佳工具。通过在网关层将特定百分比的流量路由到新版本服务，可以在不中断业务的情况下验证新版本稳定性，实现快速回滚。

实施步骤:

1. 部署新版本的服务，并在注册中心或 K8s 中将其注册为不同的服务名（如 service-v2）。
2. 在 Higress 中创建或修改对应的路由规则。
3. 配置流量分发比例，例如将 10% 的流量指向 service-v2，90% 保留在 service-v1。
4. 观察新版本的错误率和延迟，确认无误后逐步调整比例至 100%。

注意事项:

• 灰度发布过程中，务必保持后端服务的日志追踪链路（Trace ID）

性能优化建议

性能优化建议

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

说明: Higress 基于 Envoy 和 Istio 构建，原生支持 HTTP/3。HTTP/3 基于 UDP 协议，解决了 TCP 队头阻塞问题，能显著降低弱网环境下的延迟，并提升连接迁移速度。

实施方法:

1. 在 Higress 网关的监听器配置中，为 HTTPS 端口（通常为 443）启用 HTTP/3 协议。
2. 配置 UDP 端口（通常为 443）的防火墙放行策略。
3. 确保客户端（浏览器或 SDK）支持 HTTP/3。

预期效果: 在弱网环境下，首字节加载时间（TTFB）降低 30% 以上，视频流和大量数据传输场景下的卡顿率显著下降。

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

说明: 默认的超时配置通常较为保守，可能导致后端服务处理慢请求时长时间占用连接池。合理的超时与指数退避重试机制能快速释放资源，提高系统吞吐量。

实施方法:

1. 在路由或服务级别配置 perRequestTimeout，根据业务 P99 耗时设置阈值（例如 3s）。
2. 配置重试策略，设置 numRetries（建议 2-3 次）和 retryOn（如 503, 502, connect-failure）。
3. 启用指数退避算法，避免重试风暴。

预期效果: 减少无效连接占用，后端服务高负载时的响应成功率提升 15%-20%，有效防止雪崩效应。

优化 3：启用本地与分布式缓存

说明: 对于高读比率的 API（如商品详情、配置数据），在 Higress 网关层启用缓存可以大幅减少回源请求，降低后端数据库压力。

实施方法:

1. 在路由配置中启用 cache 功能，设置缓存 Key（如请求参数或 Header）和 TTL（生存时间）。
2. 对于集群部署，配置 Redis 作为分布式缓存后端，保证多副本一致性。
3. 对特定状态码（如 200）的响应进行缓存。

预期效果: 后端服务 QPS 峰值降低 40%-60%，平均响应延迟（RT）减少至毫秒级。

优化 4：启用 Wasm 插件与 CPU 亲和性

说明: Higress 支持通过 Wasm (WebAssembly) 扩展功能。将复杂的鉴权、限流或请求转换逻辑下沉到 Wasm 插件中，利用 Wasm 的高效执行特性，并配合 CPU 亲和性减少上下文切换。

实施方法:

1. 编写或使用现有的 Wasm 插件替代 Lua 脚本或外部调用。
2. 在 Higress Gateway 的 Pod 部署配置中，开启 CPU 亲和性（guaranteed QoS）。
3. 调整 Envoy 工作线程数（--concurrency）与物理核数一致。

预期效果: 插件执行延迟降低 10%-20%，网关吞吐量（QPS）提升 15%-30%。

优化 5：连接池与 Keep-Alive 优化

说明: 默认的 HTTP/1.1 连接管理效率较低。通过调整上游和下游的连接池大小以及启用 HTTP/2，可以减少 TCP 握手开销，提升并发处理能力。

实施方法:

1. 将上游协议升级为 HTTP/2 或 gRPC，复用连接。
2. 调整 upstreamConnectionPool 的大小，建议设置为 max_concurrent_streams * upstream_instance_count。
3. 启用 http2_protocol_options，并适当调大 max_concurrent_streams（默认通常为 100，可调至 256）。

预期效果: 网关与后端之间的网络延迟减少 20ms-

学习要点

• Higress 是基于阿里云内部多年实践沉淀的下一代云原生 API 网关，深度集成 Istio 与 Envoy，提供高性能的流量管理能力
• 作为开源项目，它支持将 K8s Ingress 与 Service Mesh 架构合二为一，有效降低基础设施的复杂度与运维成本
• 具备强大的安全防护功能，内置 WAF 防御规则，能有效抵御常见的 Web 攻击如 SQL 注入和 XSS
• 提供开箱即用的插件市场（Wasm 插件），支持低代码扩展网关功能，方便开发者快速集成自定义业务逻辑
• 支持对接多种后端服务，包括 Nacos、Consul 等注册中心以及固定 IP、DNS 等服务发现方式，兼容性极强
• 拥有精细化且可视化的流量治理能力，支持金丝雀发布、蓝绿发布及负载均衡策略，保障业务平滑上线
• 提供一站式的 HTTP 到 gRPC 的协议转换能力，解决了微服务架构中异构系统间的通信难题

学习路径

学习路径

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

学习内容:

• 云原生网关的基本概念与 Higress 的核心定位
• Higress 与传统网关（如 Nginx, Apache）及 Kubernetes Ingress 的区别
• Higress 的核心架构：Istio + Envoy 的结合模式
• 基础术语：路由、服务、插件、Upstream
• 在本地或 Docker 环境下快速部署 Higress

学习时间: 1-2周

学习资源:

• Higress 官方文档 (架构与简介章节)
• Higress GitHub 仓库 (README 与 Quick Start)
• Envoy 官方文档基础概念（了解数据平面基础）

学习建议: 建议先通读官方文档的“快速开始”部分，并在本地通过 Docker Compose 快速拉起一个实例。不要一开始就陷入复杂的配置，重点在于理解流量是如何通过网关进入后端服务的。

阶段 2：核心功能实战与流量管理

学习内容:

• 详细的流量路由配置：基于域名、路径、Header 的路由规则
• 负载均衡策略配置（轮询、随机、最小连接数等）
• 服务发现集成：对接 Nacos、Consul、Kubernetes Service
• 金丝雀发布与蓝绿发布配置
• 全局与域名级别的流量治理（超时、重试、限流）
• 控制台 的使用与操作

学习时间: 2-3周

学习资源:

• Higress 官方文档（流量路由、服务来源板块）
• Higress 官方示例库
• Ingress Gateway 路由规则配置语法

学习建议: 动手搭建一个包含两个服务（如 Service A 和 Service B）的后端环境，尝试配置不同的路由规则将流量按比例分发。重点练习如何将 Higress 接入注册中心（如 Nacos），这是 Higress 区别于传统网关的一大优势。

阶段 3：插件开发与安全防护

学习内容:

• Higress 插件系统的工作原理（Wasm 支持）
• 使用官方预置插件（如 Key Auth、JWT Auth、IP 限流）
• 编写自定义 Lua 或 Wasm (Go/AssemblyScript) 插件
• 网关安全配置：HTTPS 证书管理、CORS 配置、防 SQL 注入等
• 插件的热加载与配置优先级

学习时间: 3-4周

学习资源:

• Higress 官方文档（插件市场、自定义开发）
• Higress 插件示例代码
• WebAssembly (Wasm) for Proxies 教程

学习建议: 从使用一个现成的认证插件开始，理解“插件流”的执行顺序。随后，尝试编写一个简单的 Lua 插件（例如修改请求头或响应体），并尝试加载到网关中运行。如果熟悉 Go，可以尝试基于 Higress 提供的 SDK 开发 Wasm 插件。

阶段 4：高可用架构与生产级运维

学习内容:

• 在 Kubernetes 集群中部署 Higress（Helm 方式）
• Higress 的高可用部署架构与扩缩容
• 网关指标监控与日志采集（对接 Prometheus、Grafana、SkyWalking）
• 网关性能压测与调优（连接池、缓冲区大小等参数）
• 灰度发布与回滚机制在生产环境的最佳实践
• 与阿里云云原生产品的集成（如 MSE, ARMS）

学习时间: 2-3周

学习资源:

• Higess GitHub Helm Charts 部署指南
• Kubernetes 官方文档（Ingress, Service, HPA）
• Prometheus 监控最佳实践

学习建议: 此阶段重点在于“稳”。建议在 Kubernetes 测试环境中部署 Higress，使用 Helm 管理配置。学习如何查看 Access Log 和 Error Log 来定位问题。使用压测工具（如 wrk 或 JMeter）模拟高并发流量，观察 Higress 的资源消耗（CPU/内存）并根据指标进行参数调优。

阶段 5：源码剖析与深度定制

学习内容:

• Higress 项目源码结构分析
• 深入理解 Router、HttpTest 等核心模块
• Envoy 配置生成逻辑（xDS 协议在 Higress 中的应用）
• 向 Higress 开源社区贡献代码（PR 流程）
• 基于 Higress 构建自研网关产品的架构设计

学习时间: 持续学习

学习资源:

• Alibaba Higress GitHub 源码
• Istio 控制平面源码分析
• Envoy xDS 协议官方文档

学习建议: 下载源码到本地，使用 IDE（如

常见问题

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

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

A: Higress 是一个开源的、基于阿里云内部多年实践沉淀的云原生 API 网关。它深度集成了 Envoy 和 Istio，旨在解决云原生架构下的流量管理问题。

与 Nginx 相比，Higress 提供了更丰富的动态流量管理能力（如热更新配置，无需 Reload）、服务发现集成以及标准化的 WAF 插件市场。与 Kong 相比，Higress 最大的优势在于其原生支持 Istio，可以作为 Ingress Controller 或 Gateway 在 Kubernetes 集群中无缝管理南北向（入口流量）和东西向（服务间网格流量）流量，且对 WASM（WebAssembly）插件支持更加完善，性能开销更低。

2: Higress 是否支持直接从 Nginx 迁移？

2: Higress 是否支持直接从 Nginx 迁移？

A: 是的，Higress 提供了 Nginx Ingress 注解的兼容支持。虽然 Higress 的核心配置基于 Envoy，但为了降低迁移门槛，它实现了对常用 Nginx Ingress Controller 注解的兼容。这意味着在 Kubernetes 环境下，很多现有的 Nginx Ingress 配置可以直接在 Higress 上使用，或者只需少量修改。此外，Higress 社区也提供了工具和指南来帮助用户将传统的 Nginx 配置转换为 Higress 的路由规则。

3: Higress 的插件是如何工作的？支持哪些类型的插件？

3: Higress 的插件是如何工作的？支持哪些类型的插件？

A: Higress 采用灵活的插件机制来扩展网关功能，例如认证鉴权、流量限流、请求/响应修改等。

Higress 原生支持两种主要的插件类型：

1. WASM (WebAssembly) 插件：这是 Higress 推荐的主流方式。它允许开发者使用 C++, Go, Rust, JavaScript 等多种语言编写插件，编译为 WASM 格式后运行。WASM 插件具有沙箱隔离、动态加载、高性能的特点，且无需重启网关即可生效。
2. Lua/Python 插件：为了兼容旧有的 API 网关生态（如 Apache APISIX 或 OpenResty），Higress 也支持 Lua 脚本，方便用户迁移现有的逻辑。

4: Higress 能否在非 Kubernetes 环境（如虚拟机或物理机）中部署？

4: Higress 能否在非 Kubernetes 环境（如虚拟机或物理机）中部署？

A: 可以。虽然 Higress 是为云原生环境设计的，在 Kubernetes 中能发挥最大效能（如利用 Service 自动服务发现），但它也提供了标准版（Standalone）的 Docker 镜像。用户可以通过 Docker Compose 或直接运行 Docker 容器的方式，在虚拟机或物理机环境中部署 Higress，作为传统的 API 网关使用。不过，在这种模式下，服务发现通常需要配置静态上游或对接 Nacos/Consul 等注册中心。

5: Higress 和 Istio 的关系是什么？我必须安装 Istio 才能使用 Higress 吗？

5: Higress 和 Istio 的关系是什么？我必须安装 Istio 才能使用 Higress 吗？

A: Higress 的内核基于 Envoy，其控制面组件在架构上参考了 Istio 的数据面标准，因此它与 Istio 有着天然的亲和性。

• 不是必须安装 Istio：你可以单独安装 Higress 作为 Kubernetes 的 Ingress Controller 来处理集群入口流量，此时它不需要依赖完整的 Istio 控制平面。
• 结合使用：如果你已经使用了 Istio，Higress 可以作为 Istio 的东西向网关（East-West Gateway）或管理入口流量的组件，与 Istio 的控制平面协同工作，实现更统一的服务网格流量管理。

6: Higress 如何保证高可用性和性能？

6: Higress 如何保证高可用性和性能？

A: Higress 在设计上充分考虑了高性能和高可用：

1. 高性能：底层基于 Envoy C++ 内核，处理延迟极低。通过全链路异步非阻塞 I/O 模型，能够支撑极高的并发 QPS。
2. 热更新：配置变更和插件加载通过内存下发，无需重启进程，避免流量抖动。
3. 健康检查：支持主动健康检查和被动健康检查，自动摘除不健康的后端服务节点。
4. 高可用部署：在 Kubernetes 中通常以 Deployment 方式部署，通过保持多个副本（Replicas）来保证网关服务本身的高可用，通常结合 HPA（Horizontal Pod Autoscaler）实现弹性伸缩。

思考题

## 挑战与思考题

### 挑战 1: 本地快速部署与路由转发

难度**: 简单

问题描述**:

请在本地 Docker 环境中快速部署 Higress，并配置一个简单的路由规则。要求将访问网关 /httpbin/ 路径的流量，透明转发至公共测试服务 httpbin.org。

实践建议

以下是针对 Higress 仓库的 6 条实践建议，涵盖了从流量接入、AI 网关特有配置到运维安全的最佳实践：

1. 利用 AI 指标进行精细化可观测性配置

Higress 区别于传统网关的核心在于其对 AI 流量的深度理解。在部署时，不要仅关注传统的 QPS 和延迟指标。

• 操作建议：在接入大模型（如 OpenAI, 通义千问等）时，务必启用 Higress 的 AI 特有指标采集。重点关注 Token 吞吐量 和 首字生成延迟。
• 最佳实践：将 Higress 的可观测性数据对接到 Prometheus + Grafana，并配置专门的仪表盘来监控 prompt_tokens 和 completion_tokens 的消耗比例。这有助于你判断是否需要优化 Prompt，或者是否触发了供应商的 RPM（每分钟请求数）限制。

2. 实施基于语义的路由而非简单的路径匹配

在 AI 应用场景中，不同的业务场景可能需要调用不同的模型或不同的供应商。

• 操作建议：利用 Higress 的路由插件功能，根据请求内容中的特征（如 model 字段、特定的 Prompt 指纹或用户标签）将流量动态分发到不同的后端服务。
• 常见陷阱：避免在代码中硬编码模型供应商的地址。通过 Higress 的路由配置，你可以实现从 OpenA I 切换到 Azure OpenAI 或本地部署的 vLLM，而无需修改任何客户端代码，这对于降低供应商锁定风险至关重要。

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

大模型推理成本高且延迟大，对于具有重复性问题的场景，缓存是必不可少的。

• 操作建议：启用 Higress 的语义缓存插件。不要只做简单的键值缓存，而应配置基于向量相似度的语义缓存策略。
• 最佳实践：针对知识库问答或客服场景，设置合理的缓存 TTL（生存时间）和相似度阈值。例如，将相似度阈值设为 0.95，可以拦截掉大量高度重复的提问，直接返回缓存结果，从而节省 30%-50% 的 API 调用成本。

4. 谨慎处理 Prompt 模板与敏感信息注入

Higress 允许在网关层进行请求的转换和增强，这是统一管理 Prompt 的好机会，但也存在安全风险。

• 操作建议：使用 Higress 的插件在网关层动态插入 System Prompt，以统一管理机器人的“人设”和行为规范。
• 常见陷阱：严禁在网关配置或插件中直接硬编码 API Key 或数据库密码。尽管 Higress 支持配置管理，但建议将敏感凭证存储在外部密钥管理系统（如 KMS 或 HashiCorp Vault）中，并通过环境变量或 Wasm 插件的动态获取能力注入。

5. 启用结果缓存与流式传输的平衡处理

AI 交互通常使用流式传输（SSE）来提升用户体验，但这与标准的 HTTP 缓存机制存在冲突。

• 操作建议：在配置流式转发时，确保 Higress 的超时设置与模型的推理时间相匹配。对于长文本生成任务，将网关的 read_timeout 设置得比默认值更长（例如 300s）。
• 最佳实践：如果业务允许，对于非实时生成的后台任务，可以关闭流式传输，开启完整的响应缓存；对于必须实时的对话场景，确保网关的流式缓冲区大小配置合理，避免因网关缓冲导致的“卡顿感”。

6. 利用 Wasm 插件实现轻量级逻辑解耦

Higress 原生支持 Wasm（WebAssembly），这是其扩展能力的核心。

• 操作建议：将业务逻辑（如特定的数据清洗、鉴权逻辑、计费统计）编写为 Wasm 插件，而不是修改 Higress 的核心代码或编写复杂的 Lua 脚本。
• 最佳实践：使用 Go 或 C++

引用

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

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

站内链接

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

相关文章

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