前言

　　2017雙11大促剛剛過去，蘇寧易購交易系統(tǒng)的請求量和訂單量在雙11當日呈現(xiàn)指數(shù)級的增長，更是實現(xiàn)了7秒破億的最快破億記錄，蘇寧易購交易系統(tǒng)在大促期間平穩(wěn)運行，完美度過雙11。作為蘇寧易購交易系統(tǒng)負責人，我給大家介紹一下交易核心系統(tǒng)之一，庫存系統(tǒng)的架構(gòu)演進與實踐，并介紹庫存系統(tǒng)是如何籌備和應對雙11的流量洪峰的。本文推薦架構(gòu)師、技術經(jīng)理、開發(fā)工程師、技術總監(jiān)等群體閱讀，希望能夠讓大家受益。

　　庫存業(yè)務介紹及面臨的挑戰(zhàn) 庫存系統(tǒng)定位及核心業(yè)務場景分析

　　首先介紹一下庫存系統(tǒng)的定位，它主要為企業(yè)級的經(jīng)營性可用商品庫存獲取應用，與平臺商品目錄緊密關聯(lián)，定位為蘇寧核心平臺之一。平臺級商品庫存支持線上、線下銷售渠道和營銷活動對經(jīng)營性可用商品庫存的查詢，支持平臺商品庫存鎖定、解鎖、增加、減少等庫存核心服務，并為平臺商戶提供服務支撐。

　　庫存作為電商交易的核心系統(tǒng)之一，它貫穿蘇寧的整個業(yè)務價值鏈條，不論從采購線的采購、交貨、調(diào)撥、退場、入庫過賬、實物盤點等環(huán)節(jié)，還是銷售線的瀏覽、下單、發(fā)貨、出庫過賬等環(huán)節(jié)，再到客服支撐、經(jīng)營分析報表、預測補貨、多平臺銷售支撐等大數(shù)據(jù)應用，都和庫存系統(tǒng)緊密關聯(lián)。

　　庫存從業(yè)務模式上分為自營庫存和C店庫存。自營庫存即蘇寧自采自銷的庫存，C店庫存即通過開放平臺入駐的平臺商戶所銷售的庫存。

　　庫存中心聚焦的是銷售庫存，即支撐蘇寧銷售和交易相關的所有庫存服務。而蘇寧的實物庫存是在蘇寧的物流平臺進行管理的。兩套庫存的定位不一樣，但兩套庫存之間具有一定的關聯(lián)，且通過定期嚴謹?shù)膸齑鎸~機制來確保兩套庫存數(shù)據(jù)的一致。如圖1.

　　圖1 系統(tǒng)上下文圖 庫存業(yè)務架構(gòu)

　　庫存系統(tǒng)從業(yè)務架構(gòu)上分為庫存交易、庫存管理、異常管理、運維管理四大組成部分。

　　庫存交易部分分為銷售鎖定、銷售解鎖、交貨鎖定、交貨解鎖、數(shù)量查詢、庫存狀態(tài)查詢、狀態(tài)下傳、數(shù)量下傳、活動預鎖、活動預解鎖、活動庫存查詢、活動管理等功能模塊。庫存管理部分分為采購、調(diào)撥、退廠、移庫、盤點、對賬、狀態(tài)計算、銷售過賬、庫存同步、多平臺分貨等功能模塊。庫存狀態(tài)是指定義庫存有貨、無貨的一種狀態(tài)標識，通過實現(xiàn)庫存狀態(tài)，可大大減少外圍系統(tǒng)對庫存數(shù)量查詢接口的調(diào)用，比如商品詳情頁只關注商品有無貨，通過庫存狀態(tài)即可支持。業(yè)務架構(gòu)如圖2。

　　圖2 業(yè)務架構(gòu)圖 庫存面臨的挑戰(zhàn)

　　庫存系統(tǒng)主要面臨以下幾個挑戰(zhàn)：

　　熱點爭搶

　　針對同一個商品，比如秒殺、團購、打折促銷等活動商品，如何支撐高并發(fā)庫存扣減服務。

　　周轉(zhuǎn)率

　　如何提升庫存周轉(zhuǎn)率，最大化利用企業(yè)資金，做到銷售最大化。

　　避免超賣

　　避免超賣是庫存系統(tǒng)架構(gòu)設計和系統(tǒng)實施的底線原則。

　　系統(tǒng)擴展性

　　如何建設出可無限擴展的庫存架構(gòu)，在系統(tǒng)擴展過程中，各部署節(jié)點都需要具備無限擴展能力，而常見的瓶頸如數(shù)據(jù)庫的連接數(shù)、隊列的連接數(shù)等。

　　庫存系統(tǒng)的架構(gòu)演進

　　蘇寧庫存系統(tǒng)的架構(gòu)演進主要劃分為4個階段：

　　階段1： 2005-2012，線下連鎖時代，電商初期架構(gòu)，當時系統(tǒng)采用WCS/POS+SAP構(gòu)成，庫存屬于SAP系統(tǒng)中的一個業(yè)務模塊；

　　階段2： 2012-2013，互聯(lián)網(wǎng)O2O電商時代，當時系統(tǒng)進行了前臺、中臺、后臺架構(gòu)的分離，獨立出SAP庫存系統(tǒng)；

　　階段3： 2013-2016，多平臺銷售戰(zhàn)略時代，蘇寧入駐天貓，當時系統(tǒng)采用“去商業(yè)軟件，崇尚開源”思路，新建JAVA自研庫存系統(tǒng)；

　　階段4： 2016-至今，庫存系統(tǒng)多活時代，分機房部署庫存系統(tǒng)，基于大數(shù)據(jù)庫存分貨引擎實現(xiàn)多機房部署。

　　如圖3。每個階段庫存架構(gòu)的詳細內(nèi)容會在下面章節(jié)展開。

　　圖3 架構(gòu)演進圖 電商初期架構(gòu)

　　電商初期-總體架構(gòu)

　　線下連鎖時代的電商初期總體架構(gòu)，線下銷售采用POS客戶端系統(tǒng)，線上銷售采用WCS （IBM WebSphere Commerce）（JAVA）系統(tǒng)，服務端采用SAP-R3商業(yè)軟件。如圖4。

　　圖4 電商初期-總體架構(gòu)圖

　　電商初期-系統(tǒng)交互

　　線下門店POS系統(tǒng)和線上主站W(wǎng)CS（IBM WebSphere Commerce）系統(tǒng)調(diào)用SAP-R3提供的庫存檢查、庫存鎖定、庫存解鎖等服務，同時，為了減輕線上主站對后端服務系統(tǒng)的壓力，SAP-R3會將庫存數(shù)量的變化主動推送給WCS系統(tǒng)，在WCS系統(tǒng)本地暫存一份影子庫存數(shù)據(jù)，WCS商品詳情頁加載商品信息時，先查詢本地的影子庫存，判斷如果影子庫存過了保鮮期（有效期），則進行庫存懶加載，實時調(diào)用SAP-R3的庫存數(shù)量查詢服務，再更新本地影子庫存；另外，主站搜索系統(tǒng)也是基于WCS本地的影子庫存數(shù)據(jù)來創(chuàng)建和更新索引。系統(tǒng)交互關系如圖5。

　　圖5 電商初期-系統(tǒng)交互圖

　　電商初期-架構(gòu)分析

　　電商初期架構(gòu)主要存在以下問題：

　　訂單、庫存等核心業(yè)務集中運行在一個系統(tǒng)，耦合性太強，不易改造，業(yè)務擴展性很差；

　　為了快速占有電商市場，業(yè)務快速上線，選型SAP/WCS商業(yè)軟件，受制于廠商，軟件維護能力薄弱；

　　SAP僅支持單數(shù)據(jù)庫，架構(gòu)不具備系統(tǒng)擴展能力，無法支持雙線日益增長的交易處理。

　　為了解決上述架構(gòu)問題，我們自然而然想到了進行業(yè)務系統(tǒng)的拆分。我們花了近兩年時間進行了大刀闊斧的前、中、后臺架構(gòu)的分離。

　　前臺、中臺、后臺分離架構(gòu) 前中后分離-總體架構(gòu)

　　基于前臺瀏覽、銷售交易、銷售履約&運營管理的業(yè)務劃分和歸類，我們對系統(tǒng)進行了前臺、中臺、后臺的架構(gòu)分離。前臺由各個銷售平臺組成，比如易購主站、門店POS系統(tǒng)、電話銷售，以及其他銷售平臺，負責用戶體驗和商品展示；中臺是核心交易平臺，提供庫存、尋源、價格、商品、促銷、會員等基礎服務、以及提供云購物車、訂單等組合服務，同時中臺提供諸葛等一系列基于大數(shù)據(jù)的報表和應用，后臺是提供蘇寧自營（供應鏈、分賬、記賬、結(jié)算、發(fā)票、采購等）、商家運營（店鋪、商品、庫存、訂單、價格、供應鏈管理等）的一套運營管理平臺、還有大物流平臺。如圖6。

　　圖6 前中后分離-總體架構(gòu)圖 前中后分離-系統(tǒng)交互

　　新建平臺庫存系統(tǒng)，平臺庫存由庫存路由系統(tǒng)CIS（JAVA）、自營庫存系統(tǒng)SIMS（SAP）、C店庫存系統(tǒng)CIMS（JAVA）三個系統(tǒng)組成，瀏覽線的尋源系統(tǒng)調(diào)用平臺庫存的庫存數(shù)量查詢服務，交易線的訂單中心調(diào)用平臺庫存的銷售鎖定、銷售解鎖、交貨鎖定、交貨解鎖等服務，SAP-ERP同步采購庫存數(shù)據(jù)至自營庫存系統(tǒng)SIMS，開放平臺同步商戶api或頁面維護的C店庫存數(shù)據(jù)至C店庫存系統(tǒng)CIMS。平臺庫存將庫存狀態(tài)數(shù)據(jù)同步至尋源系統(tǒng)。如圖7。

　　圖7 前中后分離-系統(tǒng)交互圖 前中后臺分離-架構(gòu)分析

　　前中后臺架構(gòu)分離后分析如下：

　　將訂單、庫存等業(yè)務從SAP-R3拆分出獨立系統(tǒng)后，解決了業(yè)務擴展性的問題，符合“高內(nèi)聚、低耦合”的架構(gòu)原則；

　　自營庫存系統(tǒng)SIMS還是采用的SAP商業(yè)軟件，仍然受制于廠商，但庫存路由系統(tǒng)CIS和C店庫存系統(tǒng)CIMS是JAVA自研系統(tǒng)，軟件具備維護能力；

　　SIMS（SAP）僅支持單數(shù)據(jù)庫，自營庫存系統(tǒng)SIMS仍然無法支持雙線日益增長的交易處理，系統(tǒng)性能有一定的提升；

　　針對搶購、團購類活動場景，容易造成庫存熱點，無法有效支持高并發(fā)的庫存扣減。

　　針對以上架構(gòu)問題，我們在架構(gòu)上進一步提出優(yōu)化思路：

　　“去SAP化”，去商業(yè)軟件，實現(xiàn)自開發(fā)自營庫存系統(tǒng)；

　　搭建分布式架構(gòu)，采用應用集群、數(shù)據(jù)庫的分庫分表、集中式緩存等技術提升系統(tǒng)處理能力；

　　針對搶購、團購等活動庫存場景，新建納秒購系統(tǒng)來提供高并發(fā)、高性能的庫存服務，和普通庫存進行獨立設計和分開部署。

　　自研庫存架構(gòu)

　　自研庫存系統(tǒng)，將庫存系統(tǒng)從職能和系統(tǒng)上劃分為庫存交易和庫存管理。庫存交易由庫存路由系統(tǒng)CIS、自營庫存交易系統(tǒng)GAIA、C店庫存交易系統(tǒng)CIMS、搶購庫存系統(tǒng)AIMS 四個系統(tǒng)組成。

　　自研庫存架構(gòu)-總體架構(gòu)

　　庫存路由系統(tǒng)CIS提供庫存的統(tǒng)一服務路由、服務流控、服務降級、接口熔斷等系統(tǒng)組件；自營庫存交易系統(tǒng)GAIA和C店庫存交易系統(tǒng)SIMS提供高性能的庫存數(shù)量查詢、銷售鎖定、銷售解鎖、交貨鎖定、交貨解鎖等庫存服務，庫存交易系統(tǒng)的數(shù)據(jù)由自營庫存管理系統(tǒng)SIMS和商家?guī)齑婀芾硐到y(tǒng)SOP提供數(shù)據(jù)同步。蘇寧庫存可以在易購平臺、天貓平臺、當當平臺等多平臺上進行銷售。基于大數(shù)據(jù)的智能分貨引擎在庫存管理系統(tǒng)SIMS中實現(xiàn)多平臺分貨。

　　搶購庫存AIMS提供基于緩存的高并發(fā)庫存服務，支撐爆款搶購、爆款預約、大聚會等活動場景。

　　圖8 自研庫存架構(gòu)-總體架構(gòu)圖 自研庫存架構(gòu)-系統(tǒng)交互

　　新建GAIA系統(tǒng)（JAVA）替換 SIMS系統(tǒng)（SAP）自營庫存的交易職能，新建獨立的納秒購庫存系統(tǒng)以支撐搶購、團購等大促活動。納秒購庫存系統(tǒng)，基于“架構(gòu)獨立、庫存預鎖、數(shù)量緩存化”的思路進行搭建，提供高性能的庫存服務。如圖9。

　　圖9 自研庫存架構(gòu)-系統(tǒng)交互圖 自研庫存架構(gòu)-部署架構(gòu)

　　自研庫存系統(tǒng)是基于蘇寧技術體系搭建的一套高并發(fā)、可擴展的架構(gòu)。

　　庫存系統(tǒng)通過使用蘇寧自研的RPC調(diào)用框架（rsf）對外提供實時服務，通過使用kafka組件進行消息分發(fā)和消息訂閱，對外提供數(shù)據(jù)服務和接收外部數(shù)據(jù)；

　　應用使用wildfly standalone集群，數(shù)據(jù)庫使用MySQL集群，數(shù)據(jù)庫采用讀寫分離部署；

　　運維人員的庫存管理通過使用ES（Elastic Search）平臺提供商品和商家等多維護的庫存查詢和管理服務，管理端對數(shù)據(jù)的抽取通過讀vip訪問MySQL讀庫。

　　圖10 自研庫存架構(gòu)-部署架構(gòu)圖 自研庫存架構(gòu)-數(shù)據(jù)架構(gòu)

　　以自營庫存交易系統(tǒng)GAIA為例，庫存從數(shù)據(jù)架構(gòu)上進行了水平和垂直拆分，分為公共庫、業(yè)務庫和日志庫。

　　公共庫存放主數(shù)據(jù)及基礎配置信息，包含分庫分表規(guī)則、job配置、ATP檢查配置、公共基礎數(shù)據(jù)等，公共庫為一主多從，可通過本地緩存、集中式緩存、擴展從庫來減輕對主庫的壓力；

　　業(yè)務庫提供核心庫存交易服務，存放核心數(shù)量表、銷售鎖定表、交貨鎖定表等業(yè)務數(shù)據(jù)，業(yè)務庫按照商品編碼hash取模進行分庫分表，核心表分為1000張表；

　　日志庫存放各類接口的交易流水數(shù)據(jù)，記錄各類服務的日志、審計及庫存對賬等信息，日志庫按照外部單據(jù)號hash取模進行分庫分表，核心表分為1000張表。

　　對于庫存系統(tǒng)來說，發(fā)生一筆庫存交易，通常需要同時寫入業(yè)務庫和日志庫，這就需要解決分布式事務的問題。根據(jù)CAP（C（Consistency）、A（Availability）、P（Partition tolerance））理論，三者是無法同時滿足的。我們舍棄了Consistency（實時一致性）特性，在滿足分區(qū)容錯性和可用性基礎上，確保事務提交的結(jié)果最終一致。

　　為了最大化的提升庫存交易的性能，我們采用“實時扣、異步加”的處理原則，對于庫存數(shù)量的扣減采用實時處理的方式，而對于庫存數(shù)量的加回采用異步的處理方式，因為庫存數(shù)量的加回不存在業(yè)務上失敗的可能，業(yè)務上一定能夠確保成功，而庫存數(shù)量的扣減是存在業(yè)務并發(fā)下失敗的可能的。

　　數(shù)據(jù)架構(gòu)見圖11。

　　圖11 自研庫存架構(gòu)-數(shù)據(jù)架構(gòu)圖 搶購庫存-面臨挑戰(zhàn)及應對

　　通常的搶購、團購、秒殺等活動業(yè)務對于庫存業(yè)務來說具有以下挑戰(zhàn)：

　　瞬間流量巨大，造成庫存熱點的爭搶；

　　高并發(fā)下應用、數(shù)據(jù)庫負載連接突然飆升；

　　引起黃牛效應。

　　針對以上挑戰(zhàn)，我們有以下應對方案來確保系統(tǒng)的穩(wěn)定性：

　　庫存交易處理緩存化，避免數(shù)據(jù)庫層面鎖資源的爭用；

　　架構(gòu)分離，對活動庫存的業(yè)務進行隔離部署；

　　通過構(gòu)建基于IP/UA訪問策略的WAF防火墻，通過應用層的業(yè)務流控和系統(tǒng)流控，通過風控（人機識別）等技術手段來應對黃牛的惡意流量。

　　搶購庫存-系統(tǒng)構(gòu)建

　　搶購庫存的系統(tǒng)構(gòu)建：

　　銷售準備：活動營銷系統(tǒng)創(chuàng)建活動時，先進行庫存數(shù)量的預鎖，將活動庫存和普通庫存邏輯分離；

　　銷售執(zhí)行：活動商品詳情頁展示時，會進行活動庫存數(shù)量查詢，直接訪問活動庫存數(shù)量緩存；用戶在提交訂單時，會進行支付前檢查，這時我們進行庫存的臨時鎖定，系統(tǒng)通過緩存redis的lua（EVAL）原子命令執(zhí)行扣減腳本以支持高并發(fā)的庫存扣減服務，同時對db進行insert插入一條庫存鎖定記錄，避免產(chǎn)生數(shù)據(jù)庫鎖資源的爭搶；顧客在支付完成后，會進行庫存的正式鎖定，系統(tǒng)會更新用戶提交訂單時插入的鎖定記錄的鎖定狀態(tài)，通過異步進行db庫存數(shù)量表的更新達到數(shù)據(jù)庫的消峰目標。

　　通過庫存數(shù)量緩存化、活動庫存的部署分離、數(shù)據(jù)庫數(shù)量表扣減更新的異步化，我們實現(xiàn)了高并發(fā)的活動庫存系統(tǒng)架構(gòu)。

　　搶購庫存的實現(xiàn)示意，如圖12。

　　圖12 搶購庫存-系統(tǒng)架構(gòu)圖 自研庫存架構(gòu)-架構(gòu)分析

　　自研庫存架構(gòu)實現(xiàn)了架構(gòu)的完全開源自實現(xiàn)，并搭建了高并發(fā)的分布式架構(gòu)，但在電商業(yè)務蓬勃發(fā)展，訂單屢創(chuàng)新高的背景下，依然面臨一些挑戰(zhàn)：

　　擴展痛點：受限于數(shù)據(jù)庫的連接數(shù)瓶頸、Redis服務器的連接數(shù)瓶頸、隊列服務器的連接數(shù)瓶頸等因素，導致應用集群無法無限擴展；

　　機房容災及機房容量：機房斷電，電纜被挖，造成整個蘇寧易購交易系統(tǒng)癱瘓；單個機房容量受限，無法創(chuàng)建更多的服務器；

　　故障隔離：某數(shù)據(jù)庫分片出現(xiàn)宕機，從而影響整個交易；某redis分片出現(xiàn)宕機，從而影響整個交易；

　　熱點瓶頸：雖然通過構(gòu)建緩存化支持庫存交易，但單個商品的并發(fā)扣減仍然存在上限

　　為了解決上述問題，我們開始開展庫存的單元化和多活架構(gòu)構(gòu)建。

　　多活庫存架構(gòu) 庫存單元化

　　為了解決擴展痛點、故障隔離、熱點瓶頸等架構(gòu)問題，我們先實現(xiàn)了庫存交易系統(tǒng)的單元化部署。

　　系統(tǒng)單元化有以下幾個原則：

　　單元封閉

　　單次請求需要封閉在一個單元內(nèi)完成，嚴謹跨單元操作；

　　高可用

　　單元內(nèi)的所有部署節(jié)點，也要遵循高可用的原則，不能出現(xiàn)單點故障；

　　無限擴展

　　單元之間可以進行無限的擴展；

　　對外透明

　　庫存系統(tǒng)單元化部署對外部調(diào)用系統(tǒng)是完全透明的；

　　服務熔斷

　　單元化系統(tǒng)內(nèi)提供的服務需要能夠支持服務熔斷，單元不會因為一個服務的問題導致整個的單元收到影響。

　　單元采用商家編號hash取模的維度進行單元的劃分。多個單元組成一個單元組。跨單元的一些管理功能基于ES（Elastic Search）平臺提供服務。

　　庫存單元化示意圖如圖13。

　　圖13 庫存單元化示意圖 庫存多活架構(gòu)

　　庫存服務屬于競爭型的服務，不能在子機房之間實現(xiàn)數(shù)據(jù)共享，因此，我們基于大數(shù)據(jù)智能分貨引擎在主機房進行庫存數(shù)據(jù)的智能調(diào)撥和分貨，能夠基本實現(xiàn)交易單元中庫存業(yè)務在本機房內(nèi)提供服務，同時機房之間建立數(shù)據(jù)庫的互相備份，當A機房出現(xiàn)故障，可由B機房完全接管。

　　如圖14。

　　圖14 庫存多活架構(gòu)示意圖 庫存如何應對雙11大促 容量預估

　　對公司雙11大促的 活動預告及銷售目標進行詳細評估和分解，轉(zhuǎn)化成庫存系統(tǒng)的核心服務的SLA，確定庫存系統(tǒng)的核心服務的TPS目標。

　　機器擴容

　　基于容量預估出來的TPS目標，評估庫存的機器是否需要擴容，比如jboss集群是否需要擴容，db是否能夠支撐，db是否需要拆庫拆表，db磁盤容量是否足夠，服務器負載是否足夠等。

　　梳理流控與降級方案

　　所有交易接口需要設定合理的流控閥值，以確保系統(tǒng)不會掛死；梳理所有接口的調(diào)用系統(tǒng)和業(yè)務場景并明確業(yè)務的優(yōu)先級，假設系統(tǒng)因為某服務導致性能出現(xiàn)瓶頸，根據(jù)業(yè)務優(yōu)先級逐步調(diào)整流控閥值；業(yè)務流控或系統(tǒng)流控要實現(xiàn)用戶的友好提示；對于后端依賴系統(tǒng)，如果出現(xiàn)超時或宕機，則定義降級策略，確保服務請求的快進快出。

　　單系統(tǒng)生產(chǎn)壓測及端到端性能測試

　　大促前，我們會進行多輪的生產(chǎn)壓測，最重要的是單系統(tǒng)的接口壓測和端到端全鏈路壓測。通過單系統(tǒng)服務接口壓測，我們排除接口潛在的性能瓶頸并針對性的優(yōu)化，能夠清楚認識負責系統(tǒng)的單接口所能支持的并發(fā)上限；通過生產(chǎn)真實流量回放的端到端全鏈路壓測平臺，進行全鏈路的生產(chǎn)壓測，發(fā)現(xiàn)真實流量下的系統(tǒng)壓力情況，和資源情況，提前發(fā)現(xiàn)性能瓶頸和潛在的系統(tǒng)風險。性能測試是大促籌備最為關鍵的一環(huán)。

　　系統(tǒng)健康檢查

　　提前對系統(tǒng)的各方面進行全面的健康檢查，比如db磁盤的容量、連接數(shù)、topsql，緩存的內(nèi)存使用率、并發(fā)命令數(shù)和連接數(shù)，消息隊列的連接數(shù)，各節(jié)點的cpu負載情況，排除單點故障，排除虛擬機的資源爭用問題，排除高可用問題（同一物理機多應用節(jié)點）等。

　　大促前重大版本回溯及事故案例回溯

　　大促前會進行生產(chǎn)重大版本的回溯，針對新提供的服務，新支持的業(yè)務或活動形式要重點關注，確保新增業(yè)務的服務可靠性和穩(wěn)定性；大促前還會進行事故的案例回溯，回顧以往發(fā)生的生產(chǎn)事故，排除有類似的事故風險，確保問題不會重復的發(fā)生。

　　大促籌備的幾大環(huán)節(jié)如圖15。