Chaos Mesh 助力 Apache APISIX 提升系统稳定性

概述

Apache APISIX 作为一个云原生、高性能的微服务 API 网关，承载着来自金融、互联网、制造等多个行业客户的每秒数十亿级请求。随着其功能与外部组件（如 etcd）的交互日益复杂，系统出现潜在故障的可能性也随之增加。为了主动识别这些在常规 CI/CD 流程中难以覆盖的故障场景（如网络抖动、节点宕机），Apache APISIX 团队引入了混沌工程（Chaos Engineering）实践。他们使用云原生混沌工程平台 [Chaos Mesh] 在生产环境模拟故障，验证系统的韧性，并据此修复缺陷、建立对系统在异常条件下运行的信心。这是一个典型的通过混沌工程提升关键业务系统可靠性的 SRE 实践案例。

核心概念

本案例涉及几个 SRE 和可靠性工程的核心概念：

  • 混沌工程 (Chaos Engineering)：一种通过主动注入故障来发现分布式系统中潜在弱点的实践。其核心是建立系统的稳态假设（如“系统应保持一定吞吐量”），然后引入可控的故障，观察系统是否能维持或恢复到稳态，从而暴露问题并加以修复。
  • 稳态假设 (Steady-State Hypothesis)：在混沌实验开始前，对系统正常运行行为的可量化描述。例如，在 Apache APISIX 的案例中，稳态表现为“路由创建和访问成功，能连接 etcd，且每秒转发请求数（RPS）稳定”。
  • 故障注入 (Fault Injection)：使用 Chaos Mesh 等工具模拟真实世界中可能出现的故障，如网络延迟、Pod 被杀、文件系统错误等。这是混沌工程的关键执行步骤。
  • Chaos Mesh：一个开源的、云原生的混沌工程平台，运行于 Kubernetes 之上，提供全面的故障注入能力（包括 Pod、网络、文件系统、内核等），帮助用户发现系统弱点。

实践

Apache APISIX 团队针对用户反馈的两个具体场景，使用 Chaos Mesh 设计并执行了混沌实验，成功定位并解决了问题。

实验场景一：etcd 与 APISIX 间网络高延迟

  1. 定义稳态与度量：团队确定正常稳态为：create route 和 access route 操作成功，能连接 etcd，且 RPS 稳定。他们通过 Prometheus 采集指标，并使用 Grafana 进行可视化监控，同时分析 Nginx 错误日志。
  2. 建立对照组：在未注入故障时，进行基线测试，确认所有操作正常并记录 RPS。
  3. 注入故障：使用 Chaos Mesh 的网络混沌（NetworkChaos） 实验，为 etcd 与 APISIX 之间的网络注入 5 秒延迟。
  4. 观察与验证：注入故障后，测试发现 set route 操作失败（符合预期，因操作超时），但 access route 成功，etcd 仍可连接，且核心的 RPS 指标未发生显著变化。这验证了在短暂网络延迟下，APISIX 的数据面（流量转发）仍能正常工作，系统行为符合预期。

实验场景二：etcd 集群节点故障

  1. 建立对照组：与场景一相同，先进行无故障基线测试。
  2. 注入故障：使用 Chaos Mesh 的 Pod 破坏（PodChaos） 实验，模拟随机杀掉 etcd 集群中的节点。
  3. 发现问题：实验重现了生产环境的问题。团队发现，当杀掉 etcd endpoint 列表中的第二个节点时，set route 操作会持续返回 connection refused 错误，而删除其他节点则可能成功。日志中出现大量连接拒绝错误。
  4. 根因分析与修复：排查发现，Apache APISIX 使用的 etcd Lua API 在创建客户端时，顺序绑定了列表中的第一个端点，而非随机选择或具备故障转移能力。这导致当该特定节点失效时，客户端连接持续失败。团队随后为该 API 增加了健康检查机制，避免向不可用节点发送大量请求；同时添加了降级机制，在 etcd 集群完全不可用时提供兜底处理，防止日志被错误淹没。

SRE 要点

这个案例为 SRE 实践提供了多方面的宝贵启示：

  • 提升可靠性与韧性：混沌工程是主动寻找系统弱点、提升可靠性的有力手段。它补充了单元测试、集成测试和端到端测试的不足，特别是在验证复杂外部依赖交互的场景下。通过修复发现的问题（如 etcd 客户端的故障转移缺陷），系统整体的故障容忍度得到了实质性提高。
  • 强化可观测性驱动：成功的混沌实验严重依赖于完善的可观测性。Apache APISIX 团队通过 Prometheus、Grafana 和日志分析来定义和验证“稳态”，这直接体现了 可观测性 是实施混沌工程、量化系统健康度的基础。
  • 完善事件响应与恢复：混沌实验模拟的故障（如节点宕机）正是生产环境中可能发生的事件。通过修复实验中发现的问题，团队提升了系统在真实事件中的自动恢复能力（如 etcd 连接故障转移），从而缩短了 MTTR（平均恢复时间）。
  • 最佳实践：
    • 从具体场景出发：从真实的用户痛点或潜在风险场景（如 etcd 网络延迟）设计实验，确保混沌工程的价值直接指向业务需求。
    • 小规模、渐进式：先在 CI/CD 或测试环境中实施，验证方法并积累信心，再考虑扩展到生产环境的灰度或影响范围有限的实验。
    • 定义清晰的“爆炸半径”：使用 Chaos Mesh 等工具可以精细控制故障注入的范围和强度，这是安全进行混沌实验的关键。
  • 相关指标：实验中使用了 SLI（如 RPS、etcd 连接状态）来衡量稳态。实验结果直接影响 SLO 的设定和 错误预算 的消耗——一个未经混沌工程验证的系统，其 SLO 可能过于乐观，而混沌测试的结果可以帮助团队更准确地评估系统真实可靠性，从而制定更合理的 SLO。

通过本次实践，Apache APISIX 不仅修复了具体缺陷，还建立了将混沌工程融入开发流程的机制，并计划将其扩展到 E2E 测试场景和更多关联项目中，持续驱动系统稳定性的提升。