摘要: 自谷歌提出云计算概念之后，大数据领域的发展就逐渐加速日新月异，云计算具体到实例，可以归纳为调度、均衡、容错、监控、运维等一整套操作海量数据的方案。有别于传统小规模或孤立体系产品，云计算生态圈存在错 ...
DST在设计成功后，于2013年初引入其他非大数据产品中，依托高度自由的框架体系，帮助用户在不同的产品中构建复杂的测试场景。 图：2014年4月新建实验室与调度次数分布 分布式测试体系架构成功后，DST进入了产品推广阶段，我们认为DST更适用于以下测试场景： 1.被测目标是一个后端服务。无论是独立单机还是多机集群，通过简单的一键部署监控工具后，被测目标就将被纳入DST监控体系。同时，可以通过简单地配置将JMX端口监听起来，用于收集JVM的各项指标信息。 2.性能、压力和稳定性测试。这些场景往往测试耗时较长，人工值守存在很大的困难，对结果数据的分析也比较困难。接入DST系统后，除了实现无人值守，自动报警通知用户之外。当监控数据的量也比较大的时候，通过指标模板的自动化计算更方便阅读和查找问题。稳定性测试更是可以揉入多个实验室，通过不同工作机的调度实现非常复杂且真实的用户实际使用场景。 3.需要高效利用测试资源的产品。集群管理使得用户间沟通成本大大降低，测试资源的利用状况一目了然，每日报表更可以看到哪些产品的测试更为繁忙。 4.多机联合制造负载。被测目标需要足够大的压力才能得出准确的测试结果，而且测试场景构造复杂，通过LR之类工具实现，要么难度太大，要么根本不能实现。DST通过分布式调度器，将测试代码自动分发，并实现结果的收集整理。而最关键的是，整套runner完全可以由用户自行编码订制，自由度与方便性并存。 5.有指标监控需求的产品。监控体系纳入后，结果更加准确，有利于对被测目标的精致观察。 6.存在大数据工具的复用和传承需求。由于DST中已经积累了数千个测试场景，因此用户在接入相关产品时便可以利用已有的测试场景来验证被测目标。例如，当Hive接入测试时，可以通过Hadoop的基准测试判断环境是否已经完备，发现bug时也更方便定位是Hive还是Hadoop上的问题。 前景展望 DST架构体系的建成并非一蹴而就，期间经历了复杂的论证、摸索、重构和优化。其中仅监控收集一块，由于完全是创新的产品，在多次摸索中推翻了数种方案，对其进行的优化更是持续数月。在DST推进的过程中，业务测试的需求成为其改进优化的第一源动力。例如早期云梯1由于监控数据存储在mysql中，导致100台机器的监控数据仅需两三周就可以撑爆mysql服务器，而每次测试报告的生成往往耗时达数小时。这一切在DST系统中，由于采用海量存储的缘故，得以缩短到秒级展现。此外，由于调度的自动化，收集体系的自动化，测试环境运维的自动化，促使云梯1回归集测从长达月余，缩短到最快4天以内。 对于DST来说，目前将会跟随项目脚步，逐步实现对云梯2相关的性能、压力和稳定性测试的需求。未来的工作集中于三个方向，一个是纳入神农监控体系，实现调度执行与神农监控数据的对应关系；第二个是指标的收集整理，云梯2相关指标数量巨大，理清这些将会方便用户的测试目的性；第三个是构造各种测试场景，用于对云梯2进行多角度的验证。 分布式测试体系的构建依然任重而道远，以数据为己任，为数据的流转，计算的调度保驾护航是这套体系的价值所在。能跟随这个世界级规模的海量数据平台前行，见证这一切，既是人生之幸，也是责任之所在。 |
