騰訊區塊鏈測試團隊的混沌工程實踐

語言: CN / TW / HK

區塊鏈是一種由多方共同維護,使用密碼學保證傳輸和訪問安全,能夠實現資料一致儲存、難以篡改、防止抵賴的記賬技術,也稱為分散式賬本技術。 按照接入範圍,區塊鏈可分為公有鏈、聯盟鏈和私有鏈。 目前國內最普遍使用的是聯合行業或組織內成員搭建合作、共贏的聯盟鏈。 區塊鏈服務建立在分散式系統之上,可能遇到的故障非常多,不僅僅是節點故障、各種網路故障、檔案系統故障,甚至核心錯誤都時有發生。 如果區塊鏈服務不能很好地處理這些異常,那麼服務的穩定性將遭到挑戰,其後果也不堪設想。 出於此考慮,騰訊金融科技區塊鏈測試團隊建立了適用於區塊鏈領域的混沌工程實施框架。

1. 如何判斷區塊鏈服務是否正常?

區塊鏈往往是個基於EDA架構的自運轉系統,無請求時,也會有空塊產出,而聯盟鏈通常採用的是BFT類共識演算法,該類演算法支援3F+1容錯,所以判斷區塊鏈的對外服務是否正常不能單一依據節點程序是否執行來給出,這裡給出幾個體現區塊鏈服務是否正常的健康度指標,也就是混沌工程裡提到的穩態指標。

1)節點資料一致性

區塊鏈中的資料是經過共識節點交叉驗證後儲存上鍊的,所以正常預期是分散式的節點資料滿足最終一致性,這些資料包括區塊資料、交易資料、業務資料等。所以需要提供資料一致性校驗工具。

2)併發場景下區塊鏈服務的QPS/TPS

在穩定併發場景下,區塊鏈對外服務的QPS、TPS應該保持穩定,如果注入一些網路延遲、或者CPU高負載等異常,會導致QPS/TPS波動起伏,不再穩定。

3)併發場景下區塊鏈服務的響應時間(RT)

同樣地,在穩定併發場景下,區塊鏈對外服務的響應時間應該保持穩定,波動不大,注入異常後,會引起RT的波動,也會破壞系統穩態。

4)區塊鏈在一段時間內的round切換頻率

共識節點出現異常,導致發起的提案失敗,會引發round值的切換,觸發下一個節點發起共識,所以一個區塊內round值越大,說明系統出現問題的概率越大。

5)區塊鏈在一段時間內不同節點的高度差

區塊鏈是一個自轉系統,在無請求時,高度也會追加,正常情況下,不同節點在共識+同步的雙重影響下,高度不會差距太大,如果出現不同節點高度差有變大的趨勢,也預示著系統的穩態遭到破壞。

2.  提高混沌工程實驗的可觀測性

可觀測性,在系統中是非常重要的一環。通常來說可觀測性主要包含 Metrics(指標),Logging(日誌)和 Tracing(追蹤)。三者的關係如下圖所示:

Prometheus 已經成為了在監控領域的事實標準,然而對於日誌,卻沒有一個統一的答案。 比如 elasticsearch,fluent-bit 以及 Kibana 的解決方案,儘管這一套系統執行良好,但是卻會消耗比較多的資源,並且維護成本太高。 我們最終放棄了EFK的方案,而是採用了 Grafana開源的Loki 專案來作為日誌的解決方案。

Loki 採用了跟Prometheus一樣的標籤系統,可以很輕鬆地將Prometheus的監控指標與對應的節點日誌結合起來,並且使用類似的查詢語言去查詢。另外 Grafana 已經支援了Loki dashboard,只需使用Grafana就能同時展示監控指標和日誌。

  基於Log(聚合查詢)的區塊鏈可觀測性實現

3. 基於工作流的混沌工程實施框架

整個實施框架分為以下幾部分:

  • BlockChain :被測區塊鏈網路區域,搭建好的區塊鏈網路分為共識域和同步域,每個區塊鏈節點上都會部署相應的ChaosAgent。

  • Load/Test Script :壓測指令碼,用來對被測的區塊鏈網路施加穩定的基準流量,這些流量用例包括合約執行、交易上鍊、交易查詢等。

  • ChaosServer :負責接收指令請求,向具體的節點施加具體的異常場景,包括CPU、磁碟、網路、程序等。

  • Tools :配套工具集,包括部署、日誌收集、資料分析等。

  • Scheduler :混沌場景排程器,將某個時間點向某個節點施加某個異常,以工作流的形式放入任務佇列中,然後排程器按時取任務,然後向ChaosServer傳送命令請求。

我們藉助PipeLine搭建了區塊鏈的DevOps研發流水線。流水線將開發自測、構建、覆蓋率、質量紅線、異常測試、混沌實驗、自動化測試、報告收集等流程打通。

通過對區塊鏈實施混沌實驗,並將故障注入、實驗分析、可觀測性告警等流程自動化後,帶來的收益也較為顯著:

1)自動化實施混沌實驗,可減少手工構造異常場景的時間成功,對比如下:

2)模擬的故障場景豐富,可涵蓋接近真實生產的異常條件。

3)結合系統可觀測性的實現,可以實現分鐘級問題發現和告警能力,並且累計發現Bug數十個,迴歸混沌場景數百次。

4. 區塊鏈混沌實驗案例

1)網路分割槽實驗

場景介紹: 區塊鏈底層採用BFT共識演算法,容錯機制滿足3F+1,F為故障節點數,也就是當有10個共識節點時,是允許3個節點故障而不影響整體區塊鏈的對外服務,故注入網路隔離的異常,拆分7+3兩個隔離區。

場景示意圖:

實驗場景: 模擬10個共識節點被網路隔離成2個區,7+3分割槽

監控指標: 業務TPS、響應時間和資料的最終一致性

預期結果: 在該種分割槽情況下,滿足BFT場景要求的正常節點數,共識節點可以收集足夠多的投票資訊,共識成功,區塊鏈對外服務正常

實驗結果 :區塊鏈RPC介面對外響應超時,服務不可用

問題定位示意圖:

原因解析: 區塊鏈底層採用BFT共識演算法,某一節點共識失敗引發超時5s會切換round到下一個節點發起提案,RPC請求超時15s,當順序切換3個節點後觸發RPC超時,但是如果採用隨機切換策略或調整超時時間,共識成功。

2)BFT容錯場景驗證實驗

場景介紹: 區塊鏈底層搭建4(共識節點)+3(Seed節點)+1(同步節點)組網模式,模擬BFT場景,利用混沌工具殺掉1個共識節點和1個同步節點,正常情況應不影響共識。

場景示意圖:

實驗場景: 模擬4+3+1組網模式下,殺掉1個共識節點和1個同步節點

監控指標: 業務TPS、響應時間和資料的最終一致性

預期結果: 在該種分割槽情況下,滿足BFT場景要求的正常節點數,3個共識節點數正常,不影響共識和區塊鏈的對外服務

實驗結果: 區塊鏈RPC介面對外響應超時,區塊鏈網路共識失敗

問題定位示意圖:

原因解析: 新增同步節點時,由於服務讀取配置錯誤,誤把同步節點作為共識節點加入了區塊鏈網路,所以當由5個共識節點組成的區塊鏈網路,殺掉2個,共識失敗。

作者介紹

陳金龍 ,騰訊高階專項測試工程師,騰訊FiT測試中心區塊鏈團隊測試SE,研究生畢業後加入騰訊,一直從事區塊鏈底層技術的質量保障和專項測試工作,申請區塊鏈及測試相關專利20餘項,期間參與過深圳區塊鏈電子發票、微企鏈、至信鏈、NFT等專案。對分散式技術、智慧合約、密碼學等有極大的興趣。

參考連結: