【51CTO.com原創(chuàng)稿件】在“智慧零售大開發(fā)”的戰(zhàn)略驅(qū)動(dòng)下，2018 年蘇寧新開門店超過 8000 家，目前各類門店總數(shù)已經(jīng)超過 1.1 萬家，在線下形成了“兩大兩小多專”的智慧零售業(yè)態(tài)群。

同時(shí)構(gòu)建了以蘇寧超市、蘇寧拼購(gòu)為代表的線上平臺(tái)。從而形成了線上多平臺(tái)、線下場(chǎng)景多業(yè)態(tài)互聯(lián)網(wǎng)化，不斷打造跨線上線下全場(chǎng)景的消費(fèi)環(huán)境和空間。

隨之而來的是新增各式各樣的業(yè)態(tài)帶來的業(yè)務(wù)鏈路的多樣化，以及適應(yīng)行業(yè)的急速發(fā)展帶來業(yè)務(wù)需求的多變化…

總之一切都是“變”的，作為自營(yíng)采購(gòu)的核心系統(tǒng)采購(gòu)平臺(tái)，是如何適應(yīng)這些變化?

下面會(huì)通過采購(gòu)平臺(tái)發(fā)展的三個(gè)階段，介紹我們是如何通過積極的“擁抱”變化，走出自己獨(dú)特的架構(gòu)演進(jìn)之路。

***階段：系統(tǒng)搭建&功能完善期

采購(gòu)平臺(tái)是基于 2006 年上線的 SAP-R3 采購(gòu)管理模塊搭建的。

SAP-R3 作為蘇寧信息化歷程上重要里程碑，為蘇寧的飛速發(fā)展曾立下汗馬功勞，但隨著多元業(yè)務(wù)急速發(fā)展，已經(jīng)不能很好的滿足業(yè)務(wù)的多變性和支撐新業(yè)態(tài)的發(fā)展。

就采購(gòu)管理而言，SAP-R3 未與商品規(guī)劃、選品等前置管理環(huán)節(jié)銜接，無法在此基礎(chǔ)上開展采購(gòu)業(yè)務(wù)。

另一方面 SAP-R3 中采購(gòu)和財(cái)務(wù)相關(guān)業(yè)務(wù)耦合緊密，牽一發(fā)而動(dòng)全身，無法支持各業(yè)態(tài)新的業(yè)務(wù)的快速部署，再就是存在操作復(fù)雜，培訓(xùn)學(xué)習(xí)成本高的問題?；谝陨系膯栴}，2015 年開始搭建基于 Java 的自主研發(fā)采購(gòu)系統(tǒng)。

方向已定，同時(shí)困難也是顯而易見的，SAP-R3 作為已經(jīng)運(yùn)行 9 年多的系統(tǒng)，已經(jīng)有很多業(yè)務(wù)在上面運(yùn)行，同時(shí)與大量外部系統(tǒng)有關(guān)聯(lián)，系統(tǒng)關(guān)系錯(cuò)綜復(fù)雜。

新系統(tǒng)的切換，首要考慮的是保持業(yè)務(wù)的持續(xù)性，平滑的過渡盡可能降低對(duì)外部系統(tǒng)的影響，這對(duì)我們來說也不亞于“在行駛的汽車上換輪胎”。

綜合各種情況考慮，最終確認(rèn)新系統(tǒng)的切換方案：***步新系統(tǒng)提供各種創(chuàng)單以及管理功能，提供體驗(yàn)更好的服務(wù)，SAP-R3 系統(tǒng)繼續(xù)承擔(dān)調(diào)度功能，雙系統(tǒng)并行，業(yè)務(wù)逐步切換。

如上圖所示使用 R3 管理采購(gòu)業(yè)務(wù)、訂單調(diào)度、賬務(wù)庫存，對(duì)現(xiàn)有系統(tǒng)架構(gòu)、庫存結(jié)構(gòu)、庫存核算沒有改動(dòng)，風(fēng)險(xiǎn)相對(duì)可控，投入資源相對(duì)較少，雖然離去除 R3 的目標(biāo)只算邁出一小步，但對(duì)于保障業(yè)務(wù)的穩(wěn)定性是值得的!

確定好方案以后，著手新系統(tǒng)的框架搭建，考慮系統(tǒng)的可擴(kuò)展性和穩(wěn)定性，將模塊功能獨(dú)立化，類似微服務(wù)的概念，將業(yè)務(wù)模塊采購(gòu)，退廠，調(diào)撥，樣機(jī)&不良品，采購(gòu)需求作為獨(dú)立應(yīng)用部署，降低相互之間的耦合。

同時(shí)部署一個(gè)資源能力系統(tǒng)為各個(gè)業(yè)務(wù)系統(tǒng)提供統(tǒng)一的公共服務(wù)，主數(shù)據(jù)服務(wù)，權(quán)限服務(wù)，降低代碼的重復(fù)度。

系統(tǒng)結(jié)構(gòu)如下圖：

系統(tǒng)搭建完成后，隨著系統(tǒng)的平穩(wěn)運(yùn)行，***步工作暫告一段落，2016 年開始第二步的架構(gòu)改造：去除 SAP 的中轉(zhuǎn)，由采購(gòu)平臺(tái)作為核心調(diào)度，真正承擔(dān)對(duì)物流和庫存的調(diào)度!

如果說***步改造如同行駛中更換“輪胎”，那么第二步的改造，涉及整個(gè)鏈路上的核心的調(diào)整，就如同行駛中更換“引擎”，盡可能保障業(yè)務(wù)的無感知切換仍然是***位的，切換過程采用雙鏈路并行措施：試點(diǎn)+鏈路開關(guān)。

一旦發(fā)現(xiàn)試點(diǎn)的新鏈路功能有問題，可立刻切換到老的鏈路上，保證業(yè)務(wù)正常開展。

另外作為核心調(diào)度的系統(tǒng)，如何保證數(shù)據(jù)流轉(zhuǎn)的閉環(huán)，可追溯，安全是必須要考慮的。在原有的系統(tǒng)基礎(chǔ)上補(bǔ)充了操作日志系統(tǒng)，便于業(yè)務(wù)操作數(shù)據(jù)的追溯。

第二階段：功能突增&業(yè)務(wù)爆發(fā)期

***階段主要是系統(tǒng)搭建和功能遷移，2017 年以后的系統(tǒng)的重點(diǎn)轉(zhuǎn)移到提升用戶體驗(yàn)，以及支撐新業(yè)務(wù)的急速發(fā)展。

主要從系統(tǒng)功能架構(gòu)，數(shù)據(jù)存儲(chǔ)架構(gòu)，業(yè)務(wù)架構(gòu)幾個(gè)方面做出優(yōu)化改進(jìn)：

系統(tǒng)功能架構(gòu)優(yōu)化

為提升功能的豐富程度和體驗(yàn)，加上對(duì)新業(yè)態(tài)的支持，新增很多創(chuàng)單入口，創(chuàng)單邏輯本身復(fù)雜度很高和外圍系統(tǒng)的交互又很多，加上項(xiàng)目周期短，前期都是基于已有的功能重新做一套。

雖然降低了對(duì)已有功能的影響，但是帶來運(yùn)維的復(fù)雜度成幾何級(jí)提升，有時(shí)涉及一個(gè)創(chuàng)單共用邏輯的修改往往要改近十幾個(gè)地方，開發(fā)容易遺漏，測(cè)試也苦不堪言。系統(tǒng)功能的架構(gòu)優(yōu)化提上日程。

針對(duì)上述情況和系統(tǒng)特點(diǎn)，我們采取的技術(shù)方案：服務(wù)原子化，功能積木化。

將一些基礎(chǔ)服務(wù)，簡(jiǎn)單而言就是將創(chuàng)單邏輯分解成基礎(chǔ)服務(wù)，新的功能基于基礎(chǔ)服務(wù)進(jìn)行積木式組合，如下圖：

基礎(chǔ)服務(wù)層提供獨(dú)立的基礎(chǔ)功能保持原子性，第二層服務(wù)組合層，主要考慮一些業(yè)務(wù)的功能實(shí)現(xiàn)。

雖然功能入口不同，但是業(yè)務(wù)邏輯上有很多一致的地方，為方便業(yè)務(wù)流程層使用，將業(yè)務(wù)上關(guān)系緊密存在先后順序的原子服務(wù)耦合在一起。

業(yè)務(wù)流程層就按照業(yè)務(wù)需求將原子服務(wù)和服務(wù)組合搭建成一套完整邏輯。分層的好處就是對(duì)于新業(yè)務(wù)能實(shí)現(xiàn)快速迭代，另外涉及一些節(jié)點(diǎn)改動(dòng)，只需要在基礎(chǔ)服務(wù)層或者組合層做改動(dòng)即可，不會(huì)再存在漏改的可能了。

系統(tǒng)存儲(chǔ)架構(gòu)優(yōu)化

系統(tǒng)搭建初期，考慮到業(yè)務(wù)數(shù)據(jù)的量級(jí)，采用了分庫+分表的方案。后來實(shí)踐證明這并不是個(gè)好的方案，增加了系統(tǒng)運(yùn)維的復(fù)雜度，每次的發(fā)布都要改動(dòng)很多地方，極易出錯(cuò)。對(duì)數(shù)據(jù)庫的動(dòng)態(tài)擴(kuò)展也帶來很大復(fù)雜性。

經(jīng)過技術(shù)內(nèi)部討論，果斷將分庫+分表改成只按模分庫，按模分庫可以保證每個(gè)分庫上數(shù)據(jù)的量級(jí)差別不大，一旦量級(jí)達(dá)到需要再次切分的時(shí)候，可以將數(shù)據(jù)庫動(dòng)態(tài)擴(kuò)一組。

目前公司自研的持久層組件 DAL 支持多次路由，代碼層無需改動(dòng)，只需要將數(shù)據(jù)庫路由做調(diào)整。

先按照分庫字段的 value 值與分庫組的區(qū)間判斷路由到準(zhǔn)確的分庫組，再按照分庫字段的 value 值取模路由到分庫，可以實(shí)現(xiàn)理論上的***數(shù)據(jù)存儲(chǔ)。

分庫解決了數(shù)據(jù)存儲(chǔ)的問題，同時(shí)帶來數(shù)據(jù)使用上的不便，要充分發(fā)揮分庫的性能***的做法是每次都將分庫字段做條件傳入。

這意味著每次只能進(jìn)行單表的操作，大大限制了業(yè)務(wù)的可用性，多表的數(shù)據(jù)匯總需要開發(fā)層面上輪庫實(shí)現(xiàn)，也帶來了開發(fā)上的復(fù)雜性，為此我們考慮使用 Mycat。

為什么選擇 Mycat?主要從兩方面考慮：

• 解決當(dāng)前痛點(diǎn)，Mycat 支持 MySQL 集群，可以作為 Proxy 使用，解決了跨庫數(shù)據(jù)查詢問題。

再次 Mycat 可以很好的支撐讀寫分離，基于 MySQL 主從復(fù)制狀態(tài)的高級(jí)讀寫分離控制機(jī)制。

比如 Slave_behind_master<100 則開啟，而一旦檢測(cè)到主從同步出錯(cuò)或者延時(shí)過長(zhǎng)，則自動(dòng)排除 readHost，防止程序讀到很久的舊數(shù)據(jù)。

• 為未來的系統(tǒng)擴(kuò)展提供很好的延展性。受限于 DB 服務(wù)器本身物理資源，單個(gè)數(shù)據(jù)庫的連接數(shù)不可能跟隨基于容器技術(shù)的應(yīng)用服務(wù)器一樣理論上可***添加。

Mycat 的鏈接復(fù)用技術(shù)可以很好的解決連接數(shù)過大問題，如下圖，另外 Mycat 可以支持多種類型數(shù)據(jù)庫，Oracle，PG 等。

作為一個(gè)業(yè)務(wù)操作和管理系統(tǒng)，對(duì)一些數(shù)據(jù)有多樣化的查詢和數(shù)據(jù)鉆取匯總需求，即使基于 Mycat 的 MySQL 數(shù)據(jù)庫已經(jīng)不能很好支持了，先后引入了 ES，Druid 支撐 OLAP 相關(guān)業(yè)務(wù)需求。

系統(tǒng)業(yè)務(wù)架構(gòu)優(yōu)化

隨著大數(shù)據(jù)和 AI 相關(guān)技術(shù)的飛速發(fā)展及日趨成熟，如何運(yùn)用大數(shù)據(jù)相關(guān)技術(shù)，將大數(shù)據(jù)更好的和采購(gòu)業(yè)務(wù)融合，2017 年以后預(yù)測(cè)補(bǔ)貨系統(tǒng)融入采購(gòu)平臺(tái)，作為轉(zhuǎn)型智能采購(gòu)的核心，提煉和完善符合當(dāng)前業(yè)務(wù)的預(yù)測(cè)模型。

基于庫存，銷售，日銷等數(shù)據(jù)匹配相關(guān)預(yù)測(cè)模型，對(duì)未來銷量，庫存數(shù)量，采購(gòu)數(shù)量，調(diào)撥數(shù)量等等做精準(zhǔn)預(yù)測(cè)，并且模型基于機(jī)器學(xué)習(xí)進(jìn)行自我優(yōu)化。

同時(shí)還提供采購(gòu)時(shí)效分析，實(shí)際銷售和預(yù)測(cè)監(jiān)控，采購(gòu)需求預(yù)測(cè)跟蹤，訂單數(shù)據(jù)透析，并基于安全庫存產(chǎn)生的預(yù)警主動(dòng)提示。

第三階段：架構(gòu)拆分&平臺(tái)化期

隨著前兩階段的實(shí)施完畢，采購(gòu)平臺(tái)在系統(tǒng)架構(gòu)和業(yè)務(wù)架構(gòu)上基本處于一個(gè)相對(duì)完善的階段。

如何更好的支撐業(yè)務(wù)的飛速發(fā)展，同時(shí)提供***的的穩(wěn)定性，安全性，業(yè)務(wù)一致性。第三階段系統(tǒng)按平臺(tái)化拆分為采購(gòu)前臺(tái)和采購(gòu)中臺(tái)。

采購(gòu)前臺(tái)基于移動(dòng)端和 PC 端提供更加豐富的功能和更加人性化的用戶體驗(yàn)，核心圍繞用戶。

基于大數(shù)據(jù)平臺(tái)和 AI 相關(guān)技術(shù)：

• 實(shí)現(xiàn)門店端業(yè)務(wù)操作自動(dòng)化，滿足不同類型門店的日常不同類型要貨需求，降低人工補(bǔ)貨的繁瑣工作，更好的滿足日常銷售。
• 實(shí)現(xiàn)中心倉間自動(dòng)調(diào)撥。根據(jù)要貨倉優(yōu)先級(jí)，要貨倉-尋源倉優(yōu)先級(jí)，進(jìn)行要貨倉和尋源倉之間調(diào)撥數(shù)量的自動(dòng)匹配，用尋源倉的庫存滿足要貨倉的庫存，實(shí)現(xiàn)中心倉質(zhì)檢庫存的動(dòng)態(tài)平衡。
• 通過銷售數(shù)據(jù)共享，庫存共享，預(yù)測(cè)銷量數(shù)據(jù)共享等等，打通和供應(yīng)商的數(shù)據(jù)壁壘實(shí)現(xiàn)預(yù)測(cè)協(xié)同，生產(chǎn)協(xié)同，訂單協(xié)同。

采購(gòu)中臺(tái)將除了快速響應(yīng)采購(gòu)前臺(tái)的需求外，更加專注于功能的穩(wěn)定與完善，作為調(diào)度的核心，需要圍繞數(shù)據(jù)，保證業(yè)務(wù)的一致性和及時(shí)性，提供更加全面的監(jiān)控措施。

在現(xiàn)有業(yè)務(wù)邏輯復(fù)雜的情況下，積木式的拼搭實(shí)現(xiàn)快速響應(yīng)。服務(wù)原子化后，更多的邏輯在于流程控制上，提煉服務(wù)控制層，作為邏輯“引擎”。

例如狀態(tài)機(jī)引擎，是基于目前單據(jù)整個(gè)的生命周期中狀態(tài)多，變更觸發(fā)條件多的特性，將統(tǒng)一管理各條鏈路的單據(jù)狀態(tài)，保證單據(jù)狀態(tài)順序性和一致性。

另外作為調(diào)度中心，如何及時(shí)發(fā)現(xiàn)問題是***位的，全鏈路的監(jiān)控是非常必要的!

通過業(yè)務(wù)類型和單據(jù)號(hào)，將各個(gè)階段的單據(jù)狀態(tài)打點(diǎn)，將打點(diǎn)數(shù)據(jù)抽取后匯集串通，從而將單據(jù)的整個(gè)生命周期都處于監(jiān)控之下，哪個(gè)節(jié)點(diǎn)出問題可以***時(shí)間發(fā)現(xiàn)并處理，保證單據(jù)流轉(zhuǎn)的及時(shí)性。

總結(jié)

縱觀系統(tǒng)架構(gòu)的演進(jìn)沒有什么***之說，不存在解決一切系統(tǒng)架構(gòu)問題的“銀彈”，適合自己的才是***的。

也沒有一蹴而就的解決方案，隨著業(yè)務(wù)發(fā)展，新技術(shù)的層出不窮，再好的方案也經(jīng)不起時(shí)間的考驗(yàn)，以變應(yīng)變才是***的方案!

作者：胥磊

簡(jiǎn)介：蘇寧科技集團(tuán)供應(yīng)鏈平臺(tái)研發(fā)中心采購(gòu)中臺(tái)開發(fā)負(fù)責(zé)人。2011 年入職蘇寧以后，先后主導(dǎo)過 SCS 蘇寧供應(yīng)鏈系統(tǒng)、售后服務(wù)系統(tǒng)、采購(gòu)平臺(tái)等系統(tǒng)的搭建與架構(gòu)迭代優(yōu)化。目前負(fù)責(zé)采購(gòu)中臺(tái)、服務(wù)市場(chǎng)的開發(fā)管理以及相關(guān)系統(tǒng)架構(gòu)的演進(jìn)優(yōu)化。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】