在“智慧零售大開發(fā)”的戰(zhàn)略驅(qū)動(dòng)下，2018 年蘇寧新開門店超過 8000 家，目前各類門店總數(shù)已經(jīng)超過 1.1 萬家，在線下形成了“兩大兩小多專”的智慧零售業(yè)態(tài)群。
同時(shí)構(gòu)建了以蘇寧超市、蘇寧拼購為代表的線上平臺。從而形成了線上多平臺、線下場景多業(yè)態(tài)互聯(lián)網(wǎng)化，不斷打造跨線上線下全場景的消費(fèi)環(huán)境和空間。
隨之而來的是新增各式各樣的業(yè)態(tài)帶來的業(yè)務(wù)鏈路的多樣化，以及適應(yīng)行業(yè)的急速發(fā)展帶來業(yè)務(wù)需求的多變化…
總之一切都是“變”的，作為自營采購的核心系統(tǒng)采購平臺，是如何適應(yīng)這些變化?
下面會通過采購平臺發(fā)展的三個(gè)階段，介紹我們是如何通過積極的“擁抱”變化，走出自己獨(dú)特的架構(gòu)演進(jìn)之路。
第一階段：系統(tǒng)搭建&功能完善期
采購平臺是基于 2006 年上線的 SAP-R3 采購管理模塊搭建的。
SAP-R3 作為蘇寧信息化歷程上重要里程碑，為蘇寧的飛速發(fā)展曾立下汗馬功勞，但隨著多元業(yè)務(wù)急速發(fā)展，已經(jīng)不能很好的滿足業(yè)務(wù)的多變性和支撐新業(yè)態(tài)的發(fā)展。
就采購管理而言，SAP-R3 未與商品規(guī)劃、選品等前置管理環(huán)節(jié)銜接，無法在此基礎(chǔ)上開展采購業(yè)務(wù)。
另一方面 SAP-R3 中采購和財(cái)務(wù)相關(guān)業(yè)務(wù)耦合緊密，牽一發(fā)而動(dòng)全身，無法支持各業(yè)態(tài)新的業(yè)務(wù)的快速部署，再就是存在操作復(fù)雜，培訓(xùn)學(xué)習(xí)成本高的問題?；谝陨系膯栴}，2015 年開始搭建基于 Java 的自主研發(fā)采購系統(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ù)性，平滑的過渡盡可能降低對外部系統(tǒng)的影響，這對我們來說也不亞于“在行駛的汽車上換輪胎”。
綜合各種情況考慮，最終確認(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 管理采購業(yè)務(wù)、訂單調(diào)度、賬務(wù)庫存，對現(xiàn)有系統(tǒng)架構(gòu)、庫存結(jié)構(gòu)、庫存核算沒有改動(dòng)，風(fēng)險(xiǎn)相對可控，投入資源相對較少，雖然離去除 R3 的目標(biāo)只算邁出一小步，但對于保障業(yè)務(wù)的穩(wěn)定性是值得的!
確定好方案以后，著手新系統(tǒng)的框架搭建，考慮系統(tǒng)的可擴(kuò)展性和穩(wěn)定性，將模塊功能獨(dú)立化，類似微服務(wù)的概念，將業(yè)務(wù)模塊采購，退廠，調(diào)撥，樣機(jī)&不良品，采購需求作為獨(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)，由采購平臺作為核心調(diào)度，真正承擔(dān)對物流和庫存的調(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ù)存儲架構(gòu)，業(yè)務(wù)架構(gòu)幾個(gè)方面做出優(yōu)化改進(jìn)：
系統(tǒng)功能架構(gòu)優(yōu)化
為提升功能的豐富程度和體驗(yàn)，加上對新業(yè)態(tài)的支持，新增很多創(chuàng)單入口，創(chuàng)單邏輯本身復(fù)雜度很高和外圍系統(tǒng)的交互又很多，加上項(xiàng)目周期短，前期都是基于已有的功能重新做一套。
雖然降低了對已有功能的影響，但是帶來運(yùn)維的復(fù)雜度成幾何級提升，有時(shí)涉及一個(gè)創(chuàng)單共用邏輯的修改往往要改近十幾個(gè)地方，開發(fā)容易遺漏，測試也苦不堪言。系統(tǒng)功能的架構(gòu)優(yōu)化提上日程。
針對上述情況和系統(tǒng)特點(diǎn)，我們采取的技術(shù)方案：服務(wù)原子化，功能積木化。
將一些基礎(chǔ)服務(wù)，簡單而言就是將創(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ù)組合搭建成一套完整邏輯。分層的好處就是對于新業(yè)務(wù)能實(shí)現(xiàn)快速迭代，另外涉及一些節(jié)點(diǎn)改動(dòng)，只需要在基礎(chǔ)服務(wù)層或者組合層做改動(dòng)即可，不會再存在漏改的可能了。
系統(tǒng)存儲架構(gòu)優(yōu)化
系統(tǒng)搭建初期，考慮到業(yè)務(wù)數(shù)據(jù)的量級，采用了分庫+分表的方案。后來實(shí)踐證明這并不是個(gè)好的方案，增加了系統(tǒng)運(yùn)維的復(fù)雜度，每次的發(fā)布都要改動(dòng)很多地方，極易出錯(cuò)。對數(shù)據(jù)庫的動(dòng)態(tài)擴(kuò)展也帶來很大復(fù)雜性。
經(jīng)過技術(shù)內(nèi)部討論，果斷將分庫+分表改成只按模分庫，按模分庫可以保證每個(gè)分庫上數(shù)據(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ù)存儲。
分庫解決了數(shù)據(jù)存儲的問題，同時(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ī)制。
比如 Slave_behind_master<100 則開啟，而一旦檢測到主從同步出錯(cuò)或者延時(shí)過長，則自動(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)，對一些數(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ù)更好的和采購業(yè)務(wù)融合，2017 年以后預(yù)測補(bǔ)貨系統(tǒng)融入采購平臺，作為轉(zhuǎn)型智能采購的核心，提煉和完善符合當(dāng)前業(yè)務(wù)的預(yù)測模型。
基于庫存，銷售，日銷等數(shù)據(jù)匹配相關(guān)預(yù)測模型，對未來銷量，庫存數(shù)量，采購數(shù)量，調(diào)撥數(shù)量等等做精準(zhǔn)預(yù)測，并且模型基于機(jī)器學(xué)習(xí)進(jìn)行自我優(yōu)化。
同時(shí)還提供采購時(shí)效分析，實(shí)際銷售和預(yù)測監(jiān)控，采購需求預(yù)測跟蹤，訂單數(shù)據(jù)透析，并基于安全庫存產(chǎn)生的預(yù)警主動(dòng)提示。
第三階段：架構(gòu)拆分&平臺化期
隨著前兩階段的實(shí)施完畢，采購平臺在系統(tǒng)架構(gòu)和業(yè)務(wù)架構(gòu)上基本處于一個(gè)相對完善的階段。
如何更好的支撐業(yè)務(wù)的飛速發(fā)展，同時(shí)提供極致的的穩(wěn)定性，安全性，業(yè)務(wù)一致性。第三階段系統(tǒng)按平臺化拆分為采購前臺和采購中臺。
采購前臺基于移動(dòng)端和 PC 端提供更加豐富的功能和更加人性化的用戶體驗(yàn)，核心圍繞用戶。
基于大數(shù)據(jù)平臺和 AI 相關(guān)技術(shù)：
實(shí)現(xiàn)門店端業(yè)務(wù)操作自動(dòng)化，滿足不同類型門店的日常不同類型要貨需求，降低人工補(bǔ)貨的繁瑣工作，更好的滿足日常銷售。
實(shí)現(xiàn)中心倉間自動(dòng)調(diào)撥。根據(jù)要貨倉優(yōu)先級，要貨倉-尋源倉優(yōu)先級，進(jìn)行要貨倉和尋源倉之間調(diào)撥數(shù)量的自動(dòng)匹配，用尋源倉的庫存滿足要貨倉的庫存，實(shí)現(xiàn)中心倉質(zhì)檢庫存的動(dòng)態(tài)平衡。
通過銷售數(shù)據(jù)共享，庫存共享，預(yù)測銷量數(shù)據(jù)共享等等，打通和供應(yīng)商的數(shù)據(jù)壁壘實(shí)現(xiàn)預(yù)測協(xié)同，生產(chǎn)協(xié)同，訂單協(xié)同。
采購中臺將除了快速響應(yīng)采購前臺的需求外，更加專注于功能的穩(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ù)號，將各個(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í)性。
縱觀系統(tǒng)架構(gòu)的演進(jìn)沒有什么最好之說，不存在解決一切系統(tǒng)架構(gòu)問題的“銀彈”，適合自己的才是最好的。
也沒有一蹴而就的解決方案，隨著業(yè)務(wù)發(fā)展，新技術(shù)的層出不窮，再好的方案也經(jīng)不起時(shí)間的考驗(yàn)，以變應(yīng)變才是最好的方案!
數(shù)字化要一盤棋更要各自為戰(zhàn)
分享到微信 ×
打開微信，點(diǎn)擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。