大规模分布式系统的测试实践(2)

　　有一个很典型的例子。早期，我们内部开发一个基于表结构的存储引擎时，曾出现过这样一件事情：测试程序在最终验证一致性时，一直都是通过的，但业务方和我们一起做E2E测试时，会有很低的概率发现数据读出来是错误的。测试人员百思不得其解，最后发现，这份数据在写入的时候，会先在三个地方进行修改，但由于一些时序和锁的问题，在改过了两个地方之后就返回成功了，第三个地方是在内存中，过一阵子就会被重新刷成正确的值。如果当时测试的同学知道系统里面的这些设计，当时就会设计写入过程中，对数据一致性进行实时检测，就不会在代价更高的E2E测试中发现问题，解决的效率也会因此而提高。

　　带压力和随机故障模拟的长时间稳定性测试

　　文首提到大规模生产集群上的问题，很难在小规模的测试集群上发现。究其原因，主要是两方面导致的。

　　大规模集群中原本小概率的单机故障会随机器数增加，导致集群整体的硬件故障率线性提升，甚至多种故障同时发生的概率也大大增加。

　　机器数增多会导致对飞天模块的压力点发生转移。以弹性计算(ECS)为例，在300台变600台时发现，原本担心的文件系统Master还未成为QPS瓶颈，负责锁文件协同的命名服务首先成为瓶颈。

　　此外，各种故障的组合爆炸也让完整的容错测试在设计和执行上的代价变得太大。

　　为解决上述困难，在飞天测试实践中，我们逐渐积累出一套带背景压力和随机故障模拟的长时间稳定性测试方案。背景压力主要是针对各个底层模块的读写压力，通常会针对某类应用场景来模拟。

　　基于分而治之和系统仿真的方法，我们实现了一些轻量级的压力工具，让各模块的Master机器和Slave机器分别接受到大规模生产集群上的类似访问压力和连接规模。另外，还增加一些诸如CPU、Memory、Network的资源消耗器，以模拟生产环境业务繁忙导致机器资源紧张的场景。

　　故障模拟上，一方面，尽可能丰富软件手段模拟软硬件故障，比如磁盘错误(包括坏盘、只读等)、机器宕机、重启、断网、交换机重启、主要模块进程重启、假死等;另一方面，这些故障模拟操作都会按照预先设定比例进行随机组合。在这样的背景压力和随机故障操作下，长时间(至少7×24小时)持续运行上层应用模拟程序/作业，同时通过在线监控系统来检查飞天是否正常。

　　简而言之，我们用背景压力解决压力点问题，用长时间跑解决小集群的故障小概率问题，用随机故障模拟和组合来解决容错测试设计和执行的代价问题。

　　实践证明，飞天很多重要的Bug都是通过这个测试被发现的。当然，这类测试也有短处，就是问题调查需要较长的时间，要求测试人员对系统有较深的了解和诊断能力。

　　结束语

　　大规模分布式系统的测试是一项非常有挑战的工作。尽管我们持续落实各层测试，积累实践经验，创新测试方法，但由于测试条件的限制、生产环境的复杂，软件问题仍然无法完全依赖测试消除。本文仅仅提到了飞天测试在Test in Lab方向的一些思考和实践，完善的飞天质量保证体系其实需要Test in Lab和Test in Production双管齐下，这才是飞天测试乐此不疲的努力方向。

　　作者许呙兢，阿里云飞天技术专家，负责飞天开放服务质量保障，长期工作在测试工作第一线，目前专注于分布式大规模在线场景的测试。

　　作者陈舟锋，阿里云飞天技术专家，负责飞天基础模块集成测试。毕业于北京航空航天大学，毕业后一直从事软件测试开发工作，曾就职于微软亚洲工程院和搜索技术中心，在UI自动化测试和分布式系统测试上有浓厚兴趣和较多积累。

　　作者郑刚，阿里云飞天高级专家，负责飞天集成测试和版本发布。毕业于南京大学，主要兴趣在大规模分布式系统的系统测试、持续集成和系统仿真。

原文转自：http://www.programmer.com.cn/15093/