ERP之痛

曾幾何時(shí)，我混跡于電商、珠寶行業(yè)4年多，為這兩個(gè)行業(yè)開(kāi)發(fā)過(guò)兩套大型業(yè)務(wù)系統(tǒng)（ERP）。作為一個(gè)ERP系統(tǒng)，系統(tǒng)主要功能模塊無(wú)非是訂單管理、商品管理、生產(chǎn)采購(gòu)、倉(cāng)庫(kù)管理、物流管理、財(cái)務(wù)管理等等。作為一個(gè)管理系統(tǒng)，大家的一般開(kāi)發(fā)習(xí)慣就是使用.Net或Java技術(shù)，建立一個(gè)單塊（單進(jìn)程）架構(gòu)的應(yīng)用，只有一個(gè)SQLServer或MySql數(shù)據(jù)庫(kù)。然后在項(xiàng)目文件中分一下各個(gè)模塊，三層結(jié)構(gòu)方式組織代碼編寫(xiě)開(kāi)發(fā)。最后測(cè)試，交付上線。

起初，因?yàn)閿?shù)據(jù)量不大，系統(tǒng)性能還不錯(cuò)，各種列表查詢，報(bào)表查詢，Excel數(shù)據(jù)導(dǎo)出功能等用的都很流暢。但是隨著公司業(yè)務(wù)發(fā)展，訂單量日積月累，后期各種業(yè)務(wù)部門(mén)的報(bào)表查詢、數(shù)據(jù)導(dǎo)出需求不斷增多，我們漸漸就感覺(jué)系統(tǒng)運(yùn)行越來(lái)越慢。于是我們可能最先想到的解決方案就是，優(yōu)化系統(tǒng)瓶頸數(shù)據(jù)庫(kù)這個(gè)大頭。我們可能的一種嘗試就是將數(shù)據(jù)庫(kù)單獨(dú)放置到一個(gè)服務(wù)器，實(shí)現(xiàn)數(shù)據(jù)庫(kù)和應(yīng)用程序分離，或者是建立各種數(shù)據(jù)庫(kù)表索引，優(yōu)化程序代碼等方法。經(jīng)過(guò)這樣一番研究?jī)?yōu)化，系統(tǒng)某些功能可能性能的確大大提高，但是我們還是發(fā)現(xiàn)某些功能列表的數(shù)據(jù)查詢導(dǎo)出依然很慢，或者隨著數(shù)據(jù)量繼續(xù)積累，原來(lái)較快的列表導(dǎo)出功能，也愈來(lái)愈變得緩慢了。我們用盡各種辦法，最后也達(dá)不到理想的系統(tǒng)性能速度。

為了提高系統(tǒng)性能，我們也許會(huì)主動(dòng)學(xué)習(xí)一些互聯(lián)網(wǎng)公司的技術(shù)經(jīng)驗(yàn)，什么高并發(fā)、高性能、大數(shù)據(jù)、讀寫(xiě)分離等方案，發(fā)現(xiàn)自己根本無(wú)從下手。我們會(huì)覺(jué)得因?yàn)橄到y(tǒng)業(yè)務(wù)特點(diǎn)不一樣。ERP系統(tǒng)并發(fā)量不高，主要是業(yè)務(wù)復(fù)雜，各種業(yè)務(wù)耦合度遠(yuǎn)高于那些互聯(lián)網(wǎng)應(yīng)用，不好做拆分，數(shù)據(jù)查詢邏輯要遠(yuǎn)比互聯(lián)網(wǎng)系統(tǒng)復(fù)雜，一個(gè)列表頁(yè)查詢出來(lái)的數(shù)據(jù)，往往需要關(guān)聯(lián)4、5張表才能得到結(jié)果。有些報(bào)表類的甚至更多。加上各種業(yè)務(wù)操作事務(wù)性、數(shù)據(jù)一致性要求很高，很多時(shí)候?qū)е挛覀兇氩患笆?，無(wú)法進(jìn)一步優(yōu)化系統(tǒng)。

曾幾何時(shí)，我也被這樣或那樣的理由所挫敗，認(rèn)為ERP系統(tǒng)非常特殊，無(wú)藥可救，可是后來(lái)……

我現(xiàn)在已經(jīng)不這么認(rèn)為了，似乎有了新的解決方案O(∩_∩)O哈哈~

曙光乍現(xiàn)

在敘述具體方案前，先說(shuō)下自己的想法。我首先覺(jué)得我們做ERP系統(tǒng)前，就得有當(dāng)今互聯(lián)網(wǎng)思維。我們不要再去做一個(gè)大一統(tǒng)的系統(tǒng)了。我們要分拆一個(gè)大系統(tǒng)，做成一個(gè)個(gè)小系統(tǒng)。然后通過(guò)系統(tǒng)接口讓這些小系統(tǒng)相互通信。這樣來(lái)組成一個(gè)大系統(tǒng)，具體來(lái)說(shuō)就是“分布式”、“服務(wù)化”的互聯(lián)網(wǎng)思維。讓系統(tǒng)在架構(gòu)設(shè)計(jì)上就是一個(gè)先天支持高度可擴(kuò)展的系統(tǒng)。

怎么做呢？具體來(lái)說(shuō)就是要將訂單管理、商品管理、生產(chǎn)采購(gòu)、倉(cāng)庫(kù)管理、物流管理、財(cái)務(wù)管理拆分成一個(gè)個(gè)子系統(tǒng)。這些子系統(tǒng)可以單獨(dú)設(shè)計(jì)開(kāi)發(fā)，對(duì)外暴露出各種其他子系統(tǒng)需求的數(shù)據(jù)接口即可。每個(gè)子系統(tǒng)都有單獨(dú)的數(shù)據(jù)庫(kù)。甚至這些子系統(tǒng)可以交由不同的團(tuán)隊(duì)去開(kāi)發(fā)和維護(hù)，使用不同的技術(shù)體系，使用不同的數(shù)據(jù)庫(kù)。而不是再像以前那樣，都集成在同一個(gè)大而全的系統(tǒng)中，一個(gè)大而全的數(shù)據(jù)庫(kù)。

對(duì)于新架構(gòu)的系統(tǒng)他有什么優(yōu)點(diǎn)呢？

首先，也是最重要的就是解決系統(tǒng)的性能問(wèn)題。以往數(shù)據(jù)庫(kù)實(shí)例只有一個(gè)，沒(méi)法擴(kuò)展出多個(gè)實(shí)例，以便在性能受限的情況下依靠增加數(shù)據(jù)庫(kù)實(shí)例來(lái)達(dá)到負(fù)載均衡。也許有人會(huì)說(shuō)可以使用讀寫(xiě)分離方案，但是因?yàn)镋RP系統(tǒng)的特點(diǎn)，這個(gè)方案很多時(shí)候不現(xiàn)實(shí)。比如說(shuō)操作庫(kù)存的時(shí)候，你不能從讀庫(kù)里讀庫(kù)存，然后在寫(xiě)庫(kù)里寫(xiě)入庫(kù)存。因?yàn)橹鲝膹?fù)制會(huì)有時(shí)效性，寫(xiě)入的庫(kù)存并不能馬上寫(xiě)入從庫(kù)。這樣的場(chǎng)景在ERP中也有多處。何況寫(xiě)庫(kù)不能擴(kuò)展，只能有一個(gè)。而新設(shè)計(jì)方案是寫(xiě)庫(kù)是分離的，每個(gè)子系統(tǒng)有自己的數(shù)據(jù)庫(kù)。

其次，就是更新非常方便，各個(gè)子系統(tǒng)以后臺(tái)微服務(wù)的方式存在。前臺(tái)一個(gè)單獨(dú)的web項(xiàng)目，這個(gè)web項(xiàng)目調(diào)用后臺(tái)這些子系統(tǒng)的服務(wù)接口。這樣的設(shè)計(jì)，在某個(gè)業(yè)務(wù)子系統(tǒng)需要更新的時(shí)候，可以單獨(dú)更新。不用像以前那種單進(jìn)程架構(gòu)時(shí)，一個(gè)小更新需要整個(gè)系統(tǒng)重啟，導(dǎo)致用戶會(huì)話也丟失，用戶需要新登錄。而現(xiàn)在的這種設(shè)計(jì)就不會(huì)有這個(gè)問(wèn)題。

系統(tǒng)整體設(shè)計(jì)

系統(tǒng)物理部署視圖

詳細(xì)設(shè)計(jì)

拆分應(yīng)用層

拆分應(yīng)用層，是踐行“微服務(wù)”架構(gòu)的理念。將原來(lái)大而全的單進(jìn)程架構(gòu)按照業(yè)務(wù)模塊拆分成可獨(dú)立部署的應(yīng)用程序，以此來(lái)達(dá)到平滑系統(tǒng)更新、升級(jí)、方便負(fù)載擴(kuò)展的目的。具體來(lái)說(shuō)，技術(shù)上可以使用restfull風(fēng)格的接口，也可以使用像java中dubbo框架方式來(lái)簡(jiǎn)化開(kāi)發(fā)復(fù)雜度。ERPWeb端或其他移動(dòng)端也是一個(gè)單獨(dú)的應(yīng)用充當(dāng)表現(xiàn)層。非常薄，只是簡(jiǎn)單的接受參數(shù)，調(diào)取后臺(tái)其他各種微服務(wù)程序的接口獲取所需展示的數(shù)據(jù)。微服務(wù)充當(dāng)業(yè)務(wù)邏輯層，每個(gè)微服務(wù)都是可獨(dú)立部署上線的程序，對(duì)外提供數(shù)據(jù)訪問(wèn)接口。

微服務(wù)可以使用流行的各種RPC框架，比如dubbo，可以支持多種調(diào)用協(xié)議Http、TCP等，這些框架使得編碼比較容易，框架封裝底層數(shù)據(jù)通信細(xì)節(jié)，使得客戶端執(zhí)行遠(yuǎn)程方法如同執(zhí)行本地方法一樣簡(jiǎn)單。

dubbo微服務(wù)架構(gòu)，還支持服務(wù)治理，負(fù)載均衡等功能。這樣不僅可以提高系統(tǒng)的可用性，還能動(dòng)態(tài)提升系統(tǒng)應(yīng)用層的性能。比如倉(cāng)庫(kù)管理中入庫(kù)業(yè)務(wù)非常繁忙，占用非常多的CPU和內(nèi)存資源，我們可以另外加一臺(tái)機(jī)器，單獨(dú)再部署一個(gè)倉(cāng)庫(kù)管理服務(wù)上去。這樣使得整個(gè)系統(tǒng)，有兩個(gè)倉(cāng)庫(kù)管理服務(wù)在同時(shí)工作，平衡負(fù)載。而這一切都是在服務(wù)注冊(cè)中心，比如Zookeeper下自動(dòng)完成的。

微服務(wù)結(jié)構(gòu)，天生很好的支持系統(tǒng)更新升級(jí)操作。比如財(cái)務(wù)模塊有個(gè)新需求需要上線，我們只需要替換財(cái)務(wù)模塊的服務(wù)重啟即可。這對(duì)已經(jīng)登錄系統(tǒng)的用戶來(lái)說(shuō)，沒(méi)有多少影響，不用重新登陸系統(tǒng)，其他模塊服務(wù)使用也不受影響。

拆分?jǐn)?shù)據(jù)層

數(shù)據(jù)庫(kù)瓶頸是ERP系統(tǒng)的永久之傷。大量復(fù)雜的數(shù)據(jù)查詢表連接邏輯充斥著整個(gè)系統(tǒng)。數(shù)據(jù)庫(kù)垂直拆分成功的關(guān)鍵就是如何重新設(shè)計(jì)系統(tǒng)數(shù)據(jù)層各個(gè)模塊相互耦合的問(wèn)題。能解決這個(gè)問(wèn)題，永久之傷便可以解決了。

我們先來(lái)看一個(gè)典型數(shù)據(jù)層模塊耦合問(wèn)題。需求是展示物料庫(kù)存，列表字段：物料編號(hào)、物料名稱、品類、倉(cāng)庫(kù)、數(shù)量

物料表：

物料ID 名稱 品類ID

Z0001 Iphone6紅色手機(jī)殼 Z

Z0002 iPhone6黑色手機(jī)殼 Z

庫(kù)存表：

物料ID 倉(cāng)庫(kù)ID 數(shù)量

Z0001 W1 10

Z0002 W1 20

品類和倉(cāng)庫(kù)表省略

很顯然，傳統(tǒng)一個(gè)數(shù)據(jù)庫(kù)中，我們只需要簡(jiǎn)單的join操作，即可關(guān)聯(lián)這兩張表，外加關(guān)聯(lián)品類和倉(cāng)庫(kù)表即可查詢出我們所要的數(shù)據(jù)。但是現(xiàn)在我們的架構(gòu)中，物料表和商品表不在同一個(gè)數(shù)據(jù)庫(kù)實(shí)例中，我們不能使用join操作了，那我們?cè)撛趺磳?shí)現(xiàn)需求呢？

新的架構(gòu)，只允許我們通過(guò)對(duì)方的服務(wù)接口來(lái)獲取數(shù)據(jù)，不能直接關(guān)聯(lián)對(duì)方服務(wù)的私有數(shù)據(jù)庫(kù)。至少?gòu)募軜?gòu)上，服務(wù)化角度來(lái)說(shuō)不能直接訪問(wèn)對(duì)方服務(wù)的數(shù)據(jù)庫(kù)。這種情況下，假設(shè)web模塊子系統(tǒng)調(diào)用倉(cāng)庫(kù)子系統(tǒng)來(lái)獲取數(shù)據(jù)，則我們需要在倉(cāng)庫(kù)模塊中創(chuàng)建一個(gè)service方法來(lái)裝配這些數(shù)據(jù)。然后返回給web子系統(tǒng)。如下圖所示，倉(cāng)庫(kù)管理方法首先獲取本地庫(kù)存表的物料編碼、和倉(cāng)庫(kù)表的倉(cāng)庫(kù)名稱字段信息，并且分頁(yè)完后最終準(zhǔn)備返回20條數(shù)據(jù)到Web模塊前，將這20條數(shù)據(jù)中的物料ID作為參數(shù)請(qǐng)求商品模塊子系統(tǒng)，商品子系統(tǒng)返回這20個(gè)物料ID相關(guān)的商品信息給到倉(cāng)庫(kù)管理模塊，然后倉(cāng)庫(kù)管理模塊重新組裝上列表所需的物料名稱和品類兩個(gè)字段數(shù)據(jù)，實(shí)現(xiàn)最終要返回給Web子系統(tǒng)的數(shù)據(jù)。

也許你會(huì)說(shuō)，這太麻煩了，這種方法的性能肯定沒(méi)有直接join來(lái)的高，解決不了性能問(wèn)題。咋看起來(lái)好像是這么回事，但是仔細(xì)考慮看看，在系統(tǒng)并發(fā)量低、數(shù)據(jù)量小、業(yè)務(wù)不算繁忙的環(huán)境下，的確性能還不如傳統(tǒng)一個(gè)數(shù)據(jù)中join方式來(lái)的快速。但我們想想以后吧！我們現(xiàn)在的架構(gòu)設(shè)計(jì)是將一個(gè)數(shù)據(jù)庫(kù)拆成多個(gè)數(shù)據(jù)庫(kù)，每個(gè)數(shù)據(jù)庫(kù)可以運(yùn)行在單獨(dú)的服務(wù)器上去，這樣以后就能負(fù)載數(shù)據(jù)庫(kù)的壓力了。整體來(lái)說(shuō)這樣才能不會(huì)讓數(shù)據(jù)庫(kù)成為未來(lái)業(yè)務(wù)繁忙時(shí)候的性能瓶頸了。想想都覺(jué)得讓人興奮不已，是不是？

這時(shí)候有人又會(huì)問(wèn)，那以后系統(tǒng)數(shù)據(jù)量、業(yè)務(wù)更大了，連你這個(gè)拆分成幾個(gè)數(shù)據(jù)庫(kù)還不夠用怎么辦呢？我的方法是，可以基于拆分的數(shù)據(jù)庫(kù)，單獨(dú)每個(gè)庫(kù)可以做讀寫(xiě)分離、使用緩存等。甚至可以繼續(xù)拆分下去，將子系統(tǒng)再次拆分成多個(gè)孫子系統(tǒng)。視業(yè)務(wù)模塊繁忙程度而定。

報(bào)表系統(tǒng)

有人又會(huì)問(wèn)，有些列表查詢邏輯非常復(fù)雜，關(guān)聯(lián)十多張表，如果按上述方法拆分?jǐn)?shù)據(jù)，那簡(jiǎn)直是災(zāi)難??！是的，你說(shuō)的沒(méi)有錯(cuò)。這種情況下我的方案是將這種更加復(fù)雜的報(bào)表級(jí)別的數(shù)據(jù)查詢展示需求，可以單獨(dú)做個(gè)報(bào)表系統(tǒng)。報(bào)表數(shù)據(jù)庫(kù)設(shè)計(jì)采用數(shù)據(jù)倉(cāng)庫(kù)方式。為了更高的讀取性能，我們可以將數(shù)據(jù)庫(kù)表設(shè)計(jì)成很多冗余字段方式也就是反范式設(shè)計(jì)，以及建立非常多的組合索引。

這種系統(tǒng)成功的關(guān)鍵就是數(shù)據(jù)和主ERP系統(tǒng)業(yè)務(wù)庫(kù)的同步問(wèn)題了。一般可以寫(xiě)一個(gè)定時(shí)同步程序，將ERP主業(yè)務(wù)系統(tǒng)的數(shù)據(jù)經(jīng)過(guò)帥選、轉(zhuǎn)化等方式直接生成報(bào)表視圖所需的最終或中間數(shù)據(jù)，簡(jiǎn)化關(guān)聯(lián)查詢。報(bào)表系統(tǒng)也可以采用微服務(wù)架構(gòu)設(shè)計(jì)。如下圖所示：

如果報(bào)表所需的數(shù)據(jù)要求實(shí)時(shí)的，我們可以讓ERP系統(tǒng)業(yè)務(wù)操作時(shí)，觸發(fā)同步數(shù)據(jù)的請(qǐng)求，實(shí)時(shí)同步至報(bào)表庫(kù)。

分布式事務(wù)

也許有人又又問(wèn)了，ERP系統(tǒng)很多操作都要求事務(wù)性，你拆分系統(tǒng)后怎么實(shí)現(xiàn)事務(wù)性，保障數(shù)據(jù)一致性呢？

這個(gè)問(wèn)題很好，也是我決定寫(xiě)這篇文章前思考的最后一個(gè)問(wèn)題。在微服務(wù)架構(gòu)中，實(shí)現(xiàn)夸服務(wù)的事務(wù)并不容易，至少不像本地應(yīng)用使用本地?cái)?shù)據(jù)庫(kù)事務(wù)那樣方便，性能高效，數(shù)據(jù)一致性好。

也許你聽(tīng)過(guò)分布式事務(wù)這個(gè)概念。有兩種情景，一種是一個(gè)應(yīng)用中使用多個(gè)數(shù)據(jù)庫(kù)，為保障數(shù)據(jù)一致性，需要使用分布式事務(wù)。還有一種情況就是針對(duì)我們這個(gè)架構(gòu)而言的。微服務(wù)環(huán)境下的分布式事務(wù)，具體來(lái)說(shuō)打個(gè)比方。采購(gòu)入庫(kù)這個(gè)操作設(shè)計(jì)在倉(cāng)庫(kù)管理服務(wù)中。入庫(kù)后，需要更新采購(gòu)子系統(tǒng)中的采購(gòu)單中的入庫(kù)數(shù)量。這個(gè)過(guò)程要求數(shù)據(jù)一致性，也就是采購(gòu)單入庫(kù)成功后寫(xiě)入了庫(kù)存表中的數(shù)量，同時(shí)要更新采購(gòu)單表中的入庫(kù)數(shù)量。我們不能直接在倉(cāng)庫(kù)服務(wù)中去訪問(wèn)采購(gòu)服務(wù)中的數(shù)據(jù)庫(kù)，必須通過(guò)采購(gòu)服務(wù)提供的服務(wù)接口才行。如果這樣，我們?cè)趺茨鼙ＷC數(shù)據(jù)一致性呢？因?yàn)楹苡锌赡軒?kù)存表寫(xiě)入成功，但調(diào)取采購(gòu)服務(wù)寫(xiě)入采購(gòu)單數(shù)據(jù)時(shí)失敗了?？赡苁蔷W(wǎng)絡(luò)問(wèn)題原因?qū)е碌模@樣數(shù)據(jù)就不一致了。

在分布式事務(wù)技術(shù)中，有實(shí)現(xiàn)最終一致性這么一說(shuō)，意思就是只要我能保證兩邊數(shù)據(jù)最終實(shí)現(xiàn)了一致性就行，不一定要使用事務(wù)。這樣說(shuō)來(lái)就有方案了。如倉(cāng)庫(kù)子系統(tǒng)在處理采購(gòu)入庫(kù)時(shí)需要增加入庫(kù)單數(shù)據(jù)和更新庫(kù)存數(shù)據(jù)等多個(gè)表。這多個(gè)表都在倉(cāng)庫(kù)子系統(tǒng)中，我們可以使用一個(gè)本地事務(wù)來(lái)保證倉(cāng)庫(kù)子系統(tǒng)中的表數(shù)據(jù)一致性。然后調(diào)用采購(gòu)子系統(tǒng)更新采購(gòu)單里的入庫(kù)數(shù)量。為了防止這個(gè)過(guò)程突然中斷導(dǎo)致調(diào)用失敗，我們考慮增加一個(gè)消息隊(duì)列中間件如ActiveMQ。如果接口返回失敗我們就往MQ里寫(xiě)入這個(gè)處理請(qǐng)求，等到采購(gòu)子系統(tǒng)恢復(fù)正常后，MQ通知采購(gòu)子系統(tǒng)處理這個(gè)更新操作。由于消息消費(fèi)掉以后不會(huì)再有通知了，采購(gòu)子系統(tǒng)處理過(guò)程中發(fā)生異常導(dǎo)致更新失敗，需要將問(wèn)題寫(xiě)入本地的日志庫(kù)，以便通知管理員做后續(xù)補(bǔ)償處理。就這樣通過(guò)各種辦法來(lái)達(dá)到數(shù)據(jù)的最終一致性即可。雖然聽(tīng)上去有點(diǎn)坑，但這就是解決方案。沒(méi)有其他更好的了?；蛘吒率『笾匦抡{(diào)用倉(cāng)庫(kù)子系統(tǒng)回滾入庫(kù)單和庫(kù)存數(shù)據(jù)，達(dá)到最終一致性！如圖所示：

名稱欄目：架構(gòu) － 分布式、服務(wù)化的ERP系統(tǒng)架構(gòu)設(shè)計(jì)
分享地址：http://jinyejixie.com/news/103256.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、網(wǎng)站策劃、網(wǎng)站改版、微信小程序、企業(yè)網(wǎng)站制作、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)