前言

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

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

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

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

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

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

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

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

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

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

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

　　熱點(diǎn)爭(zhēng)搶

　　針對(duì)同一個(gè)商品，比如秒殺、團(tuán)購(gòu)、打折促銷等活動(dòng)商品，如何支撐高并發(fā)庫存扣減服務(wù)。

　　周轉(zhuǎn)率

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

　　避免超賣

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

　　系統(tǒng)擴(kuò)展性

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

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

　　蘇寧庫存系統(tǒng)的架構(gòu)演進(jìn)主要?jiǎng)澐譃?個(gè)階段：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　針對(duì)搶購(gòu)、團(tuán)購(gòu)類活動(dòng)場(chǎng)景，容易造成庫存熱點(diǎn)，無法有效支持高并發(fā)的庫存扣減。

　　針對(duì)以上架構(gòu)問題，我們?cè)诩軜?gòu)上進(jìn)一步提出優(yōu)化思路：

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

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

　　針對(duì)搶購(gòu)、團(tuán)購(gòu)等活動(dòng)庫存場(chǎng)景，新建納秒購(gòu)系統(tǒng)來提供高并發(fā)、高性能的庫存服務(wù)，和普通庫存進(jìn)行獨(dú)立設(shè)計(jì)和分開部署。

　　自研庫存架構(gòu)

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

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

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

　　搶購(gòu)庫存AIMS提供基于緩存的高并發(fā)庫存服務(wù)，支撐爆款搶購(gòu)、爆款預(yù)約、大聚會(huì)等活動(dòng)場(chǎng)景。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　通常的搶購(gòu)、團(tuán)購(gòu)、秒殺等活動(dòng)業(yè)務(wù)對(duì)于庫存業(yè)務(wù)來說具有以下挑戰(zhàn)：

　　瞬間流量巨大，造成庫存熱點(diǎn)的爭(zhēng)搶；

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

　　引起黃牛效應(yīng)。

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

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

　　架構(gòu)分離，對(duì)活動(dòng)庫存的業(yè)務(wù)進(jìn)行隔離部署；

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

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

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

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

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

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

　　搶購(gòu)庫存的實(shí)現(xiàn)示意，如圖12。

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

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

　　擴(kuò)展痛點(diǎn)：受限于數(shù)據(jù)庫的連接數(shù)瓶頸、Redis服務(wù)器的連接數(shù)瓶頸、隊(duì)列服務(wù)器的連接數(shù)瓶頸等因素，導(dǎo)致應(yīng)用集群無法無限擴(kuò)展；

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

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

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

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

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

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

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

　　單元封閉

　　單次請(qǐng)求需要封閉在一個(gè)單元內(nèi)完成，嚴(yán)謹(jǐn)跨單元操作；

　　高可用

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

　　無限擴(kuò)展

　　單元之間可以進(jìn)行無限的擴(kuò)展；

　　對(duì)外透明

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

　　服務(wù)熔斷

　　單元化系統(tǒng)內(nèi)提供的服務(wù)需要能夠支持服務(wù)熔斷，單元不會(huì)因?yàn)橐粋€(gè)服務(wù)的問題導(dǎo)致整個(gè)的單元收到影響。

　　單元采用商家編號(hào)hash取模的維度進(jìn)行單元的劃分。多個(gè)單元組成一個(gè)單元組?？鐔卧囊恍┕芾砉δ芑贓S（Elastic Search）平臺(tái)提供服務(wù)。

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

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

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

　　如圖14。

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

　　對(duì)公司雙11大促的 活動(dòng)預(yù)告及銷售目標(biāo)進(jìn)行詳細(xì)評(píng)估和分解，轉(zhuǎn)化成庫存系統(tǒng)的核心服務(wù)的SLA，確定庫存系統(tǒng)的核心服務(wù)的TPS目標(biāo)。

　　機(jī)器擴(kuò)容

　　基于容量預(yù)估出來的TPS目標(biāo)，評(píng)估庫存的機(jī)器是否需要擴(kuò)容，比如jboss集群是否需要擴(kuò)容，db是否能夠支撐，db是否需要拆庫拆表，db磁盤容量是否足夠，服務(wù)器負(fù)載是否足夠等。

　　梳理流控與降級(jí)方案

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

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

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

　　系統(tǒng)健康檢查

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

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

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

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