回顾：从 Nginx 迁移到 Kong 3.0 API 可观测性提升 40%

Source: Dev.to

Introduction

深入探讨我们团队将 Nginx 替换为 Kong 3.0 的过程，以及原生可观测性功能如何实现 40 % 的 API 可视化提升。

我们的团队管理着 120 多个内部和外部 API，全部通过一组 Nginx 反向代理进行路由。多年来，Nginx 在基本路由、SSL 终止和限流方面表现良好。随着 API 生态系统的扩展，我们遇到了关键的可观测性限制：

• 日志分散 – Nginx 访问日志需要自定义解析才能提取 API‑特定的元数据（消费者 ID、端点版本、错误码），导致故障排查延迟。
• 缺乏原生指标 – 我们依赖第三方导出器获取 Nginx 状态指标，但这些指标缺乏对每个 API 的请求量、延迟和错误率的细粒度。
• 手动仪表化 – 为新 API 添加可观测性需要编辑 Nginx 配置并重新部署，给 DevOps 团队造成瓶颈。
• 追踪缺口 – 分布式追踪需要手动注入 Header，且在微服务之间的追踪链经常中断。

到 2023 年第三季度，我们的 API 事件平均恢复时间（MTTR）已上升至 47 分钟，其中 60 % 的时间花在收集可观测性数据上。我们需要一种能够原生集成可观测性的解决方案，而无需自定义工具。

API 网关评估

我们评估了多个 API 网关，但 Kong 3.0 因以下三大关键原因脱颖而出：

1. 原生可观测性插件 – Kong 的插件生态系统提供了开箱即用的日志（HTTP、TCP、Syslog）、指标（Prometheus、StatsD）和追踪（OpenTelemetry、Zipkin）工具，无需编写自定义代码。
2. 兼容性 – Kong 基于 OpenResty（类似 Nginx），因此将我们现有的 Nginx 配置迁移过来，只需对路由规则和 SSL 设置做极少的修改。
3. 性能 – Kong 3.0 优化的请求处理为每个请求仅增加 < 2 ms 的延迟，远低于我们的 SLA 要求。

我们的目标是在三个月内完成所有生产 API 的迁移，并实现 30 % 的可观测性提升。我们超额完成，达到了 40 %。

迁移方案

1. 评估

• 审计了所有 Nginx 配置。
• 绘制了 120 多条 API 路由。
• 确认了 18 个需要转换为 Kong 插件的自定义 Nginx Lua 脚本。

2. 预发布验证

• 在预发布环境部署了 Kong 3.0。
• 通过 shadowing（流量影子）复制生产流量。
• 验证了路由、SSL 和限流行为。

3. 插件配置

为所有 API 启用了三个核心可观测性插件：

4. 渐进式发布

• 以每批 10 条 API 的方式迁移，先从低流量的内部 API 开始。
• 使用 DNS 加权一次性切换 10 % 流量，并持续监控错误率和延迟。

5. 退役

• 在迁移后 2 周 零流量后退役 Nginx 节点。

结果

我们使用一个自定义评分来衡量可观测性提升，该评分依据四个因素加权：指标粒度（30 %）、日志结构（25 %）、追踪完整性（25 %）和数据访问时间（20 %）。

• 迁移前得分： 62 / 100
• 迁移后得分： 87 / 100 (+40 %)

关键量化成果

• MTTR 从 47 分钟 降至 28 分钟（下降 40 %）。
• 追踪完整性 从 68 % 提升至 99 %——不再出现断裂的追踪链。
• 日志解析时间 从每次事件的 12 分钟 降至 几乎为零（结构化 JSON 自动索引）。
• 实时的每 API 指标现在无需手动配置即可用于新 API。
• Kong 的限流和认证插件取代了 12 个自定义 Nginx Lua 脚本，使配置体积减少了 35 %。

面临的挑战

Lessons Learned & Tips

• 尽早使用可观测性插件。 将插件视为事后考虑导致我们的预演验证延迟了两周。
• 使用 DNS 加权 或 金丝雀 方法逐步转移流量并监控关键指标。
• 在影子流量时关注 资源使用情况；采样可以减轻开销。

结论

从 Nginx 迁移到 Kong 3.0 对我们的团队来说是一次净收益。API 可观测性提升了 40 %，缩短了事件解决时间，消除了自定义工具，并为未来的 API 治理计划奠定了基础。对于已经超出 Nginx 基础可观测性功能的团队，Kong 3.0 提供了低延迟、兼容的升级路径，并带来巨大的可观测性提升。