內(nèi)容來源：2017年4月22日，貝法易集團技術部總監(jiān)黃亮在“2017年MongoDB中文社區(qū)深圳用戶組大會”進行《MongoDB在跨境電商物流供應鏈系統(tǒng)中的實踐》演講分享。IT 大咖說作為獨家視頻合作方，經(jīng)主辦方和講者審閱授權發(fā)布。

　　閱讀字數(shù)：2896 | 4分鐘閱讀

　　摘要

　　本次介紹下出口易跨境電商物流供應鏈系統(tǒng)從單體應用過渡到面向服務的分布式系統(tǒng)架構(gòu)的過程中，遇到的一些挑戰(zhàn)和實現(xiàn)。其中包括了基于MongoDB建模和數(shù)據(jù)持久化方面上具體實踐。

　　嘉賓演講視頻回顧及PPT：http://t.cn/R82rZLw

　　關于出口易物流

　　出口易物流是廣州市貝法易商貿(mào)有限公司(簡稱貝法易)旗下，以全球倉儲為核心，整合全球物流網(wǎng)絡系統(tǒng)，為跨境電商賣家提供海外倉儲、國際專線、國際小包、國際快遞、FBA頭程等物流服務以及本地化售前售后服務，解決訂單管理、金融融資難題。我們不是物流的供應商，我們是跨境電商全程物流解決方案提供商。

　　我們公司的重資產(chǎn)是人員，我們了解跨境電商物流，包括跨境電商通關的環(huán)節(jié)、關于物流方面的國際法律以及離境品的相關信息，這些都是我們公司最寶貴的資源。

　　我們公司底下有一大群長期合作的供應商，這是我們最大的優(yōu)勢。我們的難點也是在于這些供應商是不可控的，因為我們是在使用別人家的服務。

　　所以除了訂單系統(tǒng)還有一個很重要的資產(chǎn)就是我們自營的海外倉儲，這也是我們最核心的價值。

　　覆蓋歐美澳主要市場的服務網(wǎng)絡

　　上圖是我們?nèi)虿季值奈锪骶W(wǎng)絡。這些倉儲有大有小，英國倉庫是我們最核心的倉庫。截至2017年，在國內(nèi)我們一共有八個倉儲中心，重點的是在深圳、廣州和上海。

　　全球主流電商平臺重點推薦物流服務提供商

　　我們合作的平臺推薦我們的物流服務提供商有Amazon、ebay、wish、阿里國際、shopee、AliExpress還有LAZADA。

　　出口易新老架構(gòu)演變過程

　　我們之前的系統(tǒng)是上圖左邊的架構(gòu)，針對商家第三方的ERP和一些商家自己研發(fā)的一套系統(tǒng)，還有一些平臺跟我們的系統(tǒng)都是有直接交互。有的是通過出口易提供了一套UI來進行訪問，還有就是大量的線上發(fā)貨，我們會采用API來進行接入。我們后臺有admin管理后臺，還有單獨的一塊WMS系統(tǒng)。

　　我們認為這個系統(tǒng)有些過于龐大，想做一些調(diào)整。新的架構(gòu)大部分還是沒有改動，只是在后端針對admin的系統(tǒng)想要往面向服務架構(gòu)方向落地。基于業(yè)務場景的切分有兩塊，一塊是基于通用服務，比如說用戶的認證和授權，還有就是日志。

　　支付有一些支付網(wǎng)關，有和paypal、alipay、payoneer還有銀行的接口。

　　下面是我們業(yè)務最主要模塊，包括產(chǎn)品報價、客戶關系管理系統(tǒng)，還有訂單、物流網(wǎng)絡和運輸，包括WMS、支付、物流軌跡跟蹤、供應商管理系統(tǒng)，還有結(jié)算報表等等諸如此類。

　　出口易老業(yè)務系統(tǒng)特點

　　單體應用：前后端系統(tǒng)共用一套WEB App Solution。

　　單一數(shù)據(jù)庫：采用MS SQLServer 數(shù)據(jù)庫，核心業(yè)務功能共用一個數(shù)據(jù)庫。

　　業(yè)務功能完整：IT系統(tǒng)隨業(yè)務的發(fā)展不斷擴展新功能。滿足開展跨境電商物流業(yè)務最基本的功能性需求。

　　容易測試和部署：單獨一個Solution，系統(tǒng)依賴少，一旦部署，全部功能即可測試。

　　出口易老業(yè)務系統(tǒng)不足

　　不夠靈活：對應用程序做任何細微的修改都需要將整個應用程序重新構(gòu)建、重新部署。

　　妨礙持續(xù)交付：系統(tǒng)規(guī)模大，構(gòu)建和部署時間也相應地比較長，不利于頻繁部署，阻礙持續(xù)交付。

　　受技術棧限制：包括開發(fā)語言，開發(fā)工具，數(shù)據(jù)庫一旦選定，無法根據(jù)實際需要作其他選擇。

　　技術負債：系統(tǒng)邏輯異常復雜，隨著時間推移，人員更迭，技術負債不斷累積。

　　出口易新業(yè)務系統(tǒng)特點

　　面向服務：根據(jù)業(yè)務模塊切分不同的系統(tǒng)模塊，系統(tǒng)模塊采用面向服務架構(gòu)。服務與服務通過明確的接口定義進行通訊。

　　領域驅(qū)動設計：每個業(yè)務模塊團隊負責一個領域或業(yè)務功能相關的全部開發(fā)。核心領域根據(jù)DDD中明確定義的規(guī)則實現(xiàn)。

　　獨立部署、升級、擴展和替換：每個服務可以單獨部署，透明升級，不影響整個系統(tǒng)。

　　異構(gòu)/采用多種語言：每個服務開發(fā)團隊，可以選擇自己熟悉開發(fā)語言，數(shù)據(jù)庫，開發(fā)工具和開發(fā)架構(gòu)。

　　新架構(gòu)落地的切入點

　　身份認證：每個服務都需要統(tǒng)一的登錄認證。

　　鑒權：不同的用戶使用相同的服務模塊都需要鑒權。

　　由單點登錄的頁面包括基于OAuth2 API這樣的方式來接入。內(nèi)部采用的是DDD這樣的一個邏輯架構(gòu)，包括應用層、領域?qū)印ｎI域?qū)永锩嬗职祟I域模型、實體子對象、領域服務、領域事件和查詢的規(guī)格。

　　基于倉儲，要存一個訂單，必須連接實體和子對象一起存儲刷新到數(shù)據(jù)庫。

　　我們做應用的時候更偏向于完成業(yè)務，所以選用了mangoDB。我們有一套自己的架構(gòu)，在封裝的過程中就會把mangoDB做一層封裝。

　　上圖中面向切面的架構(gòu)包括了exertion、loading和cache等切面。

　　上圖是TMS系統(tǒng)調(diào)撥單聚合根示意圖，它包括了物流軌跡的集合、預計到貨時間等信息，還有這些調(diào)撥單歷經(jīng)的節(jié)點信息。

　　為什么選擇MongoDB?

　　1、非事務緊密型。錯誤數(shù)據(jù)容忍性相對比較高。

　　2、團隊成員有使用MongoDB開發(fā)經(jīng)驗。對基于MongoDB方面的建模需要考慮的必要冗余有一定的了解。

　　3、Portal 模塊數(shù)據(jù)庫讀大于寫，基于MongoDB讀寫方面的高性能，解決了高并發(fā)下系統(tǒng)卡頓問題。

　　4、TMS 系統(tǒng)模型之間關系復雜，采用傳統(tǒng)關系數(shù)據(jù)庫，勢必增加一堆表。采用MongoDB，可以把復雜的模型，通過一個Doucment存儲到一起。

　　基于MongoDB開發(fā)需要注意的問題

　　集合之間不能Join，建模方面要特別注意。建議增加必要的冗余，減少二次查詢。

　　僅僅支持單個Document級別事務。數(shù)據(jù)一致性錯誤時，要考慮增加必要數(shù)據(jù)監(jiān)控和數(shù)據(jù)修復功能。

　　聚合查詢，需要通過MongoDB 聚合管道方式查詢，MongoDB C# 驅(qū)動提供了良好支持，但是相對Linq查詢還是比較繁瑣。

　　基于MongoDB的持久化實現(xiàn)

　　一、倉儲Repository

　　倉儲限定在對整個聚合根的操作上，提供聚合根的持久化和重建或查詢。

　　二、倉儲上下文Repository Context

　　負責事務處理。每個聚合根的倉儲都會關聯(lián)到同一個倉庫上下文。但是MongoDB 不支持事務，我們提供了虛擬實現(xiàn)。倉儲上下文應用了工作單元模式。

　　一些關注點

　　一、領域模型采用POCO(POJO)

　　簡單的CLR對象(簡單的Java對象)，不繼承任何持久化框架中的基類，或?qū)崿F(xiàn)任何持久化框架中的接口。領域?qū)硬灰肕ongoDB類庫。MongoDB倉庫層使用lambda expression 實現(xiàn)類的Map。

　　二、ID 生成器

　　有多種ID生成器可供選擇。GuidGenerator，OjbectIdGenerator，String OjbectIdGenerator，etc。我們ID一律使用String類型。所以直接使用MongoDB的StringObjectIdGenerator。

　　三、多態(tài)類的Map

　　如果把多態(tài)類(繼承)映射到MongoDB，需要指定已知類型。

　　四、一些需要了解的約定

　　NamedIdMemberConvention可以指定類的哪些屬性可以作為ID。

　　IgnoreExtraElementsConvention可以忽略Document中不存在于類中的字段，否則會拋出異常。

　　EnumRepresentationConvention可以指定枚舉序列化的方式，我們都指定為BsonType.String。

　　MongoDB聚合框架(C#)

　　一、聚合框架

　　MongoDB2.2版本引入了此功能，是數(shù)據(jù)聚合的一個新框架。

　　這個框架一是對文檔進行“過濾”，也就是篩選出符合條件的文檔;二是對文檔進行“變換”，也就是改變文檔的輸出形式。其他的也包括按照某個指定字段分組和排序等。

　　它其實是MapReduce的替代方案，但比MapReduce簡單。

　　該框架使用聲明性管道符號來支持類似SQL 中的Group by 操作的功能。不需要自己編寫自定義的JavaScript。

　　二、管道操作符

　　$project：數(shù)據(jù)投影，主要用于重命名、增加和刪除字段。

　　$match：過濾操作，篩選符合條件文檔，作為下一階段的輸入。

　　$limit：限制經(jīng)過管道的文檔數(shù)量。

　　$skip：從待操作集合開始的位置跳過文檔的數(shù)目。

　　$unwind：將數(shù)組元素拆分為獨立字段。

　　$group：對數(shù)據(jù)進行分組。

　　$sort：對文檔按照指定字段排序。

　　$geoNear：會返回一些坐標值，這些值以按照距離指定點距離由近到遠進行排序。這個在地理信息系統(tǒng)中比較常用。

　　總結(jié)

　　對于大多數(shù)的聚合操作，聚合管道可以提供很好的性能和一致的接口。

　　使用起來比較簡單，和MapReduce一樣，它也可以作用于分片集合。

　　輸出的結(jié)果只能保留在一個文檔中，要遵守BSON Document大小限制(當前是16M)。

　　管道對數(shù)據(jù)的類型和結(jié)果的大小會有一些限制，對于一些簡單的固定的。

　　聚集操作可以使用管道，但是對于一些復雜的、大量數(shù)據(jù)集的聚合任務還是使用MapReduce。

　　今天的分享就到這里，謝謝大家!