虛擬化——互聯網時代的產品開發加速器

高技術高競爭的互聯網時代，對產品的交付時間逐步變短，而對交付品質的要求逐步提高，各種新創意、新產品層出不窮，市場允許的產品推出週期也越來越短，傳統的軟體發展模型已經無法跟上當前的需求，高效、便捷、 可反覆運算的產品開發模式也越來越為人們所關注，虛擬化技術正是體現這種開發模式最重要的工具。

從功能上講，虛擬化的優勢一是提高資源的利用率；二是提供多樣化的建構管理；三是提供快照的保存和恢復功能；四是提供產品動態擴展的能力，這些也都是互聯網產品開發模式所需要的重要特性。

我通過一年前的專案經歷和目前應用虛擬化技術後的專案經歷的對比，來說說虛擬化技術如何在開發、測試、上線部署各個過程中的作用。

簡要介紹一下當時跟現在的開發條件。

一年前我所在的專案組一共有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%以內。 而當流量突然增大到預期之外時又非常難以應對，緊急上機器時間不夠，也十分容易出錯。 這是一個讓運維人員非常頭疼的問題。

我們線上也同樣應用的虛擬機器，使用虛擬化技術很好的解決了這一問題。 現在上線前，只需要準備好業務相關的鏡像即可，通過流量和性能監控，隨時觀察系統的負載概況，在負載低時可以選擇關閉幾台業務虛擬機器，當負載突發時立即通過鏡像創建更多的虛擬機器提供服務，從而高效的解決了流量變化的問題。

虛擬化技術在產品的整個上線流程中起到了重要的作用，是互聯網時代產品開發的有效工具，虛擬化技術的按需分配，快照功能，隔離功能，動態擴展能力等都將為產品開發提供極大的便利。

本文來自：HTTP://www.infoq.com/cn/articles/dh-virtualization-product-development-accelerator