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

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

0 引 言

隨著時代的發(fā)展與信息技術的進步，計算機技術在各行各業(yè)得到了廣泛運用，有力推動了行業(yè)數字化產業(yè)進程。 順應時代發(fā)展的變化，向信息化方向展開變革與創(chuàng)新對所有的企業(yè)來說，既是機遇、也是挑戰(zhàn)。 ERP 系統(tǒng)的應用可以將企業(yè)業(yè)務實施中的單據記錄、數據統(tǒng)計等紙質工作轉化為信息化操作，幫助企業(yè)進行內部管理，提高企業(yè)競爭力。

A公司作為一家有著跨國木材交易業(yè)務的企業(yè)，木材商品種類多，總體業(yè)務流程復雜，交易金額大、采購訂單下達集中且常有業(yè)務改動，導致當前傳統(tǒng)的單體架構ERP 系統(tǒng)難以滿足企業(yè)需要。 單體架構將一個應用作為一個整體具有快速開發(fā)部署的優(yōu)勢，但是單體架構下系統(tǒng)各模塊間的耦合度較高，維護難度大，系統(tǒng)可拓展性低［1］，有著不利于持續(xù)開發(fā)的劣勢。 且單體架構下無法對某一模塊進行單獨的修改和部署［2］，也無法針對某一功能點實現服務器擴容等操作，性能擴展有局限性［3］。

為解決上述問題且滿足企業(yè)的多變需求，本文在木材訂單系統(tǒng)開發(fā)中選擇使用微服務作為系統(tǒng)的整體架構進行重構，降低了功能模塊間的耦合度，提升了系統(tǒng)拓展性，使用了分布式事務保證分布式架構下的數據一致性、針對企業(yè)數據安全要求進行了權限分配與權限鑒定設計并為保證系統(tǒng)安全性，使用了負載均衡與服務熔斷技術保證了系統(tǒng)的高可用。

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

系統(tǒng)將要實現從海外采購訂單下達到木材海運至國內倉庫的整體業(yè)務流程管理。 訂單將區(qū)分運營公司、項目與幣種，不同幣種的單據間還需要進行金額換算，同時不同的訂單還將對應不同的運輸方式，由此又會有包含陸上卡車運輸及海上貨船運輸在內的不同物流環(huán)節(jié)參與其中。 系統(tǒng)需要負責整個業(yè)務流程中大量的單據生成、管理、木材的狀態(tài)位置去向查詢、各環(huán)節(jié)費用登記、物流過程中的狀態(tài)變化跟蹤。 需要做好用戶的角色權限、數據權限劃分，不同部門之間的員工擁有不同的權限，保證不同用戶權限間的數據隔離。 同時要考慮市場旺季時系統(tǒng)的訪問穩(wěn)定性與數據一致性問題，以及在訂單、運輸等業(yè)務流程變動時系統(tǒng)的快速改動上線與維護，保證系統(tǒng)的高穩(wěn)定、高可用、高拓展。 木材訂單系統(tǒng)功能模塊如圖1 所示。

圖1 木材訂單系統(tǒng)功能模塊Fig． 1 Functional modules of the timber order system

按照業(yè)務功能主要可分為以下模塊:

（1）用戶模塊:負責用戶的登錄注冊、用戶基本信息以及用戶權限的管理，是用戶登錄系統(tǒng)的入口。

（2）基礎信息模塊:負責對業(yè)務流程中涉及的木材商品信息、往來單位信息、港口信息、匯率信息等一系列對業(yè)務推進至關重要的基礎信息的管理。

（3）訂單模塊:負責原木、板材等各種種類木材采購訂單的新增、編輯、審核、統(tǒng)計等操作，不同運營公司的員工對訂單需要有權限區(qū)分。

（4）運輸模塊:采購流程中的商品運輸功能，包含卡車運輸和貨船運輸兩部分。

（5）文件模塊:負責上傳紙質合同、海關報表及其他相關文件掃描件的留檔保存。

2 基于微服務的木材訂單系統(tǒng)架構設計

原先的訂單系統(tǒng)采用傳統(tǒng)單體架構，單體架構即指將一個工程的所有模塊的源碼配置等內容在一起打包和部署。 系統(tǒng)的所有代碼都集中在同一個項目中，易于開發(fā)，便于管理，本地即可完整啟動，所以也更加便于測試。 傳統(tǒng)的單體架構應用開發(fā)速度快、開發(fā)成本低，適合應用在項目工程開發(fā)初期［4］。隨著系統(tǒng)模塊增多，代碼量越來越大，多個模塊相互耦合導致代碼結構混亂，代碼邏輯難以厘清，拓展性下降。 由于耦合度高，模塊之間的邏輯邊界模糊不清，難以對模塊進行有效劃分，相互依賴關系較難梳理，出錯時難以定位出錯點，且單個模塊出現問題可能導致整個系統(tǒng)崩潰。 同時一旦功能點出現變更，將會很難發(fā)現哪些模塊會受到影響，不能有效組織測試，給系統(tǒng)的維護、拓展都會帶來影響［5］。 為解決上述問題引入了微服務作為系統(tǒng)架構進行開發(fā)。

2．1 微服務架構簡介

微服務2014 年由Martin Fowler 正式提出［6］。與單體架構不同，微服務架構將一個完整的應用程序拆分為一套可以獨立部署和拓展的小服務［7］，當一個服務出現問題就會影響到與之有關聯的其他服務，而對系統(tǒng)整體影響較小。 不同的服務間相互獨立，可以由不同的語言編寫，由不同的團隊進行管理維護。 劃分執(zhí)行的各個服務間應有較為清晰的模塊邊界且各自負責一個單一的職責與功能，每個小服務在各自的進程中獨立運行且各服務間可使用統(tǒng)一的輕量級通信協議相互通信，使其可以組成一個功能完整的系統(tǒng)［8］。 各個服務的部署和拓展都可以獨立進行，服務間有著清晰的模塊邊界，具有單一性職責，避免了龐大系統(tǒng)下耦合性過高的問題。 微服務架構思想的應用可以使得大型的軟件系統(tǒng)更方便地實現業(yè)務拓展。

2．2 微服務劃分

為降低訂單系統(tǒng)耦合度，便于系統(tǒng)的拓展與維護，將微服務按照系統(tǒng)的業(yè)務邏輯服務以及系統(tǒng)功能進行拆分。 業(yè)務服務負責實現采購系統(tǒng)的具體業(yè)務功能，系統(tǒng)功能服務則要在抽取出整個系統(tǒng)的通用功能后來確保得到好的效果。 微服務的劃分要保證各個服務之間的邏輯邊界清晰，每個服務負責實現一個功能模塊，各個服務的業(yè)務功能劃分要明確，確保服務是高內聚、低耦合的［9］，劃分的服務之間通過可以跨平臺／跨語言的輕量級通信接口實現通信［10］，便于后期拓展與修改。 微服務劃分見表1。

表1 微服務劃分Tab． 1 Microservices division

2．3 系統(tǒng)總體架構設計

系統(tǒng)的微服務框架將使用Spring Cloud［11］搭建，約定大于配置的優(yōu)勢，大大簡化了微服務系統(tǒng)的開發(fā)。 Spring Cloud 可以與其它Spring 項目兼容，快速結合，使得在整合構建微服務系統(tǒng)的組件與框架上更加靈活、快捷［12］。 系統(tǒng)總體架構如圖2 所示。對于總體架構的研發(fā)設計內容，文中給出剖析論述如下。

圖2 系統(tǒng)總體架構Fig． 2 Overall architecture of the system

（1）功能服務與業(yè)務服務。 訂單系統(tǒng)內的微服務分為系統(tǒng)功能微服務與業(yè)務邏輯微服務兩大類。服務使用Spring Boot 框架進行實際功能開發(fā)，配合Feign 實現跨服務遠程調用。 使用LogBack 日志框架實現系統(tǒng)操作日志的記錄，使用Spring Security ＋OAuth2.0 ＋JWT（JSON Web Token）實現權限鑒定。

（2）服務發(fā)現與服務配置。 木材訂單系統(tǒng)由數個不同的微服務實例組成，且在企業(yè)實際應用中根據流量壓力情況的不同，服務實例數量也是會動態(tài)變化的。 每一個服務實例可能會有不同的網絡地址和端口號，在服務實例頻繁變動的情況下人工管理與配置是不現實的。 此時就需要有一個模塊對生產者服務與消費者服務實行集中管理，解決服務間的互通問題。

各業(yè)務服務與系統(tǒng)功能服務都會有其對應的配置文件，而隨著項目的開發(fā)、部署環(huán)境變化，這些配置文件也會衍生出不同版本。 若按照傳統(tǒng)的單體架構的模式在服務中管理各自的配置文件，數量巨大的配置文件管理工作將十分棘手，因此一個可以統(tǒng)一管理各種配置、參數配置的中心模塊是不可或缺的。

為解決上述問題，使用Nacos 實現系統(tǒng)的服務注冊與配置中心，以完成微服務的發(fā)現、配置以及管理工作，實現服務發(fā)現與服務檢查、動態(tài)配置管理、動態(tài)DNS 服務、服務和元數據管理在內的四大功能。 動態(tài)管理的特點使得服務注冊與配置中心可以動態(tài)監(jiān)聽配置參數，發(fā)布新配置后不必重新部署，可以使最新的配置應用于相關服務［13］，提升了開發(fā)效率，減輕了系統(tǒng)維護對企業(yè)使用的影響。

（3）服務網關。 構建服務網關作為木材訂單系統(tǒng)的用戶請求入口，負責接收所有外界請求并向相應的微服務進行路由轉發(fā)，起到將系統(tǒng)內外部隔離的作用。 作為流量轉發(fā)的中心，網關對所有服務的需要對外提供的API 接口做統(tǒng)一管理，令外部請求只與網關、而非與多個微服務進行交互，降低客戶端調用的復雜度。 系統(tǒng)中的微服務接口調用詳見圖3。

本系統(tǒng)選擇使用Spring Cloud Gateway 作為服務網關組件，其基于Filter 攔截器鏈的工作方式，使得系統(tǒng)可以在此處拓展限流、鑒權、監(jiān)控等功能，完善系統(tǒng)的整體穩(wěn)定性、安全性與可用性。 同時，引入Sentinel 結合網關實現服務熔斷，并使用Nginx 實現系統(tǒng)負載均衡。

（4）遠程調用組件。 微服務系統(tǒng)為了降低耦合性，微服務之間是相互獨立的，但是不可避免地需要相互通信傳遞信息，此時就需要通過服務間遠程調用組件來解決這一課題［14］。

使用Feign 作為服務間的遠程調用組件。 Feign是聲明式的模板化的Http 客戶端，在服務生產者創(chuàng)建好相應接口并添加注解后遠程服務就可以被消費者調用，使得在調用遠程服務時就會更加簡單。Feign 默認整合了Ribbon 組件，使其實現了負載均衡功能。

（5）數據持久化。 訂單系統(tǒng)的持久層使用MySql 為單個微服務實現數據的存儲，使用Redis 作為數據緩存中間件，提高數據訪問速度，減輕數據庫訪問負擔。 使用MyBatis 持久層框架，簡化了JDBC操作以及參數設置。 為保證分布式系統(tǒng)下的數據一致性，使用Tx-LCN 框架實現分布式事務管理。

3 系統(tǒng)關鍵技術

3．1 權限安全設計

由于該企業(yè)跨國木材業(yè)務訂單金額大，有一定數據保密需求，企業(yè)內部區(qū)分運營分公司，不同部門員工對不同單據的操作權限也不相同，需要做好用戶權限隔離與用戶身份認證檢查，所以就用戶權限設計和權限鑒定中心兩方面進行了系統(tǒng)的權限安全設計。 具體設計可詳述如下。

（1）用戶權限設計。 木材訂單系統(tǒng)使用基于角色的訪問控制模型［15］（RBAC）實現系統(tǒng)的功能權限分配策略，同一個角色擁有相同的功能權限。 使用用戶-角色-權限的權限設置方式，不直接將權限與用戶綁定，而是將權限與角色相關聯、再將角色與用戶相關聯，令用戶和權限不直接關聯，使一個用戶可以擁有被賦予的不同角色的所有權限，有利于權限分配的多樣化。 用戶權限設計框架如圖4 所示。

用戶所在部門職位不同、項目不同，可查看的數據也不同。 分部門的數據權限分為全部部門數據、本部門數據、本部門及下屬部門數據、自定義部門數據四種粒度，項目組不做細分。 對需要有數據權限要求的數據表中都加入項目ID 以及部門ID 兩個字段，通過使用MyBatis 持久化框架下的攔截器對數據進行過濾，實現數據權限的限制。

（2）權限鑒定中心。 為保證木材訂單系統(tǒng)的數據安全性，使用Spring Security 框架與OAuth2.0 協議［16］構建權限鑒定中心微服務，利用JWT 實現Token 令牌并使用非關系型數據庫Redis 緩存Token令牌，以避免用戶登錄時頻繁訪問數據庫，減輕數據庫壓力，實現用戶登錄以及用戶操作時的權限鑒定。權限鑒定流程如圖5 所示。 對此可做探討表述如下。

圖5 權限鑒定流程Fig． 5 Permission authentication process

①用戶登錄鑒權:客戶端發(fā)送攜帶用戶登錄信息的請求，由Gateway 網關獲取，并轉發(fā)至鑒權中心，由TokenEndPoint 中的／oauth／token 接口接收。 將傳來的登錄信息同數據庫中的用戶賬號密碼匹配校驗，若成功匹配則通過Feign 遠程調用用戶管理微服務，獲取角色以及功能權限列表等詳細用戶信息；若匹配失敗則向客戶端返回錯誤提示。 此時可查詢Redis緩存，查看是否存在當前用戶有效Token，若存在則直接向客戶端返回 Token， 若不存在則調用createAccessToken 方法生成新Token 后再返回客戶端。

②用戶操作鑒權:客戶端向微服務發(fā)送請求時攜帶Token 信息，Gateway 攔截到請求后向鑒權中心發(fā)送請求，根據Token 的合法性判斷是否為用戶的有效請求。 鑒權中心將接收到的Token 同Redis 緩存中的Token 進行對比，合法性檢查合格后放行，將請求轉發(fā)到具體微服務。 微服務間通過Feign 進行遠程調用時需要權限鑒定的同樣在請求時攜帶Token，鑒權中心檢驗其合法性，合格后返回用戶角色權限列表。 在請求進入Controller 層接口前判斷當前用戶是否擁有權限，符合條件的才能進入接口并調用后續(xù)方法，否則返回權限錯誤信息。

3．2 分布式事務

木材采購系統(tǒng)采用了微服務架構，避免了單體架構中的可維護性差、架構擴展性差等問題，按照單一職責的原則劃分了微服務，每個服務有各自的數據庫、且事務是相互獨立的，只在本服務內生效，而一次業(yè)務操作中難免同時涉及多個微服務，產生多個獨立事務。 要想使跨服務業(yè)務邏輯最終獲得成功，就必須保證跨服務調用的事務與數據一致性［17］。 分布式事務處理時序如圖6 所示。

圖6 分布式事務處理時序圖Fig． 6 Sequence diagram of distributed transaction processing

系統(tǒng)使用Tx-LCN 框架實現分布式事務的管理。 事務管理中不創(chuàng)建新事務，而是通過創(chuàng)建并管理所有微服務事務信息的事務組。 在事務發(fā)起方執(zhí)行業(yè)務代碼前，調用TxManager 模塊創(chuàng)建事務組對象，并得到事務標識GroupId。 在事務發(fā)起方之后參與的事務都將加入同一個事務組，每一個參與方的事務執(zhí)行結果都需要通知TxManager。 當所有事務發(fā)起方的所有業(yè)務代碼執(zhí)行結束后，TxManager 根據事務執(zhí)行情況通知事務組中的每一個事務參與方提交或回滾事務，并將最終結果返回事務發(fā)起方，保障數據一致性。

3．3 系統(tǒng)可用性

木材訂單系統(tǒng)在市場旺季時會有大量訂單或運輸服務的高并發(fā)請求，單體架構舊系統(tǒng)無法進行針對性的處理，可能引發(fā)服務超時、報錯、請求失敗等影響企業(yè)業(yè)務運營的問題。 引入微服務架構后，為滿足系統(tǒng)可用性采取以下措施:

（1）負載均衡。 為了維持木材訂單系統(tǒng)后臺在高并發(fā)情況下的穩(wěn)定性，需要將客戶端流量以資源利用最大化的方式分配到具體服務中，也就是實現負載均衡。 在訂單系統(tǒng)的網關集群前加入反向代理服務器Nginx，流量由此轉發(fā)到網關集群。 在Nginx中添加服務器網關端口集群，根據網關服務實例的連接數目進行負載均衡，平衡請求數量的分配，保證網關的穩(wěn)定運行。 內部服務間遠程調用時在Feign中集成Ribbon 組件，通過輪詢機制實現負載均衡。

（2）服務熔斷。 為避免在服務調用鏈中因某一環(huán)節(jié)服務無法正常工作，導致其調用者請求超時、甚至因為請求堆積發(fā)生雪崩效應造成整個系統(tǒng)崩潰，此時應該將出故障的服務或接口隔離出來，斷絕其與外部訪問的聯系，直到恢復正常。 通過在網關中加入Sentinel 實現服務熔斷以達到目標需求，本系統(tǒng)中設置使用平均響應時間超過閾值800 ms 時進行熔斷。

4 結束語

本文使用Spring Cloud 微服務框架設計重構木材訂單系統(tǒng)。 相較于傳統(tǒng)單體架構，微服務高內聚低耦合的系統(tǒng)特點更有利于根據用戶具體需求對系統(tǒng)做針對性修改，更有利于企業(yè)的發(fā)展需求。 本文根據系統(tǒng)功能以及業(yè)務功能劃分了微服務，每一個服務負責單一職責，并在此基礎上進行了系統(tǒng)整體架構設計，加入了RBAC 權限分配與權限鑒定中心配合解決系統(tǒng)數據權限問題，保障企業(yè)數據安全；通過分布式事務管理保證在微服務架構下的數據一致性；在企業(yè)應用中使用了負載均衡與服務熔斷，盡力保障采購系統(tǒng)在高并發(fā)或其他突發(fā)情況下的可用性與健壯性。 本木材訂單系統(tǒng)已在企業(yè)投入使用，并取得良好效果，有效輔助了企業(yè)業(yè)務運行。