案例 | 荔枝微課基於 kubernetes 搭建分散式壓測系統

騰訊雲原生發表於2021-04-20

王誠強,荔枝微課基礎架構負責人。熱衷於基礎技術研發推廣,致力於提供穩定高效的基礎架構,推進了荔枝微課叢集化從0到1的發展,雲原生架構持續演進的實踐者。

本文根據2021年4月10日深圳站舉辦的【騰訊雲原生技術開發日】 線下活動中,【荔枝微課】基礎架構負責人“王誠強”關於“基於kubernetes搭建分散式壓測系統”的演講整理而成。

關注【騰訊雲原生】公眾號後臺回覆【lzwk】,可獲得該演講PPT。

大家好,今天想和大家分享的主題是基於kubernetes搭建分散式壓測系統。
從背景、原理、實現、效果和未來方向5個方面講解了荔枝微課在基於 kubernetes 搭建分散式壓測系統上的實踐和思考。

背景

荔枝微課作為一個高速發展的平臺,面臨著業務流量越來越大的衝擊,特別是在去年疫情期間遭遇成倍流量增長的情況,是通過什麼方式輕鬆渡過難關的?以我在荔枝微課落地雲原生的經歷來說,為什麼我們要去實踐雲原生架構呢?只是因為是業內技術趨勢嗎?

其實這個是源於業務需要的,基礎架構最重要的是穩定高效,在我最早接手並負責荔枝微課基礎架構時,第一個季度的目標居然是應急響應,但我們都知道應急響應是治標不治本的,而要治本根治的話那麼就要對改掉整個底層基礎架構,這也是為什麼荔枝微課會去做雲原生實踐的原因。

而在做這個實踐的時候,我們還需要一個工具來衡量,那就是分散式壓測系統。我們早期使用過本地壓測、CVM伸縮組壓測等方案,但是他們有著本地資源能力有限、伸縮組申請變更麻煩、伸縮速度較慢、壓測指令碼和報告管理混亂,經常無存檔等缺點。於是我們採用了現在的基於 kubernetes的分散式壓測方案。

分散式壓測方案藉助的三個技術

原理上來講,需要藉助三方面的技術:

程式設計技術

這裡我們選擇了我們團隊較熟悉的python,不同團隊可以有不同的選擇;

壓測引擎

我們用的是Locust,因為它是用python寫指令碼,其實也可以更換成jmeter之類的其它壓測引擎,

kubernetes

主要利用它的服務編排技術來進行一個資源上的排程,經過我們測試,如果是普通叢集,在需要彈出叢集物理節點的情況下,全部就緒需要90秒,但是使用彈性叢集,則可以壓縮到15~20秒,所以推薦使用彈性叢集。
整個技術框架原理上,壓測節點分為主節點(master)、從節點 (slave)和監控節點(monitor)三種型別:

主節點

負責任務管理和資料採集聚合,本身不進行壓測任務

從節點

負責壓測任務

監控節點

從主節點將結果通過webhook傳遞給web服務處理端;

另外這些節點的狀態、日誌都會通過k8s的api進行採集。
根據壓測任務裡主從節點所申請的資源,叢集將提前伸縮好節點,並將任務分配到不同節點,以達到動態提高壓測能力的目的。

壓測流程

右邊為使用者所感知到的過程,壓測集中包括多個壓測場景,通過編寫壓測指令碼和配置壓測引數的方式生成壓測任務,並最終生成壓測報告。

左邊為python控制叢集來生成任務的過程,具體是渲染生成不同任務的yaml檔案後,生成相應的 job pod,然後持續將 pod 狀態 、日誌和壓測曲線結果反饋在頁面上。

整個過程所使用的技術並沒有多高深,主要是在叢集應用上的一種探索。

實現方法

使用yaml編排job服務,舉例slave節點來說,主要是宣告一個job型別的工作負載,將生成的任務從節點名以及任務生成的名稱空間渲染上去,然後設定我們的壓測基礎映象以及啟動命令,這裡我們用到了 kubernetes 的幾個技巧,一個是通過hostAliases進行內部解析,這樣可以對一些內網代理進行壓測,另一個是宣告申請資源CPU,以便在任務啟動前提前伸縮好物理節點提供資源,還有一個是通過configmap掛載可執行檔案,這樣可以注入引數在變化的啟動命令,而不需要重新構建映象。

然後說一下我們的程式碼框架,主要是分為這幾個模組:

  • k8s模組,提供一些如建立銷燬名稱空間或pod、檢視狀態、拉取日誌等api功能;
  • 基礎映象,較為簡單,主要安裝了一些基礎通用的庫,然後開通了一些內部使用的埠;
  • 任務編排宣告檔案,包括了我上面說的幾種節點服務;
  • 任務核心方法類,主要是將上述的流程程式碼實現,提供了一些方法,這裡限於篇幅就不具體展開了。

然後最後我們來看下效果:

這是我們壓測系統的管理介面,現在看到的是壓測集,方便集中管理。

這是建立壓測場景,並基於該場景編寫python壓測指令碼,並可設定我們的任務引數。

這是壓測任務詳情頁,可以看到壓測引數、狀態以及節點情況和檢視日誌。

這是壓測過程中實時生成的圖表,可以基於圖表情況進行分析。

未來改進方向

  • 引擎型別或版本允許選擇更換;
  • 批量定時分階段的自動壓測計劃;
  • 將所有涉及資源圖表關聯進來,形成更為詳盡的報告;
  • 任務資源限制與使用審批;
  • 報告分析結論存檔,相關問題追蹤處理結果存檔;
  • 相同條件的多次壓測結果對比展示;
  • 使用更為雲原生的方式管理任務的生命週期;

Q&A環節

Q:這個壓測系統對於測試人員有什麼要求嗎?

A:需要會使用程式語言編寫壓測指令碼,並有一定的分析思考能力,通過進一步封裝的話也可以降低這部分的要求,但程式設計的話能力會更強更靈活,比如一些複雜條件或者像要動態使用賬號的情況。

Q:你們的壓測會需要多少資源呢,是怎麼控制的呢?

A:我們這套系統,是根據任務需要自動申請資源的,任務結束時也就自動銷燬了,不會出現說一直佔用消耗資源的情況。

Q:這個對於服務在哪個雲有要求嗎?

A:雖然我剛才說到的叢集是TKE的,但kubernetes作為一項開源的、通用的標準化技術,只要能提供該服務的雲理論上都可以。

Q:你們壓測會壓生產嗎?大概多久壓一次?髒資料怎麼辦?

A:我們壓測會在儘量不影響使用者的情況下定期進行線上壓測,大概是每月一次,新專案上線前也會在測試環境壓,也有專門的壓測叢集來壓,髒資料的話也是要清的,我們有機器人使用者,可以針對這些使用者進行髒資料清理。

Q:我們公司已經有用幾臺伺服器來壓測,想問下為什麼要用kubernetes叢集呢?

A:一方面我們當時剛好在做叢集方面的實踐,另一方面呢,也考慮了叢集資源管理上的優勢,比如資源隔離或限制,因為有的時候測試是不太清楚自己需要多少資源的,不加限制的話有的時候會佔用比較多資源,還有就是任務狀態、日誌的收集還有就是我前面提到的一些叢集的特性。

相關文章