分散式系統測試的應用方法——場景注入測試

騰訊 王德寶

在大數據浪潮下，海量數據處理能力的提升是推動大數據不斷前行的基礎。俗話說，工欲善其事，必先利其器，由於處理能力亟需提升，因此海量數據處理的分散式系統應運而生，例如hdfs、hadoop、spark、storm、MQ等等。

分散式系統運行的核心是集群化部署，分散化管理，任務均攤，平衡化運行。節點異常、機器異常、運營操作、策略變更都會打破原有的平衡狀態進入一種不平衡狀態，平台通過狀態管理和協議交互逐步演進到另一種平衡狀態，同時要保證這種演進過程中系統計算正確性。打破原有的平衡狀態的場景非常多，複雜的平衡演進過程中又有很多的場景可能出現，這種交織的變化對分散式系統測試，特別是穩定性測試帶來非常大的挑戰。

本文將從分散式系統出發，重點介紹分散式系統穩定性測試中的一種應用方法——場景注入測試。

分散式系統測試：

測試執行過程可以歸納為構建輸入（包括數據和系統場景）、驅動輸入、收集結果進行校驗（包括系統狀態、計算結果），如下圖。

除海量數據的湧入對系統的穩定性造成很多衝擊外，複雜的場景變化也時刻敲打著系統的穩定性。下面我將重點分享場景注入測試在分散式系統穩定性測試中的應用。

通過數據驅動分發到兩套環境（一套穩定版本環境，一套被測系統環境），對被測系統測試版本環境注入各種場景，通過對比兩套環境下的計算結果，挖掘測試版本的系統bug。

對於節點多、角色多、交互複雜的分散式系統來說，節點異常、機器異常、網路異常、運營操作、擴縮容等等場景不可避免，集群規模越大，場景的交叉出現概率倍數增加，時刻對平台的穩定性進行衝擊。既然這些場景不可避免，通過人為地觸發這些場景，能提前暴露系統的問題，是一種非常有效的預防措施。

分散式系統的特性是高可用、高容災能力。那麼，節點異常、機器異常、網路異常、運營操作、擴縮容等等場景的出現，都不能影響系統的穩定性運行和任務的正常處理。因此，把系統可能發生的場景進行分類並構建出來，注入到被測系統，並與其他測試手段結合使用，即可以提前暴露系統的問題。

基於以上思路，在數據平台部的很多系統上進行了應用，都取得了很好的效果。

鑒於場景注入測試在分散式系統上應用的效果，以及具備場景可重複使用、公共場景可在不同系統上通用、與其他測試方法可相互獨立無耦合等特性，著手建設了場景注入測試平台，在簡單的後台系統、大規模的分散式系統上都能進行應用。資源異常、網路異常這樣的功能異常都已經構建，可以應用到各種被測系統；測試同學可自行豐富被測系統的特性節點異常和運營操作等場景。

場景注入流程：原子操作與集群中的節點相結合組成一個場景；此場景被某個場景注入任務選取並被TriggerServer掃描得到，TriggerServer把此場景的原子操作ID發送給部署在各個節點上的場景執行CaseAgent，CaseAgent接收此消息後從原子操作伺服器上把原子操作拉取到本地進行執行，實現場景的觸發。

在分散式系統中，集群規模大，節點多，多個場景可能同時發生，例如，一個節點宕，同時網路異常，導致集群無法快速感知此節點狀態；一個不平衡狀態演進過程中發生其他場景等等，此類多場景同時觸發的場景對系統的穩定性考驗更大。在平台中通過構建一種多步驟場景來實現多場景同時觸發的場景。

原子操作分為公共原子操作和系統原子操作。公共原子操作由資源異常和網路異常組成，可以被所有系統所用；系統原子操作由節點異常和運營操作組成，可以被此系統所用測試環境中應用（功能測試環境、穩定性環境、准現網環境）。

一個原子操作由兩部分組成，操作的發起action和操作的恢復recover。操作的發起action在某個節點上執行就產生某個場景，操作的恢復recover在此節點上執行則此場景恢復取消。

原子操作由單獨的伺服器管理，通過原子操作名進行區分，CaseAgent從伺服器上拉起原子操作到執行節點上執行。

要求執行某個原子操作action，未被recover前，再此執行此原子操作action將失敗。例如，原子操作action是讓節點cpu消耗到90%的高負載下，如果再此執行action已無意義了。因此設計原子操作action時必須注意此要求。

要求可重複執行recover操作，但效果要相同。例如recover是啟動某節點的進程，重複執行多次，節點的進程只能啟動一次。要避免重複執行後，導致多個進程被重啟。（當然不排除要啟動多個進程的場景，希望通過其他方式實現。）

場景：由原子操作與集群節點組成，相互獨立管理。原子操作一旦建設，可以重複利用個，與被測集群節點組合成場景。

單步驟場景操作(單時間內單場景)：僅由單個原子操作與某個節點組合而成，執行過程為先執行action，再執行recover。

多步驟場景操作(單時間內多場景)：由多個場景組合而成，執行過程為先執行所有步驟的action，再執行所有的recover。先執行所有步驟的action是保障多個場景能同時觸發。

TriggerServer的任務調度

選取要執行的場景操作，提交一個場景注入任務，還包含場景執行的用戶、任務執行重複次數、場景觸發方式等信息。

場景執行的用戶：場景在某個節點上觸發時是以什麼用戶執行。除網路異常由root來執行tc netem和iptables命令外，其他場景都可以有用戶自己指定要執行的用戶。

任務執行重複次數：用戶可以指定此任務的所有場景的執行重複次數，對於分散式系統來說，很多異常是偶現的，需要多次執行某些場景下才可能偶然出現一次。

場景觸發方式：支持兩種方式，時間間隔觸發和定時觸發。時間間隔觸發，指定場景之間的執行時間間隔。定時觸發，指定場景是按某種定時規則觸發，與crontab配置方式一致（當前僅支持分鐘和小時），幫助系統某種整點時刻下特性與場景的組合觸發。

Action和recover間隔：可配置action與recover的執行時間間隔，適應action與recover快速執行、action執行後一段時間再執行recover等場景。

由於系統原子操作與具體的系統耦合性太高，以下僅以公共原子操作為例進行實例說明。

當前機器資源異常，CPU消耗高負載通過無限循環的加乘進程實現；內存不足通過申請指定內存大小，循環執行memset保障其在物理內存中實現；文件/目錄不可讀通過修改其讀寫許可權實現。網路異常，通過tc netem（tlinux2.0已開啟）和iptables兩種命令實現。

以CPU消耗高負載為例說明原子操作構建方式：

Cpu_load_make是此原子操作名，對應原子操作目錄，包含action.sh和recover.sh，其他幾個腳本為action.sh和recover.sh執行服務。

action.sh中要記錄action.sh執行的狀態（寫入runFlag.txt），如果已經執行過，就不能再次執行。

recover.sh執行後把執行狀態修改掉，以便下次action.sh能順利執行。

除手工構建場景外，平台還提供了自動生成場景的功能，解決大集群情況下重複的配置場景，同時通過自動生成場景提升場景的覆蓋度。

場景分為單步驟場景和多步驟場景，場景的自動生成也分單步驟場景的自動生成和多步驟場景的自動生成。

單步驟場景的自動生成：

選取要生成場景的操作原子和操作節點，生成一個自動生成任務。由TriggerServer根據任務的操作原子和操作節點進行差乘生成場景。

多步驟場景的自動生成：

選取已有的場景，生成一個自動生成任務。由TriggerServer根據任務的場景和場景進行差乘生成新的場景。

選取的場景還可以是多步驟場景與多步驟場景進行自動生成場景。隨著節點數、原子場景的增加，多步驟場景生成的場景數非常龐大，執行周期非常長；隨著步驟的增加，對應場景在現實情況下被觸發的可能性也大大降低；建議測試過程中可逐級生成場景進行測試，掃清一級，再生成另外一級的場景。

在數據平台部，有個分散式tube系統，是個生產消費模式的MQ系統，提供存儲外部生產的數據，可被消費者進行消費這些數據，生產和消費的數據在系統穩定情況下保持一致，在異常場景下不保證高一致性，允許少量數據丟失。

這個項目質量保障的重點是無異常情況下生產和消費高一致，有異常情況下數據只允許少量丟失，場景注入是非常有效的測試手段。

對於此系統的重要觀察點就是生成數據的一致性，校驗分作兩種類型，有損校驗（異常場景）和無損校驗（無異常場景）。為了方便生產和消費數據校驗，把系統運行狀態分成穩定運行常態和異常觸髮狀態；場景的觸發為定時觸發方式，每10分鐘觸發一次，action與recover時間間隔2分鐘，因此穩定運行常態和異常觸髮狀態按5分鐘單位交替出現； 5分鐘時間內生產的數據打上此5分鐘時間戳印記，消費端就可以通過時間戳統計此5分鐘消費多少條進行校驗了。

在此版本測試中，僅場景注入測試發現bug 19個（嚴重10個）。

大數據分散式系統的存儲與計算集群規模和複雜度在不斷增加，帶來的穩定性風險也在快速增加，場景注入測試框架可以說是隨著互聯網的發展應運而生的。在數據為王的未來，系統的可用性需要達到一個更高的層次，場景注入測試將成為了系統測試中不可或缺的一環。數據平台部場景注入測試平台場景可以不斷完善支持更多的場景，與其他測試方法獨立，又可以相互結合，具有良好的可拓展性和易用性，能夠滿足的各類軟體的測試需求。希望大數據的浪潮下，測試也能一起弄潮前行。