集約化後端裸雲系統的效能測試工具開發

什麼是集約化後端裸雲系統？ 後端雲是切除了所有用於前端訪問和部署的介面，只保留後端虛擬化管理平臺系統的雲。 因為不具備視覺化業務的任意前端模組，因此也進一步稱為裸雲。 相比于雲的前端系統，後端裸雲系統是一個緊湊化、集約化的負責雲虛擬化實現的內核系統。 對於公有雲，可以沒有前端系統，但絕不能沒有後端系統，因為後端集合了公雲系統基於HTTP://www.aliyun.com/zixun/aggregation/13883.html">虛擬化技術的所有核心操作， 是雲的基石。

區別于雲前端的效能測試旨在體現前臺交互級別的指標，雲後端性能則是基於純粹意義的評估，相當於對內核品質的評估，其重要性毋庸置疑。 不僅如此，基於裸雲系統的性能評估，即「內核」性能評估，是剝離了所有非內核因素干擾的評估，遮罩了諸如前端商業流程模組的干擾，反映的是雲系統流水線上信噪比最佳的評估結果。

本文以集約化後端裸雲系統核心操作之一的虛機創建為例，闡述了如何在該「內核」平臺上進行併發使用者虛機創建壓力測試的工具開發解決方案。 一方面展現給您在雲後端進行效能測試的實踐體驗，另一方面也提供給開發者很有複用價值的技術思路和方法論，供技術人員借鑒。

正文分六部分來探討，首先簡單描述集約化後端裸雲系統的概貌，接著分析效能測試需求，第三部分給出開發總體思路，第四部分介紹具體實現過程，第五部分給出測試結果和分析，第六部分對本文做概要性小結。

集約化後端裸雲系統

前文對集約化後端裸雲系統有了簡單介紹。 這裡結合圖例做進一步簡單說明。 如下圖所示，圖 1 是一個較為完整的全雲系統結構圖。 紅色框選的 BSS-Business Support Services，俗稱商業支援系統，是一個非常複雜的層，該層直接面對客戶。 如果把雲比作一個商業系統，那麼 BSS 便是系統前端，涉及商業流程的所有關鍵業務操作，均集成于此，諸如雲資源的的即時定制、資源付費模式的定制、收費流程、帳單提取、使用者管理等等。 本文所要討論的物件，恰恰是剝離了這一部分。 剝離後的系統擁有完整的 OSS 系統，即 Operational Support Services 層，我們可以把它理解為後臺系統，而且保留了所有和 BSS 交互的介面。 這些介面或棄而不用，或抽象化滯留。 這樣，一方面，集約化後端裸雲系統可以完成一個全雲系統可以完成的所有虛擬化業務邏輯；另一方面也保證了和任何前端模組的相容性和無縫對接。

圖 1. 全雲系統結構示意

測試需求描述

接著集約化後端雲系統的基本含義，測試需求相應簡單明瞭，即：在該系統上實現併發使用者同時觸發虛機創建，並獲得虛機創建成功率和創建所需時間。

進一步思考，該需求可以簡化為處理一個使用者的情況。 因為如果單使用者案例得以解決，則併發使用者可以利用多執行緒來後續實現。 然而，不同于有前端系統的雲：授權使用者可以在任何時間和地點，只需要連上 Internet 就可以部署虛機；僅包含後臺系統的裸雲平臺則需要使用者親自登陸某授權的 TSAM 伺服器 ( 關於 TSAM 請詳見參考資料 )， 通過特定的命令列觸發虛機部署。 其次，虛機創建的過程需要判斷虛機的健康情況，以及計算相關的時間段，這一系列位於生命週期內的操作需要精確的管理機制。

基於上述分析，需求可以提煉和歸納為四個小目標：

測試控管開發思路

測試需求的細化奠定了開發思路的框架。 這部分將圍繞第二部分「測試需求描述」所述的四個細節需求，進行開發設計。

首先，關於多執行緒啟動和相關初始化工作。 思路一是直接基於 JAVA 多執行緒技術，每個執行緒類比一個使用者。 思路二是直接利用 IBM Rational Performance Tester 的 Custom Code 嵌套技術，編寫自己所需要的類。 我們的結論是採用思路二，因為優點有三。 第一，RPT 的多使用者併發特點是本身已經內部集成好的功能，方便、安全，作為開發者我們只需要關注更多業務方面的邏輯，而不是重複開發；第二，Custom Code 技術並未限制開發者的自由，開發者完全可以像寫任何一個獨立的 JAVA 應用程式一樣實現自己的程式設計意圖；第三，RPT 已經封裝好的使用者測試類可以被開發者調用，極大的節省了開發者關於參數方面的設計精力。 基於這樣的思路，這個工作可以分解為完成兩個任務：第一，給每個使用者配備一個日誌檔案控制代碼，用來記錄這個使用者生命週期內必要的資訊匯總。 第二，提取每個使用者的出場順序標示。 這會在獨立命名虛機的時候有用，從而能夠準確定位該使用者所創建的虛機。

其次，如何實現單使用者業務主程式模組。 即，設計控制流程，如何用代碼來實現主控邏輯。 這個任務將在下一部分具體體現。

第三，解決主程式接入 TSAM 伺服器並實施命令交互。 具體的講，由於我們要打交道的後端裸雲系統的 TSAM 伺服器是 Linux 伺服器，所以我們的多執行緒控制器首先需要連通 Linux。 通過調研，我們發現 Ganymed SSH-2 for JAVA 是用純 JAVA 實現 SSH-2 協定的一個包，可以利用它直接在 JAVA 程式中連接 SSH 伺服器。 Ganymed SSH-2 支援 SSH 對話 ( 遠端命令執行和 shell 訪問 )、本地和遠端埠轉發、本地資料流程轉發、X11 轉發和 SCP。 這些都沒有依賴任何 JCE provider，而且所有這些都包含加密的功能。 這無疑是我們需要的。 我們的工作便是基於該包的 API，編寫和封裝屬於自身需求的特定類。

第四，如何實現虛機生命週期的記錄和相關操作管理。 為了即時地觸發相關命令，並獲取每個生命週期計時的關鍵節點，最終計算時間，我們同樣需要設計一個類，以方便和我們的主程式交互。 諸如記錄觸發創建的起始點，判斷結束點，有效捕獲健康情況異常的拋出點，設計虛機超時規定點等等。