微服务的混沌测试

在近日举行的 QCon 伦敦大会上， Rachel Reese 声称，世界天生就是混乱的，我们应该有计划并测试我们的系统，确保它能够处理这种混乱。他描述了 Jet 这家于 2015 年 7 月成立的电子商务公司是如何使用微服务和混沌工程的。

Reese 强调，测试微服务在环境中的交互极其重要，即使所有组件都经过了测试，但这并不意味着他们之间的交互是可靠的，也不意味着它们可以一起用于生产环境，所有这些都必须经过测试。她将 Jet 称为一家“为正确的工作选择正确的工具”的公司，对她而言，混沌测试就是其中一个正确的工具。

Reese 将微服务定义为符合单一职责原则（SRP）的应用程序，但是在服务层，由于他们以函数的方式看待微服务，所以它有一个输入，并产生一个输出。她认为，使用微服务的好处包括简化扩展性、独立发布、均匀分布的复杂性。Jet 在10 到15 个团队中运行着大约400 到1000 个微服务，主要是用 F#（一种函数优先的编程语言）编写的。

Reese 指出，混沌工程不是为了有趣而破坏代码，相反，她将其定义为：

在分布式系统上做对照实验，帮助建立对系统承受不可避免的故障的能力的信心。

参照混沌原则，Reese 定义了混沌工程的四个步骤：

1. 定义“正常”（系统的正常状态）；
2. 假定“正常”会在对照组和实验组中持续；
3. 引入混沌：服务器崩溃、硬盘异常、网络连接中断等；
4. 查找对照组和实验组行为上的差别。

更准确地讲，这意味着：

• 建立假设，定义系统的正常行为和状态，如吞吐量、延迟等；
• 真实世界的不同事件、流量峰值以及其他可以导致混沌的东西；
• 在生产环境中运行实验，确保测试的真实性；
• 自动化实验，让其连续运行。

Reese 发现，混沌工程有许多好处，包括：

• 白天测试导致系统中断，就不用在凌晨 3 点修复问题；
• 工程师在设计过程中开始考虑故障；
• 防止系统后续出现中断，让系统更健康。

根据他们的经验，Reese 指出，他们尚还没有在生产环境进行测试。作为一家初创企业，他们的主要目标是推出正确的东西。现在，他们白天所有时段都会进行随机的 QA 测试。

其中一场对他们而言最“有趣的”的灾难发生在数月之前，他们的手动测试人员发现，他们的搜索引擎宕掉了，导致了下游的一连串问题。这次故障的原因是混沌测试错误地重启了搜索引擎。就靠这么一个故障，他们发现了五六个不同的问题。

Reese 总结到：

如果可靠性很重要，那么你就应该为此开展测试。

Reese 的讲稿已经提供给 QCon 的参会者，稍后将提供给 InfoQ 的读者。

查看英文原文： Chaos Testing of Microservices