全鏈路壓測流量模型

2022-09-16 22:18:30 字數 1618 閱讀 3333

現在全鏈路越來越火,各大廠商也紛紛推出了自己的全鏈路壓測測試方案。特別是針對全鏈路壓測流量模型,各家方案都有所不同。最近我看了一些這方面的資料,有一些感悟。分享給大家。

全鏈路壓測流量模型的梳理呢,這裡就先不講了,各家公司自有司情在。因為主要是全鏈路壓測模型的實現,其實實現也對應了流量模型的梳理結果。

業界常用的三種方一種:是基於業務模型的實現,一種是基於真實流量的錄製回放,最後一種是灰度分流。

這個是一種比較常用的方式。首先要對公司業務模型進行梳理,也就是說對公司的業務鏈路進行梳理。這裡的業務鏈路可能會比較複雜,不是像很多案例中到的了就非常流行暢的一條鏈路,中間很有可能會出現各種各樣的支路。如果圖圖形化展示的話,某一條鏈路應該就是乙個樹形結構。樹形結構的開始是使用者的入口頁一般就是入口頁面的登陸,或者說是首頁介面。樹形結構的右側是使用者的出口,這裡根據業務模型不同,使用者的出口會非常的多,所以大多數來時候來講,這就是乙個分叉的樹形結構。

要對這樣的流量模型進行實現。是比較困難的。首先要梳理出這樣的業務模型,就不太容易,再加上介面的相互呼叫啊,資料之間的相互依賴又可能是複雜程度增加乙個量級。所以一般的實現方式就是做歸攏。將比較複雜的樹形結構簡單化,或者乾脆將以個業務聯絡分解成n個列有鏈路。然後分別實現。最終將流量匯聚,就變成了整個業務鏈路的流量模型實現。

在業務模型實現這個方向,各家都有不同的實現方式啊,基本上就分為工具以及指令碼實現。我自己不怎麼用工具做過介面的效能測試,全都是使用j**a和groovy指令碼去實現的。首先,我會實現乙個基於介面的業務測試框架,將每乙個介面封裝成乙個方法。介面的引數即是這個方法的引數。然後將每乙個使用者封裝成乙個物件。將使用者的各種資訊變成這個物件的屬性。然後使用者在請求不同的介面的時候對使用者的屬性進行賦值這樣就達到了乙個引數傳遞的目的。然後通過呼叫不同的方法,我們就可以實現對不同介面的請求。通過控制引數或者說介面請求的頻率,我們就可以達到控制當前使用者。在整個業務鏈的走向。

基於流量錄製和回放,這個是最容易實現的方式。也是最容易貼近真實情況的方式。哦,我接觸到的主要有乙個回放模型,就是用golang語言寫的goreply。go語言的效能是非常好的,用於效能測試足夠滿足使用者的需求。大多數公司都會選擇在原生引擎的基礎上做一些封裝。然後對對業務進行一些相容,最主要的還是適配流量**。通常流量的**是通過日誌檔案來獲取的,但是我看行業內也有通過一些固定的流量儲存分析引擎去完成。這裡的技術我不是太熟,也就不多分享啦。

我覺得基於流量錄製回放這種模式有乙個比較難以解決的問題:流量的不可見性。一般來說,錄製流量會非常大。介於幾十萬上百萬之間。這麼規模大的流量,是很難對他進行視覺化的。常遇到的乙個問題,就是對於一些請求量非常小的介面。錄製的時候可能會錄丟。還有一種就是錄製流量的時間範圍不會太廣。那麼錄製出來的流量檔案只能反映錄製時的流量模型,並不能反映其他錄製時間段的流量模型。如果某個服務的流量是根據時間變化的。那麼就需要對多個時間段都錄製流量,然後進行合併。由於流量的不可見性,所以對流量的模型進行分析,就會顯得比較麻煩。

這種方式對於公司的架構,主或者說是分流的實現來說,技術難度是比較高的。因為他用的全都是使用者的真實資料,所以一旦出現問題的話,這個問題影響範圍不太可控,而且比較嚴重。對於接收灰度分流流量的機器來說,壓測流量完全真實。但是他也無法避免基於流量錄製,回放同樣的問題。就是流量的不可見性以及流量與時間可能存在於乙個關聯關係並不是線性的。甚至這一點流量的灰度分流還不如流量的錄製與回放。我想這也是。我身邊接觸到的公司,都沒有採用這種方案的原因吧。

全鏈路壓測

2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度,將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...

全鏈路壓測

之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案,自己也看了很多相關的資料,這篇部落格,說說自己對全鏈路壓測的理解,以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境,模擬海量的使用者請求和資料對整個業...

全鏈路壓測筆記

公司業務發展,難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸,優化少量的瓶頸部分提公升整體效能,以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後,整體系統沒有問題,因為涉及到業務訪問鏈路,多個業務可能有共用資源的瓶頸,主鏈路請求量增...