博客 / 詳情

返回

一文了解電商大促系統的高可用保障思路 | 京東雲技術團隊

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

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

1.1、什麼是電商大促

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

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

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

11.11: 11.11是指各網絡購物平台在每年11月11日的大型促銷活動,最早起源於中國阿里巴巴旗下購物網站在2009年11月11日舉辦的“淘寶商城促銷日”,現已演變成全行業一年一度的購物活動,及影響全球零售業的消費現象。2012年11月11日網絡購物全日銷售額超過美國網路星期一,成為全球最大的互聯網的購物節日。(備註:淘寶商城項目剛獨立,後更名為天貓,該營銷活動主打品牌商的商品,是想要模仿美國感恩節大促銷這種活動,通過一個活動或一個事件,讓消費者記住淘寶商城)。(參考維基百科)

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

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

二、【清家底】電商平台的商業模式與系統

2.1、電商平台的商業模式

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

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

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

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

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

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

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

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

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

三、【明目標】大促備戰目標

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

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

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

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

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

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

(2)進行資源盤點梳理,包含人員、應用、上下游依賴、中間件、數據庫,本次大促的SLA約定,值班上下游羣,問題反饋羣,大促備戰手冊等。

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

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

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

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

(1) 每日郵件指標報表通曬

(2)每日錯誤日誌收集並反饋和解決

(3)每日監控報警根因分析

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

(5)跟進部門/集團大促備戰日例會

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

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

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

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

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

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

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

5.1、流量沙漏防護原理介紹

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

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配置不合理等等

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

六、【促成長】其他

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

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

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

作者:京東零售 劉曉成

來源:京東雲開發者社區

user avatar zack-grossbart 頭像
1 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.