前言

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

　　庫存業務介紹及面臨的挑戰 庫存系統定位及核心業務場景分析

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

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

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

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

　　圖1 系統上下文圖 庫存業務架構

　　庫存系統從業務架構上分為庫存交易、庫存管理、異常管理、運維管理四大組成部分。

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

　　圖2 業務架構圖 庫存面臨的挑戰

　　庫存系統主要面臨以下幾個挑戰：

　　熱點爭搶

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

　　周轉率

　　如何提升庫存周轉率，最大化利用企業資金，做到銷售最大化。

　　避免超賣

　　避免超賣是庫存系統架構設計和系統實施的底線原則。

　　系統擴展性

　　如何建設出可無限擴展的庫存架構，在系統擴展過程中，各部署節點都需要具備無限擴展能力，而常見的瓶頸如數據庫的連接數、隊列的連接數等。

　　庫存系統的架構演進

　　蘇寧庫存系統的架構演進主要劃分為4個階段：

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

　　階段2： 2012-2013，互聯網O2O電商時代，當時系統進行了前臺、中臺、后臺架構的分離，獨立出SAP庫存系統；

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

　　階段4： 2016-至今，庫存系統多活時代，分機房部署庫存系統，基于大數據庫存分貨引擎實現多機房部署。

　　如圖3。每個階段庫存架構的詳細內容會在下面章節展開。

　　圖3 架構演進圖 電商初期架構

　　電商初期-總體架構

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

　　圖4 電商初期-總體架構圖

　　電商初期-系統交互

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

　　圖5 電商初期-系統交互圖

　　電商初期-架構分析

　　電商初期架構主要存在以下問題：

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

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

　　SAP僅支持單數據庫，架構不具備系統擴展能力，無法支持雙線日益增長的交易處理。

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

　　前臺、中臺、后臺分離架構 前中后分離-總體架構

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

　　圖6 前中后分離-總體架構圖 前中后分離-系統交互

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

　　圖7 前中后分離-系統交互圖 前中后臺分離-架構分析

　　前中后臺架構分離后分析如下：

　　將訂單、庫存等業務從SAP-R3拆分出獨立系統后，解決了業務擴展性的問題，符合“高內聚、低耦合”的架構原則；

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

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

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

　　針對以上架構問題，我們在架構上進一步提出優化思路：

　　“去SAP化”，去商業軟件，實現自開發自營庫存系統；

　　搭建分布式架構，采用應用集群、數據庫的分庫分表、集中式緩存等技術提升系統處理能力；

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

　　自研庫存架構

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

　　自研庫存架構-總體架構

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

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

　　圖8 自研庫存架構-總體架構圖 自研庫存架構-系統交互

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

　　圖9 自研庫存架構-系統交互圖 自研庫存架構-部署架構

　　自研庫存系統是基于蘇寧技術體系搭建的一套高并發、可擴展的架構。

　　庫存系統通過使用蘇寧自研的RPC調用框架（rsf）對外提供實時服務，通過使用kafka組件進行消息分發和消息訂閱，對外提供數據服務和接收外部數據；

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

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

　　圖10 自研庫存架構-部署架構圖 自研庫存架構-數據架構

　　以自營庫存交易系統GAIA為例，庫存從數據架構上進行了水平和垂直拆分，分為公共庫、業務庫和日志庫。

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

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

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

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

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

　　數據架構見圖11。

　　圖11 自研庫存架構-數據架構圖 搶購庫存-面臨挑戰及應對

　　通常的搶購、團購、秒殺等活動業務對于庫存業務來說具有以下挑戰：

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

　　高并發下應用、數據庫負載連接突然飆升；

　　引起黃牛效應。

　　針對以上挑戰，我們有以下應對方案來確保系統的穩定性：

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

　　架構分離，對活動庫存的業務進行隔離部署；

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

　　搶購庫存-系統構建

　　搶購庫存的系統構建：

　　銷售準備：活動營銷系統創建活動時，先進行庫存數量的預鎖，將活動庫存和普通庫存邏輯分離；

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

　　通過庫存數量緩存化、活動庫存的部署分離、數據庫數量表扣減更新的異步化，我們實現了高并發的活動庫存系統架構。

　　搶購庫存的實現示意，如圖12。

　　圖12 搶購庫存-系統架構圖 自研庫存架構-架構分析

　　自研庫存架構實現了架構的完全開源自實現，并搭建了高并發的分布式架構，但在電商業務蓬勃發展，訂單屢創新高的背景下，依然面臨一些挑戰：

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

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

　　故障隔離：某數據庫分片出現宕機，從而影響整個交易；某redis分片出現宕機，從而影響整個交易；

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

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

　　多活庫存架構 庫存單元化

　　為了解決擴展痛點、故障隔離、熱點瓶頸等架構問題，我們先實現了庫存交易系統的單元化部署。

　　系統單元化有以下幾個原則：

　　單元封閉

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

　　高可用

　　單元內的所有部署節點，也要遵循高可用的原則，不能出現單點故障；

　　無限擴展

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

　　對外透明

　　庫存系統單元化部署對外部調用系統是完全透明的；

　　服務熔斷

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

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

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

　　圖13 庫存單元化示意圖 庫存多活架構

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

　　如圖14。

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

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

　　機器擴容

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

　　梳理流控與降級方案

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

　　單系統生產壓測及端到端性能測試

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

　　系統健康檢查

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

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

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

　　大促籌備的幾大環節如圖15。