架構師日記-從技術角度揭露電商大促備戰的奧秘-有解無憂

一、背景

今年的618大促已經如期而至，接下來我會從技術的角度，跟大家聊聊大促備戰的底層邏輯和實戰方案，希望能夠解答大家心中的一些疑惑，

首先，618大促為什么如此重要呢？先從資料的角度簡單做一下分析，以下表格羅列了我們歷年大促GMV成績單：

年份	618銷售額（億元）	年銷售額（億元）	618銷售額占比
2022	3793	33155	11.4%
2021	3439	32970	10.4%
2020	2694	26125	10.3%
2019	2017	20854	9.7%
2018	1592	16769	9.5%

根據以上資料統計，我們可以得出結論：每年的618大促銷售額約占全年銷售額的10%左右，以2022年618大促銷售額為例，大促期間，每分鐘的銷售額平均高達1463萬元，因此，從技術角度來看，保證服務的穩定性是至關重要的，相信這些資料可以為您在大促期間制定任務優先級和做出決策提供有價值的參考，

二、挑戰

大促期間系統的穩定性對于業務的正常運營如此重要，我們需要探討以下問題：

影響系統穩定性的因素都有哪些？
穩定性要求與日常對系統的高可用要求有哪些不同之處？
面對各種不穩定因素，我們應該如何應對？

下面我們一起來分析和探討這些問題，

1. 影響系統穩定性的因素有以下幾個方面：

流量大小：大促期間，流量往往是平常的幾倍甚至幾十倍，這對系統的穩定性提出了極高的要求，一個小問題，在流量放大后，往往會演變成大問題；
資料量大：以2022年的訂單為例，訂單額達到了3.4萬億，在海量訂單資料的場景下，一個簡單的查詢，都會變得非常具有挑戰；
場景復雜：各類促銷優惠、平臺、商家、運營等各種營銷玩法的疊加，使訂單生產鏈路始終處于高負荷運算狀態；
交付鏈路長：各端的流量分發、促銷計算、加車、結算、提單、支付、物流配送、客服、售后等各個流程節點都需要保持穩定，如果一個服務99.9%的可用率，那么100個相關服務節點組合起來，可用率就只能達到99.5%了，而那0.5%的不可用，對應的都是大量的訂單流失；
容忍度低：消費者要求良好的用戶體驗，商家需要促銷快速生效，平臺則要減少錯誤和資損，保護消費者和商家的利益，更高的期望和關注，帶來的是更低的耐心和容忍度；

2. 在大促期間，對系統的穩定性要求更高，但與平常對系統的高可用性要求不同，這主要體現在以下幾個方面：

時間緊迫：大促期間需要在短時間內保證服務的穩定性，通常沒有時間深入技術細節；
視角不同：穩定性注重整體業務效果，而高可用性注重服務回應結果；
維度不同：實作業務穩定性保障通常是建立在系統高可用性的基礎之上，并配合相關的服務運營策略，以實作更高維度的業務穩定性，

3. 接下來將重點圍繞備戰大促的相關思路和經驗進行展開，以幫助您應對挑戰并確保系統的穩定性，

三、穩定性保障

以下羅列了今年大促備戰的部分措施：

上圖里展示的各種備戰專案，有方向性的指導，有流程上的規范，有落地層面的要求，下面我將從更細粒度的系統執行層面出發，提供一些備戰策略，

正如前文提到的，大促期間的穩定性保障一般屬于應急策略，目的是在保證系統穩定性的前提下，對問題的快速回應，我們將從應用、存盤、運營三個視角，來探討系統穩定性保障的應急措施，

3.1 應用視角

3.1.1 單元化

單元化部署是將應用拆分成多個獨立的單元進行獨立部署，有以下好處：

降低整個應用因某個單元故障而導致服務中斷的風險；
降低故障排查的難度，因為可以快速定位出問題的單元并進行修復；
每個單元都可以獨立維護和升級，這樣可以降低整個應用因某個單元升級或維護而導致服務中斷的風險；
每個單元都可以獨立擴展和縮減，這樣可以根據實際需求動態調整應用的規模，

為了保證服務的可靠性，我們需要在備戰層面實作異地多活的能力，即要求服務進行異地多機房部署，考慮到異地跨機房呼叫的網路延時問題（例如北京到上海的往返網路延時大約為12毫秒），黃金交易鏈路的所有服務都需要本地單元化部署，因此，建議采用本地單元化優先的部署架構，并與其他異地單元化互為災備，

另外，也要注意流量負載均衡策略，防止出現分組的呼叫流量不均衡，造成部分分組因流量傾斜，導致性能表現不佳的情況出現；

3.1.2 監控預警

預防和發現問題的最直接方式，需要關注以下幾個方面：

監控粒度方面：監控按照層級分為底層中間件監控、依賴RPC監控、方法監控、機器監控、系統監控、業務監控、流程監控、整體的大盤監控；
監控的靈敏度問題，靈敏度過低會導致部分問題被延時暴露甚至被隱藏，而靈敏度過高則會造成資訊爆炸，難以分辨資訊的主次，因此，在實施監控前需要提前做好功課，確定合適的靈敏度；
監控的覆寫度方面：關注監控服務單元、監控指標梳理、監控觸達方法，比如：監控需要覆寫容器數、資源指標、運行環境（JVM、執行緒池）、流量大小、限流值、上下游依賴、超時時長、例外日志、資料容量、模型規模、特征數量等，并可以進行時間維度的縱向對比；
監控的準確性方面：看可用率，需要看上游呼叫方的，可能200ms回應時長，對于呼叫方來說，已經屬于不可用的區間了，看CPU繁忙程度，不能只盯著利用率，還要結合容器核數和CPU負載來分析；
預警解除方面：接到預警訊息，及時排查并處理風險，切不可將小問題演變成大問題，先確認是單機硬體或網路問題，還是集群通用問題，如果是通用問題，能否通過服務呼叫鏈追蹤技術快速定位問題點，確認好問題原因，才能做好應對預案；

3.1.3 日志列印

日志格式、日志級別、輸出方式，歸檔策略，序列化方式，traceId策略等都需要進行合理設定，特別要限制重復日志和無效日志的輸出，減少日志對機器資源的占用，比如：業務例外堆疊日志不建議直接列印，通過狀態碼統計結果就可以了；

3.1.4 快速失敗

能夠快速地檢測和回應故障，幫助服務更快地恢復正常狀態，從而提高系統的可用性和穩定性，實作快速失敗，常見的技術手段如下：

執行緒池超時時間的設定，關鍵系統要擁有動態調整執行緒池運行引數的能力；
利用好工具已有的能力，比如：JSF，JimDB，JMQ等中間件也都支持超時失敗的動態調整能力；
服務限流也是快速失敗的一種實作策略，常見的微服務框架和物理網關一般也都支持類似功能；

總之，快速失敗可以保護系統資源的合理分配，避免出現資源調度阻塞甚至全盤崩潰情況發生，是穩定性保證的重要手段，

3.1.5 服務限流

限流一定是基于系統的承載能力來進行的，整個服務呼叫鏈路上，遵循木桶原理，下面給出一些建議：

限流方式和閾值需要經過系統多輪壓測驗證，以確保資料指標的準確性，
對于業務聚合系統，主要依賴于第三方服務，通常沒有存盤層，瓶頸往往出現在應用服務本身，這種情況下，單機限流是比較好的方式，因為這種方式對于服務擴容或縮容非常友好，只需保證擴容的容器硬體配置與線上容器保持一致即可，
對于底層基礎服務，瓶頸點往往在資料存盤層，而存盤層的擴容成本相對較高，實作起來也比較困難，在這種情況下，全域集中式限流是一個很好的選擇，其目的是優先保證存盤層的穩定性，
建議根據呼叫方的重要程度進行精細化限流運營，確保在極端情況下，具有優先保證核心業務可用性的能力；

3.1.6 業務降級

通常情況下，降級策略是一種防御性的應對措施，用于應對可預見的風險，這種策略可能會犧牲部分非核心能力，以確保業務的基本可用性，隨著業務不斷迭代，需要時刻關注之前的降級策略是否仍然適用，特別是在多人協作的系統中，

3.2 存盤視角

下面從存盤視角來看看穩定性保障方面的一些思路，

3.2.1 資料庫

主從架構：這是最常見的資料庫實體部署架構模式，目的是保證核心資料的高可用，防止出現單機故障，導致資料丟失的情況發生；

讀寫分離：對于大部分實時性要求不高的場景，可以將從庫資源充分利用起來的，按照業務場景，實作寫主庫，讀從庫的架構模式；

事務隔離：MySQL默認的事務隔離級別是RR，但對于大部分應用場景，特別是在寫頻繁的場景，將隔離級別設定為RC級別，也能夠提高資料庫吞吐量；

分庫分表：這里不是要求大促前進行資料庫架構升級，而是說在大促期間，可以進一步將資料進行更細粒度的遷移，比如啟動冷熱資料的遷移任務；

慢查詢：提前做好索引優化，比較重的查詢，提前進行降級屏蔽，做好監控預警；

3.2.2 快取

一主多從：核心資料需要關注部署架構的合理性，目的是保證核心資料的高可用，防止出現單機故障，導致資料丟失的情況發生；

能力擴容：快取是否需要擴容，主要考慮兩個因素，存盤空間上限和IO流量上限，在達到上限之前，及時增加分片來提高容量上限；

主從雙讀：快取主從部署架構的模式下，從分片也可以用來承接部分業務壓力；

熱點資料：熱點資料需要及時消滅，否則容易引起節點性能的急劇下降，高版本的快取客戶端已經支持了熱點資料的識別，并實作了熱點資料進行本地快取的優化；

大key問題：大key同樣會導致集群性能的穩定性問題，核心業務需要考慮風險隔離，避免多條業務線共用一個快取集群，盡量做到集群隔離；

3.2.3 Elasticsearch

雙集群：ES雖然擁有資料容災的能力，但在壓力大的情況下，能夠優化的空間有限，另一方面，集群節點故障的時候，分片再平衡也可能會影響可用率，所以重要的業務建議做雙集群進行能力冗余互備；

慢請求：有時候慢請求會導致整個集群卡住，類似關系型資料庫中出現鎖庫的場景，那么我們可以通過查詢集群中的慢請求任務，若有必要可取消，以釋放資源；

寫控速：大量的寫請求會比較影響查詢性能，有時候可以適當的限制寫速度，來保證集群查詢的穩定性；

存盤容量：集群對存盤容量默認有根據不同的水位線進行保護，若超過水位線則無法再提供寫入特性，需要監視集群存盤占用情況，亦可根據實際服務器存盤配置調高水位線；

3.3 運營視角

千里之行始于足下，再好的預案都需要貫徹執行到位，否則只能事倍功半，下面給出一些運營保障措施，

3.3.1 備戰小組

站在系統或團隊內看問題往往是有視野盲區的，還需要有站在更高維度看問題的視角，這就是備戰小組，準則就是：及時回應、效率第一，從問題的發現、影響范圍的控制、解決方案的推進到流程規范的執行，備戰小組都扮演著不可或缺的角色，

3.3.2 軍演壓測

這需要協調上下游相關部門，組織協調成本很高，旨在模擬真實線上流量，以進行系統穩定性的壓力測驗，這是應用維度，穩定性保障預案的資料指標基礎，如：監控指標，熔點閾值、限流閾值和機器擴容數等，

3.3.3 技術封版

上線封版，聽起來往往讓人難以理解，難道大促期間我們就不上線了嗎？據統計，70%的線上問題是由于改動發版導致，大促期間，業務需求讓步于系統穩定性保障，也是再三權衡的結果，

3.3.4 每日巡檢/假期值班

作為系統自動巡檢的補充，對系統定時定點的進行可用性檢查，其目的是及時發現問題，降低例外影響范圍，

3.3.5 應急預案

這是出現問題后的備用計劃，備戰是為了避免問題的發生，但如果問題真的出現了，應急預案將成為我們最后一道防線，關于應急預案相關的要求和操作，參照下圖：

四、總結

本文從技術角度深入分析了大促備戰的背景和重要性，重點介紹了備戰期間穩定性保障的相關措施，包括具體的指導方向和落地細節，本文旨在回顧和梳理備戰期間的關鍵步驟，以幫助我們更加從容地應對系統穩定性的挑戰，雖然大促備戰是一場緊急行動，但備戰的效果離不開平時的協作共識和技識訓累，過往的經驗和教訓，在此刻將得到充分驗證，

-end-

作者| 煉訓卿

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Revealing-the-Mystery-of-E-commerce-Promotion-and-Preparation-from-a-Technical-Perspective.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/555298.html

標籤：架構設計

上一篇：【技識訓累】軟體設計模式中的工廠模式【一】

下一篇：返回列表