微服务的混沌测试

  • Jan Stenberg
  • 谢丽

2016 年 3 月 18 日

话题:DevOps语言 & 开发架构

在近日举行的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

DevOps语言 & 开发架构