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

朱義方

（國(guó)網(wǎng)上海市電力公司信息通信公司，上海 200072）

0 引言

微服務(wù)構(gòu)架可以看做是一種軟件架構(gòu)風(fēng)格，能夠以開(kāi)發(fā)一組組小型服務(wù)來(lái)構(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ù)的開(kāi)展，負(fù)責(zé)ERP 系統(tǒng)中的一個(gè)或者多個(gè)業(yè)務(wù)。

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

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

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

2.1 靈活性

根據(jù)微服務(wù)的架構(gòu)思想，簡(jiǎn)單的將ERP 系統(tǒng)劃分為多個(gè)子系統(tǒng)，在這些子系統(tǒng)當(dāng)中，開(kāi)發(fā)環(huán)節(jié)、部署環(huán)節(jié)、測(cè)試環(huán)節(jié)都可以通過(guò)不同的團(tuán)隊(duì)來(lái)完成，甚至可以由不同的技術(shù)棧來(lái)完成。這些團(tuán)隊(duì)有不同的技術(shù)支撐，子系統(tǒng)只需要完成相關(guān)業(yè)務(wù)服務(wù)，通過(guò)Web Service 或RFC 形式的接口輸出即可。同時(shí)，這些暴露的接口粒度開(kāi)發(fā)人員可根據(jù)具體業(yè)務(wù)需求、系統(tǒng)擴(kuò)展需求、靈活性需求來(lái)進(jìn)行綜合性設(shè)計(jì)。微服務(wù)還有另外一個(gè)顯著特征，即與單一應(yīng)用程序的服務(wù)方向不同，單一程序根據(jù)層級(jí)來(lái)定義不同的團(tuán)隊(duì)，如用戶(hù)界面、服務(wù)器、數(shù)據(jù)團(tuán)隊(duì)等，而微服務(wù)是為公司全業(yè)務(wù)而服務(wù)，不受任何類(lèi)型局限，這種方式讓團(tuán)隊(duì)具備了跨職的可能，因此，微服務(wù)的功能更全面，如用戶(hù)體驗(yàn)、數(shù)據(jù)庫(kù)管理、項(xiàng)目管理等[4]。這些功能的出現(xiàn)讓微服務(wù)更快融入了生活，使我們進(jìn)一步走進(jìn)Dev Ops 時(shí)代。此外，在數(shù)據(jù)庫(kù)層面，獨(dú)立的子系統(tǒng)均具備單獨(dú)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的具體設(shè)計(jì)根據(jù)系統(tǒng)具體需求而定義，可以是關(guān)系型數(shù)據(jù)庫(kù)，也可以是其他類(lèi)型的數(shù)據(jù)庫(kù)。

微服務(wù)架構(gòu)的核心就是去中心化，集合大量不同的子系統(tǒng)，圍繞企業(yè)的需求開(kāi)展本身業(yè)務(wù)以外的其他業(yè)務(wù)實(shí)現(xiàn)，這其中采取的手段不同，實(shí)現(xiàn)結(jié)果也不同，降低了系統(tǒng)的債務(wù)情況，讓系統(tǒng)功能的實(shí)現(xiàn)不再依賴(lài)某一個(gè)框架或者是語(yǔ)言。每個(gè)服務(wù)技術(shù)選型靈活，不受遺留系統(tǒng)的技術(shù)約束。即使是一個(gè)比較小型微服務(wù)系統(tǒng)的升級(jí)、重構(gòu)，也不會(huì)對(duì)系統(tǒng)的運(yùn)行產(chǎn)生影響，這給軟件的更新?lián)Q代降低了多種風(fēng)險(xiǎn)[5]。

2.2 自治性

微服務(wù)有自己的邏輯和數(shù)據(jù)，能完全獨(dú)立部署和運(yùn)行在一個(gè)進(jìn)程內(nèi)，通過(guò)REST API 架構(gòu)或RPC 架構(gòu)，將事件流程與報(bào)文代理結(jié)合起來(lái)，以達(dá)到相互協(xié)同的輕量級(jí)通信機(jī)制。在微服務(wù)體系結(jié)構(gòu)中，各個(gè)服務(wù)是獨(dú)立的業(yè)務(wù)單位，對(duì)領(lǐng)域內(nèi)可進(jìn)行自我管理和修復(fù)，且不對(duì)其他服務(wù)功能造成影響。微服務(wù)體系中的應(yīng)用系統(tǒng)包含了許多具有高度自主性的、獨(dú)立的商業(yè)實(shí)體，能夠在各自的系統(tǒng)中運(yùn)行，并且能夠很方便地將各種服務(wù)配置到不同的主機(jī)上，從而達(dá)到高度自治和高度分離性。作為單個(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)讓?xiě)?yīng)用系統(tǒng)的發(fā)布流程更為可靠、便捷，同時(shí)也能降低對(duì)系統(tǒng)產(chǎn)生的各類(lèi)風(fēng)險(xiǎn)，進(jìn)一步縮短應(yīng)用的交付周期。

2.3 擴(kuò)展性

傳統(tǒng)單體架構(gòu)下的應(yīng)用系統(tǒng)擴(kuò)展往往都是水平方向的，例如服務(wù)器的擴(kuò)充，數(shù)據(jù)庫(kù)的復(fù)制，這確實(shí)能夠在一定程度上解決訪問(wèn)速度緩慢、訪問(wèn)失敗等故障，但是無(wú)法解決根源上存在的問(wèn)題。在這個(gè)過(guò)程中會(huì)消耗大量資源，系統(tǒng)負(fù)荷量也會(huì)顯著增加，資源消耗量大幅提升。如果將ERP 系統(tǒng)拆分為一個(gè)個(gè)微型服務(wù)，通過(guò)業(yè)務(wù)流程對(duì)服務(wù)進(jìn)行排列組合，就可以處理更多的工作，或者很容易地進(jìn)行擴(kuò)展。這些無(wú)狀態(tài)的自治節(jié)點(diǎn)靈活地分布在整體系統(tǒng)中，自由地拓展伸縮，為系統(tǒng)提供了穩(wěn)定且可靠的性能基礎(chǔ)和更加清晰的業(yè)務(wù)劃分。

從開(kāi)發(fā)角度來(lái)看，我們還可以嘗試分散服務(wù)來(lái)擴(kuò)大服務(wù)范圍，管理人員與開(kāi)發(fā)人員通過(guò)業(yè)務(wù)需求來(lái)確定使用哪種程序語(yǔ)言，而其決定因素是圍繞微服務(wù)架構(gòu)更適合哪一種語(yǔ)言。這也意味著開(kāi)發(fā)與管理人員可能選擇彼此獨(dú)立的數(shù)據(jù)庫(kù)，但這也是微服務(wù)架構(gòu)具備的最大優(yōu)勢(shì)，即無(wú)限拓展性。開(kāi)發(fā)人員可在微服務(wù)部署結(jié)束之后根據(jù)自己需要的功能調(diào)整即可，而不是每次都要?jiǎng)?chuàng)建語(yǔ)言，節(jié)省了大量的時(shí)間和成本。

3 微服務(wù)架構(gòu)下ERP 應(yīng)用系統(tǒng)運(yùn)用過(guò)程中面臨的挑戰(zhàn)

3.1 拆分粒度問(wèn)題

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

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

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

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

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

假設(shè)將ERP 系統(tǒng)中某大型業(yè)務(wù)分為多個(gè)子服務(wù)，那么在運(yùn)行該業(yè)務(wù)時(shí)，服務(wù)與服務(wù)之間需彼此通信，遠(yuǎn)程協(xié)作后才能輸出最終結(jié)果，即完成一整套分布式事務(wù)操作[7]。但是如果在服務(wù)調(diào)用過(guò)程中某一個(gè)服務(wù)突然不可用，或由于網(wǎng)絡(luò)問(wèn)題遠(yuǎn)程調(diào)用超時(shí)，那么服務(wù)之間就可能出現(xiàn)數(shù)據(jù)不一致甚至級(jí)聯(lián)反應(yīng)導(dǎo)致整個(gè)業(yè)務(wù)運(yùn)行失敗。例如，采購(gòu)管理系統(tǒng)的業(yè)務(wù)實(shí)現(xiàn)，在材料采購(gòu)入庫(kù)時(shí)相應(yīng)數(shù)據(jù)會(huì)寫(xiě)入庫(kù)存管理系統(tǒng)內(nèi)，系統(tǒng)當(dāng)前的數(shù)據(jù)為庫(kù)存數(shù)據(jù)，當(dāng)材料完成入庫(kù)之后，庫(kù)存管理系統(tǒng)中的材料數(shù)量就應(yīng)同步更新。如果在這一整套流程中發(fā)生了某一個(gè)節(jié)點(diǎn)的卡頓或夯死，就會(huì)造成數(shù)據(jù)鏈斷裂，一旦數(shù)據(jù)出現(xiàn)不一致，就會(huì)導(dǎo)致整個(gè)業(yè)務(wù)邏輯執(zhí)行任務(wù)失敗。為保證業(yè)務(wù)流程順利進(jìn)行，我們需要提供更多的服務(wù)，如文檔管理、服務(wù)治理、服務(wù)模擬的工具和框架；實(shí)現(xiàn)統(tǒng)一認(rèn)證、統(tǒng)一配置、統(tǒng)一日志框架、分布式匯總分析；采用全局事務(wù)方案、異步模擬同步或搭建持續(xù)集成平臺(tái)、統(tǒng)一監(jiān)控平臺(tái)等。

4 微服務(wù)架構(gòu)下ERP 應(yīng)用系統(tǒng)設(shè)計(jì)

4.1 ERP 系統(tǒng)的總體需求

ERP 系統(tǒng)的一個(gè)主要功能就是使企業(yè)的業(yè)務(wù)過(guò)程自動(dòng)化。例如，在客戶(hù)發(fā)出訂單后，銷(xiāo)售部會(huì)根據(jù)企業(yè)的存貨和生產(chǎn)能力，對(duì)客戶(hù)的訂單進(jìn)行審核，如果存貨和生產(chǎn)能力都能滿(mǎn)足，那么就對(duì)客戶(hù)的定單進(jìn)行確認(rèn)，然后按照定單上的產(chǎn)品，向倉(cāng)庫(kù)部提出出貨要求，如果存貨達(dá)到了要求，則直接出庫(kù)。如果存貨不夠，則由生產(chǎn)部根據(jù)訂單確定生產(chǎn)任務(wù)，待產(chǎn)品生產(chǎn)出來(lái)后再提交倉(cāng)庫(kù)。

4.2 基于微服務(wù)的ERP 系統(tǒng)架構(gòu)設(shè)計(jì)

基于微服務(wù)的ERP 系統(tǒng)架構(gòu)可以分為四層，從底層到頂層分別是基礎(chǔ)設(shè)施層、微服務(wù)層、服務(wù)網(wǎng)關(guān)層、應(yīng)用交互層。其中基礎(chǔ)設(shè)施層的主要作用是數(shù)據(jù)存儲(chǔ)，由Redis 數(shù)據(jù)庫(kù)來(lái)提供緩存服務(wù)和關(guān)系型數(shù)據(jù)庫(kù)資源；微服務(wù)層的主要作用是為ERP 系統(tǒng)的應(yīng)用提供聚合微服務(wù)和基礎(chǔ)業(yè)務(wù)服務(wù)，包括銷(xiāo)售管理、生產(chǎn)管理、庫(kù)存管理、采購(gòu)管理、財(cái)務(wù)管理、訂單服務(wù)、支付服務(wù)等；服務(wù)網(wǎng)關(guān)層則主要為ERP 系統(tǒng)的正常運(yùn)行提供Gateway服務(wù)網(wǎng)關(guān)和Nginx 反向代理；應(yīng)用交互層可為用戶(hù)和管理人員提供信息數(shù)據(jù)交互使用的功能，如Web View、Web APP、第三方OA 或者是CRM 系統(tǒng)。

4.3 協(xié)作接口設(shè)計(jì)

設(shè)計(jì)協(xié)作接口的本質(zhì)是定義各個(gè)銜接上下文的應(yīng)用服務(wù)接口，保證企業(yè)對(duì)ERP 系統(tǒng)使用的需求。在微服務(wù)框架下，ERP 系統(tǒng)協(xié)作接口可采用事件機(jī)制，協(xié)作接口可按照之前確定的上下文映射來(lái)獲得。由于每個(gè)協(xié)作關(guān)系都有一個(gè)接口，不同的上下文映射模式可能會(huì)影響到接口的設(shè)計(jì)效果。比如：生產(chǎn)訂單上下文映射時(shí)，需要將訂單和系統(tǒng)集成之間的協(xié)作改為事件機(jī)制，并詳細(xì)記錄和訂單上下文相關(guān)的協(xié)作接口。

有時(shí)一個(gè)服務(wù)會(huì)對(duì)應(yīng)多個(gè)接口，而每個(gè)接口所擔(dān)任的職責(zé)功能可能會(huì)有關(guān)聯(lián)，所以開(kāi)發(fā)一套簡(jiǎn)單又便捷的協(xié)作服務(wù)接口是很重要的。我們?cè)谠O(shè)計(jì)時(shí)應(yīng)盡可能地減少依賴(lài)性，以降低故障發(fā)生的可能，提高服務(wù)可靠性。還可以嘗試將一個(gè)功能下的接口根據(jù)主次拆分到不同的服務(wù)中去，優(yōu)先級(jí)高的放在一個(gè)服務(wù)中，優(yōu)先級(jí)低的放在另一個(gè)服務(wù)中，以減少一個(gè)服務(wù)不可用導(dǎo)致其所有接口均不可用的情況。

4.4 微服務(wù)網(wǎng)關(guān)設(shè)計(jì)

網(wǎng)關(guān)是ERP 系統(tǒng)的上層服務(wù)，它隔絕了微服務(wù)與客戶(hù)端的直接通信，所有的外部請(qǐng)求都會(huì)先經(jīng)過(guò)網(wǎng)關(guān)這一層。傳統(tǒng)單體式架構(gòu)的ERP 系統(tǒng)通常只開(kāi)放一個(gè)服務(wù)給客戶(hù)端調(diào)用，而微服務(wù)架構(gòu)中服務(wù)都是獨(dú)立拆分的。當(dāng)客戶(hù)端訪問(wèn)某個(gè)服務(wù)時(shí)，需要先在本地記錄該微服務(wù)的調(diào)用地址，如需訪問(wèn)多個(gè)服務(wù)，則需要記錄每個(gè)微服務(wù)的接口地址，這無(wú)疑增加了系統(tǒng)的負(fù)擔(dān)。這時(shí)就需要由網(wǎng)關(guān)來(lái)統(tǒng)一系統(tǒng)入口，即將微服務(wù)進(jìn)行封裝，所有請(qǐng)求經(jīng)網(wǎng)關(guān)合理分配至各微服務(wù)，使客戶(hù)端只需與網(wǎng)關(guān)通信，不必再一一調(diào)用其他服務(wù)。另外，網(wǎng)關(guān)系統(tǒng)還能收集相關(guān)監(jiān)控?cái)?shù)據(jù)，對(duì)訪問(wèn)請(qǐng)求進(jìn)行統(tǒng)一認(rèn)證，控制并發(fā)流量等，為系統(tǒng)的安全加上一把“鎖”。目前市場(chǎng)上使用較多的網(wǎng)關(guān)有Zuul、Spring Cloud Gateway、Kong 等，其性能較好，可維護(hù)性強(qiáng)，可實(shí)現(xiàn)身份認(rèn)證、內(nèi)部負(fù)載均衡、限流等主要功能。

5 結(jié)語(yǔ)

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