微服務架構下ERP應用系統的優勢及挑戰

朱義方 徐易婕

摘 要：近年來互聯網徹底改變了人們的生活方式，給人們的工作和生活帶來了極大的方便。隨著互聯網技術的發展和業務的需求，傳統的IT建設已經滿足不了客戶的需求，那么我們的IT架構也需要作出相應的改進，來支撐企業的數字化轉型。而容器與微服務平臺已是當今眾多IT公司的主流技術，相關的云計算、虛擬化技術也已深入滲透到我們日常的開發運維中[1]。相比較而言，傳統單體式架構下的ERP信息系統逐漸暴露出了諸多短板缺陷，如程序結構復雜，系統擴展性差，故障影響范圍廣等。隨著移動互聯時代的推進，ERP系統需要應對公司業務規模的日益擴張，單體架構已經很難適應或是滿足應用系統對于擴展性、可用性、靈活性等方面的要求。繼而，系統向新型微服務架構的轉變應運而生。

關鍵詞：微服務;ERP系統;軟件架構

微服務構架可以看做是一種軟件架構風格，能夠以開發一組組小型服務來構建成一個大型應用系統。微服務之間彼此耦合度松散，每個服務都可獨立放置、自我管理，且服務間調用編排靈活。由此構建的ERP系統內，各微服務模塊即可保持彼此獨立，亦可相互關聯，也能對每個微服務進行單獨部署、測試、和運轉。在服務內部，服務模塊只關心其關聯業務的開展，負責ERP系統中的一個或者多個業務。

1.ERP應用系統的發展

典型的ERP系統是一個由多個模塊例如銷售管理、庫存管理、物資采購、人資管控、財務管理等組成的企業信息資源管理系統。初期以IBM大型機為平臺，主要開發語言為ABAP，之后推出SAP NetWeaver平臺，配合單獨的Oracle數據庫，從而形成一個數據庫層、應用層、展示層的SAP三層架構體系[2]。隨著時間的推移，ERP系統業務在現代化技術的依托下發展越來越快，功能不斷完善，流程日益增多，伴隨著開發人員不斷交替，代碼質量參差不齊，單體式架構下的應用越來越復雜，系統的擴展性和可維護性的弊端逐漸暴露出來。尤其是在進入新時期之后，ERP系統急需一個全新的軟件結構模式來支撐其龐大的架構體系和業務需求。而近年來逐漸成熟化的云計算和微服務等新興技術架構，恰好能靈活的滿足我們對系統的需求，而且具備更加獨立的運營維護效率[3]。

2.微服務架構應用的優勢

2.1 靈活性

首先我們根據微服務的架構思想，簡單的將ERP系統劃分為多個子系統，在這些子系統當中，開發環節、部署環節、測試環節都可以由不同的團隊來完成，甚至可以由不同的技術棧來完成。子系統只需要運行系統相關業務服務，通過WebService或RFC形式的接口輸出即可。同時，這些暴露的接口粒度開發人員可根據具體業務需求、系統擴展需求、靈活性需求來進行綜合性設計。微服務的另一個重要特征是，與單一應用程序不同的是，單一程序根據應用程序的不同層級來定義團隊：用戶界面團隊，服務器端團隊，數據庫團隊等;微服務允許公司圍繞特定業務功能來構建團隊。這反過來又驅使團隊具備了跨職能能力，從而擁有了一系列更強大的技能：用戶體驗、數據庫管理、項目管理等[4]。這使我們進一步走進DevOps時代。最后在數據庫層面，允許每個獨立子系統有自己的單獨數據庫，可以是關系性數據庫，或是新型鍵值等其他類型的數據庫。

微服務架構的核心就是去中心化，不同的子系統以本身業務特征采取不同的業務手段來實現，從而降低了系統的技術債務現象，使系統不過分依賴某個框架或者是某種語言來實現應用。每個服務技術選型靈活，不受遺留系統的技術約束。即使是一個比較小型的微服務系統進行升級、重構，也不會對運維團隊造成很大的困擾，這給軟件的更新換代降低了多種風險[5]。

2.2 自治性

微服務有自己的邏輯和數據，能完全獨立部署和運行在一個進程內，對領域內可進行自我管理和修復，且不對其他服務功能造成影響。作為單個獨立的微服務，其職責也是單一的，即一個微服務解決一個業務需求。當某個子系統需要升級，或者是添加額外功能的情況下，只需要對單個子系統進行重構，不需要對整個應用進行編譯和部署了。這種松耦合、自治的系統架構讓應用系統的發布流程更為可靠，讓發布更加高效便捷，同時也降低了對生產環境的風險，也相應縮短了應用的交付周期。

2.3 擴展性

傳統單體架構下的應用系統擴展往往都是水平方向的，例如服務器的擴充，數據庫的復制，這確實能夠在一定程度上解決訪問速度緩慢、訪問失敗等常見性問題，但無法解決根源上的問題，而且還會消耗大量資源，增加系統負荷，資源利用率大幅增長。而服務的分散管理使開發人員能夠根據特定業務需求選用不同的編程語言，這取決于他們認為哪種語言才是圍繞微服務構建的最佳選擇。這也意味著他們可以使用獨立的數據存儲，從而獲得這種架構的最大優勢——幾乎無限的可擴展性。在微服務多地部署完成后，您只需要調整所需的功能，而不是每次都創建整個應用程序的重復實例。這反過來又節省了時間和資源。如果將ERP系統拆分為一個個微型服務，通過業務流程對服務進行排列組合，就可以處理更多的工作，或者很容易地進行擴展。這些無狀態的自治節點靈活地分布在整體系統中，自由地拓展伸縮，為系統提供了穩定且可靠的性能基礎和更加清晰的業務劃分。

3.微服務架構運用過程中面臨的挑戰

3.1 拆分粒度問題

在微服務構架設計的過程中首要任務就是對服務進行拆分，拆分的原則可以有很多種，但基本上都是圍繞業務展開完成的，服務的拆分粒度實際上沒有統一的標準。因此按照業務劃分的各個微服務系統，應該在這個環節內做到高內聚，盡量減少分布式事務的存在。由于服務力度很難劃分出統一的標準，當服務力度過于粗糙，內部代碼就會產生耦合的現象，在具體的設計過程中，服務力度也不是以細為好，如果拆分過于細密，系統之間相互的依賴關系就會變得復雜，出現問題之后也很難找到問題的根源。對于服務的拆分粒度，應該盡量保證本身服務開展的獨立性和完整性，盡量減少服務之間的依賴性，盡可能避免多層依賴、鏈式調用現象的存在[5]。

3.2 服務間通信問題

前面我們說到服務之間要盡量做到高內聚、低耦合，但無論怎樣，一定不能避免系統中各服務之間的互相調用。所以當服務完成拆分后，就需要處理服務間互相通信的問題。如何使服務間進行最有效便捷的相互調用，是目前微服務架構下眾說紛紜的熱點[6]。當前，已有一些成熟開源的RPC框架調用使用較為廣泛，如Dubbo、SpringCloud、gRPC等，都能夠支持多種調用協議。這些框架能夠幫助封裝底層數據間的通信細節，讓不同微服務之間的通信就像是本地通信一樣簡單快捷。另外，我們也能根據自身特性開發適合ERP系統的調用框架，或與其他技術框架結合使用，才是解決眾多服務間調用交互的根本方法。

3.3 分布式事務問題

基于微服務的靈活性，每個服務都可以有自己的數據庫。這對于開發人員來說大大提高了他們的發布效率，但如何實施跨服務的事務和查詢以及保持整個系統的數據一致性卻不是一件輕松的事，可以說是一把“雙刃劍”。

假設我們將ERP系統中某大型業務分為多個子服務，那么在運行該業務時，服務與服務之間需彼此通信，遠程協作后才能輸出最終結果，即完成一整套分布式事務操作[7]。但是如果在服務調用過程中某一個服務突然不可用，或由于網絡問題遠程調用超時，那么服務之間就可能出現數據不一致甚至級聯反應導致整個業務運行失敗。比如采購管理系統，在采購入庫時相應數據會寫入庫存管理系統;當庫存管理系統中的產品完成入庫之后，還需要更新采購系統中的具體數量。上面這些問題我們應該都遇到過，并且也會有一些解決方案，比如提供文檔管理、服務治理、服務模擬的工具和框架; 實現統一認證、統一配置、統一日志框架、分布式匯總分析; 采用全局事務方案、采用異步模擬同步;搭建持續集成平臺、統一監控平臺等等。可見這一整套流程嚴格要求數據的一致性得到保證，一旦數據出現不一致，就會導致業務邏輯執行任務失敗。

結語：綜上，微服務架構的優勢固然可見，與之而來的困難與挑戰也是關卡重重。故無論是傳統單體式還是新型微服務架構，我們在使用它之前都需要對其有全面深入的認知，在結合系統本身特性的基礎上認清系統面臨的變革與挑戰，而不是為了追求技術而去微服務化。

參考文獻：

[1]巢晟盛.基于SpringBoot微服務架構下前后端分離的MVVM模型淺析[J].電腦知識與技術，2021，17（23）：128-129+141.

[2]吳磊， 湛健， 宋麗華.微服務架構在智能家居網關系統中的應用研究[J].計算機技術與發展， 2019， 029（011）：200-205.

[3]周文坤， 喬運華， 侯佳佳， etal.微服務架構的ERP應用系統的優勢及挑戰[J].制造業自動化， 2020， 042（006）：123-124，132.

[4]張廣鑫.基于微服務架構的智慧校園系統平臺建設研究[J].遼寧高職學報， 2020， v.22;No.203（02）：85-89.

[5]桂俊，沈迎春.基于微服務架構的企業ERP設計與應用[J].計算機系統應用，2021，30（08）：81-88.

[6]池煒成，史立學，劉智瓊，朱明英.微服務架構下規則平臺方案與規則遷移方法[J].現代計算機，2021（18）：142-145.

[7]周藝偉，洪逸凡.基于微服務架構下題庫系統智能組卷算法應用的研究[J].電腦知識與技術，2020，16（24）：183-184+190.