以變應變，蘇寧采購平臺架構演進之路

原創

作者：胥磊 2019-04-23 09:13:54

開發架構開發工具

在“智慧零售大開發”的戰略驅動下，2018 年蘇寧新開門店超過 8000 家，目前各類門店總數已經超過 1.1 萬家，在線下形成了“兩大兩小多專”的智慧零售業態群。

【51CTO.com原創稿件】在“智慧零售大開發”的戰略驅動下，2018 年蘇寧新開門店超過 8000 家，目前各類門店總數已經超過 1.1 萬家，在線下形成了“兩大兩小多專”的智慧零售業態群。

同時構建了以蘇寧超市、蘇寧拼購為代表的線上平臺。從而形成了線上多平臺、線下場景多業態互聯網化，不斷打造跨線上線下全場景的消費環境和空間。

隨之而來的是新增各式各樣的業態帶來的業務鏈路的多樣化，以及適應行業的急速發展帶來業務需求的多變化…

總之一切都是“變”的，作為自營采購的核心系統采購平臺，是如何適應這些變化?

下面會通過采購平臺發展的三個階段，介紹我們是如何通過積極的“擁抱”變化，走出自己獨特的架構演進之路。

***階段：系統搭建&功能完善期

采購平臺是基于 2006 年上線的 SAP-R3 采購管理模塊搭建的。

SAP-R3 作為蘇寧信息化歷程上重要里程碑，為蘇寧的飛速發展曾立下汗馬功勞，但隨著多元業務急速發展，已經不能很好的滿足業務的多變性和支撐新業態的發展。

就采購管理而言，SAP-R3 未與商品規劃、選品等前置管理環節銜接，無法在此基礎上開展采購業務。

另一方面 SAP-R3 中采購和財務相關業務耦合緊密，牽一發而動全身，無法支持各業態新的業務的快速部署，再就是存在操作復雜，培訓學習成本高的問題。基于以上的問題，2015 年開始搭建基于 Java 的自主研發采購系統。

方向已定，同時困難也是顯而易見的，SAP-R3 作為已經運行 9 年多的系統，已經有很多業務在上面運行，同時與大量外部系統有關聯，系統關系錯綜復雜。

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

綜合各種情況考慮，最終確認新系統的切換方案：***步新系統提供各種創單以及管理功能，提供體驗更好的服務，SAP-R3 系統繼續承擔調度功能，雙系統并行，業務逐步切換。

如上圖所示使用 R3 管理采購業務、訂單調度、賬務庫存，對現有系統架構、庫存結構、庫存核算沒有改動，風險相對可控，投入資源相對較少，雖然離去除 R3 的目標只算邁出一小步，但對于保障業務的穩定性是值得的!

確定好方案以后，著手新系統的框架搭建，考慮系統的可擴展性和穩定性，將模塊功能獨立化，類似微服務的概念，將業務模塊采購，退廠，調撥，樣機&不良品，采購需求作為獨立應用部署，降低相互之間的耦合。

同時部署一個資源能力系統為各個業務系統提供統一的公共服務，主數據服務，權限服務，降低代碼的重復度。

系統結構如下圖：

系統搭建完成后，隨著系統的平穩運行，***步工作暫告一段落，2016 年開始第二步的架構改造：去除 SAP 的中轉，由采購平臺作為核心調度，真正承擔對物流和庫存的調度!

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

一旦發現試點的新鏈路功能有問題，可立刻切換到老的鏈路上，保證業務正常開展。

另外作為核心調度的系統，如何保證數據流轉的閉環，可追溯，安全是必須要考慮的。在原有的系統基礎上補充了操作日志系統，便于業務操作數據的追溯。

第二階段：功能突增&業務爆發期

***階段主要是系統搭建和功能遷移，2017 年以后的系統的重點轉移到提升用戶體驗，以及支撐新業務的急速發展。

主要從系統功能架構，數據存儲架構，業務架構幾個方面做出優化改進：

系統功能架構優化

為提升功能的豐富程度和體驗，加上對新業態的支持，新增很多創單入口，創單邏輯本身復雜度很高和外圍系統的交互又很多，加上項目周期短，前期都是基于已有的功能重新做一套。

雖然降低了對已有功能的影響，但是帶來運維的復雜度成幾何級提升，有時涉及一個創單共用邏輯的修改往往要改近十幾個地方，開發容易遺漏，測試也苦不堪言。系統功能的架構優化提上日程。

針對上述情況和系統特點，我們采取的技術方案：服務原子化，功能積木化。

將一些基礎服務，簡單而言就是將創單邏輯分解成基礎服務，新的功能基于基礎服務進行積木式組合，如下圖：

基礎服務層提供獨立的基礎功能保持原子性，第二層服務組合層，主要考慮一些業務的功能實現。

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

業務流程層就按照業務需求將原子服務和服務組合搭建成一套完整邏輯。分層的好處就是對于新業務能實現快速迭代，另外涉及一些節點改動，只需要在基礎服務層或者組合層做改動即可，不會再存在漏改的可能了。

系統存儲架構優化

系統搭建初期，考慮到業務數據的量級，采用了分庫+分表的方案。后來實踐證明這并不是個好的方案，增加了系統運維的復雜度，每次的發布都要改動很多地方，極易出錯。對數據庫的動態擴展也帶來很大復雜性。

經過技術內部討論，果斷將分庫+分表改成只按模分庫，按模分庫可以保證每個分庫上數據的量級差別不大，一旦量級達到需要再次切分的時候，可以將數據庫動態擴一組。

目前公司自研的持久層組件 DAL 支持多次路由，代碼層無需改動，只需要將數據庫路由做調整。

先按照分庫字段的 value 值與分庫組的區間判斷路由到準確的分庫組，再按照分庫字段的 value 值取模路由到分庫，可以實現理論上的***數據存儲。

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

這意味著每次只能進行單表的操作，大大限制了業務的可用性，多表的數據匯總需要開發層面上輪庫實現，也帶來了開發上的復雜性，為此我們考慮使用 Mycat。

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

解決當前痛點，Mycat 支持 MySQL 集群，可以作為 Proxy 使用，解決了跨庫數據查詢問題。

再次 Mycat 可以很好的支撐讀寫分離，基于 MySQL 主從復制狀態的高級讀寫分離控制機制。

比如 Slave_behind_master<100 則開啟，而一旦檢測到主從同步出錯或者延時過長，則自動排除 readHost，防止程序讀到很久的舊數據。

為未來的系統擴展提供很好的延展性。受限于 DB 服務器本身物理資源，單個數據庫的連接數不可能跟隨基于容器技術的應用服務器一樣理論上可***添加。

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

作為一個業務操作和管理系統，對一些數據有多樣化的查詢和數據鉆取匯總需求，即使基于 Mycat 的 MySQL 數據庫已經不能很好支持了，先后引入了 ES，Druid 支撐 OLAP 相關業務需求。

系統業務架構優化

隨著大數據和 AI 相關技術的飛速發展及日趨成熟，如何運用大數據相關技術，將大數據更好的和采購業務融合，2017 年以后預測補貨系統融入采購平臺，作為轉型智能采購的核心，提煉和完善符合當前業務的預測模型。

基于庫存，銷售，日銷等數據匹配相關預測模型，對未來銷量，庫存數量，采購數量，調撥數量等等做精準預測，并且模型基于機器學習進行自我優化。

同時還提供采購時效分析，實際銷售和預測監控，采購需求預測跟蹤，訂單數據透析，并基于安全庫存產生的預警主動提示。

第三階段：架構拆分&平臺化期

隨著前兩階段的實施完畢，采購平臺在系統架構和業務架構上基本處于一個相對完善的階段。

如何更好的支撐業務的飛速發展，同時提供***的的穩定性，安全性，業務一致性。第三階段系統按平臺化拆分為采購前臺和采購中臺。

采購前臺基于移動端和 PC 端提供更加豐富的功能和更加人性化的用戶體驗，核心圍繞用戶。

基于大數據平臺和 AI 相關技術：

實現門店端業務操作自動化，滿足不同類型門店的日常不同類型要貨需求，降低人工補貨的繁瑣工作，更好的滿足日常銷售。
實現中心倉間自動調撥。根據要貨倉優先級，要貨倉-尋源倉優先級，進行要貨倉和尋源倉之間調撥數量的自動匹配，用尋源倉的庫存滿足要貨倉的庫存，實現中心倉質檢庫存的動態平衡。
通過銷售數據共享，庫存共享，預測銷量數據共享等等，打通和供應商的數據壁壘實現預測協同，生產協同，訂單協同。