|
庫存業(yè)務介紹及面臨的挑戰(zhàn) 庫存系統(tǒng)定位及核心業(yè)務場景分析首先介紹一下庫存系統(tǒng)的定位，它主要為企業(yè)級的經(jīng)營性可用商品庫存獲取應用，與平臺商品目錄緊密關聯(lián)，定位為蘇寧核心平臺之一。平臺級商品庫存支持線上、線下銷售渠道和營銷活動對經(jīng)營性可用商品庫存的查詢，支持平臺商品庫存鎖定、解鎖、增加、減少等庫存核心服務，并為平臺商戶提供服務支撐。 庫存作為電商交易的核心系統(tǒng)之一，它貫穿蘇寧的整個業(yè)務價值鏈條，不論從采購線的采購、交貨、調撥、退場、入庫過賬、實物盤點等環(huán)節(jié)，還是銷售線的瀏覽、下單、發(fā)貨、出庫過賬等環(huán)節(jié)，再到客服支撐、經(jīng)營分析報表、預測補貨、多平臺銷售支撐等大數(shù)據(jù)應用，都和庫存系統(tǒng)緊密關聯(lián)。 庫存從業(yè)務模式上分為自營庫存和C店庫存。自營庫存即蘇寧自采自銷的庫存，C店庫存即通過開放平臺入駐的平臺商戶所銷售的庫存。 庫存中心聚焦的是銷售庫存，即支撐蘇寧銷售和交易相關的所有庫存服務。而蘇寧的實物庫存是在蘇寧的物流平臺進行管理的。兩套庫存的定位不一樣，但兩套庫存之間具有一定的關聯(lián)，且通過定期嚴謹?shù)膸齑鎸~機制來確保兩套庫存數(shù)據(jù)的一致。如圖1。
庫存業(yè)務架構庫存系統(tǒng)從業(yè)務架構上分為庫存交易、庫存管理、異常管理、運維管理四大組成部分。 庫存交易部分分為銷售鎖定、銷售解鎖、交貨鎖定、交貨解鎖、數(shù)量查詢、庫存狀態(tài)查詢、狀態(tài)下傳、數(shù)量下傳、活動預鎖、活動預解鎖、活動庫存查詢、活動管理等功能模塊。庫存管理部分分為采購、調撥、退廠、移庫、盤點、對賬、狀態(tài)計算、銷售過賬、庫存同步、多平臺分貨等功能模塊。庫存狀態(tài)是指定義庫存有貨、無貨的一種狀態(tài)標識，通過實現(xiàn)庫存狀態(tài)，可大大減少外圍系統(tǒng)對庫存數(shù)量查詢接口的調用，比如商品詳情頁只關注商品有無貨，通過庫存狀態(tài)即可支持。業(yè)務架構如圖2。 庫存面臨的挑戰(zhàn)庫存系統(tǒng)主要面臨以下幾個挑戰(zhàn)： 1. 熱點爭搶 2. 周轉率 3. 避免超賣 4. 系統(tǒng)擴展性 庫存系統(tǒng)的架構演進 蘇寧庫存系統(tǒng)的架構演進主要劃分為4個階段：
如圖3。每個階段庫存架構的詳細內容會在下面章節(jié)展開。
電商初期架構電商初期-總體架構 線下連鎖時代的電商初期總體架構，線下銷售采用POS客戶端系統(tǒng)，線上銷售采用WCS （IBM WebSphere Commerce）（JAVA）系統(tǒng)，服務端采用SAP-R3商業(yè)軟件。如圖4。 圖4 電商初期-總體架構圖 電商初期-系統(tǒng)交互 線下門店POS系統(tǒng)和線上主站W(wǎng)CS（IBM WebSphere Commerce）系統(tǒng)調用SAP-R3提供的庫存檢查、庫存鎖定、庫存解鎖等服務，同時，為了減輕線上主站對后端服務系統(tǒng)的壓力，SAP-R3會將庫存數(shù)量的變化主動推送給WCS系統(tǒng)，在WCS系統(tǒng)本地暫存一份影子庫存數(shù)據(jù)，WCS商品詳情頁加載商品信息時，先查詢本地的影子庫存，判斷如果影子庫存過了保鮮期（有效期），則進行庫存懶加載，實時調用SAP-R3的庫存數(shù)量查詢服務，再更新本地影子庫存；另外，主站搜索系統(tǒng)也是基于WCS本地的影子庫存數(shù)據(jù)來創(chuàng)建和更新索引。系統(tǒng)交互關系如圖5。 圖5 電商初期-系統(tǒng)交互圖 電商初期-架構分析 電商初期架構主要存在以下問題： 1. 訂單、庫存等核心業(yè)務集中運行在一個系統(tǒng)，耦合性太強，不易改造，業(yè)務擴展性很差； 2. 為了快速占有電商市場，業(yè)務快速上線，選型SAP/WCS商業(yè)軟件，受制于廠商，軟件維護能力薄弱； 3. SAP僅支持單數(shù)據(jù)庫，架構不具備系統(tǒng)擴展能力，無法支持雙線日益增長的交易處理。 為了解決上述架構問題，我們自然而然想到了進行業(yè)務系統(tǒng)的拆分。我們花了近兩年時間進行了大刀闊斧的前、中、后臺架構的分離。 前臺、中臺、后臺分離架構 前中后分離-總體架構基于前臺瀏覽、銷售交易、銷售履約&運營管理的業(yè)務劃分和歸類，我們對系統(tǒng)進行了前臺、中臺、后臺的架構分離。前臺由各個銷售平臺組成，比如易購主站、門店POS系統(tǒng)、電話銷售，以及其他銷售平臺，負責用戶體驗和商品展示；中臺是核心交易平臺，提供庫存、尋源、價格、商品、促銷、會員等基礎服務、以及提供云購物車、訂單等組合服務，同時中臺提供諸葛等一系列基于大數(shù)據(jù)的報表和應用，后臺是提供蘇寧自營（供應鏈、分賬、記賬、結算、發(fā)票、采購等）、商家運營（店鋪、商品、庫存、訂單、價格、供應鏈管理等）的一套運營管理平臺、還有大物流平臺。如圖6。 前中后分離-系統(tǒng)交互新建平臺庫存系統(tǒng)，平臺庫存由庫存路由系統(tǒng)CIS（JAVA）、自營庫存系統(tǒng)SIMS（SAP）、C店庫存系統(tǒng)CIMS（JAVA）三個系統(tǒng)組成，瀏覽線的尋源系統(tǒng)調用平臺庫存的庫存數(shù)量查詢服務，交易線的訂單中心調用平臺庫存的銷售鎖定、銷售解鎖、交貨鎖定、交貨解鎖等服務，SAP-ERP同步采購庫存數(shù)據(jù)至自營庫存系統(tǒng)SIMS，開放平臺同步商戶api或頁面維護的C店庫存數(shù)據(jù)至C店庫存系統(tǒng)CIMS。平臺庫存將庫存狀態(tài)數(shù)據(jù)同步至尋源系統(tǒng)。如圖7。
前中后臺分離-架構分析前中后臺架構分離后分析如下： 1. 將訂單、庫存等業(yè)務從SAP-R3拆分出獨立系統(tǒng)后，解決了業(yè)務擴展性的問題，符合“高內聚、低耦合”的架構原則； 2. 自營庫存系統(tǒng)SIMS還是采用的SAP商業(yè)軟件，仍然受制于廠商，但庫存路由系統(tǒng)CIS和C店庫存系統(tǒng)CIMS是JAVA自研系統(tǒng)，軟件具備維護能力； 3. SIMS（SAP）僅支持單數(shù)據(jù)庫，自營庫存系統(tǒng)SIMS仍然無法支持雙線日益增長的交易處理，系統(tǒng)性能有一定的提升； 4. 針對搶購、團購類活動場景，容易造成庫存熱點，無法有效支持高并發(fā)的庫存扣減。 針對以上架構問題，我們在架構上進一步提出優(yōu)化思路： 1. “去SAP化”，去商業(yè)軟件，實現(xiàn)自開發(fā)自營庫存系統(tǒng)； 2. 搭建分布式架構，采用應用集群、數(shù)據(jù)庫的分庫分表、集中式緩存等技術提升系統(tǒng)處理能力； 3. 針對搶購、團購等活動庫存場景，新建納秒購系統(tǒng)來提供高并發(fā)、高性能的庫存服務，和普通庫存進行獨立設計和分開部署。 自研庫存架構 自研庫存系統(tǒng)，將庫存系統(tǒng)從職能和系統(tǒng)上劃分為庫存交易和庫存管理。庫存交易由庫存路由系統(tǒng)CIS、自營庫存交易系統(tǒng)GAIA、C店庫存交易系統(tǒng)CIMS、搶購庫存系統(tǒng)AIMS 四個系統(tǒng)組成。 自研庫存架構-總體架構庫存路由系統(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。 自研庫存架構-系統(tǒng)交互新建GAIA系統(tǒng)（JAVA）替換 SIMS系統(tǒng)（SAP）自營庫存的交易職能，新建獨立的納秒購庫存系統(tǒng)以支撐搶購、團購等大促活動。納秒購庫存系統(tǒng)，基于“架構獨立、庫存預鎖、數(shù)量緩存化”的思路進行搭建，提供高性能的庫存服務。如圖9。 自研庫存架構-部署架構自研庫存系統(tǒng)是基于蘇寧技術體系搭建的一套高并發(fā)、可擴展的架構。 1. 庫存系統(tǒng)通過使用蘇寧自研的RPC調用框架（rsf）對外提供實時服務，通過使用kafka組件進行消息分發(fā)和消息訂閱，對外提供數(shù)據(jù)服務和接收外部數(shù)據(jù)； 2. 應用使用wildfly standalone集群，數(shù)據(jù)庫使用MySQL集群，數(shù)據(jù)庫采用讀寫分離部署； 3. 運維人員的庫存管理通過使用ES（Elastic Search）平臺提供商品和商家等多維護的庫存查詢和管理服務，管理端對數(shù)據(jù)的抽取通過讀vip訪問MySQL讀庫。 見圖10。
自研庫存架構-數(shù)據(jù)架構以自營庫存交易系統(tǒng)GAIA為例，庫存從數(shù)據(jù)架構上進行了水平和垂直拆分，分為公共庫、業(yè)務庫和日志庫。 1. 公共庫存放主數(shù)據(jù)及基礎配置信息，包含分庫分表規(guī)則、job配置、ATP檢查配置、公共基礎數(shù)據(jù)等，公共庫為一主多從，可通過本地緩存、集中式緩存、擴展從庫來減輕對主庫的壓力； 2. 業(yè)務庫提供核心庫存交易服務，存放核心數(shù)量表、銷售鎖定表、交貨鎖定表等業(yè)務數(shù)據(jù)，業(yè)務庫按照商品編碼hash取模進行分庫分表，核心表分為1000張表； 3. 日志庫存放各類接口的交易流水數(shù)據(jù)，記錄各類服務的日志、審計及庫存對賬等信息，日志庫按照外部單據(jù)號hash取模進行分庫分表，核心表分為1000張表。 對于庫存系統(tǒng)來說，發(fā)生一筆庫存交易，通常需要同時寫入業(yè)務庫和日志庫，這就需要解決分布式事務的問題。根據(jù)CAP（C（Consistency）、A（Availability）、P（Partition tolerance））理論，三者是無法同時滿足的。我們舍棄了Consistency（實時一致性）特性，在滿足分區(qū)容錯性和可用性基礎上，確保事務提交的結果最終一致。 為了最大化的提升庫存交易的性能，我們采用“實時扣、異步加”的處理原則，對于庫存數(shù)量的扣減采用實時處理的方式，而對于庫存數(shù)量的加回采用異步的處理方式，因為庫存數(shù)量的加回不存在業(yè)務上失敗的可能，業(yè)務上一定能夠確保成功，而庫存數(shù)量的扣減是存在業(yè)務并發(fā)下失敗的可能的。 數(shù)據(jù)架構見圖11。
搶購庫存-面臨挑戰(zhàn)及應對通常的搶購、團購、秒殺等活動業(yè)務對于庫存業(yè)務來說具有以下挑戰(zhàn)： 1. 瞬間流量巨大，造成庫存熱點的爭搶； 2. 高并發(fā)下應用、數(shù)據(jù)庫負載連接突然飆升； 3. 引起黃牛效應。 針對以上挑戰(zhàn)，我們有以下應對方案來確保系統(tǒng)的穩(wěn)定性： 1. 庫存交易處理緩存化，避免數(shù)據(jù)庫層面鎖資源的爭用； 2. 架構分離，對活動庫存的業(yè)務進行隔離部署； 3. 通過構建基于IP/UA訪問策略的WAF防火墻，通過應用層的業(yè)務流控和系統(tǒng)流控，通過風控（人機識別）等技術手段來應對黃牛的惡意流量。 搶購庫存-系統(tǒng)構建搶購庫存的系統(tǒng)構建： 1. 銷售準備：活動營銷系統(tǒng)創(chuàng)建活動時，先進行庫存數(shù)量的預鎖，將活動庫存和普通庫存邏輯分離； 2. 銷售執(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)架構。 搶購庫存的實現(xiàn)示意，如圖12。 自研庫存架構-架構分析自研庫存架構實現(xiàn)了架構的完全開源自實現(xiàn)，并搭建了高并發(fā)的分布式架構，但在電商業(yè)務蓬勃發(fā)展，訂單屢創(chuàng)新高的背景下，依然面臨一些挑戰(zhàn)： 1. 擴展痛點：受限于數(shù)據(jù)庫的連接數(shù)瓶頸、Redis服務器的連接數(shù)瓶頸、隊列服務器的連接數(shù)瓶頸等因素，導致應用集群無法無限擴展； 2. 機房容災及機房容量：機房斷電，電纜被挖，造成整個蘇寧易購交易系統(tǒng)癱瘓；單個機房容量受限，無法創(chuàng)建更多的服務器； 3. 故障隔離：某數(shù)據(jù)庫分片出現(xiàn)宕機，從而影響整個交易；某redis分片出現(xiàn)宕機，從而影響整個交易； 4. 熱點瓶頸：雖然通過構建緩存化支持庫存交易，但單個商品的并發(fā)扣減仍然存在上限 為了解決上述問題，我們開始開展庫存的單元化和多活架構構建。 多活庫存架構 庫存單元化為了解決擴展痛點、故障隔離、熱點瓶頸等架構問題，我們先實現(xiàn)了庫存交易系統(tǒng)的單元化部署。 系統(tǒng)單元化有以下幾個原則： 1. 單元封閉 2. 高可用 3. 無限擴展 4. 對外透明 5. 服務熔斷 單元采用商家編號hash取模的維度進行單元的劃分。多個單元組成一個單元組?？鐔卧囊恍┕芾砉δ芑贓S（Elastic Search）平臺提供服務。 庫存單元化示意圖如圖13。
庫存多活架構庫存服務屬于競爭型的服務，不能在子機房之間實現(xiàn)數(shù)據(jù)共享，因此，我們基于大數(shù)據(jù)智能分貨引擎在主機房進行庫存數(shù)據(jù)的智能調撥和分貨，能夠基本實現(xiàn)交易單元中庫存業(yè)務在本機房內提供服務，同時機房之間建立數(shù)據(jù)庫的互相備份，當A機房出現(xiàn)故障，可由B機房完全接管。 如圖14。 庫存如何應對雙11大促 容量預估對公司雙11大促的 活動預告及銷售目標進行詳細評估和分解，轉化成庫存系統(tǒng)的核心服務的SLA，確定庫存系統(tǒng)的核心服務的TPS目標。 機器擴容基于容量預估出來的TPS目標，評估庫存的機器是否需要擴容，比如jboss集群是否需要擴容，db是否能夠支撐，db是否需要拆庫拆表，db磁盤容量是否足夠，服務器負載是否足夠等。 梳理流控與降級方案所有交易接口需要設定合理的流控閥值，以確保系統(tǒng)不會掛死；梳理所有接口的調用系統(tǒng)和業(yè)務場景并明確業(yè)務的優(yōu)先級，假設系統(tǒng)因為某服務導致性能出現(xiàn)瓶頸，根據(jù)業(yè)務優(yōu)先級逐步調整流控閥值；業(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，緩存的內存使用率、并發(fā)命令數(shù)和連接數(shù)，消息隊列的連接數(shù)，各節(jié)點的cpu負載情況，排除單點故障，排除虛擬機的資源爭用問題，排除高可用問題（同一物理機多應用節(jié)點）等。 大促前重大版本回溯及事故案例回溯大促前會進行生產(chǎn)重大版本的回溯，針對新提供的服務，新支持的業(yè)務或活動形式要重點關注，確保新增業(yè)務的服務可靠性和穩(wěn)定性；大促前還會進行事故的案例回溯，回顧以往發(fā)生的生產(chǎn)事故，排除有類似的事故風險，確保問題不會重復的發(fā)生。 大促籌備的幾大環(huán)節(jié)如圖15。
|
|
|
