虚拟化——互联网时代的产品开发加速器-InfoQ

高技术高竞争的互联网时代，对产品的交付时间逐步变短，而对交付质量的要求逐步提高，各种新创意、新产品层出不穷，市场允许的产品推出周期也越来越短，传统的软件开发模型已经无法跟上当前的需求，高效、便捷、可迭代的产品开发模式也越来越为人们所关注，虚拟化技术正是体现这种开发模式最重要的工具。

从功能上讲，虚拟化的优势一是提高资源的利用率；二是提供多样化的配置管理；三是提供快照的保存和恢复功能；四是提供产品动态扩展的能力，这些也都是互联网产品开发模式所需要的重要特性。

我通过一年前的项目经历和目前应用虚拟化技术后的项目经历的对比，来说说虚拟化技术如何在开发、测试、上线部署各个过程中的作用。

简要介绍一下当时跟现在的开发条件。

一年前我所在的项目组一共有 6 台开发机，2 台测试机，6 个开发人员和 2 个测试人员，机器由团队公用，每个开发人员会被分配一个以自己名字命名的独立账号，开发人员使用这个账号登录系统并进行开发工作。相信这也是大部分公司的标准配置。

现在我所在的项目组有 10 台开发测试机，在功能上没有做特别的区分，一共有 24 名开发兼测试人员，没有专门的测试人员。开发人员通过登录属于自己的虚拟机进行开发工作。

开发阶段的作用

虚拟化在开发阶段的作用有两个关键点：

第一，快速的环境搭建

开发初始，需要一个资源分配的过程，而开发人员往往无法得到需要的灵活的硬件资源，一般可以得到的是一个账号，和一个确定操作系统的机器，这有三个原因，首先是硬件资源有限，无法保证每个开发人员能有一台独立的开发机，只能采用公用机器，通过不同账号进行隔离的方式；其次由于机器共同使用，多人同时开发，所以无法依照自己的意愿进行环境调整；第三是因为服务器进行操作系统变更的代价很高。如果开发确实需要定制的环境，需要变更操作系统，在我们以前的团队里，需要提交单独的变更单，经重重审核后到系统工程师，系统工程师到周五安排下周的操作，所以从提起申请到操作一般要经历一周时间。即使进入实际操作阶段，系统重装耗费的时间也很长，安装系统的时间占用在 30 分钟左右，服务器系统重启的时间在 8-15 分钟，重新下载和配置软件的时间在 1 小时 -3 小时不等。总体说来，重建一次系统环境至少需要半天时间。

在这种情况下，开发人员在开发伊始就没有得到期望的良好开发环境，只能在整个开发过程中带着镣铐跳舞。

再来看一下目前的状况，我们应用 Xen 虚拟化技术，很好的解决了这些问题。开发人员在开发进行之初，提交需要的环境配置列表，配置管理人员按照开发的请求，从镜像库里选择对应的虚拟机镜像，再找一台合适的物理机由该镜像生成虚拟机，交付给开发人员使用，虽然硬件资源依然有限，但由于虚拟机所占的物理资源较少，可以保障每个开发人员都拥有自己独立操控的环境。而整个虚拟机的创建时间在 1-5 分钟即可完成。

由于拥有的是独立的一台虚拟机，其资源跟其他的开发人员完全隔离，开发人员可以自主进行系统配置。在需要的时候也可以随时进行重装请求，重装操作非常简单，删除虚拟机，从镜像库生成一台新的虚拟机即可，原先需要一周多提供的初始系统现在在 1-5 分钟即可完成。

图一：目前一个开发人员的的开发测试机

第二，独立的运行环境

在以前的配置下，由于系统被多人共用，或者已历经开发多个项目的时候，很多系统环境参数已经经过了多轮配置，导致整个开发环境暗流汹涌，隐藏着诸多冲突因素。同时，由于多个账号同时使用，分属于不同账号的模块之间也会产生冲突，最常见的如端口冲突，这往往通过开发人员之间协调好彼此模块使用的端口号解决，但也不可避免的遗留下一些问题，比如我们遇到过一次故障，就是开发在提交产品时忘了修改内部某个模块的通信端口导致的。还有一次开发人员在程序出错之后花费了大量时间精力查找原因，最后悲催的发现是另一个开发人员在系统上做了某个工具库的升级。此外，由于某个开发人员的程序问题把机器跑死从而导致其他程序无法运行的问题更是家常便饭。

迁移到虚拟化的环境下，共享开发环境的问题也迎刃而解。由于虚拟机自身的独立性，每台虚拟机都是一整套完整而隔离的系统，虚拟机之间有充分的隔离，开发人员不用再担心端口问题，系统参数问题等，用自己的机器自然对系统的一切变化均了然于心，当出现 bug 时，开发人员也可以把时间精力集中在程序功能的调试上。

测试阶段的作用

开发完成后进入到测试阶段，虚拟化的重要性更加显现，虚拟化在测试中的重要性体现在四个方面：

第一，灵活的环境选择

测试人员首先需要有一套良好的测试环境。在以往的测试中，需要由测试人员提出环境申请，在测试机器上重装系统，按照测试要求配置好系统参数。在物理机上操作，一般 1 天左右，测试人员可以拿到自己需要的环境。但由于测试的多样性，如果说开发阶段一天时间准备好环境还能接受的话，对于测试来说这是非常难以容忍的，因为测试更强调环境的多样性。例如我们的产品需要同时提供对 Windows 环境，Linux 环境的支持，以及对 Windows 和 Linux 的各个不同的发行版的支持。这种情况下，每次产品测试都是一个痛苦的过程，系统工程师需要根据测试进度随时重装系统，以便提供出不同环境配置的机器，而测试则等待系统工程师提供好环境后才能进行下一个环境的测试。

即使环境已经提供，每个环境里还需要加上不同的应用组合，比如前端产品需要测试对主流浏览器的支持情况，浏览器包括 IE，firefox，chrome，safari，opera 等等，对于每款浏览器还需要考虑不同版本，如 IE6，IE7，IE8 等。更可怕的是，同类型的很多浏览器不能同时装在一个系统里，IE 系列即是如此，这种情况导致了测试环境的变更极其频繁，系统工程师往往不堪重负，测试工程师则抱怨需要的系统环境迟迟不能提供。

在我们当前的项目组里，该问题已经不复存在。虚拟化系统里早已创建好对应于多个不同操作系统的模板，例如 CentOS 5.4，Ubuntu 10.04，Windows 2003 Server，Windows 2008 Server，Windows xp，Windows 7 等等，在测试需要的时候可以由模板迅速生成对应的虚拟机，每个虚拟机的生成时间在 1-5 分钟。同时，对应不同的应用和环境的组合，也单独生成一个模板，比如 Windows 2003 server+IIS 的模板，Windows xp + IE8 的模板，需要时轻轻点击生成虚拟机，一套可用环境就出现了。模板的形式见图二和图三。

图二：截取的 Windows 部分镜像

图三：截取的 Linux 部分镜像

第二，资源的按需分配

虚拟化情况下资源的按需分配是一大重要特性。如果物理资源足够多，那么可以在每台物理机上单独部署一套环境，提供给开发人员使用，但这种方式占用的资源极多，比如我们目前已经保存的镜像环境就有 56 个，如果使用 56 台物理机搭建环境的话则是极大的资源浪费。

正是由于测试环境的机器有限，需要虚拟化做到真正的按需分配资源。虚拟机只有在运行时才会占用 CPU，内存，网络资源，当虚拟机关机时，其消耗的仅仅是镜像占用的磁盘资源，目前我们每个初始镜像的大小都在 1G 以内，56 个镜像占用的空间都没有超过 50g。

同时，工程师在测试时也养成了良好的使用习惯，停止测试时关闭虚拟机，这样现有的 10 台测试机可以发挥 20，甚至 40 台机器的作用。

资源按需分配的另一点好处是测试人员可以轻松保留以往的测试环境，一年前我们隔壁的项目组有个约 20 台机器组成的集群，是为很久前的一款产品测试准备的，那款产品还在维护，所以这套测试环境大概每个月使用一次，但因为配置复杂，资源没人敢回收利用，只能由其一直闲置。

而在用了虚拟化技术之后，我们对项目中对应于每个模块发布版本的测试环境，都做了做一份备份，在测试完成后关闭虚拟机，制作镜像保存。在需要的时候再由镜像生成虚拟机进行测试。其代价仅仅是多占用了一些磁盘空间。

第三，高效的快照回放功能

快照回放功能对于测试而言意义极其重大，实际上这也是最受测试工程师们欢迎的功能，没有之一。其主要的应用场景有两点：

第一是用于分支检测的场景。产品从 A 点有两个选择方向 A1 和 A2，测试工程师选择路径 A1，当 A1 测试完成后需要回到 A 点进行 A2 的测试。在以前，我们是通过先重新走到 A，再进行下一步操作的。当路径复杂之后，这是一项非常耗时的工作，而且因为两次操作不可能完全一致（比如每步的操作延迟不同）可能会导致无法真正走到 A 点，从而降低了测试的可靠性。

虚拟化快照是解决这个问题的最佳方案。从我们的实践经验来看，在面对分支选择时，只需要在 A 点做一份快照，接下来便可以放心的进行 A1 分支的检测了。当 A1 检测完毕后，恢复虚拟机至 A 点快照的状态，接下类就可以顺利的走 A2 分支了。整个过程非常流程，减少了通过操作恢复 A 状态的工作，快照的创建和恢复都在 1-2 分钟内，大大节省了测试时间，也提高了测试可靠性。

第二是故障现场保留。以往测试人员在发现产品 bug 后，会进入一个两难的境地，该 bug 很可能无法每次都顺利复现，那么如果继续测试会破坏现场环境；如果保留现场叫 RD 来查找原因，可能临时找不到 RD，而且 RD 定位问题本身也需要时间，这种情况下环境被占用了，进一步的测试工作就被耽误了。

利用虚拟化快照技术，测试人员只需要在此时进行一次快照，保存完整的虚拟机环境，可以在 RD 有空时恢复这个快照给 RD 看，或者直接将虚拟机镜像丢给 RD，RD 从此镜像生成虚拟机，进行 debug 工作，原先的测试工作也可以顺利的走下去了。

对于 rd 而言，有了一份保存 bug 后的环境，也可以放心的进行各种调试工作了。

第四，特殊环境的模拟

由于测试环境的硬件限制，在很多时候无法模拟出产品的真正应用场景，比如我们正在做的一个网络模块开发，需要测试三块网卡情况下的应用场景，但是测试机只有两块网卡，无法模拟出来。于是我们在 Xen 的同一个网桥上了里创建 3 块虚拟网卡，就很好的解决了这个应用场景面临的问题。

另外，我们另一个项目需要进行集群化测试，同样是由于测试环境的硬件限制，无法达到集群化的机器数量要求，于是我们在一台物理机上搭建多台虚拟机，解决了这个问题，最后这个项目是创建了 20 台虚拟机完成了测试。

最后来说说产品部署和运行阶段，虚拟化的意义。

部署、上线阶段

第一，增强产品预发布功能

在产品正式上线之前应该有一个预发布的过程，即将产品先在预发布环境上线，跑一段时间稳定后再上线生产环境。因此预发布环境需要模拟生产环境的系统架构，并要保证机器数量，由于硬件资源的限制，这个过程甚至经常被取消掉，从而增大了产品风险。

目前我们团队，基于虚拟机搭建了一套完整的预发布环境，跟生产环境做到了基本一致，在多次的产品上线过程中也现了很多问题，做到了防患于未然。

第二，产品服务能力的动态扩展

产品上线后一天的业务流量往往并不是一个正太分布，而是较为极端，在早晨流量最低，在晚上流量突发很高。以往的业务上线时，一般都按照预计的最大流量上线机器，当流量低时系统资源十分浪费，比如很多物理机器的 CPU 利用率都在 1% 以内。而当流量突然增大到预期之外时又非常难以应对，紧急上机器时间不够，也十分容易出错。这是一个让运维人员非常头疼的问题。

我们线上也同样应用的虚拟机，使用虚拟化技术很好的解决了这一问题。现在上线前，只需要准备好业务相关的镜像即可，通过流量和性能监控，随时观察系统的负载概况，在负载低时可以选择关闭几台业务虚拟机，当负载突发时立即通过镜像创建更多的虚拟机提供服务，从而高效的解决了流量变化的问题。