供應鏈域資料中臺設計

關注我，緊跟本系列專欄文章，我們們下篇再續！

作者簡介：魔都技術專家兼架構，多家大廠後端一線研發經驗，各大技術社群頭部專家博主，程式設計嚴選網創始人。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
中央/分銷預訂系統效能最佳化
活動&優惠券等營銷中臺建設
交易平臺及資料中臺等架構和開發設計
目前主攻降低軟體複雜性設計、構建高可用系統方向。

參考：

程式設計嚴選網

1 前言

受限於對業務掌握度及對應資料特性的瞭解，大資料平臺更傾向海量的同構或異構資料採集，清洗，加工，儲存。而提供的資料服務更多是對採集到資料進行彙總及分析。

供應鏈域資料中臺專注供應鏈域業務資料，優勢是具備熟練掌握相關業務的產品和開發，更瞭解業務和資料特性：

為產品線提供準確及時的資料服務
也為數分提供完善的資料脈絡，幫助其更好對這些資料深層挖掘分析，再次提升資料價值

系統設計上也將考慮系統能做到能進能退：

進則作為獨立資料域的資料中臺產品，逐漸完善自身特性
退則作為一個資料域模組快速融入公司大資料中臺

2 理論篇

有了存在意義和價值空間，接下來考慮如何構建。採用DDD構建資料中臺的各類模型。結合當下情況分析，自頂向下的策略更適合。首先目標建立供應鏈域資料中臺，頂層領域已限定供應鏈。其次該策略不受限於當前系統，適合用 DDD 領域逐級分解的建模方法。

2.1 領域模型界定

現階段業務需求是給相關業務系統提供準確及時的供應鏈域資料服務，同時也是資料中臺核心服務，所以作為主體的資料服務是毫無爭議的核心域。

資料中臺第二個重要功能是提供後設資料字典服務，即提供有關聯關係的後設資料的脈絡服務。

其展示該域下各資料實體的關聯關係及鏈路節點出處，以及相關資料服務詳情介紹等，可稱之為資料治理，作用上區分可將資料治理歸為通用域。資料治理和資料服務的共同基石則是資料，這裡指出的就是資料中臺另一個功能同時也是本質功能，打通資料孤島對資料的採集加工和儲存，這些就組成另外一個子域，歸為支撐域。

資料中臺域模型圖：

系統架構設計模、領域模型界定完畢後，下面就是以領域模型為指導進行系統架構模型的設計。系統架構模型設計依然用 DDD。

搭建有自身特色的資料中臺，決定我們沒有可參考案例，為防過度設計，提前設定一個設計方針，即系統架構須是一個演進式，經得起破壞和重構，才能滿足低成本，快建設，快試錯。大而全系統架構設計雖也是我們嚮往，但現狀不許。

2.2 資料中臺系統設計模型

① 介面層

資料中臺對外服務的統一入口：

對接各種型別的訪問請求，如restful 介面，api介面，RPC框架服務介面等
提供服務適配，對各種型別介面提供請求引數和返回結果集的適配相關的服務

② 應用層

實現服務組合和編排，以快速滿足業務需求。不可否認使用者需求一直在變化。能做的就是如何快速響應這些變化，服務組合和重新編排，提升服務可重用性，降低重複功能的開發成本，提升開發效率，為業務的快速試錯提供了很好支撐。

③ 領域層

該層實現核心業務邏輯，同時聚集了領域模型的聚合、聚合根、實體、值物件、領域服務和事件等領域物件，以及它們組合所形成的業務能力。通俗易懂的，是實現了業務處理邏輯的服務原子化，按業務邏輯將服務細分，細分後的原子服務將脫離具體的業務模式，為應用層的服務組合和編排提供“原材料”。

④ 基礎層

貫穿所有層，為各層提供基礎資源服務。包含MySQL，PG，ES，HBase和Redis等資料儲存和快取服務。

還有一部分重要組成就是公共服務，好產品離不開監控運維和相關日誌服務，這些是保障系統健康的重要措施。

3 實踐篇

3.1 供應鏈域資料中臺系統架構設計

資料中臺系統架構設計模型：

資料治理將供應鏈全鏈路涉及到或者相關的所有子域的資料進行目錄化管理
資料服務則基於所有子域資料提供標準或者定製化的服務
資料儲存則主要依賴大資料平臺和搜尋，是基於資料中臺的資料的量級和服務的便利性以及可用性考慮
資料採集基本是 kafka 和資料同步元件，基於資料的吞吐量和可靠性考慮

3.2 系統實現模型設計

資料中臺資料流轉模型（資料中臺服務保障方案）：

如圖所示，按既定介面層/應用層/領域層/基礎層設計，逐層封裝，各層相互協作，對業務系統提供靈活的資料服務，很好地實現了各層分工，便於快速響應業務需求。

考慮到資料中臺主要為業務系統提供資料服務，為保障資料服務的可靠性和及時性，還得兼顧系統效能和穩定，對資料服務做了冗餘和歸檔服務。冗餘的服務同時具備降級職責，提升服務 SAL 指標。

4 總結

基於 DDD 領域建模的供應鏈域資料中臺設計基本完畢，緊接著就是後續流暢的開發工作。覆盤過程，雖不甚完美，“先開槍後瞄準”至少在探索資料中臺領域邁出第一步，那麼成功就不會太遠。