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

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

一、背景

今年的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