3. APISIX 网关特性与插件开发：特性对比、自定义插件、热加载、etcd 配置
本章聚焦 APISIX 网关的核心竞争力：与 Kong/Envoy 的选型对比、自定义插件开发全流程、热加载底层原理以及 etcd 配置管理。高级岗位面试中，面试官不仅考察你「会不会用」，更关注你「为什么选」「怎么落地」「如何保障高可用」。以下从特性对比、插件开发、etcd 高可用三个维度拆解高频考题，并附真实项目模板。
📊 APISIX vs Kong vs Envoy 核心特性对比
| 对比维度 | APISIX | Kong | Envoy |
|---|---|---|---|
| 配置中心 | etcd（强一致 + Watch） | PostgreSQL / Cassandra | xDS 控制面 |
| 扩展语言 | Lua / Java / Python / WASM | Lua | C++ / Lua（WASM） |
| 单核 QPS | ~18 万 | ~5 万 | ~10 万 |
| 热加载 | 原生支持（etcd watch + worker 优雅重载） | 需 Declarative Config 插件 | 控制面推送 |
| 插件热更新 | 支持（不中断请求） | 部分支持 | 需重新编译 |
| 社区活跃度 | Apache 顶级项目 | Kong Inc. 商业驱动 | CNCF 毕业项目 |
Q1 请对比 APISIX、Kong 和 Envoy 在网关能力上的核心差异，以及你选择 APISIX 的理由。
| 面试官考察点 | ① 主流网关的广度认知与技术视野；② 对 APISIX 核心特长的深度理解；③ 基于业务场景的技术选型能力。 |
|---|---|
| 回答框架 | 对比维度（性能 / 配置中心 / 扩展性 / 热加载） → APISIX 差异化优势（etcd 驱动、极致性能、低门槛插件） → 场景匹配结论。 |
| 示例回答 | APISIX 基于 etcd 实现毫秒级配置同步，单核 QPS 达 18 万，插件开发支持 Lua/Java/Python。Kong 依赖 PostgreSQL 性能受 DB 瓶颈限制；Envoy 扩展需 C++/Lua 调试成本高。APISIX 在性能、易扩展性和运维便捷性上更优，适合高并发、快速迭代的云原生场景。 |
| 可能追问 | APISIX 与 Kong 的插件机制有何底层不同？etcd 如何保证配置的强一致性？APISIX 在 IoT 边缘场景下有何劣势？ |
| 避坑提醒 | 不要只夸 APISIX，要承认各网关的适用场景差异（如 Envoy 在 Service Mesh 更成熟）；不可忽略 etcd 在 APISIX 中的核心地位；避免空谈性能数字，需结合业务解释。 |
Q2 描述 APISIX 自定义插件的完整开发流程，以及热加载机制是如何实现的？
| 面试官考察点 | ① 插件开发实战经验与工程化落地能力；② 对热加载底层原理（etcd watch + worker 重载）的掌握；③ 异常处理与优雅升级意识。 |
|---|---|
| 回答框架 | 插件目录与文件命名 → 结构体定义（schema / check / 钩子） → 钩子方法实现（access / rewrite / init_worker） → 插件注册与热加载 → 测试与发布。 |
| 示例回答 | 在 apisix/plugins 下创建插件文件，定义 schema 和 access 等钩子。热加载通过 etcd watch 监听配置变更，APISIX worker 进程收到信号后优雅重载：老进程处理完当前请求再退出，新进程加载新配置，请求全程不中断。 |
| 可能追问 | 热加载时如何保证长连接不断？插件内能否调用外部 HTTP 服务？多个插件之间如何共享上下文？ |
| 避坑提醒 | 不要混淆「热加载」与「hot reload」的概念；必须说清 worker 进程的优雅过渡过程（prestop 信号 + 超时强制退出）；避免说「热加载无需任何代价」，需提及内存开销和连接迁移。 |
Q3 APISIX 为什么选用 etcd 作为配置中心？如何保障 etcd 集群的高可用？
| 面试官考察点 | ① 对 etcd 核心机制（raft、watch、lease）的理解；② 分布式系统高可用设计能力；③ 实际生产环境中 etcd 运维经验。 |
|---|---|
| 回答框架 | etcd 选型优势（强一致 / watch 增量同步 / 高性能读） → APISIX 配置分层（route / service / upstream / plugin） → 高可用方案（集群部署 / 自动压缩 / 快照备份 + 本地缓存降级）。 |
| 示例回答 | etcd 的 watch 机制支持配置增量同步，避免全量拉取；raft 协议保证强一致性。配置按 route/service/upstream/plugin 分层存储。高可用方面部署 3 节点 etcd 集群，设置 --auto-compaction 自动清理历史版本，定期快照备份，APISIX 本地缓存做 etcd 不可用时的降级。 |
| 可能追问 | etcd 的 compaction 策略怎么配置才合理？网络分区时 APISIX 如何行为？etcd 的 watch 性能瓶颈在哪里？ |
| 避坑提醒 | 不要只说 etcd 的优点，也需提运维复杂度（如磁盘 IO 敏感、快照过大风险）；避免忽略 APISIX 的本地缓存降级机制；注意说清 route 和 upstream 在 etcd 中的存储结构。 |
⚠️ 高潜追问点拨： 在多数据中心场景下，etcd 跨机房延迟会直接影响配置推送速度。面试官可能追问「APISIX + etcd 多活架构如何设计」，可提前准备「区域化 etcd 集群 + 本地缓存优先」的思路。
🏭 项目案例：统一 API 网关平台
| 项目名称 | 统一 API 网关平台（API Gateway Unified Platform） |
|---|---|
| 业务背景 | 公司微服务化后，各业务团队自行管理网关，认证、限流、日志等横切关注点重复实现，安全合规风险高，急需统一网关层进行收敛。 |
| 规模指标 | 接入微服务 200+；日均请求量 30 亿+；峰值 QPS 12 万；自定义插件 20+；etcd 集群 3 节点。 |
| 技术栈 | APISIX 2.15 + etcd 3.5 + OpenTracing (Jaeger) + Prometheus + Grafana + Kafka + OAuth2.0 |
| 核心难点 | ① 存量网关平滑迁移，要求零停机全量切换；② 自定义认证插件对接公司统一 SSO 与 OAuth2.0；③ 多租户隔离下的精细化限流策略配置；④ etcd 集群跨单机房容灾与备份恢复。 |
| 面试高频追问 | 如何设计「灰度引流 + 流量染色」的平滑迁移方案？多租户限流的 key 如何设计才能避免隔离失效？etcd 跨机房同步延迟时网关如何降级？ |
| 可迁移回答话术 | 「迁移采用灰度引流 + 流量染色，通过自定义请求头标记染色流量，实时对比新旧网关响应差异，逐步放大比例直至全量。」 「限流 key 使用 租户 ID + 路由 ID + 服务名 三级粒度隔离，结合 APISIX 的 counter 与漏桶算法实现。」 「本地缓存 etcd 配置快照 + etcd watch 异步更新，当 etcd 连续心跳超时自动切换到缓存降级模式。」 |
📌 项目陈述加分点： 在描述项目时，主动带出「流量染色对比」「三级限流 key 设计」「本地缓存降级」这三个关键词，能向面试官强烈传递你的工程化深度和分布式系统经验。