顶级游戏公司如何运用混沌工程提升测试质量
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
网易伏羲人工智能实验室是国内首家专业游戏AI研究机构。研究人员使用我们基于Kubernetes的丹炉平台进行算法开发、训练调优和在线发布。得益于与Kubernetes的深度集成，平台运行效率显著提升。然而由于Kubernetes及微服务相关的挑战，我们持续通过测试优化平台稳定性。
本文将重点介绍我们最核心的测试工具之一：Chaos Mesh。作为开源混沌工程平台，它通过丰富的故障注入能力和强大的控制面板监控功能，为系统稳定性保驾护航。
为什么选择Chaos Mesh
自2018年起，我们就开始寻找满足以下核心需求的混沌工程工具：
-
云原生支持。Kubernetes已成为服务编排调度的事实标准，应用运行时环境已全面标准化。对于完全运行在K8s上的应用，配套工具必须具备原生云支持能力。
-
完备的故障注入类型。对有状态服务而言，网络故障模拟尤为关键。平台需支持Pod、网络、I/O等多层级的故障模拟。
-
优秀的可观测性。精确掌握故障注入和恢复时间点，对判断应用异常至关重要。
-
活跃的社区支持。我们倾向选择经过充分验证、持续维护的开源项目，因此及时长效的社区支持是核心考量。
-
零侵入现有应用，无需领域专业知识。
-
具备实际用例供评估借鉴。
2019年Kubernetes混沌工程平台Chaos Mesh开源后，我们终于找到了理想工具。尽管当时处于早期阶段，但其支持的丰富故障类型令人惊艳——这在很大程度上决定了系统问题定位的覆盖范围，成为相比其他混沌工具的核心优势。我们立即意识到Chaos Mesh几乎完美契合了所有预期。
与Chaos Mesh的实践历程
Chaos Mesh帮助我们发现了多个关键缺陷。例如检测到丹炉平台开源消息队列软件rabbitMQ的脑裂问题。根据维基百科定义："脑裂状态指因维护两个存在范围重叠的独立数据集而导致的数据或可用性不一致"。当rabbitMQ集群发生脑裂时，会出现数据写入冲突或错误，进而引发消息服务数据不一致等更严重问题。如下图所示架构中，脑裂发生时消费者端功能异常并持续上报服务异常。
通过Chaos Mesh向容器实例云注入pod-kill故障，我们成功稳定复现了该问题。
Chaos Mesh还发现了包括启动失败、崩溃代理集群加入失败、心跳超时及连接通道关闭等多项问题。随着开发团队逐步修复这些缺陷，丹炉平台的稳定性得到显著提升。
快速发展的项目
Chaos Mesh 持续更新迭代。当我们首次采用时，它尚未发布稳定版本，缺乏调试和日志收集工具，且 Dashboard 组件仅适用于 TiDB。当时我们测试其他应用的唯一方式是通过 kubectl apply 执行 YAML 配置文件。
Chaos Mesh 1.0 解决了大部分限制：提供更细粒度的混沌实验支持、正式可用的 Chaos Dashboard、增强的可观测性以及更精确的混沌作用域控制。这些成果都得益于开放协作、充满活力的社区驱动。
未来展望
见证 Chaos Mesh 的快速成长和广泛落地令人振奋，我们对其助力取得的成果同样感到欣喜。
但混沌工程领域仍有广阔空间，我们期待未来实现以下特性：
-
原子化故障注入
-
结合自定义故障类型与标准化验证方法的无人值守故障注入
-
MySQL、Redis、Kafka 等通用组件的标准化测试用例
我们已与 Chaos Mesh 维护团队讨论过这些特性，确认它们已列入 Chaos Mesh 2.0 路线图。
若您感兴趣，欢迎通过 Slack (#project-chaos-mesh) 或 GitHub 加入 Chaos Mesh 社区。