文 / 刘星 孙靓

云计算的出现，带来了相关技术的长足发展，同时也带来了多方位的挑战。这种状况，在云计算从概念到实现的转变之后，尤为明显。无论是业界的领导者，如Google、Yahoo，还是那些刚露出尖尖角的后来者，都将面临着一些共同的难题和挑战。在这些难题与挑战之中，如何在云中合理搭配计算资源则一直是让业者纠结的话题。

开发者的云与测试者的云

开发阶段的云平台应用产品，大多数情况下并不需要太多的计算资源，例如为客户开发一个基于云平台的并行存储系统，在开发阶段，往往只需3~4台实体机便可以搭建出足以支撑程序员进行全部功能开发的环境。在开发阶段完成后，白盒的单元测试和黑盒的功能测试也都可以在这个环境里很好地进行，且当产品在真实的云平台上运行之后，单元和功能测试的结果也都拥有足够的说服力。但是，我们都知道，传统的企业级应用产品，在上线之前，系统测试是不可或缺的。云平台上的应用产品会有例外吗？财力雄厚的诸如Google这样的国际性公司，在产品上线前，必然会进行一系列的性能测试、压力测试、稳定性测试以及安全性测试，这样一来，3~4台实体机组成的开发环境就显得捉襟见肘了。他们必然会通过自家的云平台模拟实际运行环境，以供系统测试执行。

显然，无论是传统软件产品还是云平台上的应用产品，系统测试都是必需的一环。云平台产品的特点，决定了其在集群中的优异表现来自于可智能化地伸缩和迁移计算资源。专业的系统测试可以获知产品的真实能力，同时带来对计算资源的伸缩性预估。然而对于不如Google那样财大气粗的软件公司来说，大量采购计算资源以实现对产品的系统测试，是不够现实的。原因在于以下几点。

• 产品的吞吐需求可能是无法从客户那儿预知的，这意味着，软件开发者无法获知产品将处于何种规模的云朵中，甚至这片云彩的大小是否足以容纳产品都将是未知数。
• 程序员需要知道产品在云平台上的瓶颈所在，而客户则想了解如何使用最少的计算资源就可以满足实际情况的需求，这需要数据来支持程序员和客户的想法。平衡点的权衡是一个重要的课题，而程序员和客户由于视角的不同，必将在测试规模上产生分歧，无法确定因此产生的计算资源需求量。
• 过度采购必然会产生浪费，程序员当然有理由相信客户已经拥有了足够的计算资源，这样产品可以直接在实际应用环境中进行各种系统测试。然而，客户也同样有理由相信企业在推出自己产品的同时，也可以告知真实的计算资源需求——两者都不愿看到由于过度采购而产生的不必要浪费。
• 维护一套云平台需要投入大量的人力资源，硬件的损坏对于海量的计算资源来说几乎必然在每时每刻都会发生。聘请大量有经验的人员来维护这些可能大部分时间由于无测试任务而处于闲置状态的计算资源，显然也是一种浪费。除此之外，网络的搭建、环境安全上的顾虑都将大大增加维护的成本。
• 这样一套用于系统测试的模拟环境，对于QA来说，是需要投入大量精力用于搭配和部署各种组件的。这无疑将带来额外的消耗，同时也将使QA无法全神贯注地投入到产品的测试中。

灵感与曙光

好在大多数IT从业者都充满激情，面对困难总会迸发出超乎寻常的灵感火花，以接受挑战并解决难题。上述的困难，对于这些才华横溢的行业开拓者来说，似乎也总该有合理的解决办法。曙光终于在本世纪的第六个年头开始出现，由Amazon带来的EC2(Amazon Elastic Compute Cloud)服务使得解决以上困难变得更加容易且低成本。

Amazon是一家伟大的公司，它不仅仅在卖书，还在改变历史。EC2服务无疑正是Amazon改变历史的一个强有力证据，它告诉我们Amazon还能够贩卖富余的空闲计算资源。在Amazon EC2服务出现前，计算资源只能通过购买实体硬件获得。但客观的现实是，我们所需的计算资源经常会因实际需求而发生变化。例如，对于C2C网站来说，某些特殊的节日，对于其主站点的访问量会达到平时的数倍。但如果根据最高访问量来购买实体计算资源，那有可能在大多数的空闲时段将会处于闲置状态。这还没有算上硬件的折旧损耗，如此一来将会产生严重的浪费，如图1所示。

[caption id="attachment_9319" align="aligncenter" width="340" caption="图1 需求总是呈现出波浪形，采购计算资源可以满足最大需求，但多余的资源在波谷处又总是被浪费"]

[/caption]

有没有什么方案能够让我们根据实际需求来启用合适的计算资源呢？Amazon给出了答案。无论是Core、Memory还是Disk，对于Amazon来说都仿佛是可以被租赁的汽车，当你恰好需要的时候，你将以极低的成本(相对于购买一辆汽车来说)获得它们的使用权。在你使用完毕后，完全不必考虑这辆汽车是否有损坏，只需要归还这些汽车就行了。甚至Amazon还顺带帮你完成了租赁资源的升级和保养，使用者永远不用担心租到的汽车会发生故障(也许还是有一些微不足道的故障概率)，或者外观不够新潮，马力不够强劲。

闲话少说，让我们从一个实例来看看Amazon EC2服务改变的历史。

建立在云中基石上

这个实例来自于趋势科技中国研发中心的一群充满热情的工程师们，他们在2009年接到了一个分布式存储数据库的开发任务，很快他们在研究了各种可行方案之后，制定了技术路线，确定将基于Hadoop/HBase这样的并行计算框架来开发这个产品。这个产品被正式命名为GMS(Global Meta Store)。

GMS在HBase的基础上补充了一些更为有用的功能。例如，HBase作为典型的Key-Value型数据库，其本身只提供了单索引的快速检索能力；而GMS为其扩展了多索引实时检索的支持。再例如，HBase本身是不支持SQL语句的，使用者为了查询自己需要的数据，标准做法是编写一个包含了查询语句的jar包提交到Hadoop的MapReduce计算框架下进行查询；而GMS则支持部分类SQL语句的直接提交和执行，这将极大地提高产品的用户体验。此外，HBase本身不提供对BigTable的备份还原功能；而GMS也对这个极为常见的需求进行了开发，使得数据在HBase中的可靠性大为提高。

然而，在GMS产品开发阶段完成之后，他们的QA同样也遇到了缺少云平台进行系统测试的难题。他们无法回答，在真实的云平台上，支持多索引的GMS会比HBase的数据插入性能下降了多少；他们也无法回答当数据量达到何种规模的时候，客户需要为他们的云增加计算资源，更无法指导客户该如何增减计算资源。甚至由于不良配置的Hadoop/HBase可能造成性能瓶颈或者稳定性不佳，也是他们所无法预知的。而等到产品发布之后再进行这些系统测试，又将会影响其他依赖于GMS的产品，使得这些产品不得不重新进行设计，更严重的情况下，甚至会影响云平台下全套产品的基本架构。同时，采购足量的计算资源用于这个产品的系统测试也是不现实的，一方面，从成本角度考虑，采购带来的花费太大；另一方面，从采购到搭建到完成测试，所需的时间周期太长，会影响到其他依赖于GMS的模块的开发进度。

对于GMS这样的项目来说，系统测试——尤其是性能测试，又是极为必要的。无论是依赖于GMS的产品，还是云平台的维护者们此时都需要了解GMS的具体能力，他们需要看到可靠的数据来说明GMS的真实性能。然而对于GMS开发团队的QA来说，除了上文的两方面考虑之外，凑集足够规模的计算资源来模拟现实运作环境还有两点困难：其一是因为我们需要不止一朵云来模拟不同的运作环境，其二是因为即使是Hadoop/HBase的最低推荐运行环境所要求的每个节点的硬件配置也是相当高的。这个时候，GMS团队想到了利用Amazon EC2提供的计算资源租赁服务来实现系统测试。

恰当的解决方案

GMS产品，包括Hadoop和HBase，都有一个共同的特点，而这个特点也往往是大多数云平台应用的共同点，那便是这些模块的配置在所有节点上都是完全一致的。这意味着，只要在一个节点上配置完毕，便可以将这个节点直接克隆到其他所有节点上。这当然也意味着，虚拟机的镜像文件在这里将大有作为。

Amazon EC2为使用者提供了类似于虚拟机镜像的AMI(Amazon Machine Image)，这样就可以在EC2上申请一个已安装了CentOS系统(也可以是其他系统，如Ubuntu、Fedora或Windows)的Instance，在配置好我们需要的组件后将其保存为AMI，然后从这个AMI启动所有的Instance，便可以轻易地搭建出产品运行所需的集群。计算资源的伸缩在EC2上也是相当容易的一件事情，可以简单地通过Amazon提供的RESTful Interface来启停Instance，也可以通过EC2提供的Elastic Load Balancer服务来根据集群整体负载状况自动启停Instance。在EC2上运行的Instance一旦被使用者销毁之后，其上发生的所有改变都将随同Instance一起消失。这看起来不像是一个好消息，但实际上对于测试来说却是省去了集群初始化的麻烦。当然EC2也提供了永久保存 Instance的办法(前提是用户持续为占用的空间付费)，称之为EBS(Elastic Block Store)，如图2所示。

[caption id="attachment_9320" align="aligncenter" width="313" caption="图2 使用EC2的流程"]

[/caption]

Amazon EC2提供的强大功能远不止上述这几项，由于其在五个地方(US Virginia、US California、EU Ireland、APAC Singapore、APAC Tokyo)拥有实体物理机，因此我们运行的Instance也可以任意分布在这些地方。从大的方面来说，分散节点到物理世界的不同位置，有利于在发生自然灾害时不至于丢失数据；从小的方面来说，也可以方便用户模拟真实的网络分布环境。同时，各地区申请运行Instance的花费也会存在一些差异，这些信息都可以在Amazon EC2的首页上查询到，最便宜的租赁地点当属美国的Virginia。为了更节约花费，Amazon还推出了竞价机制，在申请Instance的时候，如果EC2的计算资源比较富余，那么通过竞价，使用者可以低于普通方式的费用来获得Instance的使用权；相反，在计算资源紧张的时候，竞价方式可能会提高到接近于普通方式的花费，但最多也不会超过普通方式。竞价机制的缺点在于，申请者有可能一次性无法申请到足够数量的Instance，或者申请到的Instance可能会在不同的物理位置，这将带来一些网络I/O的花费，但是比起普通方式申请Instance来说，竞价机制节省下来的成本还是非常令人心动的。

前面提到，在EC2上运行的Instance一旦被使用者销毁之后，其上发生的所有改变都将随同Instance一起消失。这里的消失，不仅包括数据的消失，也包括IP地址的消失。因此，在某些情况下，我们有必要申请Elastic IP用于公网的永久性服务。同时为了这些服务的高可靠性，我们可以使用 Elastic Load Balancer服务，当负载加重的时候，EC2会按照我们设定的规则自动增加节点数量；反之，EC2将会销毁节点以节省用户的开销。

简单的流程

GMS的性能测试是完全使用EC2提供的云平台完成的。QA们制作了一个自动化脚本，通过Amazon EC2的RESTful Interface来实现云的搭建。这个脚本完成的功能和流程大致如图3。

[caption id="attachment_9324" align="aligncenter" width="300" caption="图3 在EC2中进行性能测试的流程图"]

[/caption]

1. 从配好的AMI启动足够数量的Instance。
2. 自动获取所有Instance的内网IP地址和Hostname。
3. 根据网络信息自动分配各Instance担负的角色，部署Hadoop和HBase到各节点，将其启动并检查进程运行状态。
4. 部署GMS产品和性能测试客户端到集群中。
5. 执行性能测试，并收集测试结果。
6. 通过邮件方式传回测试结果，随后销毁Instance。

取得的成果

通过这个脚本，GMS团队实现了模拟百数量级集群的性能测试和稳定性测试，而所需的花费仅是一台相当于Instance配置的实体物理机价格的不到二分之一，如下表所示。

使用恰当的方法解决实际问题，这正是GMS团队面对困难时迸发出的灵感火花。在这个实例中，QA们不用去考虑实体机的安装部署，简单的几行命令便可以置身于云中，甚至连安全方面的顾虑也可以避免了，因为EC2为其中的私云内置了防火墙，使用者可以通过AWS(Amazon Web Services)迅速配置允许外界访问私云的端口。

结束语

使用EC2不仅节约了花费，更令GMS团队开拓了视野和思路，他们将这种测试方法推广到了趋势科技中国研发中心的其他开发团队中，目前已有部分产品的系统测试是通过使用EC2平台来实现了，将来这样的应用场景会在趋势科技的开发团队中更加常见。

展望未来，我们不难发现，类似于Amazon EC2这样的计算资源提供商会越来越多(例如微软的Azure和天云的TCloud)，系统测试对于这样的云中基石来说，不过是牛刀小试，如今更有像Twitter这样的著名公司将自己的全部架构建立在了EC2中。可以想象，不久的将来，如何合理利用这些计算资源来完成我们的需求必将成为一个热点话题。这将是IT界的革命同时也是挑战，当然对于程序员们来说，这将是一场值得期待的智慧与灵感交融的盛宴。

趋势科技中国研发中心资深QA，在六年职业生涯中，开发和测试的经验恰好参半。2009年加入趋势科技至今，一直从事基于HBase的分布式存储数据库的研发。

作者刘星，趋势科技中国研发中心资深QA，在六年职业生涯中，开发和测试的经验恰好参半。2009年加入趋势科技至今，一直从事基于HBase的分布式存储数据库的研发。

作者孙靓，2005年加入趋势科技中国研发中心。现主要负责趋势科技GMS项目的测试工作。

本文选自《程序员》杂志2011年12期，更多精彩内容敬请关注12期杂志

《程序员》2012年杂志订阅送好礼活动火热进行中