如何將“分布式”、“服務化”技術在開發ERP中實戰應用

來源:傲鵬ERP 發布時間:2019-01-05 10:13:17 點擊:45670次 作者:傲鵬erp文工


自主開發ERP系統,系統主要功能模塊無非是訂單管理、商品管理、生產采購、倉庫管理、物流管理、財務管理等等。作為一個管理系統,大家的一般開發習慣就是使用.Net或Java技術,建立一個單塊(單進程)架構的應用,只有一個SQLServer或MySql數據庫。然后在項目文件中分一下各個模塊,三層結構方式組織代碼編寫開發。最后測試,交付上線。開始因為數據量不大,系統性能還不錯,各種列表查詢,報表查詢,Excel數據導出功能等用的都很流暢。但是隨著公司業務發展,訂單量日積月累,后期各種業務部門的報表查詢、數據導出需求不斷增多,我們漸漸就感覺系統運行越來越慢。起初解決想法優化數據庫。我們可能的一種嘗試就是將數據庫單獨放置到一個服務器,實現數據庫和應用程序分離,或者是建立各種數據庫表索引,優化程序代碼等方法。經過這樣優化,系統某些功能可能性能的確大大提高,但是我們還是發現某些功能列表的數據查詢導出依然很慢,或者隨著數據量繼續積累,原來較快的列表導出功能,也愈來愈變得緩慢了。有人會說拆分。但ERP系統并發量不高,主要是業務復雜,各種業務耦合度遠高于那些互聯網應用,數據查詢邏輯要遠比互聯網系統復雜,一個列表頁查詢出來的數據,往往需要關聯4、5張表才能得到結果。有些報表類的甚至更多。加上各種業務操作事務性、數據一致性要求很高,無法拆分。

解決方法是采用互聯網思維我們不要去做一個大一統的系統了。把他們一個個小系統。然后通過系統接口讓這些小系統相互通信。這樣來組成一個大系統,具體來說就是“分布式”、“服務化”的互聯網思維。讓系統在架構設計上就是一個先天支持高度可擴展的系統。

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

1、解決系統的性能問題:

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

2、更新非常方便:

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

系統整體設計

系統物理部署視圖


如何在開發ERP中使用“分布式”、“服務化”技術

詳細設計

拆分應用層

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

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

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

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

拆分數據層

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

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

物料表:


如何在開發ERP中使用“分布式”、“服務化”技術

庫存表:


如何在開發ERP中使用“分布式”、“服務化”技術

品類和倉庫表省略。。。

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

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


如何在開發ERP中使用“分布式”、“服務化”技術

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

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

報表系統

有人又會問,有些列表查詢邏輯非常復雜,關聯十多張表,如果按上述方法拆分數據,那簡直是災難啊!是的,你說的沒有錯。這種情況下我的方案是將這種更加復雜的報表級別的數據查詢展示需求,可以單獨做個報表系統。報表數據庫設計采用數據倉庫方式。為了更高的讀取性能,我們可以將數據庫表設計成很多冗余字段方式也就是反范式設計,以及建立非常多的組合索引。

這種系統成功的關鍵就是數據和主ERP系統業務庫的同步問題了。一般可以寫一個定時同步程序,將ERP主業務系統的數據經過帥選、轉化等方式直接生成報表視圖所需的最終或中間數據,簡化關聯查詢。報表系統也可以采用微服務架構設計。如下圖所示:


如何在開發ERP中使用“分布式”、“服務化”技術

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

分布式事務

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

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

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

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


如何在開發ERP中使用“分布式”、“服務化”技術

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

傲鵬ERP系統二維碼

常見問答

  • 你們的ERP可以試用不?

    普及版可以試用,提供二個并發,不限用戶不限時間,普及版適用簡單生產的微小企業,協同版不提供試用,你可以申請顧問上門產品講解與演示,詳情請與在線客服聯系

  • 你們的erp支持多語言不?

    可以,要先做對照表

  • 我們怎樣判斷用什么ERP系統才是是最適合自身企業的?

    在選型過程中首先要知道自己要什么,這個需求要清楚,這是最核心的。然后自己預算多少錢,erp從幾萬到幾千萬,適合自己的就是最好的

  • 你們的ERP能自動備份?

    我們備份機制是建議在sql數據庫的機制,建議你備份要多重保障,數據庫備份,異地備份,手工備份等

  • 你們ERP是怎么收費的?

    我們收費是模塊+用戶許可+服務人天,費用從幾萬到百萬,根據客戶具體需求具體情況具體分析,可聯系顧問溝通13822145811 文工

  • 你們的erp系統安全不?

    相對安全,我們很多客戶都是走局域網,安全還是可控的

相關評論

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

    上erp真心不容易,傲鵬的顧問培訓我們好幾次,每次都是盯著我們來操作,折騰了好久才上線了,基礎資料太重要了,我們就費時間在這里,傲鵬的顧問還是不錯,沒有放棄我們,終于上線

  • 來自[東莞客戶]的點評

    我們公司是第一次上ERP,也咨詢了好幾家ERP廠商,傲鵬的工程師給人印象最深的就是專業和熱情,教了我們很多選型和上線時應該注意的問題,最終我們還是選擇了傲鵬,因為他們的專業,通過他...

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

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

  • 來自[中山客戶]的點評

    我上過好幾家的erp,接觸過好幾個顧問,傲鵬的顧問是全方面的,一個顧問就可以全部搞定,還能自己開發,還懂管理,真心不錯

  • 來自[東莞客戶]的點評

    我們東莞的,當時我們找了廣州傲鵬的來實施的,我知道東莞也有人,但朋友說廣州的顧問實施的項目不錯,我就找他人了,真心不錯

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

    我真心的說一下,傲鵬的界面真的不行,但功能不錯,邏輯性相當強,開關也太多了,完全要靠顧問,我一不小心設錯,就會出不來數據的

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

erp系統開發相關文章

万博娱乐平台可靠吗 江苏快3全天计划 南京麻将作弊器真的吗 一个人摆麻将捡对怎么玩 青海十一选五走势图电子 118免费高清图库 重庆幸运农场包赢 网上棋牌真的假的 江西优乐麻将官方下载 上海十一选五开奖公告 河北快三开奖结果顺序 一分彩在线人工计划 斗地主棋牌游戏赚钱 大庆52麻将下载苹果 网络捕鱼输了100万 天津11选5规则 河南快3彩票网