一文了解電商大促系統的高可用保障思路-獻給技術夥伴們
來源：京東技術 導讀
本文面向受眾可以是運營，可以是產品，也可以是研發、測試人員，希望透過如下思路（知歷史->清家底->明目標->定戰略->做戰術->促成長）幫助大家瞭解電商大促系統的高可用保障，減少那些高深莫測的黑話和高大尚的論調，而希望以體系化的知識讓讀者有所得。
導讀
本文面向受眾可以是運營，可以是產品，也可以是研發、測試人員，希望透過如下思路（知歷史->清家底->明目標->定戰略->做戰術->促成長）幫助大家瞭解電商大促系統的高可用保障，減少那些高深莫測的黑話和高大尚的論調，而希望以體系化的知識讓讀者有所得。
1.1 什麼是電商大促
電商大促是電商平臺組織的一種大型銷售推廣活動，目的是透過提供各種優惠、折扣等方法，提高商品銷售額和網站流量，增加消費者的購物慾望，以實現銷售目標。電商大促活動通常會在一些特定的節點或者節日舉行，比如“雙11”、“618”、“黑色星期五”等，這些時期的電商大促極具吸引力，既有大量的商品打折優惠，又有豐富多樣的活動供消費者參與，是電商平臺提升銷售業績的重要手段。 電商大促活動期間，大家可以購買到平時心儀已久的商品，並且價格通常會遠低於平時，而電商平臺也會透過活動吸引更多的消費者流量和購買力，進一步提升其在電商行業的影響力。電商大促不僅僅是一種營銷方式，也是電商平臺和消費者互動、提高使用者粘性的有效方式。
1.2 典型的電商大促活動簡介
【清家底】電商平臺的商業模式與系統
2.1 電商平臺的商業模式
圖1.“十節甘蔗”示意
2.2 電商平臺下的系統鏈路劃分
上面提到的鏈路因為分叉分支很多，比如時效保證、開寄發票、預售先款/先貨、商品評價、直播空間、店鋪評價、客服處理等等內容未涉及，也從側面想說明如果想要保障整個電商平臺的大促穩定，如果不區分重點的話，那麼眉毛鬍子一把抓是肯定完不成好的效果，所以這一個環節主要想要闡述說明在特定場景下，電商大促更多的是保障重點在哪裡。
【明目標】大促備戰目標
大促備戰是一個完整的事件，具備著詳細的故事線，這裡面延展開說明下，在領域驅動設計的建模過程中有個事件建模其實就非常好的應證了這一個點，如果將人類文明的活動想要梳理清楚，其實很多時候會發現越理越亂，所謂的點-線-面-體，其中線是更好的中間表述環節。基於故事線來看的話，那麼整體備戰思路，可以拆解為事前-事中-事後來考慮，相對而言會比較全面的將大促備戰體系針對特定場景下的備戰儘可能全面。
4.1 事前：基於現狀進行整體提前工作安排
（1）參與部門/集團大促啟動會，及時獲取最新集團備戰導向和最新的戰略內容，比如京東的三道防線戰略。
（2）進行資源盤點梳理，包含人員、應用、上下游依賴、中介軟體、資料庫，本次大促的SLA約定，值班上下游群，問題反饋群，大促備戰手冊等。
（3）針對可以降低發生機率的事項進行改造，比如梳理核心鏈路，針對鏈路上的薄弱點進行改造，並對於日誌進行改造可以基於不同場景進行日誌輸出，規範整個大促備戰的指南方案。
（4）宣講儀式增強備戰感知，比如基於大促封板需求開始，進行大促意識宣講，同時完善監控大盤，補充關鍵日誌，報警郵件簡訊治理，歷屆大促相關指標同環比資料對照分析資料表等。
（5）宣講會後日檢工作內容，比如成立應急故障虛擬小組，基於歷史故障和常見問題形成故障手冊，同時制定限流和降級預案等指南手冊。
圖2.工作安排示意4.2 事中：基於備戰情況保持警惕備戰狀態
（1）每日郵件指標報表通曬
（2）每日錯誤日誌收集並反饋和解決
（3）每日監控報警根因分析
（4）每日站會同步當天系統應用和人員情況
4.3 事後：基於整個備戰結果進行效果覆盤
（1）業務目標的達成情況，比如某個營銷活動的達成情況，做的好的，待改善的，可以萃取經驗的內容。
（2）產研測團隊的系統需求保障情況，比如大促前期和中間上線的需求，上線情況和需求收益達成情況。
（3）系統應用的指標、資源成本、人力成本投入情況，比如每年大促備戰基於成熟化的工作流程、工具等內容，在業務變化不大的情況下，成本投入應該逐年下降等。
（4）備戰沉澱的經驗形成文件資產，每次大促都是系統歷煉的一次非常好的機會，期間形成的文件資產都可以歸檔方便下次使用。
（5）大促備戰中的待辦工作內容和事項持續跟蹤，很多時候團隊部門缺少跟蹤事項表，只是記錄了時間和人但是持續跟蹤的事情沒有持續性。
5.1 流量沙漏防護原理介紹
圖3.流量沙漏防護原理示意
5.2 流量沙漏防護原理後端應用考慮因素評估表
| 考慮因素 | 特徵 | 措施 |
|---|---|---|
| 功能/適用性 | 合適原則 | 系統需求的可理解 |
| 效能效率 | 全面性 | 頁面、介面、功能載入時間 |
| 時間性 | RT響應時間、吞吐量 | |
| 資源利用率 | 記憶體、磁碟空間、CPU使用率 | |
| 可擴充套件性 | 程式碼、架構設計 | |
| 可用性 | 全面性 | 平均無故障時間、平均修復時間、平均故障間隔時間 |
| 穩定性 | 平均停機時間 | |
| 容錯性 | 錯誤崩潰、程式碼覆蓋率、多機房容災、冗餘備份等 | |
| 可維護性 | 全面性 | 應用維護人力投入情況 |
| 模組化 | 結構清晰、邊界清晰 | |
| 可重複使用性 | 程式碼、功能複用情況 | |
| 可測試性 | 程式碼覆蓋率 | |
| 可分析性 | 複雜性、程式碼圈複雜度、服務之間互動耦合等 | |
| 可變更性 | 程式碼大小、變更、程式碼耦合、服務單一職責等 | |
| 成本 | 全面性 | 開發、測試、部署維護 |
| 基礎設施 | 雲/本地基礎設施成本 |
5.3 流量沙漏防護原理的備戰重點&應用健康度
| 檢測指標 | |
| 基礎資源 | 應用跨叢集 |
| 應用跨機房 | |
| 應用跨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出現熱點的商品造成的資料流量不均引發的服務不可用；
透過上述的流量沙漏防護原理是希望幫助大家能夠對於大促備戰有個整體框架，從而更好的結合三道防線戰略，以及考慮因素評估表和應用畫像來決策如何治理整改應用不合理的內容，最終形成相對合理的應用架構。
圖4.整體架構示意那麼如何成為一個事業部架構師或者集團架構師呢？筆者認為需要有嚴格清晰的備戰路線和里程碑，關注的重點事項以及日例會進行事項跟進和同步，因為當人數超過幾十人以後，大促備戰更多的是管人、管流程，而不是管應用，所以需要責任到部門、到個人，緊抓流程，同時日例會及時資訊溝通減少資訊變更差。
【做回顧】總結
本文從（知歷史->清家底->明目標->定戰略->做戰術->促成長）的6個環節，詳細闡述了電商大促系統的高可用保障思路。其中對商業模式和業務流程的全面理解、針對性的解決方案、嚴謹的風險評估與控制檢查指標，以及持續的最佳化改進路徑和自身應該成長的要素等，這些又是保障大促系統順利執行的重要基礎。此外，本文也強調了在整個保障思路中，技術和人員的協作是不可或缺的。只有技術和人員達成有效配合，才能使電商大促系統在面臨巨大壓力時仍能保持高可用，保障使用者良好的購物體驗，為公司帶來持續的商業成功。
- 集團軍演全鏈路壓測資料
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2992225/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 如何在大促中做好系統高可用
- 助力新能源，NewStart HA保障電網系統的高可用執行
- Mysql核心技術：用NOSql給高併發系統加速MySql
- SQL SERVER——高可用技術概述SQLServer
- 一文了解iOS超級簽名的技術原理iOS
- 搭建高併發、高可用的系統
- 寫給正在入坑linux系統的夥伴Linux
- 一文了解資料庫高可用容災方案的設計與實現資料庫
- 這樣的CMS如何製作！大蝦們給點思路！
- Activemq構建高併發、高可用的大規模訊息系統MQ
- 主機系統高可用
- 關於系統高可用的思考
- MySQL 資料高可用的實現思路MySql
- 兩技術措施保障集團資訊系統的兩性要求
- 資料庫如何應對保障大促活動資料庫
- 一文搞懂促銷系統架構設計架構
- ［小夥伴們］知識管理藝術
- OpenStack的高可用系統構建(1)
- OpenStack的高可用系統構建(2)
- 大資料技術在電商的應用大資料
- 金融級系統海量流量下高可用架構的道與術架構
- 記一次mysql高可用技術分享MySql
- 億級流量電商詳情頁系統的大型高併發與高可用快取架構實戰快取架構
- 一文了解點晴PMS碼頭管理系統
- 個人技術棧大體思路總結
- 高併發，大資料量系統的資料結構優化思路大資料資料結構優化
- 高效能高併發系統的穩定性保障
- 高可用訂單系統設計
- 【轉】如何建設高可用系統
- 「架構技術專題」9種高效能高可用高併發的技術架構（5）架構
- 美鏈電商商城系統開發技術詳情分析
- 構建高併發&高可用&安全的IT系統-高併發部分
- 高可用系列文章之二 - 傳統分層架構技術方案架構
- 一文了解推薦系統中的圖神經網路神經網路
- 一文了解DNS（域名系統）DNS
- 高可用性系統在大眾點評的實踐與經驗
- 高可用高可靠系統設計中的重試機制
- 假期平臺子系統高可用方案