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

（東華大學(xué) 計算機科學(xué)與技術(shù)學(xué)院， 上海 201620）

0 引 言

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

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

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

1 系統(tǒng)需求分析

1．1 業(yè)務(wù)需求

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

圖1 關(guān)鍵業(yè)務(wù)流程圖Fig． 1 Key business implementation process

1．2 可用性需求

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

2 基于微服務(wù)架構(gòu)的倉儲管理系統(tǒng)架構(gòu)設(shè)計

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

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

因此，本系統(tǒng)基于微服務(wù)架構(gòu)實現(xiàn)系統(tǒng)的高伸縮性、結(jié)合熔斷限流和服務(wù)無狀態(tài)化設(shè)計實現(xiàn)高可用性、結(jié)合分布式事務(wù)管理以保證數(shù)據(jù)一致性來實現(xiàn)倉儲系統(tǒng)。

2．1 微服務(wù)架構(gòu)簡介

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

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

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

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

2．2 系統(tǒng)架構(gòu)設(shè)計

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

圖2 系統(tǒng)架構(gòu)圖Fig． 2 The architecture of the system

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

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

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

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

（5）事務(wù)完整性:基于公司業(yè)務(wù)繁多，在系統(tǒng)內(nèi)劃分多個業(yè)務(wù)模塊，必然會涉及到跨服務(wù)調(diào)用導(dǎo)致數(shù)據(jù)的不一致性。 為解決此類事務(wù)問題、保證事務(wù)的一致性，本系統(tǒng)引入LCN 分布式事務(wù)框架實現(xiàn)事務(wù)完整性［18］。

3 系統(tǒng)關(guān)鍵技術(shù)

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

3．1 安全性與高可用性

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

圖3 無狀態(tài)登錄的認證過程圖Fig． 3 Authentication process of stateless entry

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

3．2 事務(wù)完整性

在微服務(wù)架構(gòu)下，各功能都按照微服務(wù)劃分原則［16］分為獨立的微服務(wù)，但在進行跨服務(wù)調(diào)用時，會涉及到一次操作需要多個系統(tǒng)協(xié)同進行，不管是對同一個數(shù)據(jù)庫的操作、還是多個數(shù)據(jù)庫，此時則要保證這些操作都要同時成功或同時失?。?2］。 這樣一來，Spring 自帶的事務(wù)會失效，造成系統(tǒng)數(shù)據(jù)的不一致性。

對于本文的跨國公司而言，業(yè)務(wù)邏輯復(fù)雜需要將業(yè)務(wù)拆分為多個微服務(wù)，存在跨服務(wù)和跨數(shù)據(jù)庫的事務(wù)操作。 因此，解決微服務(wù)架構(gòu)下的事務(wù)完整性也是本系統(tǒng)的關(guān)鍵。 為此，本文將LCN 框架引入微服務(wù)架構(gòu)中，以保證本系統(tǒng)在跨服務(wù)場景下的數(shù)據(jù)一致性。

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

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

圖4 分布式事務(wù)流程圖Fig． 4 LCN distributed transaction

在流程中，將所有服務(wù)單元的標識信息都存在統(tǒng)一單元內(nèi)，并稱為事務(wù)組。 核心步驟分為3 步:

（1）創(chuàng)建事務(wù)組:在服務(wù)發(fā)起方執(zhí)行代碼之前，創(chuàng)建事務(wù)協(xié)調(diào)者TxManager，給服務(wù)分配Group Id。

（2）添加事務(wù)組:在參與方執(zhí)行結(jié)束代碼之后，將本模塊的信息發(fā)送給事務(wù)協(xié)調(diào)者。

（3）關(guān)閉事務(wù)組:在發(fā)起方執(zhí)行了業(yè)務(wù)代碼之后，將發(fā)起方狀態(tài)發(fā)送給事務(wù)協(xié)調(diào)者。

（4）當關(guān)閉事務(wù)組之后，事務(wù)協(xié)調(diào)者根據(jù)事務(wù)組信息來通知參與方提交或回滾。

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

4 結(jié)束語

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