erp系統(tǒng)構架

　　當今互聯(lián)網(wǎng)思維。泛普軟件問題不要再去做一個大一統(tǒng)的系統(tǒng)了。我們要分拆一個大系統(tǒng)，做成一個個小系統(tǒng)。然后通過系統(tǒng)接口讓這些小系統(tǒng)相互通信。這樣來組成一個大系統(tǒng)，具體來說就是“分布式”、“服務化”的互聯(lián)網(wǎng)思維。讓系統(tǒng)在架構設計上就是一個先天支持高度可擴展的系統(tǒng)。

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

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

　　首先，也是最重要的就是解決系統(tǒng)的性能問題。以往數(shù)據(jù)庫實例只有一個，沒法擴展出多個實例，以便在性能受限的情況下依靠增加數(shù)據(jù)庫實例來達到負載均衡。也許有人會說可以使用讀寫分離方案，但是因為ERP系統(tǒng)的特點，這個方案很多時候不現(xiàn)實。比如說操作庫存的時候，你不能從讀庫里讀庫存，然后在寫庫里寫入庫存。因為主從復制會有時效性，寫入的庫存并不能馬上寫入從庫。這樣的場景在ERP中也有多處。何況寫庫不能擴展，只能有一個。而新設計方案是寫庫是分離的，每個子系統(tǒng)有自己的數(shù)據(jù)庫。

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

　　泛普erp系統(tǒng)整體架構設計

　　詳細設計

　　拆分應用層

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

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

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

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

　　拆分數(shù)據(jù)層

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

　　分布式事務

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

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

　　也許你聽過分布式事務這個概念。有兩種情景，一種是一個應用中使用多個數(shù)據(jù)庫，為保障數(shù)據(jù)一致性，需要使用分布式事務。還有一種情況就是針對我們這個架構而言的。微服務環(huán)境下的分布式事務，具體來說打個比方。采購入庫這個操作設計在倉庫管理服務中。入庫后，需要更新采購子系統(tǒng)中的采購單中的入庫數(shù)量。這個過程要求數(shù)據(jù)一致性，也就是采購單入庫成功后寫入了庫存表中的數(shù)量，同時要更新采購單表中的入庫數(shù)量。我們不能直接在倉庫服務中去訪問采購服務中的數(shù)據(jù)庫，必須通過采購服務提供的服務接口才行。如果這樣，我們怎么能保證數(shù)據(jù)一致性呢?因為很有可能庫存表寫入成功，但調(diào)取采購服務寫入采購單數(shù)據(jù)時失敗了?？赡苁蔷W(wǎng)絡問題原因導致的，這樣數(shù)據(jù)就不一致了。

　　在分布式事務技術中，有實現(xiàn)最終一致性這么一說，意思就是只要我能保證兩邊數(shù)據(jù)最終實現(xiàn)了一致性就行，不一定要使用事務。這樣說來就有方案了。如倉庫子系統(tǒng)在處理采購入庫時需要增加入庫單數(shù)據(jù)和更新庫存數(shù)據(jù)等多個表。這多個表都在倉庫子系統(tǒng)中，我們可以使用一個本地事務來保證倉庫子系統(tǒng)中的表數(shù)據(jù)一致性。然后調(diào)用采購子系統(tǒng)更新采購單里的入庫數(shù)量。為了防止這個過程突然中斷導致調(diào)用失敗，我們考慮增加一個消息隊列中間件如ActiveMQ。如果接口返回失敗我們就往MQ里寫入這個處理請求，等到采購子系統(tǒng)恢復正常后，MQ通知采購子系統(tǒng)處理這個更新操作。由于消息消費掉以后不會再有通知了，采購子系統(tǒng)處理過程中發(fā)生異常導致更新失敗，需要將問題寫入本地的日志庫，以便通知管理員做后續(xù)補償處理。就這樣通過各種辦法來達到數(shù)據(jù)的最終一致性即可。雖然聽上去有點坑，但這就是解決方案。沒有其他更好的了。或者更新失敗后重新調(diào)用倉庫子系統(tǒng)回滾入庫單和庫存數(shù)據(jù)，達到最終一致性!

發(fā)布：2021-05-08 13:54 編輯：泛普軟件 · hujian [打印此頁] [關閉]

相關欄目：