來源：京東技術

導讀

本文面向受眾可以是運營，可以是產品，也可以是研發、測試人員，希望透過如下思路（知歷史->清家底->明目標->定戰略->做戰術->促成長）幫助大家瞭解電商大促系統的高可用保障，減少那些高深莫測的黑話和高大尚的論調，而希望以體系化的知識讓讀者有所得。

01 

【知歷史】電商大促的簡介

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

1.1  什麼是電商大促

    

電商大促是電商平臺組織的一種大型銷售推廣活動，目的是透過提供各種優惠、折扣等方法，提高商品銷售額和網站流量，增加消費者的購物慾望，以實現銷售目標。電商大促活動通常會在一些特定的節點或者節日舉行，比如“雙11”、“618”、“黑色星期五”等，這些時期的電商大促極具吸引力，既有大量的商品打折優惠，又有豐富多樣的活動供消費者參與，是電商平臺提升銷售業績的重要手段。 電商大促活動期間，大家可以購買到平時心儀已久的商品，並且價格通常會遠低於平時，而電商平臺也會透過活動吸引更多的消費者流量和購買力，進一步提升其在電商行業的影響力。電商大促不僅僅是一種營銷方式，也是電商平臺和消費者互動、提高使用者粘性的有效方式。

1.2  典型的電商大促活動簡介

    

618大促：每年6月是京東的店慶月，也是京東的電商促銷主戰場，在店慶月京東都會推出一系列的大型促銷活動，從6月1日延續至6月18日（近幾年開始從5.20日左右開啟預售模式，但是整體時間依然是以6月1日開門紅為準）。從2010年開始，以滿減、優惠券等活動的方式，透過單品類、跨店鋪等方式逐步蔓延到23年的百億補貼，歷時已經13年之久為整個京東零售平臺的GMV營收帶來不小的貢獻。

雙十一&雙十二: 雙十一是指各網路購物平臺在每年11月11日的大型促銷活動，最早起源於中國阿里巴巴旗下購物網站在2009年11月11日舉辦的“淘寶商城促銷日”，現已演變成全行業一年一度的購物活動，及影響全球零售業的消費現象。2012年11月11日網路購物全日銷售額超過美國網路星期一，成為全球最大的網際網路的購物節日。雙十一購物節戰場延伸進12月，即“雙十二”。（備註：淘寶商城專案剛獨立，後更名為天貓，該營銷活動主打品牌商的商品，是想要模仿美國感恩節大促銷這種活動，透過一個活動或一個事件，讓消費者記住淘寶商城）。（參考維基百科）

黑色星期五：Black Friday最早於2005年美國網路shop.org創造的購物節日，與1111被電商炒成購物節原因相似。與之相對應的還有興起於法國、葡萄牙與德國的Cyber Monday。關於黑色星期五這一叫法的起源，較普遍的一種認為看法是，由於這一天是感恩節（11月第四個星期四）後開業的第一天。再加上人們通常由此開始聖誕節大采購，很多商店都會顧客盈門從而有大額進帳。傳統上商家會用不同顏色的墨水來記賬：紅色表示虧損即赤字；反之黑色則為有盈利。商家把這個星期五叫做黑色星期五，用以期待這一天過後，年度營收由負轉正，由紅字轉為黑字。而商店的員工則使用黑色星期五這一名字來自嘲，表示這一天會非常忙碌。黑色星期五這一天一般都會是一個大的採購狂潮，銷售額是一年中第二或第三高的一天，而通常一年中銷售額最高潮是聖誕節前夜或之前的一個星期六。（參考維基百科）

除上述比較大型的電商促銷活動外，其他零售電商平臺比如蘇寧818、國美418，以及其他電商平臺也在自己造節日，而近幾年的拼多多、抖音、快手等電商平臺更多的是借勢雙11或者618來提升整個電商平臺的GMV交易額。

02 

  

【清家底】電商平臺的商業模式與系統

  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

2.1  電商平臺的商業模式

    

經過上面電商大促簡介，大家心裡已經有一個簡單的電商大促活動認識，對於電商行業從業者，電商大促活動是基本的知識，近幾年隨著“新零售”、“無界零售”、“全渠道”等新詞的頻出，給原本電商大促活動增加了更多的業務複雜性。這也是為甚麼會在這裡提下系統分類的原因。在整個零售業鏈路的節點上，劉總曾經提到過“十節甘蔗”理論，而我們致力於做的事是後5節甘蔗的內容，大家知道京東是以自建倉儲物流打通供應鏈為核心驅動力，而淘寶天貓平臺更多是聚集在平臺交易環節透過營銷和兼併購買生態產品帶動流量增長為核心驅動力（近幾年阿里也開始佈局菜鳥平臺開始衍生至其他節甘蔗）；拼多多商業模式更側重於不同的營銷模式，所以系統也聚焦在營銷、交易側，採用第三方商家和物流配送體系；抖音、快手直播電商本身是在構建一個流量場，從開始京東、淘寶天貓入駐流量場到現在獨立發展電商，他們更多是希望搭建的平臺場來實現交易額；

圖1.“十節甘蔗”示意

透過上面的講述其實是想要說一件事，如果單純字面上說電商大促備戰是沒有意義的，針對不同環節的“甘蔗”，整個電商大促中重要性不同，所以電商大促備戰中，需要明確自己的系統在整個業務鏈路中的位置，同時系統提供的核心功能，是否涉及資損、使用者體驗、阻礙交易行為或者影響公司名譽、品牌、集團戰略、營銷計劃等內容。

2.2  電商平臺下的系統鏈路劃分

    

基於上述內容，可以基於營銷、交易、倉儲、配送、售後來劃分京東零售整個系統的業務鏈路環節初步劃分，從大促活動來看營銷是吸引流量、聚集流量、進行流量轉化的手段，屬於整個大促活動的核心環節；從電商平臺大促目的來說，大促活動更多的是希望帶來交易訂單的達成，促進交易額的提升，所以整個交易鏈路是真正目標核心鏈路，屬於整個大促活動的最重要環節；從倉儲、配送、售後來看更多的是交易後履約服務保障，這裡面更多的是給電商平臺帶來的口碑影響，和使用者的長期體驗，對於電商平臺長期發展來看也是非常重要，但是在電商大促的特定場景下可能相對前置的交易屬於次重要核心環節。因為涉及業務知識比較龐大，以下簡要說明下鏈路作為大家一個參考（歡迎大家討論）

營銷鏈路：營銷策略方案制定->營銷方案採銷/商家宣講->營銷方案外部市場公關->營銷活動建立->營銷活動稽核->營銷活動投放->促銷招商->商家報名->商家選品、發品->營銷活動商品稽核->營銷活動、優惠券、商品的投放&推薦

交易鏈路：登陸（網站/APP/小程式/H5）->京東首頁（搜尋&推薦）->商詳->購物車->結算頁->收銀臺（支付）->訂單(訂單列表/訂單詳情頁)->資金對賬

履約鏈路：訂單拆分、轉移、下傳、出管->POP商家(採銷/供應商)接單->發貨、揀貨、打包、出庫、列印面單->分揀、配送、自提->確認收貨

售後鏈路：拒收/訂單取消/售後退貨、換貨、退款->商家稽核/快速退款/糾風判責->暫停修改訂單、攔截物流返倉、原路（部分）退款、上門維修、換新單等->財務對賬->客戶滿意度評價

上面提到的鏈路因為分叉分支很多，比如時效保證、開寄發票、預售先款/先貨、商品評價、直播空間、店鋪評價、客服處理等等內容未涉及，也從側面想說明如果想要保障整個電商平臺的大促穩定，如果不區分重點的話，那麼眉毛鬍子一把抓是肯定完不成好的效果，所以這一個環節主要想要闡述說明在特定場景下，電商大促更多的是保障重點在哪裡。

03 

  

【明目標】大促備戰目標

  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

大促備戰目標的核心一個點：穩。在工作中，很多有經驗的同學會發現，如何去設計一個良好的系統，大概會從如下幾個要素考慮：功能性、可用性、效能效率、安全和擴充套件性，有些場景可能比如秒殺系統更多考率的是高併發因素。那麼在整個大促備戰過程中，基於場景不同，所以大促備戰目標也不可同述。但是整體的總目標來說，依然維持在可用性，如何保障交易核心鏈路更穩、更好的支撐使用者購買下單，促成交易。

但是事與願違，往往會發現管理者、專案、產品、研發、測試總是會面臨同樣的一個問題，資源不足，無論是人力、物力或者財力，永遠資源不足的問題是需要解決的一大核心問題。從古至今，上到將軍打仗、皇帝恩濟百姓，下到企業家創業，資源不足就決定了我們在做決策的時候，需要集中優勢力量兵力結合正確的戰略方針，攻擊目標最薄弱的環節，保障方案正確落地，正所謂蛇打七寸。所以接下來就很明晰要做什麼、如何做是需要考慮的重點。

04 

  【定戰略】大促整體備戰思路  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

大促備戰是一個完整的事件，具備著詳細的故事線，這裡面延展開說明下，在領域驅動設計的建模過程中有個事件建模其實就非常好的應證了這一個點，如果將人類文明的活動想要梳理清楚，其實很多時候會發現越理越亂，所謂的點-線-面-體，其中線是更好的中間表述環節。基於故事線來看的話，那麼整體備戰思路，可以拆解為事前-事中-事後來考慮，相對而言會比較全面的將大促備戰體系針對特定場景下的備戰儘可能全面。

4.1  事前：基於現狀進行整體提前工作安排

    

（1）參與部門/集團大促啟動會，及時獲取最新集團備戰導向和最新的戰略內容，比如京東的三道防線戰略。

（2）進行資源盤點梳理，包含人員、應用、上下游依賴、中介軟體、資料庫，本次大促的SLA約定，值班上下游群，問題反饋群，大促備戰手冊等。

（3）針對可以降低發生機率的事項進行改造，比如梳理核心鏈路，針對鏈路上的薄弱點進行改造，並對於日誌進行改造可以基於不同場景進行日誌輸出，規範整個大促備戰的指南方案。

（4）宣講儀式增強備戰感知，比如基於大促封板需求開始，進行大促意識宣講，同時完善監控大盤，補充關鍵日誌，報警郵件簡訊治理，歷屆大促相關指標同環比資料對照分析資料表等。

（5）宣講會後日檢工作內容，比如成立應急故障虛擬小組，基於歷史故障和常見問題形成故障手冊，同時制定限流和降級預案等指南手冊。

圖2.工作安排示意

4.2  事中：基於備戰情況保持警惕備戰狀態

    

（1）每日郵件指標報表通曬

（2）每日錯誤日誌收集並反饋和解決

（3）每日監控報警根因分析

（4）每日站會同步當天系統應用和人員情況

（5）跟進部門/集團大促備戰日例會

4.3  事後：基於整個備戰結果進行效果覆盤

    

（1）業務目標的達成情況，比如某個營銷活動的達成情況，做的好的，待改善的，可以萃取經驗的內容。

（2）產研測團隊的系統需求保障情況，比如大促前期和中間上線的需求，上線情況和需求收益達成情況。

（3）系統應用的指標、資源成本、人力成本投入情況，比如每年大促備戰基於成熟化的工作流程、工具等內容，在業務變化不大的情況下，成本投入應該逐年下降等。

（4）備戰沉澱的經驗形成文件資產，每次大促都是系統歷煉的一次非常好的機會，期間形成的文件資產都可以歸檔方便下次使用。

（5）大促備戰中的待辦工作內容和事項持續跟蹤，很多時候團隊部門缺少跟蹤事項表，只是記錄了時間和人但是持續跟蹤的事情沒有持續性。

05 

  【做戰術】大促整體備戰工作  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

5.1  流量沙漏防護原理介紹

    

因為上述戰略中提到的內容比較多，這裡以系統應用為切入點，開始進行系統評估是否屬於良好的應用，如果特徵因素中有不滿足的進行薄弱挖掘，比如大促備戰中，其實整個防護工作是以流量沙漏防護原理為核心的，從流量請求開始，CDN、Nginx、業務閘道器/前端應用直到後端應用（包含中後臺系統）以及依賴的相關元件和其他應用，其實是在一個整個流量沙漏下，最複雜最核心的也是最常講的就是後端應用故障穩定保障。

圖3.流量沙漏防護原理示意

5.2  流量沙漏防護原理後端應用考慮因素評估表

    

基於上述的流量沙漏防護原理可以進行如下的考慮因素進行後端應用評估，挖掘薄弱點。

考慮因素	特徵	措施
功能/適用性	合適原則	系統需求的可理解
效能效率	全面性	頁面、介面、功能載入時間
	時間性	RT響應時間、吞吐量
	資源利用率	記憶體、磁碟空間、CPU使用率
	可擴充套件性	程式碼、架構設計
可用性	全面性	平均無故障時間、平均修復時間、平均故障間隔時間
	穩定性	平均停機時間
	容錯性	錯誤崩潰、程式碼覆蓋率、多機房容災、冗餘備份等
可維護性	全面性	應用維護人力投入情況
	模組化	結構清晰、邊界清晰
	可重複使用性	程式碼、功能複用情況
	可測試性	程式碼覆蓋率
	可分析性	複雜性、程式碼圈複雜度、服務之間互動耦合等
	可變更性	程式碼大小、變更、程式碼耦合、服務單一職責等
成本	全面性	開發、測試、部署維護
	基礎設施	雲/本地基礎設施成本

5.3  流量沙漏防護原理的備戰重點&應用健康度

    

CDN動靜分離：主要集中在前後端分離場景下，但是據筆者瞭解因為歷史、組織結構調整交接等各種原因依然有很多應用沒完整徹底的前後端分離，介面還是以後端維護和編寫；但是如果是核心應用的話基本上都完成了前後端分離，所以這塊最佳化相對簡單。

閘道器安全保障：通常閘道器分為技術閘道器和業務閘道器，技術閘道器更多關注的是安全、鑑權、防刷、防攻擊、限流和降級等功能，業務閘道器更多的是偏BFF層的業務介面適配、裁剪等能力。這塊應該更多面對的是熱點流量峰值的不確定性、使用者行為的不確定性以及安全攻擊等風控行為，需要結合風控團隊對於黑產異常流量、異常IP、Cookie自動加入黑名單進行限流操作；同時結合大促壓測進行壓測指標評估，結合大促預期目標對於系統應用有個合理的閾值和水位管控。

後端應用：後端應用型別、功能、服務面向使用者不同決定了高可用的保障手段不同，比如後端應用分類可以基於任務類、工具類、支撐業務類、核心業務類等劃分；根據其應用分級的定義程度進行應用健康緯度的評估，評估基礎硬體資源、容器資源、應用資源、監控報警、鏈路維度等明細情況，進行薄弱環節治理，比如公司平臺的應用健康度能夠合理的給應用進行畫像，便於問題的診斷和定位。

	檢測指標
基礎資源	應用跨叢集
	應用跨機房
	應用跨POD
	應用POD分佈
	JIMDB POD分佈
	網路TCP重傳
	應用容器CPU
	JIMDB CPU
	JMQ CPU
	資料庫 CPU
	JIMDB分片拓撲
	JIMDB分片POD
	資料庫主從
	資料庫機房
	資料庫規格
	JMQ POD
	VIP機房數量
	後端機房數量
	錯誤後端(ip)
	叢集環境一致
容器	容器存活
	應用模組化
	GIT分支
	灰度更新超時
	CPU利用率
	記憶體使用率
	磁碟繁忙
	網路流入
	TCP連線數
	CPU利用率
	記憶體使用率
	Swap使用率
	磁碟繁忙
	磁碟使用率(根目錄)
	磁碟使用率(export)
	網路連通性
	網路流入
	網路流出
	系統時間偏差
應用	JSF版本
	JMDB版本
	JMQ2版本
	JMQ4版本
	UMP版本
	DUCC版本
	LOG4J版本
	JVM版本
	Full GC/Young GC
	JVM_XMX最大堆記憶體
	JVM_XMS最小堆記憶體
	JVM_堆外記憶體
	JVM_ParallelGCThreads
	JVM_GCConcGCThreads
	JVM_CICompilerCount
	JVM_Metaspace
	JVM_CMS回收閾值
	JVM_新生代大小
	JVM_HeapDump
	JVM_Server模式
	JDOS_日誌清理
	JSF_Timeout超時時間
	JSF_跨單元呼叫
	JSF_跨環境呼叫
	JSF_跨機房呼叫
	JSF_重試次數
	負載均衡
	JSF_限流
	JSF_動態別名
	JSF_設定黑名單
	JSF_同機房部署
	JSF_別名命名規範
	JSF_混合環境部署
	color閘道器timeout
	最大連線數
	初始連線數
	connectTimeout
	SocketTimeout
	maxWait
	時區
	JIMDB FAILOVER狀態
	JIMDB 熱KEY
	JIMDB 大KEY
	JIMDB 慢日誌
	JIMDB 掃描過期頻率
	JIMDB 服務端版本一致
	JIMDB 服務端風險版本
	淘汰策略
	JIMDB_Swap交換區
	JIMDB_綁核
	JIMDB_CPU模式
	JIMDB_網路卡軟中斷
	慢SQL
	優先治理慢SQL
	含外來鍵表
	索引過多表
	自增溢位表
	大表
	接入方式
	最大執行緒數
	JIMDB讀超時
	JIMDB跨單元呼叫
	JIMDB連線超時
	JIMDB等待超時
JIMKV連線超時
JIMKV讀超時
JMQ_sendTimeout
空應用
純預發應用
單例項應用
預發流量過大
預發資源過多
不活躍預發分組
應用_例項存活
應用_Port存活
應用_URL存活
JSF_Provider介面存活
JSF_Consumer介面存活
依賴JIMDB叢集異常Server_OPS次數
Server_CPU利用率
Server_記憶體使用率
Server_記憶體RSS
Server_網路流入
Server_網路流出
Server_連線數
tp99異常次數
積壓
broker 主機-負載
broker 主機-磁碟繁忙
JED Qps
JED連線數
JED主從延遲
監控報警	CPU利用率
	負載
	記憶體使用率
	Swap使用率
	磁碟繁忙
	磁碟使用率
	網路連通性
	TCP連線數
	TCP重傳
	網路流入
	網路流出
	系統時間偏差
	JsfProvider元件報警
	JimDB元件報警
	JmqProducer元件報警
	Mysql元件報警
	SpringMVC元件報警
	UMP JVM監控
	UMP 方法監控
	JVM_CPU利用率
	JVM_記憶體使用率
	JVM_執行緒數
	FULLGC次數
	YONGGC次數
	方法TP99
	方法TP999
	方法可用率
	方法TP99配置合理性
	方法TP999配置合理性
	方法可用率配置合理性
	方法呼叫次數
	Port存活
	URL存活
	OPS次數
	連線數
	記憶體使用率
	主從斷開
	主從複製延遲
	積壓
	重試
	主從延遲
	Logbook關鍵字報警配置
鏈路超時	鏈路超時
	鏈路超時JIMDB元件

其他應用/中介軟體/資料庫：會發現很多時間我們的問題引入集中在三方因素較多，也是在備戰中需要關注的重點：

•- 介面定義不合理，業務周知不到位，新上的業務需求直接在某個時刻脈衝流量到達薄弱依賴將服務打掛；

•- 還有部分是因為上下游依賴不穩定，比如遇到效能瓶頸，業務系統強依賴無法作出降級操作，只能靜靜等待恢復故障；

•- 在機房方面沒有容災，可能因為通訊機房網路問題，電纜被挖斷或者訊號中斷等問題導致網路癱瘓故障不可用；

•- 中介軟體使用策略異常，比如沒有做業務冪等性操作、重試策略未控制次數和時間導致依賴的業務系統無法承接脈衝流量從而服務不可用；

•- 還有依賴的中介軟體和資料庫容量水位已到閾值，沒有及時擴容，從而引發業務系統的不可用；

•- 應用運算元據庫執行緒阻塞、死鎖、慢SQL等造成資料庫拖垮服務應用；

•- 應用操作快取/ES出現熱點的商品造成的資料流量不均引發的服務不可用；

•- 應用記憶體洩漏、JVM配置不合理等等。

透過上述的流量沙漏防護原理是希望幫助大家能夠對於大促備戰有個整體框架，從而更好的結合三道防線戰略，以及考慮因素評估表和應用畫像來決策如何治理整改應用不合理的內容，最終形成相對合理的應用架構。

圖4.整體架構示意

06 

  【促成長】其他  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

電商大促相對每個人來說都是很好的成長機會，透過大促備戰能夠讓你更好的補齊自身知識的不足，也能更深入的瞭解所在團隊的核心業務，所以建議無論是業務運營、產品、研發、測試人員都可以簡單瞭解下。

那麼如何成為一個合格的團隊大促備戰師呢？筆者以自身當時經歷來說，就是大促備戰師要做到胸有成竹，在大促備戰前應該充分了解核心鏈路業務，做好事前工作梳理，能夠有著大促指南手冊宣導給團隊每一個人，做到精兵強將，人人互為備份，將監控報警視覺化皮膚進行大屏展示，及時捕捉和觀察業務變動情況。

那麼如何成為一個事業部架構師或者集團架構師呢？筆者認為需要有嚴格清晰的備戰路線和里程碑，關注的重點事項以及日例會進行事項跟進和同步，因為當人數超過幾十人以後，大促備戰更多的是管人、管流程，而不是管應用，所以需要責任到部門、到個人，緊抓流程，同時日例會及時資訊溝通減少資訊變更差。

07 

  

【做回顧】總結

  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

本文從（知歷史->清家底->明目標->定戰略->做戰術->促成長）的6個環節，詳細闡述了電商大促系統的高可用保障思路。其中對商業模式和業務流程的全面理解、針對性的解決方案、嚴謹的風險評估與控制檢查指標，以及持續的最佳化改進路徑和自身應該成長的要素等，這些又是保障大促系統順利執行的重要基礎。此外，本文也強調了在整個保障思路中，技術和人員的協作是不可或缺的。只有技術和人員達成有效配合，才能使電商大促系統在面臨巨大壓力時仍能保持高可用，保障使用者良好的購物體驗，為公司帶來持續的商業成功。

參考資料：

- 集團應用健康度指標

- 集團三道防線

- 集團軍演全鏈路壓測資料

‍

‍