羅輯思維在全鏈路壓測方面的實踐和工作筆記

業務的知名度越高，其背後技術團隊承受的壓力就越大。一旦出現技術問題，就有可能被放大，尤其是當服務的是對知識獲取體驗要求頗高的使用者群體。

提供知識服務的羅輯思維主張「省時間的獲取知識」，那麼其技術團隊在技術實踐方面是如何踐行省時間的理念的呢？本文將還原羅輯思維技術團隊在全鏈路壓測上的構建過程，為您一**竟。

在實際生產環境中，使用者的訪問行為一旦發生，從cdn到接入層、前端應用、後端服務、快取、儲存、中介軟體整個鏈路都面臨著不確定的流量，無論是公有雲、專有雲、混合雲還是自建idc，全域性的瓶頸識別、業務整體容量摸底和規劃都需要高**的全鏈路壓測來檢驗。這裡的不確定的流量指的是某個大促活動、常規高併發時間段以及其他規劃外的場景引起的不規則、大小未知的流量。

眾所周知，應用的服務狀態除了會受到自身穩定性的影響，還會受到流量等環境因素的影響，並且影響面會繼續傳遞到上下游，哪怕乙個環節出現一點誤差，誤差在上下游經過幾層累積後會造成什麼影響誰都無法確定。

因此，在生產環境裡建立起一套驗證機制，來驗證各個生產環節都是能經受住各類流量的訪問，成為保障服務的可用性和穩定性的重中之重。最佳的驗證方法就是讓事件提前發生，即讓真實的流量來訪問生產環境，實現全方位的真實業務場景模擬，確保各個環節的效能、容量和穩定性均做到萬無一失，這就是全鏈路壓測的誕生背景，也是將效能測試進行全方位的公升級，使其具備「預見能力」。

可見，全鏈路壓測做得好，遇到真實環境的流量，系統僅僅只是再經歷一次已經被反覆驗證過的場景，再考一遍做「做過的考題」，不出問題在意料之中將成為可能。

實施完整的業務壓測，路徑很重要。

要達成精準衡量業務承接能力的目標，業務壓測就需要做到一樣的線上環境、一樣的使用者規模、一樣的業務場景、一樣的業務量級和一樣的流量**，讓系統提前進行「模擬考」，從而達到精準衡量業務模型實際處理能力的目標，其核心要素是：壓測環境、壓測基礎資料、壓測流量（模型、資料）、流量發起、掌控和問題定位。

生產環境上基礎資料基本分為兩種方式，一種是資料庫層面不需要做改造，直接基於基礎表裡的測試賬戶（相關的資料完整性也要具備）進行，壓測之後將相關的測試產生的流水資料清除（清除的方式可以固化sql指令碼或者落在系統上）；另一種就是壓測流量單獨打標（如單獨定義的header），然後業務處理過程中識別這個標並傳遞下去，包括非同步訊息和中介軟體，最終落到資料庫的影子表或者影子庫中。這種方式詳見阿里的全鏈路壓測實踐，我們也是選用了這種方式。此外，生產環境的壓測盡量在業務低峰期進行從而避免影響生產的業務。

對整體系統進行全鏈路壓測，從而有效保障每個流量入口的服務穩定性成為技術團隊的當務之急。因此，我們在2023年，計畫引入全鏈路壓測。期間，也對系統做了服務化改造，對於服務化改造的內容之前在**上傳播過，這次我們主要是講下保障服務穩定性的核心 - 全鏈路壓測。大致的構建過程如下：

經過3個多月的集中實施，我們將全鏈路壓測接入鏈路174個，建立44個場景，壓測消耗vum1.2億，發現各類問題200多個。

如果說2023年全鏈路壓測的設施在羅輯是從0到1，那麼2023年就是從1到n了。

從2023年開始，全鏈路壓測進入比較成熟的階段，我們的測試團隊基於pts和之前的經驗，迅速地將全鏈路壓測應用於日常活動和跨年活動中，並應用於新推出的業務「少年得到」上。目前，全鏈路壓測已經成為保障業務穩定性的核心基礎設施之一。

a. 流量模型的確定：

流量較大的時候可以通過日誌和監控快速確定。但是往往可能日常的峰值沒有那麼高，但是要應對的乙個活動卻有很大的流量，有個方法是可以基於業務峰值的乙個時間段內統計各界面的峰值，最後拼裝成壓測的流量模型。

b. 髒資料的問題：

無論是通過生產環境改造識別壓測流量的方式還是在生產環境使用測試帳號的方式，都有可能出現產生髒資料的問題，最好的辦法是：

c. 監控：

由於是全鏈路壓測，目的就是全面的識別和發現問題，所以要求監控的覆蓋度很高。從網路接入到資料庫，從網路4層到7層和業務的，隨著壓測的深入，你會發現監控總是不夠用。

d. 壓測的擴充套件：

比如我們會用壓測進行一些技術選型的比對，這個時候要確保是同樣的流量模型和量級，可以通過全鏈路壓測測試自動擴容或者是預案性質的手工擴容的速度和穩定性。在全鏈路壓測的後期，也要進行重要的比如限流能力的檢驗和各種故障影響的實際檢驗和預案的演練。

e. 網路接入：

如果網路接入的節點較多，可以分別做一些dis再壓測，逐個確定能力和排除問題，然後整體enable之後再一起壓測確定整體的設定和搭配上是否有能力對不齊的情況。

比如，網路上使用了cdn動態加速、waf、高防、slb等等，如果整體壓測效果不理想的時候建議遮蔽掉一些環節進行壓測，收斂問題，常見的比如waf和slb之間的會話保持可能帶來負載不勻的問題。當然這些產品本身的容量和規格也是需要壓測和驗證的，如slb的cps、qps、頻寬、連線數都有可能成為瓶頸，通過在pts的壓測場景中整合相關slb監控可以方便地一站式檢視，結合壓測也可以更好的選擇成本最低的使用方式。

另外負載不勻除了前面說的網路接入這塊的，內部做硬負載的nginx的負載也有可能出現不勻的現象，特別是在高併發流量下有可能出現，這也是全鏈路、高**壓測的價值。

特別是一些重要活動的壓測，建議要做一下業務中會真實出現的流量脈衝的情況。

阿里雲pts是具備這個能力的，可以在逐級遞增滿足容量的背景下再觀察下峰值脈衝的系統表現，比如驗證限流能力，以及看看峰值脈衝會不會被識別為ddos。

f. 引數調優：壓測之後肯定會發現大量的引數設定不合理，我們的調優主要涉及到了這些：核心網路引數調整（比如快速**連線）、nginx的常見引數調優、php-fpm的引數調整等等，這些網上相關的資料非常多。

g. 快取和資料庫：

h. mock服務：

一般在簡訊下發、支付環節上會依賴第三方，壓測涉及到這裡的時候一般需要做一些特殊處理，比如搭建單獨的mock服務，然後將壓測流量路由過來。這個mock服務涉及了第三方服務的模擬，所以需要盡量真實，比如模擬的延遲要接近真正的三方服務。當然這個mock服務很可能會出現瓶頸，要確保其容量和高併發下的介面延時的穩定性，畢竟一些第三方支付和簡訊介面的容量、限流和穩定性都是比較好的。

i. 壓測時系統的cpu閾值和業務sla

j. 其他

目前，全鏈路壓測已成為羅輯思維的核心技術設施之一，大幅提公升了業務的穩定性。借助阿里雲pts，全鏈路壓測的自動化程度得以進一步提高，加速了構建程序、降低了人力投入。我們非常關注技術團隊的效率和專注度，不僅是全鏈路壓測體系的構建，還包括其他很多業務層面的系統建設，我們都借助了合作夥伴的技術力量，在可控時間內支撐起業務的快速發展。

當業務跑的快的時候，技術建設的路徑和方式，是團隊的基礎調性決定的。

閱讀原文

羅輯思維在全鏈路壓測方面的實踐和工作筆記

業務的知名度越高，其背後技術團隊承受的壓力就越大。一旦出現技術問題，就有可能被放大，尤其是當服務的是對知識獲取體驗要求頗高的使用者群體。提供知識服務的羅輯思維主張 省時間的獲取知識 那麼其技術團隊在技術實踐方面是如何踐行省時間的理念的呢？本文將還原羅輯思維技術團隊在全鏈路壓測上的構建過程，為您一 竟...

羅輯思維在全鏈路壓測方面的實踐和工作筆記

業務的知名度越高，其背後技術團隊承受的壓力就越大。一旦出現技術問題，就有可能被放大，尤其是當服務的是對知識獲取體驗要求頗高的使用者群體。提供知識服務的羅輯思維主張 省時間的獲取知識 那麼其技術團隊在技術實踐方面是如何踐行省時間的理念的呢？本文將還原羅輯思維技術團隊在全鏈路壓測上的構建過程，為您一 竟...

羅輯思維在全鏈路壓測方面的實踐和工作筆記

業務的知名度越高，其背後技術團隊承受的壓力就越大。一旦出現技術問題，就有可能被放大，尤其是當服務的是對知識獲取體驗要求頗高的使用者群體。提供知識服務的羅輯思維主張 省時間的獲取知識 那麼其技術團隊在技術實踐方面是如何踐行省時間的理念的呢？本文將還原羅輯思維技術團隊在全鏈路壓測上的構建過程，為您一 竟...