大規模分布式系統的測試實踐(2)

　　有一個很典型的例子。早期，我們內部開發一個基于表結構的存儲引擎時，曾出現過這樣一件事情：測試程序在最終驗證一致性時，一直都是通過的，但業務方和我們一起做E2E測試時，會有很低的概率發現數據讀出來是錯誤的。測試人員百思不得其解，最后發現，這份數據在寫入的時候，會先在三個地方進行修改，但由于一些時序和鎖的問題，在改過了兩個地方之后就返回成功了，第三個地方是在內存中，過一陣子就會被重新刷成正確的值。如果當時測試的同學知道系統里面的這些設計，當時就會設計寫入過程中，對數據一致性進行實時檢測，就不會在代價更高的E2E測試中發現問題，解決的效率也會因此而提高。

　　帶壓力和隨機故障模擬的長時間穩定性測試

　　文首提到大規模生產集群上的問題，很難在小規模的測試集群上發現。究其原因，主要是兩方面導致的。

　　大規模集群中原本小概率的單機故障會隨機器數增加，導致集群整體的硬件故障率線性提升，甚至多種故障同時發生的概率也大大增加。

　　機器數增多會導致對飛天模塊的壓力點發生轉移。以彈性計算(ECS)為例，在300臺變600臺時發現，原本擔心的文件系統Master還未成為QPS瓶頸，負責鎖文件協同的命名服務首先成為瓶頸。

　　此外，各種故障的組合爆炸也讓完整的容錯測試在設計和執行上的代價變得太大。

　　為解決上述困難，在飛天測試實踐中，我們逐漸積累出一套帶背景壓力和隨機故障模擬的長時間穩定性測試方案。背景壓力主要是針對各個底層模塊的讀寫壓力，通常會針對某類應用場景來模擬。

　　基于分而治之和系統仿真的方法，我們實現了一些輕量級的壓力工具，讓各模塊的Master機器和Slave機器分別接受到大規模生產集群上的類似訪問壓力和連接規模。另外，還增加一些諸如CPU、Memory、Network的資源消耗器，以模擬生產環境業務繁忙導致機器資源緊張的場景。

　　故障模擬上，一方面，盡可能豐富軟件手段模擬軟硬件故障，比如磁盤錯誤(包括壞盤、只讀等)、機器宕機、重啟、斷網、交換機重啟、主要模塊進程重啟、假死等;另一方面，這些故障模擬操作都會按照預先設定比例進行隨機組合。在這樣的背景壓力和隨機故障操作下，長時間(至少7×24小時)持續運行上層應用模擬程序/作業，同時通過在線監控系統來檢查飛天是否正常。

　　簡而言之，我們用背景壓力解決壓力點問題，用長時間跑解決小集群的故障小概率問題，用隨機故障模擬和組合來解決容錯測試設計和執行的代價問題。

　　實踐證明，飛天很多重要的Bug都是通過這個測試被發現的。當然，這類測試也有短處，就是問題調查需要較長的時間，要求測試人員對系統有較深的了解和診斷能力。

　　結束語

　　大規模分布式系統的測試是一項非常有挑戰的工作。盡管我們持續落實各層測試，積累實踐經驗，創新測試方法，但由于測試條件的限制、生產環境的復雜，軟件問題仍然無法完全依賴測試消除。本文僅僅提到了飛天測試在Test in Lab方向的一些思考和實踐，完善的飛天質量保證體系其實需要Test in Lab和Test in Production雙管齊下，這才是飛天測試樂此不疲的努力方向。

　　作者許咼兢，阿里云飛天技術專家，負責飛天開放服務質量保障，長期工作在測試工作第一線，目前專注于分布式大規模在線場景的測試。

　　作者陳舟鋒，阿里云飛天技術專家，負責飛天基礎模塊集成測試。畢業于北京航空航天大學，畢業后一直從事軟件測試開發工作，曾就職于微軟亞洲工程院和搜索技術中心，在UI自動化測試和分布式系統測試上有濃厚興趣和較多積累。

　　作者鄭剛，阿里云飛天高級專家，負責飛天集成測試和版本發布。畢業于南京大學，主要興趣在大規模分布式系統的系統測試、持續集成和系統仿真。

原文轉自：http://www.programmer.com.cn/15093/