知識星球前言
在“智慧零售大開發”的戰略驅動下，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 相關技術：
-
實現門店端業務操作自動化，滿足不同型別門店的日常不同型別要貨需求，降低人工補貨的繁瑣工作，更好的滿足日常銷售。
-
實現中心倉間自動調撥。根據要貨倉優先順序，要貨倉-尋源倉優先順序，進行要貨倉和尋源倉之間調撥數量的自動匹配，用尋源倉的庫存滿足要貨倉的庫存，實現中心倉質檢庫存的動態平衡。
-
透過銷售資料共享，庫存共享，預測銷量資料共享等等，打通和供應商的資料壁壘實現預測協同，生產協同，訂單協同。
採購中臺將除了快速響應採購前臺的需求外，更加專註於功能的穩定與完善，作為排程的核心，需要圍繞資料，保證業務的一致性和及時性，提供更加全面的監控措施。
在現有業務邏輯複雜的情況下，積木式的拼搭實現快速響應。服務原子化後，更多的邏輯在於流程控制上，提煉服務控制層，作為邏輯“引擎”。
例如狀態機引擎，是基於目前單據整個的生命週期中狀態多，變更觸發條件多的特性，將統一管理各條鏈路的單據狀態，保證單據狀態順序性和一致性。
另外作為排程中心，如何及時發現問題是第一位的，全鏈路的監控是非常必要的！
透過業務型別和單據號，將各個階段的單據狀態打點，將打點資料抽取後彙集串通，從而將單據的整個生命週期都處於監控之下，哪個節點出問題可以第一時間發現並處理，保證單據流轉的及時性。
總結
縱觀系統架構的演進沒有什麼最好之說，不存在解決一切系統架構問題的“銀彈”，適合自己的才是最好的。
也沒有一蹴而就的解決方案，隨著業務發展，新技術的層出不窮，再好的方案也經不起時間的考驗，以變應變才是最好的方案!
問答
Q1：按模分庫，如果動態擴容之後，歷史資料遷移怎麼辦，這個是很頭痛的地方吧？
A：不需要做資料遷移的，這裡採用的是二次路由的方式，第一次是區間路由，主要是尋找資料庫組，第二次，資料庫組內部再取模路由。好處是不需要遷移資料了，不過新資料都會落到新加的那資料庫組上。
Q2：本文采用的方法是去訪問一個路由配置表，但是這個方案，路由配置表會成為一個訪問瓶頸。
A：持久化元件DAL支援多次路由的，只需要自己配置路由規則。另外mycat也支援多次路由。
如果有其他問題，歡迎在本文留言處互動哦~
作者：胥磊
簡介：蘇寧科技集團供應鏈平臺研發中心採購中臺開發負責人。2011 年入職蘇寧以後，先後主導過 SCS 蘇寧供應鏈系統、售後服務系統、採購平臺等系統的搭建與架構迭代最佳化。目前負責採購中臺、服務市場的開發管理以及相關係統架構的演進最佳化。
朋友會在“發現-看一看”看到你“在看”的內容