吳莉萍



摘要:隨著電力企業應用規模的增大和管理需求的外展,基于單體式架構的傳統ERP 系統逐漸暴露拓展性差、迭代難度大等問題。為此采用微服務技術設計與實現了一套基于分布式架構的電力企業ERP 系統。梳理了電力企業ERP 業務現狀,提出了微服務體系架構,將單體式的ERP 系統分解為多個小型、獨立、自洽的微服務,設計了微服務之間的異步通信機制,給出了采用Spring Cloud 框架實現微服務體系的技術路徑,最后通過系統測試,驗證了微服務架構體系的性能優勢。
關鍵詞:微服務、單體式架構、ERP、電力企業、Spring Cloud
中圖分類號:TM744文獻標志碼:A文章編號:1001-5922(2023)05-0179-04
Optimizeddesignandimplementationof enterprisesERP intelligentsystembasedonmicroservices
WU Liping
(State Grid Electric Power Research Institute Co.,Ltd.,Nanjing 211106,Jiangsu,China)
Abstract: With the increase of the application scale of electric power enterprises and the outreach of management requirements,the traditional ERP system based on the monolithic architecture has gradually exposed problems such as poor scalability and difficult iterations. Therefore,a set of ERP system for electric power enterprises based on dis? tributed architecture was designed and implemented using micro-service technology. After sorting out the current status of ERP business in electric power enterprises,a microservice architecture was proposed,a single ERP system was decomposed into multiple small,independent,and self-consistent microservices,and an asynchronous commu? nication mechanism between microservices was designed. The technical path of the micro-service system wasimple? mented using the Spring Cloud framework,and finally the performance advantages of the micro-service architecture system were verified through system testing.
Keywords: microservices;monolithic architecture;ERP;power companies;Spring Cloud
ERP 系統通過工作流程優化、業務模塊標準化以及業務數據高度融合,為電力裝備企業的財務資金、人員信息、項目、物資等職能領域的業務流程提供一體化的管理平臺,是提升電力裝備企業數字化管理能力的重要工具[1]。電力裝備企業現有ERP 系統采用單體式架構,各個業務模塊之間存在業務和數據的強耦合關系,導致對其中某個模塊存在功能或性能缺陷,也需要對較大范圍的業務模塊的進行重建和部署,因此非常不利于快速提升系統性能和迭代業務流程,具體表現是現有ERP 運行不穩定、響應慢且運維難度大[2]。作為一個國有企業,電力裝備企業要對國家政策、行業發展、企業管理以及市場營銷等各方面需求做出更快速、更靈活的反應,因此迫切需求對ERP系統進行體系架構升級。
為此設計并實現了基于分布式微服務架構的 ERP 系統。首先提出了基于微服務的系統架構設計,分析了服務治理的運行原理,闡述了基于消息總線的微服務通信機制,將電力企業ERP 業務分解成多個微服務,最后以庫存業務為例詳細介紹了基于 spring技術框架的微服務實現方法。
1 基于微服務的 ERP 系統設計
微服務是于2014年3月的被提出的一種新的系統架構設計風格[3]。微服務體系結構將體積大、復雜度高的單個應用程序按業務域或功能域分解為多個具有輕耦合關系的小規模的微服務。微服務借助 JSON 等輕量級通信機制進行通信,充分降低微服務之間的耦合度。
1.1ERP總體架構
基于微服務的ERP架構設計,具體如圖1所示。
主要分為6個新的微服務和原有的ERP 系統,包括服務發現、負載平衡、服務網關閉、消息總線和認證系統。
1.2服務發現和請求轉發
服務提供者在分布式服務注冊中心自動注冊其服務名稱,IP 地址,以及開始啟動后的端口號。完成注冊后服務提供者將持續向分布式服務注冊中心發送心跳信號,表明服務的運行狀態[4]。
當服務注冊中心連續3 s未被接收或接收到異常狀態心跳信號時,即從列表中刪除該服務實例。
服務訪問請求的轉發由服務網關與服務注冊中心協作完成。服務網關是用戶服務請求唯一入口地址,服務網關首先識別用戶請求訪問的服務名稱,然后將該服務名稱與從本地緩存中的可用服務列表進行遍歷比對,如果比對成功則查詢該服務實例的IP 地址和端口號,并將請求轉發到真實服務提供商的地址,如果比對失敗則拋棄該請求。
1.3消息總線
消息總線采用符合高級消息隊列協議的消息中間件技術,為微服務提供統一的應用層消息服務標準協議[5]。
以采購服務和庫存服務為例,具體如圖2所示。
從圖2可以看出,首先,入站消息隊列和出站消息隊列是在消息總線中建立的,并通過“入站”和“出站”鍵與交換機綁定。之后,采購服務向交換機發送“采購消息”,交換機使用預先商定的JSON 格式,以便消息內容獨立于語言,并攜帶路由關鍵字值“in? bound”。收到消息后,交換機將消息的路由密鑰與綁定的消息隊列密鑰進行比較,然后將消息路由到入站消息隊列,入站消息消息隊列緩存該消息。庫存服務偵聽入站消息。一旦消息到達,庫存服務立即接收消息并解析相應的JSON 字符串。任何新服務都以相同的JSON 格式向交換機發送消息,并攜帶“入站”路由密鑰,庫存服務可以從入站消息隊列接收消息,而不會影響其他服務的正常操作。
1.4微服務
基于業務研究,本文將電力 ERP 業務歸納至5個微服務群:財務管理服務、人力資源管理服務、物資管理服務、項目管理服務和設備管理需求服務。按照功能屬性,在每個微服務群下面分別劃分了若干微服務,具體如表1所示[6]。
由表1可知,財務管理服務是對電力企業內部資金流的運行狀況進行監督管理和風險控制,從而實現對企業內部各種主要功能活動進行綜合性管理。財務管理包括2個微服務:一是預算微服務;二是會計微服務。人力資源管理服務是對電力企業員工的信息管理,包括績效、教育培訓、人事信息、薪酬與福利等微服務。物資管理服務的業務范圍包括物資采購、物資倉儲、供應鏈管理等,包括需求計劃子服務、采購子服務、庫存子服務、供應商子服務等。項目管理服務是對管理管理的全生命周期過程進行管理。項目管理包括前項目管理和項目驗收與后評估2個微服務。設備管理服務是對電力企業的設備運維進行管理,包括設備巡檢子服務、通知單管理子服務、工單管理子服務等。
材料采購、工程管理、設備管理這些系統是各自獨立的,沒有系統之間的互動。因此必須手動在每個系統中輸入數據,如項目管理需要采購物資,則需要在物資管理系統中人工填寫采購申請,或者設備維修需要申領備品備件,則在物資采購系統人工填寫領用單等。微服務框架通過采用統一的消息傳遞機制,以庫存服務為“消息”接收中心,將數據自動在各服務之間進行傳遞,基本杜絕了人工錄入數據與系統間數據重復錄入的需求,使效率大大提高,人為差錯減少。如果需要在ERP 中加入新的服務,只需與已有的微服務使用相同的消息傳遞機制來進行數據交互,對已有的微服務基本不需要進行修改,這樣對已有系統的沖擊就會大大降低。
2 基于微服務的 ERP 系統的實現
本文采用基于 Spring 框架技術開發 ERP 微服務,其中SpringMVC用于Web 開發,Spring Boot 用于微服務的開發,Spring Cloud 用于實現服務注冊發現,Mybatis用于實現 ORM 持久化,Redis 集群用于建立統一分布式緩存[7-8]。
2.1微服務的實現
電力裝備企業ERP 系統中的每個微服務的數據實體、控制層、實現層和數據持久層的實現步驟和配置內容類似,因此使用Spring Boot快速構建微服務。
以物資管理服務中的庫存微服務為例,包括物資出庫和物資入庫兩個父類,以及庫存實體類、庫存控制類、業務服務接口類和數據庫映射關系類等子類。每個類除了包括單據創建、查詢、審核等任務,還存在與采購微服務、供應商微服務等其他模塊的業務關聯和數據耦合關系,因此還包括消息總線的接口。基于Spring Boot和業務邏輯的庫存微服務模塊時序圖,具體如圖3所示。
從圖3可以看出,用戶需要先進行登錄才能訪問庫存查詢頁面。在該頁面中,用戶可以輸入物資編號、倉庫信息等查詢參數,通過SpringMVC控制層調用庫存服務接口中的查詢方法來獲取相應的數據。庫存服務接口中封裝了多個查詢方法,以供控制層進行調用。而具體的查詢操作則由庫存服務實現類中的DAO 組件和Mapper 接口類完成。查詢數據后,還需要對其進行組裝,以便前端用戶能夠直觀地了解查詢結果。在整個過程中,需要注意封裝的細節,確保查詢結果的準確性和可讀性。通過這樣的流程,用戶可以方便地查詢到所需的庫存信息,提高工作效率和準確性。
2.2服務注冊發現與負載均衡的實現
Eureka 是一個流行的服務注冊發現系統,它允許服務將自己注冊到服務注冊中心,并允許其他服務發現和調用它們。在ERP 系統中,將各個模塊作為獨立的服務運行,可以極大地提高系統的靈活性和可擴展性。例如開發一個名為 stock-service 的服務,可以在其內部運行一個名為 Stock-Server 的應用程序。為了將該服務注冊到 Eureka 注冊中心,則使用 Spring Boot 中的@EnableEurekaServer 注釋。在此可以指定服務的端口、主機名和服務地址。一旦 Stock-Service 被注冊到Eureka 中心,它將定期發送心跳消息以確認其在線狀態。其他服務可以通過服務注冊中心訪問Stock-Service 的服務地址,從而實現與該服務的通信。
在一個ERP 系統中,服務之間的調用需要經過多個層次的處理。其中,客戶端通過Zuul網關向服務端發起請求,Zuul網關會根據請求的URL 路由到對應的可用服務上。而Eureka 服務端則扮演著服務注冊發現的角色,它能夠及時地感知服務實例的上下線情況,確保客戶端始終能夠調用到可用的服務實例。為了應對大流量、多并發的場景,Ribbon 負載均衡被應用于服務調用過程中,它可以根據一定的調度算法來選擇可用的服務實例,并且根據服務實例的性能情況動態調整負載均衡策略。在具體的實現中,我們可以通過圖4所示的結構來進行服務調用,并且針對不同的業務需求實現具體的調度算法。同時,在代碼層面上,可以通過配置文件或代碼的方式來完成對服務的注冊、發現、負載均衡等相關操作,確保系統的穩定性和可靠性。
在所定義的StockService類聲明一個restTem? plate 對象,在該類的QueryStock()方法以Rest 方式調用 Eureka client API 接口。
通過在StockController類添加@RestController 注解開啟RestController功能,利用 Get 方法接口調用StockService類的QueryStock()方法。
2.3服務網關的實現
本文實現的服務網關架構包括Main 包、API 包、代理包等多個組件。其中,Main 包負責啟動服務網關,并集成各種組件。API 包包含了所有的接口服務,以及請求路由和限流等功能。代理包則負責將請求轉發到對應的后端服務中,并將數據返回給客戶端。Cofiguration類是一個關鍵的組件,它定義了 Springbeans,響應路由和庫存查詢請求[9-11]。為了實現這些功能,StockHandlers類使用API 接口獲取庫存信息,并通過請求處理程序使用遠程代理調用后端服務,以便在處理請求時能夠獲取必要的數據。
2.4微服務調用的實現
使用Feign 時,首先是定義一個接口來描述調用遠程服務的方式,并使用@FeignClient 注解來標識該接口所對應的遠程服務。其中,value 屬性用于指定遠程服務的名稱,該名稱對應于注冊中心中的服務名。例如,在調用采購服務時,可以使用@FeignClient(value ="purchase-service")來指定遠程服務的名稱。然后在application.yml中配置eure? ka-feign-client 相關的屬性,包括端口號、服務注冊地址等信息[12]。
3 運行測試
3.1功能測試
以計劃服務為例子,對其中的合同臺賬查詢功能進行測試,查詢界面顯示如圖5所示。
用戶輸入采購訂單、項目編號、采購訂單號等信息,即可調出相關的合同信息和合同的執行情況。
3.2性能測試
在ERP 系統的實際應用過程中,由于數據量的大量積累和處理,往往會遇到一些性能問題,例如響應時間過長等。因此需要進行系統性能測試已驗證基于微服務的分布式體系架構的性能。合同臺賬查詢功能是ERP 系統中的一個重要功能,因此本文針對該功能進行性能測試。
在進行性能測試時,使用在線壓力測試工具Jmeter,這是一個開源的免費工具,可用于測試各種 Web 應用程序和微服務架構。Jmeter可以模擬并發量和持續時間等仿真條件,對比測試結果,分析性能瓶頸,進而優化系統性能。為了保證測試結果的準確性,測試環境盡可能地模擬真實環境,并排除其他干擾因素。
對于合同臺賬查詢功能,實驗使用Jmeter模擬多個用戶同時查詢,然后分別測量基于微服務架構的ERP 系統和原ERP 系統響應時間,以評估其性能表現。在模擬并發量值1000、持續時間30 s 的條件下,2個系統的響應時間如圖6所示。
從圖6可以看出,當響應數據量達50%時,單體式架構和微服務架構的響應時間分別為2.9、0.095 s,說明微服務架構在高并發情況下的響應時間較短。
4 結語
針對單體式信息系統架構存在的局限性,本文設計了基于微服務的分布式體系架構,并將電力 ERP 業務分解為微服務。電力企業ERP 微服務的開發基于Spring Boot 框架,采用Spring Cloud 實現了大量微服務的治理,并利用Redis 部署了分布式數據緩存,最終完成了基于微服務分布式架構的電力企業 ERP系統的設計與實現。運行測試數據表明基于微服務的電力企業ERP系統性能優于傳統的單體式架構。未來,將遵從微服務相關技術的發展創新,對微服務通信機制優化,進一步快速響應用戶高并發的訪問需求,并且探索微服務的身份認證的新策略和數據加密的新方法,確保微服務遠程調用的數據安全性。
【參考文獻】
[1] 莊園.云計算視角下電力企業信息化建設研究[J].網絡安全技術與應用,2022(4):103-104.
[2] 李霆,陳麗英.基于PCA-FAHP 的電力企業ERP 項目績效評價研究[J].計算機與數字工程,2020,48(5):1076-1081.
[3] 曹亞南.電力企業實施Oracle 與SAP 的設計探討[J].網絡安全技術與應用,2020(1):115-117.
[4] 薛皓辰,柳先輝.基于微服務架構的制造技術資源服務平臺架構研究[J].科技管理研究,2021,41(14):208-212.
[5] 余和劍.基于微服務架構的信息資源服務平臺構建研究[J].科技管理研究,2019,39(13):211-216.
[6] 龍新征,彭一明,李若淼.基于微服務框架的信息服務平臺[J].東南大學學報(自然科學版),2017,47(S1):48-52.
[7] 楊英櫻,喬運華,班玉榮.基于spring boot 微服務架構的 RS10系統管理[J].制造業自動化,2021,43(12):193-196.
[8] 韓萬江,陳淑文,韓卓言,等.基于微服務架構的分布式災情管理系統設計[J].中國地震,2021,37(4):806-818.
[9] 馬梓昂,賈克斌.基于Web的高性能智能快遞柜管理系統[J].計算機應用與軟件,2020,37(4):1-5.
[10] 余和劍.基于微服務架構的信息資源服務平臺構建研究[J].科技管理研究,2019,39(13):211-216.
[11] 劉罡.基于微服務架構的汽車經銷商管理系統[J].計算機應用,2018,38(S2):243-249.
[12] 辛園園,鈕俊,謝志軍,等.微服務體系結構實現框架綜述[J].計算機工程與應用,2018,54(19):10-17.