第 01 期 / 共 10 期

项目入门与架构总览

用 20 讲建立 Higress 的整体心智模型——它是什么、跟同类产品什么差异、内部由谁分工、源码长什么样。这是读懂后 9 期的地基

L01

Higress 是什么

Higress 是阿里巴巴开源的 云原生 API 网关,对外宣称"三合一":南北向流量网关 + 微服务网关 + AI 网关。底层架构是 Envoy 作数据面 + Istio Pilot 改造版作控制面 + Wasm 插件作扩展点。它原生支持 K8s Ingress、Gateway API、Knative、并扩展了 McpBridge / WasmPlugin / Http2Rpc 等 CRD。

核心卖点:配置热生效(不 reload)、丰富插件生态(60+ 官方插件)、对 LLM / MCP 友好。

思考:为什么阿里要再造一个网关而不是直接用 Nginx Ingress?想想"配置热生效"对线上意味着什么。
L02

与 Nginx / APISIX / Kong 对比

维度Nginx IngressAPISIXKongHigress
数据面NginxOpenRestyOpenRestyEnvoy
插件语言LuaLua / WasmLua / GoWasm (Go/Rust/CPP/AS) + Envoy Go Filter
配置热生效reloadetcd 热db / dblessxDS 热
K8s 原生较弱较弱
AI 网关实验商业原生第一公民
思考:插件用 Wasm 相比 Lua 的优劣是什么?提示:沙箱、跨语言、性能、可观测性。
L03

与 Istio 的血缘

Higress 控制面本质是裁剪魔改版 Istiod。证据:

  • 仓库根目录有 istio/istio 子目录,是 Istio 源码的 vendored 副本。
  • go.modreplaceistio.io/istio 重定向到本地副本。
  • pkg/bootstrap/server.go 大量 import "istio.io/istio/pilot/..."

Higress 复用了 Istio 的 Pilot 配置聚合、xDS Server、Push 模型;去掉了 mTLS / CA / Sidecar Injector。

思考:vendoring 一份 Istio 副本相比"直接依赖上游 + override"的好处与代价分别是什么?
L04

与 Envoy 的关系

Higress 数据面是定制化 Envoy,集成了官方 Wasm HTTP Filter 和 Higress 自研的若干扩展(在 envoy/envoy 子模块、plugins/golang-filter 等位置)。运行时通过 gRPC ADS 从控制面拉取 LDS/RDS/CDS/EDS。所有"AI 网关能力"最终都跑在 Envoy filter chain 里,要么是 Wasm 沙箱,要么是 Go Filter。

思考:为什么不直接用上游 Envoy?什么场景下 Higress 需要 patch Envoy?
L05

三大组件分工

┌─ Higress Console (前端 + Java/Spring) ────────────┐
│  用户图形化管理:路由、插件、AI、监控               │
└──────────────┬─────────────────────────────────────┘
               │ 调 K8s API (改 CRD)
               ▼
┌─ Higress Controller (本仓库 pkg/) ─────────────────┐
│  监听 CRD → 翻译成 Istio Config → xDS 推送         │
└──────────────┬─────────────────────────────────────┘
               │ gRPC ADS
               ▼
┌─ Higress Gateway (定制 Envoy) ─────────────────────┐
│  实际转发流量;加载 Wasm 插件                       │
└────────────────────────────────────────────────────┘
思考:本仓库是哪一层?Console 在哪里?提示:Console 是独立仓库 higress-console。
L06

仓库顶层目录

cmd/higress/    控制面唯一入口
pkg/            ★ 控制面核心 Go 代码
registry/       ★ 多注册中心适配
istio/          vendored 裁剪版 Istio
envoy/          Envoy 自定义构建材料
plugins/        ★ Wasm 插件(含 wasm-go SDK)
api/、client/   CRD schema 与 typed client
helm/           部署 chart
hgctl/          命令行工具
docker/、docs/、samples/、test/、tools/、release-notes/
思考:上面 3 个标 ★ 的目录加起来覆盖了多少代码量?为什么它们最重要?
L07

go.mod 与 replace

Higress 的 go.mod 充满 replace 指令,把所有 istio.io/istioistio.io/apiistio.io/client-go 等 import 路径重定向到本地的 ./istio/...。这让 Higress 可以独立修改 Istio 代码而不必等上游合并。

replace (
    istio.io/istio          => ./istio/istio
    istio.io/api            => ./istio/api
    istio.io/client-go      => ./istio/client-go
    ...
)
思考:IDE 跳转 istio.io/istio/pilot/... 实际会跳到哪里?读源时一定要意识到这点。
L08

构建体系 Makefile

顶层有 3 个 Makefile:Makefile(入口)、Makefile.core.mk(核心目标)、Makefile.overrides.mk(覆盖钩子)。这套体系沿用了 Istio 的 build-common 模式。常用目标:

make build           # 编译 higress 二进制
make docker          # 构建镜像
make lint            # tools/linter
make test            # 单元测试
make gen             # 生成 CRD client / proto
make higress.tar     # 离线包
思考:如果你想给 controller 加一个新字段到 CRD,要不要跑 make gen?为什么?
L09

镜像与 Docker

docker/ 下分别放 higress(控制面)、higress-gateway(数据面)、higress-pilot(裁剪 Istiod)等 Dockerfile。Higress 主镜像通常基于 distroless 或精简 Ubuntu,Gateway 镜像基于上游 envoyproxy/envoy 派生并打包 Wasm runtime。

思考:单机 all-in-one 镜像把哪几个进程塞到了一个容器里?
L10

Helm Chart 结构

helm/ 下分多个子 chart:core(CRD + controller)、higress(聚合)、console(前端)。安装时一句命令拉起完整集群形态:

helm install higress higress.cn/higress -n higress-system --create-namespace
思考:Helm values 里 global.controller.replicasglobal.gateway.replicas 谁该调大?答案在控制面/数据面的不同负载特征。
L11

关键 CRD 一览

CRDgroup/version作用
McpBridgenetworking.higress.io/v1多注册中心服务来源
WasmPluginextensions.higress.io/v1alpha1Wasm 插件配置
Http2Rpcnetworking.higress.io/v1HTTP→Dubbo 转换
McpServernetworking.higress.io/v1MCP Server 托管
Ingress (v1)networking.k8s.io/v1原生 K8s 资源 + Higress 注解扩展
HTTPRoutegateway.networking.k8s.io/v1Gateway API
思考:为什么 Higress 不把所有功能都做成 Annotation 而要新增 McpBridge / WasmPlugin 这类 CRD?提示:注解放不下复杂结构。
L12

关键依赖一览

  • istio.io/istio:Pilot / xDS / ServiceRegistry 模型(vendored)
  • k8s.io/client-go:K8s API 客户端
  • github.com/envoyproxy/go-control-plane:Envoy proto + ADS 库
  • github.com/tetratelabs/proxy-wasm-go-sdk:Wasm 插件 ABI
  • github.com/nacos-group/nacos-sdk-go/v2go-zookeeper/zkhashicorp/consul/api 等注册中心客户端
  • github.com/spf13/cobra:CLI
  • google.golang.org/grpc:gRPC ADS server
思考:proxy-wasm-go-sdk 不在控制面也不在 Higress 主仓,为什么会出现在 go.mod?提示:plugins/wasm-go。
L13

数据流总图(请求侧)

Client
  │ HTTP/TLS
  ▼
Higress Gateway (Envoy)
  ├─ Listener Filter (TLS Inspector / SNI)
  ├─ HTTP Connection Manager
  │     ├─ Wasm Filter[ai-security-guard]
  │     ├─ Wasm Filter[jwt-auth]
  │     ├─ Wasm Filter[ai-token-ratelimit]
  │     ├─ Wasm Filter[ai-cache]
  │     ├─ Wasm Filter[ai-proxy]   ← 改写 path/body
  │     └─ Router → Cluster
  ▼
Upstream (K8s Service / Nacos 实例 / 大模型 API)
思考:ai-cache 必须放在 ai-proxy 之前还是之后?提示:缓存命中要直接返回,不能走 LLM。
L14

配置流总图(推送侧)

K8s API Server  +  Nacos/ZK/Consul/Eureka
       │                  │
       ▼                  ▼
   Informer        registry/* Watcher
       │                  │
       └───── IngressConfig ─────── ConfigAggregate
                            │
                            ▼
                  Pilot DiscoveryServer (xds)
                            │  gRPC ADS
                            ▼
                       Envoy 数据面
思考:一次 Ingress YAML 修改会引发哪些 xDS 资源类型重推?答:通常 RDS + CDS,必要时 LDS。
L15

插件运行模型

Higress 插件由两条路径加载:

  • WasmPlugin CRD:声明式,最常用;插件以 .wasm 镜像形态从 OCI/HTTP 拉取,挂载到指定 phase + priority。
  • Envoy Go Filterplugins/golang-filter,需要重编 Envoy 镜像。

插件运行在 Envoy 的 Worker 线程内的 V8/WAVM 沙箱里,每个 worker 各自一份独立实例。

思考:插件里能写阻塞 IO 吗?答:不能直接,必须用 HttpCall/RedisCall 这种 SDK 提供的异步外呼。
L16

多集群与多注册中心

Higress 支持:

  • 多 K8s 集群:每个集群一个 Ingress Controller 实例,由 common.AggregateController 聚合。
  • 多注册中心:McpBridge 的 registries 是数组,可同时接入多个 Nacos/ZK/Consul/Eureka。

统一表示:所有外部服务都被翻译成 Istio ServiceEntry 注入 ServiceRegistry。

思考:跨集群通信的 Cluster 名怎么避免冲突?提示:clusterId 前缀。
L17

AI 网关定位

Higress 的 AI 网关能力不在控制面也不在 Envoy core,全部以 Wasm 插件形态存在于 plugins/wasm-go/extensions/ai-*

  • ai-proxy:协议归一化(统一 OpenAI 协议 → 各厂商)
  • ai-cache、ai-rag、ai-history:上下文增强
  • ai-security-guard、ai-token-ratelimit、ai-quota:治理
  • ai-statistics、ai-load-balancer、ai-intent、ai-search:辅助
思考:把 AI 能力做成 Wasm 而不是写死在 Envoy 里有什么好处?提示:迭代速度、隔离、可灰度。
L18

代码量画像

区域大致 LOC语言
pkg/ (控制面)~35kGo
registry/~8kGo
plugins/wasm-go/~200k(含插件)Go
istio/ (vendored)很大,按需读Go
envoy/、tools/、test/辅助多语言
思考:作为读者,哪个目录的"投入产出比"最高?建议:pkg/ingress/config + plugins/wasm-go/extensions/ai-proxy。
L19

版本演进里程碑

  • 1.x:稳定 Ingress + 多注册中心 + Wasm 插件。
  • 2.0:AI 网关首发,ai-proxy / ai-token-ratelimit 等大量插件入驻。
  • 2.1+:MCP Server 托管、mcp-router 推出;与各 LLM 厂商对接扩展。

查看 release-notes/ 下按版本号组织的目录是最直接的"项目史读法"。

思考:如果你读到一份老资料说"Higress 不支持 X",怎么验证当前是否已支持?答:先查 release-notes 再 grep 代码。
L20

读源路线推荐

  1. 纵向 1 条主线:跟一条 Ingress YAML 的命运,从 Informer → IngressConfig → VirtualService → Pilot xDS → Envoy(贯穿 02~05 期)。
  2. 横向 1 条插件:选 ai-proxy,从 main.go 看到 provider 实现(贯穿 08~09 期)。
  3. 横向 1 条注册中心:选 Nacos,从 McpBridge CRD 到 Endpoint 推送(07 期)。

这三条线覆盖 80% 的核心代码,剩下都是补充。

本期收尾:你现在应该能回答:Higress 是什么、它跟 Istio/Envoy 什么关系、源码大概长什么样。下一期我们从 main.go 开始钻进控制面。