新型分布式ERP系統架構設計

来源:傲鹏ERP 发布时间:2019-01-03 19:42:05 点击:8833次 作者:傲鹏erp文工


ERP之痛

起初,因为数据量不大,系统性能还不错,各种列表查询,报表查询,Excel数据导出功能等用的都很流畅。但是随着公司业务发展,订单量日积月累,后期各种业务部门的报表查询、数据导出需求不断增多,我们渐渐就感觉系统运行越来越慢。于是我们可能最先想到的解決方案就是,优化系统瓶颈数据库这个大头。我们可能的一种尝试就是将数据库单独放置到一个服务器,实现数据库和应用程序分离,或者是建立各种数据库表索引,优化程序代码等方法。经过这样一番研究优化,系统某些功能可能性能的确大大提高,但是我们还是发现某些功能列表的数据查询导出依然很慢,或者随着数据量继续积累,原来较快的列表导出功能,也愈来愈变得缓慢了。我们用尽各种办法,最后也达不到理想的系统性能速度。

爲了提高系統性能,我們也許會主動學習一些互聯網公司的技術經驗,什麽高並發、高性能、大數據、讀寫分離等方案,發現自己根本無從下手。我們會覺得因爲系統業務特點不一樣。ERP系統並發量不高,主要是業務複雜,各種業務耦合度遠高于那些互聯網應用,不好做拆分,數據查詢邏輯要遠比互聯網系統複雜,一個列表頁查詢出來的數據,往往需要關聯4、5張表才能得到結果。有些報表類的甚至更多。加上各種業務操作事務性、數據一致性要求很高,很多時候導致我們措不及手,無法進一步優化系統。

曾幾何時,我也被這樣或那樣的理由所挫敗,認爲ERP系統非常特殊,無藥可救,可是後來。。。

我现在已经不这么认为了,似乎有了新的解決方案O(∩_∩)O哈哈~

曙光乍現

在敘述具體方案前,先說下自己的想法。我首先覺得我們做ERP系統前,就得有當今互聯網思維。我們不要再去做一個大一統的系統了。我們要分拆一個大系統,做成一個個小系統。然後通過系統接口讓這些小系統相互通信。這樣來組成一個大系統,具體來說就是“分布式”、“服務化”的互聯網思維。讓系統在架構設計上就是一個先天支持高度可擴展的系統。

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

對于新架構的系統他有什麽優點呢?

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

其次,就是更新非常方便,各個子系統以後台微服務的方式存在。前台一個單獨的web項目,這個web項目調用後台這些子系統的服務接口。這樣的設計,在某個業務子系統需要更新的時候,可以單獨更新。不用像以前那種單進程架構時,一個小更新需要整個系統重啓,導致用戶會話也丟失,用戶需要新登錄。而現在的這種設計就不會有這個問題。

系統整體設計

系統物理部署視圖


分布式ERP系统架构设计

.

詳細設計

拆分應用層

拆分應用層,是践行“微服务”架构的理念。将原来大而全的单进程架构按照业务模块拆分成可独立部署的应用程序,以此来达到平滑系统更新、升级、方便负载扩展的目的。具体来说,技术上可以使用restfull风格的接口,也可以使用像java中dubbo框架方式来简化开发复杂度。ERPWeb端或其他移动端也是一个单独的应用充当表现层。非常薄,只是简单的接受参数,调取后台其他各种微服务程序的接口获取所需展示的数据。微服务充当业务逻辑层,每个微服务都是可独立部署上线的程序,对外提供数据访问接口。

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

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

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

拆分數據層

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

我們先來看一個典型數據層模塊耦合問題。需求是展示物料庫存,列表字段:物料編號、物料名稱、品類、倉庫、數量


分布式ERP系统架构设计

.

品類和倉庫表省略。。。

很顯然,傳統一個數據庫中,我們只需要簡單的join操作,即可關聯這兩張表,外加關聯品類和倉庫表即可查詢出我們所要的數據。但是現在我們的架構中,物料表和商品表不在同一個數據庫實例中,我們不能使用join操作了,那我們該怎麽實現需求呢?

新的架構,只允許我們通過對方的服務接口來獲取數據,不能直接關聯對方服務的私有數據庫。至少從架構上,服務化角度來說不能直接訪問對方服務的數據庫。這種情況下,假設web模塊子系統調用倉庫子系統來獲取數據,則我們需要在倉庫模塊中創建一個service方法來裝配這些數據。然後返回給web子系統。如下圖所示,倉庫管理方法首先獲取本地庫存表的物料編碼、和倉庫表的倉庫名稱字段信息,並且分頁完後最終准備返回20條數據到Web模塊前,將這20條數據中的物料ID作爲參數請求商品模塊子系統,商品子系統返回這20個物料ID相關的商品信息給到倉庫管理模塊,然後倉庫管理模塊重新組裝上列表所需的物料名稱和品類兩個字段數據,實現最終要返回給Web子系統的數據。


分布式ERP系统架构设计

.

也許你會說,這太麻煩了,這種方法的性能肯定沒有直接join來的高,解決不了性能問題。咋看起來好像是這麽回事,但是仔細考慮看看,在系統並發量低、數據量小、業務不算繁忙的環境下,的確性能還不如傳統一個數據中join方式來的快速。但我們想想以後吧!我們現在的架構設計是將一個數據庫拆成多個數據庫,每個數據庫可以運行在單獨的服務器上去,這樣以後就能負載數據庫的壓力了。整體來說這樣才能不會讓數據庫成爲未來業務繁忙時候的性能瓶頸了。想想都覺得讓人興奮不已,是不是?

這時候有人又會問,那以後系統數據量、業務更大了,連你這個拆分成幾個數據庫還不夠用怎麽辦呢?我的方法是,可以基于拆分的數據庫,單獨每個庫可以做讀寫分離、使用緩存等。甚至可以繼續拆分下去,將子系統再次拆分成多個孫子系統。視業務模塊繁忙程度而定。

報表系統

有人又会问,有些列表查询逻辑非常复杂,关联十多张表,如果按上述方法拆分数据,那简直是灾难啊!是的,你说的没有错。这种情况下我的方案是将这种更加复杂的报表级别的数据查询展示需求,可以单独做个報表系統。报表数据库设计采用数据仓库方式。为了更高的读取性能,我们可以将数据库表设计成很多冗余字段方式也就是反范式设计,以及建立非常多的组合索引。

这种系统成功的关键就是数据和主ERP系统业务库的同步问题了。一般可以写一个定时同步程序,将ERP主业务系统的数据经过帅选、转化等方式直接生成报表视图所需的最终或中间数据,简化关联查询。報表系統也可以采用微服务架构设计。如下图所示:


分布式ERP系统架构设计

.

如果報表所需的數據要求實時的,我們可以讓ERP系統業務操作時,觸發同步數據的請求,實時同步至報表庫。

分布式事務

也許有人又又問了,ERP系統很多操作都要求事務性,你拆分系統後怎麽實現事務性,保障數據一致性呢?

這個問題很好,也是我決定寫這篇文章前思考的最後一個問題。在微服務架構中,實現誇服務的事務並不容易,至少不像本地應用使用本地數據庫事務那樣方便,性能高效,數據一致性好。

也许你听过分布式事務这个概念。有两种情景,一种是一个应用中使用多个数据库,为保障数据一致性,需要使用分布式事務。还有一种情况就是针对我们这个架构而言的。微服务环境下的分布式事務,具体来说打个比方。采购入库这个操作设计在仓库管理服务中。入库后,需要更新采购子系统中的采购单中的入库数量。这个过程要求数据一致性,也就是采购单入库成功后写入了库存表中的数量,同时要更新采购单表中的入库数量。我们不能直接在仓库服务中去访问采购服务中的数据库,必须通过采购服务提供的服务接口才行。如果这样,我们怎么能保证数据一致性呢?因为很有可能库存表写入成功,但调取采购服务写入采购单数据时失败了。可能是网络问题原因导致的,这样数据就不一致了。

在分布式事務技术中,有实现最终一致性这么一说,意思就是只要我能保证两边数据最终实现了一致性就行,不一定要使用事务。这样说来就有方案了。如仓库子系统在处理采购入库时需要增加入库单数据和更新库存数据等多个表。这多个表都在仓库子系统中,我们可以使用一个本地事务来保证仓库子系统中的表数据一致性。然后调用采购子系统更新采购单里的入库数量。为了防止这个过程突然中断导致调用失败,我们考虑增加一个消息队列中间件如ActiveMQ。如果接口返回失败我们就往MQ里写入这个处理请求,等到采购子系统恢复正常后,MQ通知采购子系统处理这个更新操作。由于消息消费掉以后不会再有通知了,采购子系统处理过程中发生异常导致更新失败,需要将问题写入本地的日志库,以便通知管理员做后续补偿处理。就这样通过各种办法来达到数据的最终一致性即可。虽然听上去有点坑,但这就是解決方案。没有其他更好的了。或者更新失败后重新调用仓库子系统回滚入库单和库存数据,达到最终一致性!如图所示:


分布式ERP系统架构设计

.

非常有幸能和大家一起分享知識和經驗,正是由于大家的無私分享,才讓我們得以成長和進步,我最近幾年來都很少分享東西,有時候是因爲工作很忙沒有時間寫點東西,有時候也是因爲自己懶或是沒有什麽新東西可以分享給大家的。最後也希望大家對我的分享不足之處給予批評指正,一起進步!

更多erp相關,請點擊百度搜索:ERP

傲鹏ERP系统二维码

常見問答

  • 我們公司很想上erp,但怕選錯了

    15年以上的erp公司都不錯了,經過這麽多年沈澱,都不錯的,你可以來我們公司多了解一下

  • 你們的crm能與erp同步?

    可以的,我們的erp與crm已經集成了,雙向同步

  • 你們傲鵬erp允許我們自己修改不?

    傲鵬erp是自定義平台,用戶可以自己修改表單,字段,流程

  • 你們的ERP可以租用不?

    可以,軟件款可以分期,也可以租用,也可以買斷

  • 你們的erp能實現阿米巴式獨立核算不?

    可以,1.你們要先上好erp,數據准確後,我們采用BI系統來實現阿米巴經營分析系統,詳情致電顧問13822145811

  • 你們的erp可以上雲?

    可以的,支持公有雲,私有雲,混合雲

相關評論

  • 來自[江蘇客戶]的點評

    傲鵬ERP自定義平台不錯,懂數據庫的人都能自己弄了。

  • 來自[浙江客戶]的點評

    現在傳統的制造業的ERP只是強調內部的制造管理,關于客戶管理這快比較弱,我公司是個以業務牽頭的公司,客戶的管理和跟進是我們目前管理的重點。如果用兩套系統管理,那麽在CRM下一次單,...

  • 來自[廣州客戶]的點評

    傲鵬的顧問幫我們把舊系統的基礎資料全部倒入過來了,還幫我們導入了很多舊系統的單據。這下極大地減輕了我們前期數據錄入的負擔。給傲鵬的顧問點個贊。

  • 來自[浙江客戶]的點評

    傲鵬ERP加上BPM後,真正做到全面流程化了

  • 來自[黑龍江客戶]的點評

    傲鵬的售後香工挺負責任的,下班後找他,他也會幫我處理

  • 來自[廣州客戶]的點評

    傲鵬ERP很好的,很適合我們制造型企業

上一篇:已經沒有了下一篇:已經沒有了