新型分布式ERP系統架構設計(jì)

ERP之痛

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

為(wèi)了提高(gāo)系統性能，我們也許會(huì)主動學習一些(xiē)互聯網公司的技(jì)術(shù)經驗，什麽高(gāo)并發、高(gāo)性能、大(dà)數(shù)據、讀寫分離等方案，發現自己根本無從下手。我們會(huì)覺得(de)因為(wèi)系統業務特點不一樣。ERP系統并發量不高(gāo)，主要是業務複雜，各種業務耦合度遠高(gāo)于那(nà)些(xiē)互聯網應用，不好做(zuò)拆分，數(shù)據查詢邏輯要遠比互聯網系統複雜，一個(gè)列表頁查詢出來(lái)的數(shù)據，往往需要關聯4、5張表才能得(de)到結果。有(yǒu)些(xiē)報表類的甚至更多(duō)。加上(shàng)各種業務操作(zuò)事務性、數(shù)據一緻性要求很(hěn)高(gāo)，很(hěn)多(duō)時(shí)候導緻我們措不及手，無法進一步優化系統。

曾幾何時(shí)，我也被這樣或那(nà)樣的理(lǐ)由所挫敗，認為(wèi)ERP系統非常特殊，無藥可(kě)救，可(kě)是後來(lái)。。。

我現在已經不這麽認為(wèi)了，似乎有(yǒu)了新的解決方案O(∩_∩)O哈哈~

曙光乍現

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

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

對于新架構的系統他有(yǒu)什麽優點呢?

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

其次，就是更新非常方便，各個(gè)子系統以後台微服務的方式存在。前台一個(gè)單獨的web項目，這個(gè)web項目調用後台這些(xiē)子系統的服務接口。這樣的設計(jì)，在某個(gè)業務子系統需要更新的時(shí)候，可(kě)以單獨更新。不用像以前那(nà)種單進程架構時(shí)，一個(gè)小(xiǎo)更新需要整個(gè)系統重啓，導緻用戶會(huì)話(huà)也丢失，用戶需要新登錄。而現在的這種設計(jì)就不會(huì)有(yǒu)這個(gè)問題。

系統整體(tǐ)設計(jì)

系統物理(lǐ)部署視(shì)圖

.

詳細設計(jì)

拆分應用層

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

微服務可(kě)以使用流行(xíng)的各種RPC框架，比如dubbo，可(kě)以支持多(duō)種調用協議Http、TCP等，這些(xiē)框架使得(de)編碼比較容易，框架封裝底層數(shù)據通(tōng)信細節，使得(de)客戶端執行(xíng)遠程方法如同執行(xíng)本地方法一樣簡單。

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

微服務結構，天生(shēng)很(hěn)好的支持系統更新升級操作(zuò)。比如财務模塊有(yǒu)個(gè)新需求需要上(shàng)線，我們隻需要替換财務模塊的服務重啓即可(kě)。這對已經登錄系統的用戶來(lái)說，沒有(yǒu)多(duō)少(shǎo)影(yǐng)響，不用重新登陸系統，其他模塊服務使用也不受影(yǐng)響。

拆分數(shù)據層

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

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

.

品類和(hé)倉庫表省略。。。

很(hěn)顯然，傳統一個(gè)數(shù)據庫中，我們隻需要簡單的join操作(zuò)，即可(kě)關聯這兩張表，外加關聯品類和(hé)倉庫表即可(kě)查詢出我們所要的數(shù)據。但(dàn)是現在我們的架構中，物料表和(hé)商品表不在同一個(gè)數(shù)據庫實例中，我們不能使用join操作(zuò)了，那(nà)我們該怎麽實現需求呢?

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

.

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

這時(shí)候有(yǒu)人(rén)又會(huì)問，那(nà)以後系統數(shù)據量、業務更大(dà)了，連你(nǐ)這個(gè)拆分成幾個(gè)數(shù)據庫還(hái)不夠用怎麽辦呢?我的方法是，可(kě)以基于拆分的數(shù)據庫，單獨每個(gè)庫可(kě)以做(zuò)讀寫分離、使用緩存等。甚至可(kě)以繼續拆分下去，将子系統再次拆分成多(duō)個(gè)孫子系統。視(shì)業務模塊繁忙程度而定。

報表系統

有(yǒu)人(rén)又會(huì)問，有(yǒu)些(xiē)列表查詢邏輯非常複雜，關聯十多(duō)張表，如果按上(shàng)述方法拆分數(shù)據，那(nà)簡直是災難啊!是的，你(nǐ)說的沒有(yǒu)錯。這種情況下我的方案是将這種更加複雜的報表級别的數(shù)據查詢展示需求，可(kě)以單獨做(zuò)個(gè)報表系統。報表數(shù)據庫設計(jì)采用數(shù)據倉庫方式。為(wèi)了更高(gāo)的讀取性能，我們可(kě)以将數(shù)據庫表設計(jì)成很(hěn)多(duō)冗餘字段方式也就是反範式設計(jì)，以及建立非常多(duō)的組合索引。

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

.

如果報表所需的數(shù)據要求實時(shí)的，我們可(kě)以讓ERP系統業務操作(zuò)時(shí)，觸發同步數(shù)據的請(qǐng)求，實時(shí)同步至報表庫。

分布式事務

也許有(yǒu)人(rén)又又問了，ERP系統很(hěn)多(duō)操作(zuò)都要求事務性，你(nǐ)拆分系統後怎麽實現事務性，保障數(shù)據一緻性呢?

這個(gè)問題很(hěn)好，也是我決定寫這篇文章前思考的最後一個(gè)問題。在微服務架構中，實現誇服務的事務并不容易，至少(shǎo)不像本地應用使用本地數(shù)據庫事務那(nà)樣方便，性能高(gāo)效，數(shù)據一緻性好。

也許你(nǐ)聽(tīng)過分布式事務這個(gè)概念。有(yǒu)兩種情景，一種是一個(gè)應用中使用多(duō)個(gè)數(shù)據庫，為(wèi)保障數(shù)據一緻性，需要使用分布式事務。還(hái)有(yǒu)一種情況就是針對我們這個(gè)架構而言的。微服務環境下的分布式事務，具體(tǐ)來(lái)說打個(gè)比方。采購入庫這個(gè)操作(zuò)設計(jì)在倉庫管理(lǐ)服務中。入庫後，需要更新采購子系統中的采購單中的入庫數(shù)量。這個(gè)過程要求數(shù)據一緻性，也就是采購單入庫成功後寫入了庫存表中的數(shù)量，同時(shí)要更新采購單表中的入庫數(shù)量。我們不能直接在倉庫服務中去訪問采購服務中的數(shù)據庫，必須通(tōng)過采購服務提供的服務接口才行(xíng)。如果這樣，我們怎麽能保證數(shù)據一緻性呢?因為(wèi)很(hěn)有(yǒu)可(kě)能庫存表寫入成功，但(dàn)調取采購服務寫入采購單數(shù)據時(shí)失敗了。可(kě)能是網絡問題原因導緻的，這樣數(shù)據就不一緻了。

在分布式事務技(jì)術(shù)中，有(yǒu)實現最終一緻性這麽一說，意思就是隻要我能保證兩邊數(shù)據最終實現了一緻性就行(xíng)，不一定要使用事務。這樣說來(lái)就有(yǒu)方案了。如倉庫子系統在處理(lǐ)采購入庫時(shí)需要增加入庫單數(shù)據和(hé)更新庫存數(shù)據等多(duō)個(gè)表。這多(duō)個(gè)表都在倉庫子系統中，我們可(kě)以使用一個(gè)本地事務來(lái)保證倉庫子系統中的表數(shù)據一緻性。然後調用采購子系統更新采購單裏的入庫數(shù)量。為(wèi)了防止這個(gè)過程突然中斷導緻調用失敗，我們考慮增加一個(gè)消息隊列中間(jiān)件如ActiveMQ。如果接口返回失敗我們就往MQ裏寫入這個(gè)處理(lǐ)請(qǐng)求，等到采購子系統恢複正常後，MQ通(tōng)知采購子系統處理(lǐ)這個(gè)更新操作(zuò)。由于消息消費掉以後不會(huì)再有(yǒu)通(tōng)知了，采購子系統處理(lǐ)過程中發生(shēng)異常導緻更新失敗，需要将問題寫入本地的日志(zhì)庫，以便通(tōng)知管理(lǐ)員做(zuò)後續補償處理(lǐ)。就這樣通(tōng)過各種辦法來(lái)達到數(shù)據的最終一緻性即可(kě)。雖然聽(tīng)上(shàng)去有(yǒu)點坑，但(dàn)這就是解決方案。沒有(yǒu)其他更好的了。或者更新失敗後重新調用倉庫子系統回滾入庫單和(hé)庫存數(shù)據，達到最終一緻性!如圖所示：

.

非常有(yǒu)幸能和(hé)大(dà)家(jiā)一起分享知識和(hé)經驗，正是由于大(dà)家(jiā)的無私分享，才讓我們得(de)以成長和(hé)進步，我最近幾年來(lái)都很(hěn)少(shǎo)分享東西，有(yǒu)時(shí)候是因為(wèi)工作(zuò)很(hěn)忙沒有(yǒu)時(shí)間(jiān)寫點東西，有(yǒu)時(shí)候也是因為(wèi)自己懶或是沒有(yǒu)什麽新東西可(kě)以分享給大(dà)家(jiā)的。最後也希望大(dà)家(jiā)對我的分享不足之處給予批評指正，一起進步!

更多(duō)erp相關，請(qǐng)點擊百度搜索：ERP