蘇寧庫存架構轉變

轉：http://blog.csdn.net/dev_csdn/article/details/78769402

前言

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

庫存業務介紹及面臨的挑戰

庫存系統定位及核心業務場景分析

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

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

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

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

圖1 系統上下文圖

庫存業務架構

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

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

圖2 業務架構圖

庫存面臨的挑戰

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

1. 熱點爭搶 
   針對同一個商品，比如秒殺、團購、打折促銷等活動商品，如何支撐高併發庫存扣減服務。
2. 週轉率 
   如何提升庫存週轉率，最大化利用企業資金，做到銷售最大化。
3. 避免超賣 
   避免超賣是庫存系統架構設計和系統實施的底線原則。
4. 系統擴充套件性 
   如何建設出可無限擴充套件的庫存架構，在系統擴充套件過程中，各部署節點都需要具備無限擴充套件能力，而常見的瓶頸如資料庫的連線數、佇列的連線數等。

庫存系統的架構演進

蘇寧庫存系統的架構演進主要劃分為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 電商初期-系統互動圖

電商初期-架構分析

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

1. 訂單、庫存等核心業務集中執行在一個系統，耦合性太強，不易改造，業務擴充套件性很差；
2. 為了快速佔有電商市場，業務快速上線，選型SAP/WCS商業軟體，受制於廠商，軟體維護能力薄弱；
3. SAP僅支援單資料庫，架構不具備系統擴充套件能力，無法支援雙線日益增長的交易處理。

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

前臺、中臺、後臺分離架構

前中後分離-總體架構

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

圖6 前中後分離-總體架構圖

前中後分離-系統互動

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

圖7 前中後分離-系統互動圖

前中後臺分離-架構分析

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

1. 將訂單、庫存等業務從SAP-R3拆分出獨立系統後，解決了業務擴充套件性的問題，符合“高內聚、低耦合”的架構原則；
2. 自營庫存系統SIMS還是採用的SAP商業軟體，仍然受制於廠商，但庫存路由系統CIS和C店庫存系統CIMS是JAVA自研系統，軟體具備維護能力；
3. SIMS（SAP）僅支援單資料庫，自營庫存系統SIMS仍然無法支援雙線日益增長的交易處理，系統效能有一定的提升；
4. 針對搶購、團購類活動場景，容易造成庫存熱點，無法有效支援高併發的庫存扣減。

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

1. “去SAP化”，去商業軟體，實現自開發自營庫存系統；
2. 搭建分散式架構，採用應用叢集、資料庫的分庫分表、集中式快取等技術提升系統處理能力；
3. 針對搶購、團購等活動庫存場景，新建納秒購系統來提供高併發、高效能的庫存服務，和普通庫存進行獨立設計和分開部署。

自研庫存架構

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

自研庫存架構-總體架構

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

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

如圖8。

圖8 自研庫存架構-總體架構圖

自研庫存架構-系統互動

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

圖9 自研庫存架構-系統互動圖

自研庫存架構-部署架構

自研庫存系統是基於蘇寧技術體系搭建的一套高併發、可擴充套件的架構。

1. 庫存系統通過使用蘇寧自研的RPC呼叫框架（rsf）對外提供實時服務，通過使用kafka元件進行訊息分發和訊息訂閱，對外提供資料服務和接收外部資料；
2. 應用使用wildfly standalone叢集，資料庫使用MySQL叢集，資料庫採用讀寫分離部署；
3. 運維人員的庫存管理通過使用ES（Elastic Search）平臺提供商品和商家等多維護的庫存查詢和管理服務，管理端對資料的抽取通過讀vip訪問MySQL讀庫。

見圖10。

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

自研庫存架構-資料架構

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

1. 公共庫存放主資料及基礎配置資訊，包含分庫分表規則、job配置、ATP檢查配置、公共基礎資料等，公共庫為一主多從，可通過本地快取、集中式快取、擴充套件從庫來減輕對主庫的壓力；
2. 業務庫提供核心庫存交易服務，存放核心數量表、銷售鎖定表、交貨鎖定表等業務資料，業務庫按照商品編碼hash取模進行分庫分表，核心表分為1000張表；
3. 日誌庫存放各類介面的交易流水資料，記錄各類服務的日誌、審計及庫存對賬等資訊，日誌庫按照外部單據號hash取模進行分庫分表，核心表分為1000張表。

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

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

資料架構見圖11。

圖11 自研庫存架構-資料架構圖

搶購庫存-面臨挑戰及應對

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

1. 瞬間流量巨大，造成庫存熱點的爭搶；
2. 高併發下應用、資料庫負載連線突然飆升；
3. 引起黃牛效應。

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

1. 庫存交易處理快取化，避免資料庫層面鎖資源的爭用；
2. 架構分離，對活動庫存的業務進行隔離部署；
3. 通過構建基於IP/UA訪問策略的WAF防火牆，通過應用層的業務流控和系統流控，通過風控（人機識別）等技術手段來應對黃牛的惡意流量。

搶購庫存-系統構建

搶購庫存的系統構建：

1. 銷售準備：活動營銷系統建立活動時，先進行庫存數量的預鎖，將活動庫存和普通庫存邏輯分離；
2. 銷售執行：活動商品詳情頁展示時，會進行活動庫存數量查詢，直接訪問活動庫存數量快取；使用者在提交訂單時，會進行支付前檢查，這時我們進行庫存的臨時鎖定，系統通過快取redis的lua（EVAL）原子命令執行扣減指令碼以支援高併發的庫存扣減服務，同時對db進行insert插入一條庫存鎖定記錄，避免產生資料庫鎖資源的爭搶；顧客在支付完成後，會進行庫存的正式鎖定，系統會更新使用者提交訂單時插入的鎖定記錄的鎖定狀態，通過非同步進行db庫存數量表的更新達到資料庫的消峰目標。

通過庫存數量快取化、活動庫存的部署分離、資料庫數量表扣減更新的非同步化，我們實現了高併發的活動庫存系統架構。

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

圖12 搶購庫存-系統架構圖

自研庫存架構-架構分析

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

1. 擴充套件痛點：受限於資料庫的連線數瓶頸、Redis伺服器的連線數瓶頸、佇列伺服器的連線數瓶頸等因素，導致應用叢集無法無限擴充套件；
2. 機房容災及機房容量：機房斷電，電纜被挖，造成整個蘇寧易購交易系統癱瘓；單個機房容量受限，無法建立更多的伺服器；
3. 故障隔離：某資料庫分片出現當機，從而影響整個交易；某redis分片出現當機，從而影響整個交易；
4. 熱點瓶頸：雖然通過構建快取化支援庫存交易，但單個商品的併發扣減仍然存在上限

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

多活庫存架構

庫存單元化

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

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

1. 單元封閉 
   單次請求需要封閉在一個單元內完成，嚴謹跨單元操作；
2. 高可用 
   單元內的所有部署節點，也要遵循高可用的原則，不能出現單點故障；
3. 無限擴充套件 
   單元之間可以進行無限的擴充套件；
4. 對外透明 
   庫存系統單元化部署對外部呼叫系統是完全透明的；
5. 服務熔斷 
   單元化系統內提供的服務需要能夠支援服務熔斷，單元不會因為一個服務的問題導致整個的單元收到影響。

單元採用商家編號hash取模的維度進行單元的劃分。多個單元組成一個單元組。跨單元的一些管理功能基於ES（Elastic Search）平臺提供服務。 
庫存單元化示意圖如圖13。

圖13 庫存單元化示意圖

庫存多活架構

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

如圖14。

圖14 庫存多活架構示意圖

庫存如何應對雙11大促

容量預估

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

機器擴容

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

梳理流控與降級方案

所有交易介面需要設定合理的流控閥值，以確保系統不會掛死；梳理所有介面的呼叫系統和業務場景並明確業務的優先順序，假設系統因為某服務導致效能出現瓶頸，根據業務優先順序逐步調整流控閥值；業務流控或系統流控要實現使用者的友好提示；對於後端依賴系統，如果出現超時或當機，則定義降級策略，確保服務請求的快進快出。

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

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

系統健康檢查

提前對系統的各方面進行全面的健康檢查，比如db磁碟的容量、連線數、topsql，快取的記憶體使用率、併發命令數和連線數，訊息佇列的連線數，各節點的cpu負載情況，排除單點故障，排除虛擬機器的資源爭用問題，排除高可用問題（同一物理機多應用節點）等。

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

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

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

圖15 雙11籌備示意圖