Day 01 / 共 20 天 · 第 1 周 全景与控制器

项目全景：AI 云原生网关

欢迎来到 Higress——higress-group 系列第 3 站。学完 Envoy（数据面）和 Istio（控制面），现在看它们怎么组装成一个产品级 AI 网关。第一天的"题眼"：Higress 怎么"寄生"在 Istio 之上。今天先建立全景地图，为 Day 02 拆启动流程、Day 03-05 拆"配置怎么翻译并喂给 istiod"打地基。

📍 你在 Higress 源码课的位置（第1周 全景与控制器 · 第2周 服务发现与配置）
D01 全景→ D02 启动→ D03 Ingress控制器→ D04 配置翻译→ D05 xDS-over-MCP→ D06 多注册中心→ D07 McpBridge→ D08 Nacos→ D09 ServiceEntry→ D10 配置+证书
💡 先用一个类比兜住整门课（贯穿 20 天的世界观） 把 Higress 想成一栋写字楼的大堂前台 + 门卫系统。网关（Envoy）=真正站在大门口验证件、指路、拦人的门卫；Higress Core=前台的翻译官，把租户递上来的大白话申请单（K8s Ingress + 注解）翻译成物业总部认的正式公文（Istio 配置对象）；istiod=物业总部，收到公文后排班、下发给门卫。今天你只需记住这条"翻译 → 下发 → 执行"的链，后面每天都在放大其中一环。
L01

Higress 是什么

Higress 是阿里开源的AI 原生 API 网关（Go 编写，README.md:35）。它基于 Istio + Envoy，可用 Go/Rust/JS 写 Wasm 插件扩展。定位：面向"API 网关/Ingress"（南北向流量），比 Istio 的服务网格（东西向）更适合做网关入口。

"站在巨人肩膀上做产品" Higress 没有从零造网关——它复用了 Envoy（成熟的数据面）+ Istio istiod（成熟的 xDS 生成），自己加了三样：①一个更友好的用户接口（用 K8s Ingress + 注解就能配，不用写复杂的 Istio CRD）；②多注册中心服务发现（Nacos/ZK/Consul，不止 K8s）；③丰富的 Wasm 插件生态 + AI 网关能力。好比在成熟的发动机（Envoy）和变速箱（Istio）上，造一辆好开的整车（Higress）。你前两站学了发动机和变速箱，现在看整车怎么组装。
L02

三大组件

docs/architecture.md:19-71 定义三大组件：

  • Higress Controller（控制器）：内含 ① Discovery（就是 Istio 的 istiod）+ ② Higress Core（Higress 自己写的，核心是 Ingress Config + Cert Server）。
  • Higress Gateway（网关/数据面）：就是 Envoy。
  • Higress Console（控制台）：Web 管理界面（本系列下一站单独讲）。
读法：关键：Higress Controller 内嵌了 istiod（Discovery），再加自己的 Core。Core 才是 Higress 独有的代码（本课主角），istiod 就是你 Istio 课学的那个。数据面 Gateway 就是 Envoy 课学的 Envoy。
L03

寄生在 Istio 上

核心协作模型（整门课的"题眼"，architecture.md:47-71）：
istiod 支持 4 种配置来源：Kubernetes / MCP / Memory / File。
MCP（Mesh Configuration Protocol）是基于 xDS 协议的配置管理协议。istiod 作为 MCP 客户端（ADS client），任何实现 MCP Server 的都能给它下发 Istio 配置。
Higress Core 实现了 MCP-over-xDS 的 Server——于是它成为 istiod 的配置来源。
回想 Istio 课 Day 20 的"反转" Istio 课结尾讲过：正常 istiod 是"xDS 服务端"（给 Envoy 发配置），但在 Higress 里有个反转——istiod 变成"MCP 客户端"，Higress Core 是服务端，给 istiod 发配置！今天正式坐实这个反转。为什么这么设计？因为这样 Higress 不用重写 istiod 复杂的 xDS 生成逻辑——它只需把自己的配置（从 Ingress/CRD/注册中心来）翻译成 Istio 配置对象，通过标准 MCP 协议"喂"给 istiod，剩下的 xDS 生成交给成熟的 istiod。复用 + 扩展，事半功倍。

👶 小白：为什么要搞得这么绕？Higress 自己直接给 Envoy 发配置不行吗？

👨‍🏫 老师：给 Envoy 发运行配置（xDS 生成）非常复杂——监听器、路由、集群、TLS 一大堆细节，istiod 花了多年才做扎实。Higress 若自己重写，等于把物业总部的活儿全干一遍，费力又易出 bug。更聪明的做法：只当"翻译官"，把用户的申请单翻成 istiod 认得的公文，剩下排班下发全交给成熟的 istiod。这正是"寄生在 Istio 上"的价值——省掉最难那部分。

L04

MCP over xDS

MCP = "用 xDS 协议传配置" 你在 Istio/Envoy 课学的 xDS 是"控制面给数据面发配置"。MCP 复用了同一套 xDS 协议机制，但用途不同——它是"配置源给 istiod 发 Istio 配置对象"（VirtualService/Gateway 等）。好比同一条快递网络，既能送外卖（xDS 给 Envoy 发运行配置），也能送公文（MCP 给 istiod 发配置定义）。因为 MCP 和 xDS 底层都是 gRPC 流式协议，Higress 能直接复用 istiod 的 DiscoveryServer（Istio 课 Day 06）来当 MCP Server——只需替换"某类资源怎么生成"的 Generator。（Day 05 详讲。）
L05

configSources

Higress Core 和 istiod 通过 higress-config ConfigMap 的 mesh.configSources 关联（architecture.md:56-71）：

configSources:
  - address: xds://127.0.0.1:15051   # 指向 Higress Core 的 MCP Server
  - address: k8s://
读法：端口 15051 就是 Higress Core 起的 MCP/xDS 服务，istiod 连它拉取 Gateway/VirtualService/DestinationRule/EnvoyFilter/ServiceEntry/WasmPlugin 六类配置。k8s:// 表示 istiod 也直接从 K8s 读一部分。记住 15051——这是 Higress Core 和 istiod 的接口（就像 15012 是 istiod 和 Envoy 的接口）。
📝 举个例子：这两行配置在说什么 xds://127.0.0.1:15051 就是告诉 istiod："你的一路配置来源是本机 15051 端口的那个 MCP Server（Higress Core）"。
翻译成大白话——物业总部（istiod）的排班依据有两处：① 直接查 K8s（k8s://）；② 听前台翻译官（15051）报上来的正式公文。两处合并后一起下发给门卫。
L06

完整数据流

K8s Ingress + Higress CRD + 外部注册中心（Nacos…）
  → Higress Core 翻译成 Istio 配置对象（VirtualService/Gateway/…）
    → 经 MCP-over-xDS(:15051) 下发给 istiod（istiod 是客户端！）
      → istiod 合并后经标准 xDS(:15012) 下发给 Envoy（Istio 课）
        → Envoy 执行 + Wasm 插件处理（Envoy 课）
读法：这条链把三站串起来了：Higress Core（本课）生成配置 → istiod（Istio 课）转 xDS → Envoy（Envoy 课）执行。你三站都学，就能看到从"用户写 Ingress"到"Envoy 转发流量"的完整链路。本课聚焦第一段：Higress Core 怎么翻译并喂配置。
配置的一生：从"大白话申请单"到"门卫真的放行" 用户申请单 Ingress+注解/CRD Nacos 注册中心 Higress Core 翻译官（本课） → Istio 配置对象 istiod 物业总部（Istio 课） 生成 xDS Envoy 门卫 数据面（Envoy 课） 真的转发流量 :15051 MCP-over-xDS（Core→istiod）　　:15012 xDS（istiod→Envoy）
图注：本课主角是最左边两格（申请单 → 翻译官）；后两格是你 Istio/Envoy 课已学的部分。
L07

为什么要 Higress

Istio 已经很强，为什么还要 Higress？ Istio 面向"服务网格"——管集群内服务间（东西向）流量，配置用 VirtualService/DestinationRule 等，功能强但对"做个 API 网关"来说偏复杂。Higress 面向"API 网关/Ingress"——管从外部进集群（南北向）的流量：①让你用简单的 K8s Ingress + 注解就能配路由/限流/鉴权，不用写 Istio CRD；②支持从 Nacos 等注册中心发现服务（微服务迁移友好）；③Wasm 插件生态开箱即用；④专门的 AI 能力（LLM 代理、Token 限流）。它把 Istio 的能力"产品化"成一个易用的网关。这就是"平台 vs 产品"的区别——Istio 是平台，Higress 是基于平台做的产品。
L08

今日小结 + 动手

🧠 今天你应该能回答

  • Higress 是什么？它基于什么？
  • 三大组件？Controller 内部的 Discovery vs Core？
  • Higress 怎么"寄生"在 Istio 上？istiod 在这里是什么角色？
  • MCP 是什么？15051 端口的意义？
  • 完整数据流的四段？为什么在 Istio 上再套 Higress？

✋ 动手

cd /Users/bitmart/work/codes/github/higress-group/higress
sed -n '1,114p' docs/architecture.md
head -40 README.md
ls pkg/ingress/ pkg/bootstrap/
明天预告 · Day 02：启动流程——Higress Controller 怎么 boot：cmd/higress/main.go → NewServer → initFuncList（一串初始化函数）。看它怎么把 istiod 和自己的 Core 装配起来。
← 总目录 Day 02 · 启动流程 →