微服務(wù)架構(gòu)下ERP應(yīng)用系統(tǒng)的優(yōu)勢(shì)及挑戰(zhàn)

朱義方 徐易婕

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

關(guān)鍵詞：微服務(wù);ERP系統(tǒng);軟件架構(gòu)

微服務(wù)構(gòu)架可以看做是一種軟件架構(gòu)風(fēng)格，能夠以開發(fā)一組組小型服務(wù)來構(gòu)建成一個(gè)大型應(yīng)用系統(tǒng)。微服務(wù)之間彼此耦合度松散，每個(gè)服務(wù)都可獨(dú)立放置、自我管理，且服務(wù)間調(diào)用編排靈活。由此構(gòu)建的ERP系統(tǒng)內(nèi)，各微服務(wù)模塊即可保持彼此獨(dú)立，亦可相互關(guān)聯(lián)，也能對(duì)每個(gè)微服務(wù)進(jìn)行單獨(dú)部署、測(cè)試、和運(yùn)轉(zhuǎn)。在服務(wù)內(nèi)部，服務(wù)模塊只關(guān)心其關(guān)聯(lián)業(yè)務(wù)的開展，負(fù)責(zé)ERP系統(tǒng)中的一個(gè)或者多個(gè)業(yè)務(wù)。

1.ERP應(yīng)用系統(tǒng)的發(fā)展

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

2.微服務(wù)架構(gòu)應(yīng)用的優(yōu)勢(shì)

2.1 靈活性

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

微服務(wù)架構(gòu)的核心就是去中心化，不同的子系統(tǒng)以本身業(yè)務(wù)特征采取不同的業(yè)務(wù)手段來實(shí)現(xiàn)，從而降低了系統(tǒng)的技術(shù)債務(wù)現(xiàn)象，使系統(tǒng)不過分依賴某個(gè)框架或者是某種語言來實(shí)現(xiàn)應(yīng)用。每個(gè)服務(wù)技術(shù)選型靈活，不受遺留系統(tǒng)的技術(shù)約束。即使是一個(gè)比較小型的微服務(wù)系統(tǒng)進(jìn)行升級(jí)、重構(gòu)，也不會(huì)對(duì)運(yùn)維團(tuán)隊(duì)造成很大的困擾，這給軟件的更新?lián)Q代降低了多種風(fēng)險(xiǎn)[5]。

2.2 自治性

微服務(wù)有自己的邏輯和數(shù)據(jù)，能完全獨(dú)立部署和運(yùn)行在一個(gè)進(jìn)程內(nèi)，對(duì)領(lǐng)域內(nèi)可進(jìn)行自我管理和修復(fù)，且不對(duì)其他服務(wù)功能造成影響。作為單個(gè)獨(dú)立的微服務(wù)，其職責(zé)也是單一的，即一個(gè)微服務(wù)解決一個(gè)業(yè)務(wù)需求。當(dāng)某個(gè)子系統(tǒng)需要升級(jí)，或者是添加額外功能的情況下，只需要對(duì)單個(gè)子系統(tǒng)進(jìn)行重構(gòu)，不需要對(duì)整個(gè)應(yīng)用進(jìn)行編譯和部署了。這種松耦合、自治的系統(tǒng)架構(gòu)讓應(yīng)用系統(tǒng)的發(fā)布流程更為可靠，讓發(fā)布更加高效便捷，同時(shí)也降低了對(duì)生產(chǎn)環(huán)境的風(fēng)險(xiǎn)，也相應(yīng)縮短了應(yīng)用的交付周期。

2.3 擴(kuò)展性

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

3.微服務(wù)架構(gòu)運(yùn)用過程中面臨的挑戰(zhàn)

3.1 拆分粒度問題

在微服務(wù)構(gòu)架設(shè)計(jì)的過程中首要任務(wù)就是對(duì)服務(wù)進(jìn)行拆分，拆分的原則可以有很多種，但基本上都是圍繞業(yè)務(wù)展開完成的，服務(wù)的拆分粒度實(shí)際上沒有統(tǒng)一的標(biāo)準(zhǔn)。因此按照業(yè)務(wù)劃分的各個(gè)微服務(wù)系統(tǒng)，應(yīng)該在這個(gè)環(huán)節(jié)內(nèi)做到高內(nèi)聚，盡量減少分布式事務(wù)的存在。由于服務(wù)力度很難劃分出統(tǒng)一的標(biāo)準(zhǔn)，當(dāng)服務(wù)力度過于粗糙，內(nèi)部代碼就會(huì)產(chǎn)生耦合的現(xiàn)象，在具體的設(shè)計(jì)過程中，服務(wù)力度也不是以細(xì)為好，如果拆分過于細(xì)密，系統(tǒng)之間相互的依賴關(guān)系就會(huì)變得復(fù)雜，出現(xiàn)問題之后也很難找到問題的根源。對(duì)于服務(wù)的拆分粒度，應(yīng)該盡量保證本身服務(wù)開展的獨(dú)立性和完整性，盡量減少服務(wù)之間的依賴性，盡可能避免多層依賴、鏈?zhǔn)秸{(diào)用現(xiàn)象的存在[5]。

3.2 服務(wù)間通信問題

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

3.3 分布式事務(wù)問題

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

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

結(jié)語：綜上，微服務(wù)架構(gòu)的優(yōu)勢(shì)固然可見，與之而來的困難與挑戰(zhàn)也是關(guān)卡重重。故無論是傳統(tǒng)單體式還是新型微服務(wù)架構(gòu)，我們?cè)谑褂盟岸夹枰獙?duì)其有全面深入的認(rèn)知，在結(jié)合系統(tǒng)本身特性的基礎(chǔ)上認(rèn)清系統(tǒng)面臨的變革與挑戰(zhàn)，而不是為了追求技術(shù)而去微服務(wù)化。

參考文獻(xiàn)：

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

[2]吳磊， 湛健， 宋麗華.微服務(wù)架構(gòu)在智能家居網(wǎng)關(guān)系統(tǒng)中的應(yīng)用研究[J].計(jì)算機(jī)技術(shù)與發(fā)展， 2019， 029（011）：200-205.

[3]周文坤， 喬運(yùn)華， 侯佳佳， etal.微服務(wù)架構(gòu)的ERP應(yīng)用系統(tǒng)的優(yōu)勢(shì)及挑戰(zhàn)[J].制造業(yè)自動(dòng)化， 2020， 042（006）：123-124，132.

[4]張廣鑫.基于微服務(wù)架構(gòu)的智慧校園系統(tǒng)平臺(tái)建設(shè)研究[J].遼寧高職學(xué)報(bào)， 2020， v.22;No.203（02）：85-89.

[5]桂俊，沈迎春.基于微服務(wù)架構(gòu)的企業(yè)ERP設(shè)計(jì)與應(yīng)用[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2021，30（08）：81-88.

[6]池?zé)槼?，史立學(xué)，劉智瓊，朱明英.微服務(wù)架構(gòu)下規(guī)則平臺(tái)方案與規(guī)則遷移方法[J].現(xiàn)代計(jì)算機(jī)，2021（18）：142-145.

[7]周藝偉，洪逸凡.基于微服務(wù)架構(gòu)下題庫系統(tǒng)智能組卷算法應(yīng)用的研究[J].電腦知識(shí)與技術(shù)，2020，16（24）：183-184+190.