2、核心概念：什么是云原生网关（Kong/APISIX/Envoy），路由表（Route Table）的定义与组成
在开始跨环境迁移演练之前，必须统一团队对两个核心概念的理解：云原生网关与路由表。本章将明确它们的定义、主流实现差异以及路由表的内在结构，为后续的路由对账提供精确的术语基础。
2.1 云原生网关：从流量代理到控制面数据面分离
传统网关（如 Nginx、HAProxy）通常采用静态配置 + 重载生效的模式，配置变更需要重启进程或发送 SIGHUP 信号。云原生网关则基于 控制面（Control Plane）与数据面（Data Plane）分离 的架构，支持动态路由更新、服务发现集成、插件热加载，并天然适配容器化与 Kubernetes 环境。
当前生产环境最主流的三个云原生网关实现如下：
| 特性 | Kong | Apache APISIX | Envoy |
|---|---|---|---|
| 数据面核心 | OpenResty (Nginx + Lua) | OpenResty (Nginx + Lua) | C++ 自研 (Envoy Proxy) |
| 控制面 | Kong Manager / Kong Admin API | APISIX Admin API / Dashboard | 通常搭配 xDS (Istio/Consul/自定义) |
| 配置热更新 | 增量更新（DB 轮询或事件） | 增量更新（etcd watch） | 全量/增量 xDS 推送 |
| 路由匹配引擎 | Lua 正则 + 优先级 | Radix Tree + 优先级 | 前缀树 / 正则 / 自定义 |
| 插件生态 | Lua 插件（社区 + 商业） | Lua / Wasm / Java / Go 插件 | C++ / Lua / Wasm 插件 |
| K8s 集成 | Kong Ingress Controller | APISIX Ingress Controller | Envoy Gateway / Istio |
迁移视角提示： 路由表对账的核心难点不在于网关选型，而在于不同网关对“路由”的抽象层级不同。Kong 的 Route 与 Service 分离，APISIX 的 Route 直接绑定 Upstream，Envoy 的 RouteConfiguration 嵌套在 Listener 之下。对账时必须理解这些抽象差异，否则会出现“路由存在但流量不通”的隐蔽问题。
2.2 路由表（Route Table）的定义
在云原生网关语境下，路由表 是一组 匹配规则 + 后端目标 的有序集合。网关收到请求后，按照路由表的优先级顺序逐条匹配，命中后执行对应的转发、过滤或改造动作。
一个完整的路由条目通常包含以下四个组成部分：
- 匹配条件（Match Criteria）：定义请求必须满足的特征，包括域名（Host）、路径（Path）、HTTP 方法（Method）、请求头（Header）、查询参数（Query Param）等。
- 优先级（Priority / Weight）：当多条路由匹配同一请求时，优先级决定最终生效的路由。不同网关的实现方式不同（整数排序 / 最长前缀优先 / 显式权重）。
- 后端目标（Backend Target）：路由命中后流量应发往的目标，通常表示为 Upstream 名称、Service 名称或直接的目标 IP:Port 列表。
- 插件/策略（Plugin / Policy）：附加在路由上的中间件逻辑，如限流、鉴权、重写、日志、熔断等。
路由表 ≠ 转发规则表： 在跨环境迁移中，路由表对账不仅要对比“匹配条件”和“后端目标”，还必须对比“插件配置”和“优先级顺序”。两个环境的路由条目数量一致但插件参数不同，同样属于路由表不一致。
2.3 路由表的组成结构（以 Kong 为例）
为了更直观地理解路由表的层级关系，下面以 Kong 的 Route → Service → Upstream 三级模型展示其组成：
2.4 路由表在 APISIX 与 Envoy 中的差异
虽然核心概念一致，但不同网关对路由表的抽象层级和字段命名存在差异。下表列出三个网关在路由表关键字段上的对应关系：
| 逻辑概念 | Kong | APISIX | Envoy (xDS) |
|---|---|---|---|
| 路由条目 | Route | Route | VirtualHost → Route |
| 域名匹配 | hosts (数组) | host (字符串) | domains (VirtualHost 级别) |
| 路径匹配 | paths (数组) | uri (支持精确/前缀/正则) | match.path (前缀/精确/正则) |
| 方法匹配 | methods (数组) | methods (数组) | match.headers (:method) |
| 后端目标 | service.id (引用) | upstream_id (引用) 或 plugins.proxy-rewrite | route.cluster_name |
| 优先级 | regex_priority (自动) + strip_path | priority (整数，越大越优先) | VirtualHost 顺序 + 路由顺序 |
| 插件挂载 | Route 级别 / Service 级别 / Global | Route 级别 / Service 级别 / Global | HttpFilter (Listener 级别 / Route 级别) |
迁移陷阱： APISIX 的
host 字段是单值字符串，而 Kong 的 hosts 是数组。当从 Kong 迁移到 APISIX 时，一条 Kong Route 如果配置了多个域名，必须拆成多条 APISIX Route。Envoy 的域名匹配在 VirtualHost 级别，一个 VirtualHost 可以包含多个域名，但路由条目本身不直接携带域名信息。这些差异会导致对账脚本的匹配逻辑完全不同。
2.5 路由表对账的原子单位
基于上述分析，我们可以定义路由表对账的 原子单位：
- 源环境路由条目：从源网关（如 Kong）Admin API 导出的完整 Route 对象，包含所有匹配条件、后端引用、插件列表。
- 目标环境路由条目：从目标网关（如 APISIX）Admin API 导出的完整 Route 对象，包含所有匹配条件、后端引用、插件列表。
- 对账键（Reconciliation Key）：用于唯一标识一条路由的复合键，通常由
域名 + 路径 + 方法三元组构成。当网关不支持多域名时，需拆分为多条记录。 - 对账维度：包括匹配条件一致性、后端目标一致性、插件配置一致性、优先级一致性四个维度。