全鏈路壓測落地和演進之路

​前言

筆者所在的公司是一家快速發展的互聯網電商公司，在保證業務快速穩定發展的同時，對於系統穩定性、可用性和擴展性的要求，也在不斷提升。

特別是互聯網電商企業每一年的兩次大考:618&雙11，更是對服務的三大特性有更多的要求。在大促活動開啓以前，不管是前期的核心業務梳理、線上流量評估、場景建模，

仍是測試實施階段的監控分析、調優驗證，乃至線上的容量規劃，每一個環節都須要作不少工做。且這些工做都須要運維、開發、測試、產品甚至數據分析團隊的協同配合，才能保質高效的完成。

全鏈路壓測，做爲電商大促的穩定性保障利器，也在不斷的迭代演進。

這篇文章，爲你們介紹下全鏈路壓測在我司的落地和實踐演進史。

固然，其中的某些敏感部分已脫敏，請諒解（圖片水印爲本人微信公衆號水印）。

 

落地

挑戰

去年雙十一，爲了應對零點的峯值流量衝擊，咱們在八月下旬啓動了第一次全鏈路壓測。因爲是從零開始，所以單獨的搭建了一套和生產1:1的環境。

2個月的時間，環境成本就高達幾百萬。從項目KO到雙十一活動開始，第一次雙十一大促，咱們面臨着下面幾點挑戰。

核心鏈路梳理

電商業務自己比較複雜，且當前階段咱們微服務架構下，各個服務間依賴高，調用關係複雜，且沒有較爲清晰的鏈路梳理。

因此，面臨的第一個挑戰，就是從錯綜複雜的系統中梳理出核心業務鏈路。

如上圖所示，梳理核心鏈路前必定要考慮清楚上面三個問題：

1）咱們在梳理什麼？

梳理核心鏈路，其實是對咱們的業務場景、數據場景和邏輯場景的梳理。

2）什麼是核心鏈路？

從實踐來講，核心鏈路主要有這幾個特色：它是核心業務彙集區域、牽一髮而動全身、影響導購下單支付。

3）爲何要梳理它？

梳理核心鏈路最重要的目的是讓團隊的每一個人都清晰的知道：誰會影響個人服務，我會影響誰的服務，以及梳理過程當中發現潛在的風險。

 

環境成本高昂

按照業內的實踐經驗和方案，全鏈路壓測都是在生產環境進行，這樣測試的結果才能更貼近實際的生產場景。

但因爲咱們是第一次進行全鏈路壓測，所以只能選擇折中方案——按照生產環境當前的配置，搭建一套等配鏡像環境。

鏡像環境從資源準備到服務部署聯調都比較耗時，且成本高昂，這逼迫咱們必須拿到更好的結果，才能提升ROI。

 

流量評估困難

爲了儘量使壓測場景更貼近真實的生產場景，須要對核心鏈路的流量模型進行比較準確的評估和模型確認。

因爲各服務間依賴較高，且調用關係複雜，這對咱們提出了新的挑戰——如何評估出更接近真實場景的流量模型。

流量評估從我我的角度來講，最大的難點實際上在於找到切入點。

而最好的切入點，除了前面講到的核心鏈路梳理，其次就在於完善的監控體系。其中，核心鏈路梳理是前置項，而監控工具則是流量評估的提效工具。

1）評估流量

完成核心鏈路梳理後，能夠依據核心鏈路的請求調用關係進行上下游分析。相關工具的話，開源的有jaeger、skywalking、pinpoint等。

2）模型分析

模型分析主要關注三點：入口流量、內部流量和出口流量。它們各自的區別以下：

• 入口流量：主要指到達網關入口的預估峯值流量；

• 內部流量：微服務架構下，內部服務間調用會出現單個接口被屢次調用的狀況，這是須要重點關注的；

• 出口流量：這裏指的是核心鏈路以外的下游調用以及一些外部調用；

3）安全水位

所謂的安全水位，即服務能在保證自身比較穩定的狀況下支撐業務的能力，通常以CPU%爲基準。業內目前的安全水位，大多以40%——50%爲安全水位。固然，安全水位的設定須要明確以下三點：

• 最大處理能力：即服務器資源耗用達到超過90%時的處理能力；

• 穩定處理能力：服務在安全水位線時候的處理能力；

• 水平擴容可否提升能力：服務集羣可否經過快速的水平擴容來提升處理能力；

 

任務多線開展

在雙十一啓動到活動開始這段時間，須要同時開展的任務較多。好比服務拆分、小紅點遷移、DB&Redis垂直拆分、全鏈路壓測及性能優化，以及新的業務線不斷拓展，這些都是咱們須要面對而且克服的困難。

 

過程

啓動階段

任務拆分

項目kickoff後，在負責人牽頭下肯定了本次雙11的TODO項。主要是以下幾項：

前端：降級點確認、容錯保護、監控數據接入；

後端：核心鏈路梳理、監控&服務保護接入、專項預案、

測試：資源準備、壓測模型梳理、壓測方案、預案演練、線上功能驗證；

基礎架構：架構優化、DB垂直拆分、基礎設施接入（鏈路追蹤、監控、報警......）；

資源保障：容量規劃、鏡像環境搭建、服務部署聯調、線上擴容；

 

準備階段

在準備階段，按照任務規劃拆解出來的細化任務進行同步開展，下面是準備階段咱們開展的主要事項。

核心鏈路梳理

各業務研發團隊的owner對咱們目前的核心業務鏈路進行了梳理，主要包括：首頁、商品、訂單、支付、用戶、風控、優惠券、大促活動、基礎服務等。

流量模型梳理

梳理了首頁、商品、交易、支付等關鍵場景的下游依賴。將商品+交易+支付繪製了對應的依賴大圖，並粗估雙十一峯值數據，做爲接下來壓測、性能優化的技術目標。

鏡像環境準備

因爲本次全鏈路壓測是在和生產等配的鏡像環境進行，至關於一切從零開始搭建一套環境，不管是資源準備、服務部署仍是服務聯調驗證，都耗費了較多的時間。

運維同窗投入了很大的精力作support，從中也發現了咱們以前的一些不足，累積了不少經驗。

壓測數據準備

爲了儘量保證壓測數據的真實性，咱們的解決方案是複製生產庫的數據，進行脫敏和可用性驗證，用來作壓測的基礎數據。

在數據脫敏和可用性驗證這點，安全團隊、DBA以及功能測試的同窗給予了很大支持。

專項預案溝通

專項預案主要包括以下幾項：限流、降級、熔斷、脈衝、資損五種場景。

大促指標溝通

爲保證壓測流量和生產預估流量對齊，和運營產品同窗進行了屢次溝通，確認了本次雙十一大促活動相關的活動場次、時間段、優惠券投放量、預估DAU等相關關鍵指標。

線上鏈路監控

監控就是咱們的眼睛，有了監控，才能快速發現問題並定位修復問題。這一點，基礎架構的同窗爲此作了不少工做。好比：鏈路追蹤監控的Cat、可視化監控大盤-Grafana以及更多的監控組件。

 

實施階段

在全鏈路壓測實施階段，根據測試場景和測試策略，咱們主要進行了以下工做：

單機單鏈路基準測試

在微服務架構下，總體鏈路的性能瓶頸，取決於短板（木桶原理）。所以，單機單鏈路基準測試的目的，是在全鏈路壓測開始前進行性能摸底，定位排查鏈路瓶頸。

單機混合鏈路水位驗證

單機混合鏈路壓測的目的，是排查上下游調用依賴的瓶頸，並以此測試結果做爲限流預案的基準值。

全鏈路壓測演練

全鏈路壓測是大促的保障。在整個實施階段，須要不斷的壓測、排查定位分析問題並進行優化，最終拿到結果。

專項演練

專項演練主要是針對服務限流降級熔斷以及高可用、服務擴容進行驗證。進行演練的目的主要有以下幾項：

• 驗證預案是否生效；

• 針對預案設定閾值進行測試調優；

• 驗證預案生效時服務自己的穩定性；

穩定性測試

穩定性測試的目的，是驗證系統處於負載狀況下，可否長時間提供穩定的服務能力。

每日問題覆盤

在雙十一期間，會針對天天壓測發現的問題進行復盤，儘量讓性能問題及時解決。

 

發佈階段

通過閉關做戰半個月，針對咱們的核心業務鏈路，進行了多輪的壓測和性能優化，各系統qps已經基本達到了預約的目標（等比例）。

 

演進

從19年雙十一，到今年雙十一及雙十二，全鏈路壓測在我司的演進，整體能夠從以下幾個階段來介紹，這幾個階段分別有大事件發生，也正好推進了全鏈路壓測的迭代演進。

五彩石

時間

2020年3月

環境準備

混部環境（測試+預發+生產）：特殊的環境致使了19年雙11沉澱的一些經驗幾乎沒法複用，環境問題也是五彩石全鏈路壓測過程當中，最大的難點和挑戰。

最終的解決方案是接入流量標框架fusion+生產部分服務mock+生產DB建立影子庫表的方式來解決了這個問題。

數據準備

經過生產數據定時同步到影子庫+數據清洗的方式，準備了千萬量級的壓測相關數據。

總體耗時

從前期鏈路梳理到框架接入、影子庫表建立、可用性驗證、以及壓測優化完成，共耗時24個天然日。

固然，因爲當時整個環境是業務測試+產品驗收+數據遷移+壓測共用，實際耗時實際上是不多的。

方法論

19年雙11沉澱的無法複用，業內也沒有這種特殊環境下的壓測方法論，對壓測團隊而言，是一次從新探索實踐。

覆蓋範圍

因爲五彩石項目主要是交易體系重構，當時全鏈路壓測的覆蓋範圍也僅限於核心交易+搜索鏈路。

 

618大促

時間

2020年5月

環境準備

從今年618開始，咱們的全鏈路壓測開始在生產環境開展。關於環境的前置準備，主要是表結構同步檢查+ECS規格巡檢以及其餘好比SLB、CDN、帶寬的資源的平常巡檢。

數據準備

數據準備主要分兩個方面：

用戶數據：專門準備了100W的虛擬用戶數據，經過邏輯身份綁定和替換的方式，按序打通總體用戶數據可用性。

業務測試數據：同步生產真實數據，針對敏感數據進行脫敏處理，而後業務數據綁定虛擬用戶數據。

總體耗時

618階段相比於五彩石，環境相對來講沒那麼複雜，且五彩石自己有必定的適合咱們本身的技術沉澱，所以整個壓測全階段的耗時，相比五彩石少了很多，耗時爲15天。

方法論

因爲五彩石已有了必定的探索實踐經驗，在618全鏈路壓測階段，進行了補充完善。

20年618的全鏈路壓測，能夠說是咱們全鏈路壓測方法論從0到1落地的重要實踐。

覆蓋範圍

618相比於五彩石，壓測的核心鏈路覆蓋範圍擴大了很多，主要包括交易+搜索+社區+客戶端部分核心鏈路。

 

五週年活動

時間

2020年9月

環境準備

生產環境：表結構同步檢查+ECS規格巡檢以及其餘好比SLB、CDN、MQ、帶寬等資源的平常巡檢。

數據準備

數據準備策略基本和618保持一致，虛擬用戶數據保持不變，因爲版本迭代的緣由，只變動了部分業務測試數據。

總體耗時

從需求提出到開始壓測，耗時僅用三天！

方法論

基本參照了618沉澱的技術文檔以及一些實踐經驗，作到了快速複用。

覆蓋範圍

因爲五週年活動主要是一些營銷相關的玩法，本次覆蓋範圍爲交易+搜索+無線平臺部分核心鏈路。

 

雙十一大促

時間

2020年10月

環境準備

到今年雙十一，生產環境已經成了全鏈路壓測的標配環境。

數據準備

用戶數據：因爲業務快速增加，考慮到數據分佈和業務邏輯緩存的問題，此次虛擬用戶從100W增長到了700W；

業務測試數據：從新將生產環境的數據同步到影子庫，針對性進行脫敏處理。

總體耗時

因爲版本迭代和業務邏輯的不斷變化，在準備階段，從新梳理了核心鏈路以及強弱依賴，對流量模型進行了重構。迭代優化了主動/緊急預案、新增了緩存預熱+客戶端限流浮層。

容量巡檢方面，新增了ToB的慢SQL梳理、MQ堆積告警等事項。且在今年雙十一，咱們接入了Zeus壓測平臺，對整個壓測過程進行了規範提效。

整個準備階段耗時15天，經過6次通宵壓測，完美的達到了預期指標並留有必定冗餘空間。

方法論

若是說19年雙十一是從零開始，五彩石是從新探索觸發，618是從零到一落地，五週年是快速複用，那麼20年雙十一的全鏈路壓測，能夠用從一到十來歸納。

覆蓋範圍

相比於以前，本次雙十一打通了風控鏈路。風控研發團隊經過接入fusion框架+dubbo改造，讓咱們總體的壓測流量能一直透傳到風控服務，這樣對總體的穩定性來講，提高是潛移默化而且巨大的。

覆蓋範圍：交易+搜索+無線平臺（社區+客戶端+增加）+風控。

 

大促方法論

經過這幾回大的技術項目，全鏈路壓測，從零開始探索實踐，到從零到一的能快速複用的方法論，以及從一到十的完善優化，咱們也漸漸找到了適用於咱們得物的全鏈路壓測方法論。

 

性能指標提高

全鏈路壓測在我司的不斷演進，對應的是咱們核心鏈路的性能不斷突破新的領域。相信明年的618和雙十一，咱們的服務穩定性和性能表現，會達到一個更高的高度，不斷超越本身。

 

將來

關於將來的工做規劃，實際上還有不少方向等待咱們去探索實踐。好比：

技術優化

在技術優化規劃方面，咱們主要集中在針對Dubbo、gRPC等協議的壓測組件擴展支持，流量錄製回放，全鏈路壓測SOP等方面。其中全鏈路壓測SOP、多協議壓測組件支持，已經在路上。

場景覆蓋

場景覆蓋方面，考慮到後續業務場景的愈加複雜，以及大促營銷玩法的不斷變化，咱們會不斷拓展核心鏈路的覆蓋範圍，探索深度組合場景在全鏈路壓測中的實踐，儘量貼近真實的業務場景。

數據預埋

目前的數據預埋方式相對來講效率仍是比較低的，後續規劃中，會嘗試自動化數據預埋的方案接入，以及緩存預熱的方案梳理以及在針對深度組合場景的數據構造方面，有新的探索和實踐。

流程提效

經過不斷實踐和團隊的大量演練，後續的大促保障和生產全鏈路壓測，咱們但願經過SOP的方式，使其標準化，從經驗複用過分到有法可循。

自動化和常態化方面，更多的是技術上的不斷創新和落地實踐，相信在不久的未來，咱們能將這些一一落地，對生產穩定性保障，大促全鏈路壓測，有更好的支持。