基于微服務架構的大宗商品ERP 倉儲系統的研究

姚 礪， 徐夢娜， 張海路， 付 帥

（東華大學 計算機科學與技術學院， 上海 201620）

0 引 言

以ERP 系統為主的信息管理系統在企業中得到廣泛運用，但是當前市場上并沒有針對大宗商品交易的ERP 系統，其交易的特殊性在于大宗商品交易的數量和金額巨大，且業務流程復雜多樣，通用的ERP 系統并不能滿足該類企業的業務需求。 另外，傳統的信息管理系統通常采用一體式的單體架構［4］進行開發，結構冗余、功能老舊單一且不利于更新換代，只能夠應對企業在初級階段所面臨的業務問題。 隨著互聯網技術和企業發展的多維協作和和深度融合，倉儲管理系統面臨著諸如業務邏輯越發復雜、業務需求更新換代更快、企業信息安全性無法保證等諸多問題［5］。

目前，ERP 系統開發多基于單體架構，使用SSM 框架（Spring、Spring MVC、Mybatis）將整個應用作為一體進行開發［6］。 其中，通過Spring 框架進行開發時，首先需要進行復雜的xml 配置，配置易出錯且易影響開發效率。 當配置過于復雜時，還會導致容器的響應速度下降。 Spring MVC 作為MVC 架構的代表技術而言，在業務規模小時有良好的表現，但在隨著業務不斷復雜、訪問量不斷增加時，該架構顯露出并發請求響應時間過長、新增部署服務器操作繁瑣等嚴重問題［7］。 本文所涉及的跨國公司業務復雜、交易時并發量大，顯然當前常用的ERP 開發模式無法搭建一個符合本公司需求的高可用、高安全性以及高伸縮性的倉庫管理系統。

針對目前基于單體架構的ERP 系統設計存在的問題，本文實現了基于微服務架構的面向大宗商品的倉儲管理系統。 系統基于微服務劃分原則，將整體業務拆分為獨立的微服務降低系統耦合性。 采用Spring Cloud 框架，結合服務熔斷限流、服務無狀態化設計、事務管理服務等技術搭建了一個高并發，高可用、高安全性、高伸縮性以及事務一致性的分布式系統，并在實際應用中取得了優異表現，也為其他具有同類業務需求的大型公司提供了微服務架構下倉儲管理系統的開發思路［8］。

1 系統需求分析

1．1 業務需求

對于主營原木大宗商品的跨國公司而言，在進行倉儲管理時存在商品品種繁多、不同品類間存儲或處理流程多樣、存儲的數量龐大、涉及跨地區流轉等特點。 針對以上特點，設計時將業務拆分為入庫、檢測熏蒸、裝箱轉運等模塊，如圖1 所示。 另外，在大型跨國公司中，公司業務的嚴謹性也尤為重要，每一項流程都需要高級權限進行審核，審核之后存在一定情況需要人為回退的為反審。 由于原木商品進行跨國交易時，涉及到的海關政策、實時匯率等突發性情況較多，因此反審功能極為重要，需要針對每一個流程進行定制化的回退，是本系統實現的難點。系統關鍵業務流程如圖1 所示。

圖1 關鍵業務流程圖Fig． 1 Key business implementation process

1．2 可用性需求

由于原木商品交易數據極大、并發高、交易涉及面廣，系統的高并發、高可用是系統實現的難點之一；其次，跨國公司的合作商與員工眾多，因此系統需要更嚴格的權限認證與訪問控制，如何達到系統的高安全性也是系統實現的難點；最后，在倉儲系統與其他業務子系統進行跨服務、跨系統調用時，保證系統的事務一致性同樣是系統實現的難點。

2 基于微服務架構的倉儲管理系統架構設計

當前很多的ERP 系統都采用單體架構。 所謂單體架構，即指將整個軟件系統的功能模塊及運行數據等作為整體看待，再進行統一地設計、開發、打包及部署運行［9］。 在單體架構式應用中，所有的業務邏輯作為整體進行設計，一旦企業的業務需求發生更新，則需要從底層進行修改，開發成本耗費巨大。

本文涉及的跨國公司業務功能復雜，若以單體架構進行開發會導致整個系統邏輯過于復雜，維護與更新成本巨大。 另外，該公司交易量大、并發高，單體架構應用在高并發場景下會出現服務崩潰、響應時間過長等致命問題。 所以，本文的倉儲ERP 系統并不適合單體架構進行開發。 而屬于分布式架構的微服務能夠將整體應用進行拆分，模塊之間獨立更新，能夠更好地適應企業當下快速變化的業務需求。 另外，對于一個大型跨國公司而言，內部信息和數據的安全性至關重要，僅僅依靠微服務架構無法保證系統的信息數據安全性。

因此，本系統基于微服務架構實現系統的高伸縮性、結合熔斷限流和服務無狀態化設計實現高可用性、結合分布式事務管理以保證數據一致性來實現倉儲系統。

2．1 微服務架構簡介

微服務架構（Micro Services Architecture，MSA）是指根據應用系統的業務需求，通過對預定義的微服務進行重組而形成企業級應用的分布式體系結構［10］。 微服務架構的基本思想是將傳統的單體應用按業務功能拆分為一系列可被獨立設計、開發、部署、運維的軟件服務單元，服務間彼此配合、相互協作以實現最終價值［11］。 相比較于傳統的單體架構，微服務架構模式具有以下眾多優勢:

（1）開發效率高。 每個微服務技術多元化，有效降低維護風險［12］，開發時每個部分可以選取不同的技術，只要提供統一的對外接口即可，極大提高了開發效率。

（2）低耦合性與強擴展性。 微服務架構屬于分布式架構，每個微服務獨立開發部署互不影響，服務間通過RPC 進行調用［13］，耦合度低。 單個服務升級更新不影響總體，具有強大的橫向擴展性。

（3）高可用性。 根據實際需要，對部分微服務進行集群部署，解決了隨用戶數量上升帶來的高并發問題。

2．2 系統架構設計

針對大宗商品交易流程復雜、需求多變、交易時數量龐大等特殊性，本系統基于微服務架構，搭建一個低耦合、易擴展、高并發、高可用、高安全性的分布式系統。 目前，使用較主流的4 種微服務框架、即Dubbo、Motan、gRPC 和Spring Cloud，其中Dubbo、Motan 屬于服務治理型RPC 框架提供了全面的服務治理功能，gRPC 雖然沒有全面的服務治理功能但是提供了多種語言的接口支持［14］。 與其他3 種比較而言，Spring Cloud 不僅提供了服務治理功能，同時還包含服務網關Gateway、服務熔斷Sentinel、服務調用Feign 等搭建微服務所需要的組件，通過負載均衡、服務無狀態設計、網關鑒權等技術能夠滿足本系統所需的并發性、可用性與安全性。 基于Spring Cloud 以上優勢，本系統選取Spring Cloud 2020 快速搭建微服務［15］。 系統架構如圖2 所示。 由圖2 分析可知，對該系統的功能特性可做闡釋分述如下。

圖2 系統架構圖Fig． 2 The architecture of the system

（1）伸縮性:基于公司業務復雜且更新快的特點，將公司的業務服務群分為基礎資料、庫存管理、貨品運輸等5 個，每個業務服務功能與設計獨立，便于擴展與升級，具有良好的伸縮性。

（2）安全性:基于跨國公司常涉及海內交易且用戶群廣泛，為避免惡意的網絡攻擊、非法入侵，系統引入Oauth2.0 作為安全解決方案提高系統安全性［16］。

（3）高效性:為解決微服務下的服務管理問題，將所有服務在Nacos 注冊與配置中心進行注冊后，對這些服務進行獨立配置、部署及管理。 利用動態配置，以集中和動態的方式管理各個服務的配置信息，無需重新部署服務，使配置管理具有高效性。

（4）高并發可用性:基于公司交易商品的交易量大，瞬間的大量請求會導致服務癱瘓，造成服務雪崩。 為解決以上問題，整合Sentinel［17］做到流量控制、熔斷降級等來提升服務的穩定性、保持服務在高并發性能。

（5）事務完整性:基于公司業務繁多，在系統內劃分多個業務模塊，必然會涉及到跨服務調用導致數據的不一致性。 為解決此類事務問題、保證事務的一致性，本系統引入LCN 分布式事務框架實現事務完整性［18］。

3 系統關鍵技術

針對大宗商品市場用戶覆蓋面廣、跨國交易復雜、交易時用戶與貨品數量龐大等特點，如何搭建一個高可用、高安全性以及具有事務一致性的分布式系統是本系統的關鍵。

3．1 安全性與高可用性

（1）無狀態登錄實現登錄安全性。 在大型企業中，公司的機密信息顯然需要更嚴格的控制。 本文涉及的跨國公司業務廣泛、覆蓋幾十個國家和地區、用戶的使用環境與信息傳輸都存在風險。 因此提供安全可靠的登錄認證服務也是本系統實現的關鍵點之一。 傳統的登錄認證在當前客戶端登錄后，如需訪問另外的服務提供者，則需要當前客戶端的用戶密碼來獲取當前的用戶信息，此時存在密碼暴露的風險。 因此為解決以上風險，本系統基于Spring Oauth2.0 設計思想，在客戶端與服務提供者間加入授權層，客戶端無法直接登錄服務提供者［19］，而是通過授權層獲取設有有效期的令牌（Token），客戶端攜帶令牌訪問，授權層攔截token 進行檢查處理和查詢用戶信息［20］，把無狀態的token 轉化成用戶信息，實現用戶無狀態登錄，具有良好的安全性。 無狀態登錄的認證過程如圖3 所示。

圖3 無狀態登錄的認證過程圖Fig． 3 Authentication process of stateless entry

（2）服務層無狀態實現服務層高可用性。 本文涉及的跨國公司用戶量龐大、業務量高，當同時出現大量訪問時，單個微服務性能可能會遭遇瓶頸［21］。因此，實現服務層的高可用性也是本系統的關鍵之一。 針對以上問題，本系統內使用無狀態登錄可以使得服務器端無需保留大量用戶數據，減輕服務端壓力，實現服務層無狀態。 服務層無狀態化設計使集群中的節點可彼此替代，任何節點宕機都不會導致系統停止服務，實現了服務層的高可用性。

3．2 事務完整性

在微服務架構下，各功能都按照微服務劃分原則［16］分為獨立的微服務，但在進行跨服務調用時，會涉及到一次操作需要多個系統協同進行，不管是對同一個數據庫的操作、還是多個數據庫，此時則要保證這些操作都要同時成功或同時失敗［22］。 這樣一來，Spring 自帶的事務會失效，造成系統數據的不一致性。

對于本文的跨國公司而言，業務邏輯復雜需要將業務拆分為多個微服務，存在跨服務和跨數據庫的事務操作。 因此，解決微服務架構下的事務完整性也是本系統的關鍵。 為此，本文將LCN 框架引入微服務架構中，以保證本系統在跨服務場景下的數據一致性。

LCN 框架的基本思想是不創建事務、不操作事務，通過協調事務來達到事務一致性［21］。 在進行跨服務操作時，TxManager 作為事務協調者獨立在業務服務之外，不嵌入業務代碼中，因此與業務服務的耦合性低。 并且TxManager 能夠兼容Nacos 注冊中心并進行服務注冊，便于獨立部署與管理。 基于LCN 框架對業務的入侵性低、對第三方框架的兼容性強等優勢，選取LCN 框架能夠更好地實現本系統的數據一致性。

對于交易量大、并發高的跨國公司而言，事務管理的高可用性同樣至關重要。 TxManager 集群可以與Redis 相結合，將TxManager 的分組信息緩存至Redis，因此雙方發起事務，不需要確定連接到了哪個TxManager，單一節點宕機可通過Redis 輪詢來確定TxManager，達到事務管理的高可用性。 LCN 分布式事務協調流程如圖4 所示。

圖4 分布式事務流程圖Fig． 4 LCN distributed transaction

在流程中，將所有服務單元的標識信息都存在統一單元內，并稱為事務組。 核心步驟分為3 步:

（1）創建事務組:在服務發起方執行代碼之前，創建事務協調者TxManager，給服務分配Group Id。

（2）添加事務組:在參與方執行結束代碼之后，將本模塊的信息發送給事務協調者。

（3）關閉事務組:在發起方執行了業務代碼之后，將發起方狀態發送給事務協調者。

（4）當關閉事務組之后，事務協調者根據事務組信息來通知參與方提交或回滾。

綜上，LCN 框架能夠解決在分布式系統下的事務一致性問題，并且事務操作和代碼耦合度極低、通過集群化能夠達到高可用，保證了大型公司在高并發場景下的事務完整性。

4 結束語

本文通過分析當下大宗商品ERP 系統的開發現狀，研究基于微服務架構對當前問題的解決方案，搭建基于微服務架構的大宗商品倉儲管理系統，通過服務自動化管理、熔斷限流、服務無狀態化以及低耦合高兼容的事務管理實現了高并發、高可用、高安全性、高伸縮性以及事務一致性的分布式系統。 業務部分針對木材大宗商品市場進行定制化的系統設計，并與公司業務深度結合，拋開固有的模板化系統設計，使系統具有更多的適用性與變通性。 本系統現已投入使用并取得良好成果，為同類型企業的信息管理系統提供了優質的范本。