隨著近年來云計算,虛擬化技術(shù)的發(fā)展,以及傳統(tǒng)單體式架構(gòu)ERP系統(tǒng)暴露出的軟件復雜性,系統(tǒng)擴展性等問題,使得單體應用已很難適應或滿足對擴展性,可用性,靈活性要求較高的系統(tǒng)。采用新型微服務架構(gòu)的應用系統(tǒng)可以有效解決這些問題,微服務也可看作是一種軟件架構(gòu)風格,一個大型的系統(tǒng)應是由若干微服務構(gòu)成。在此架構(gòu)下,各個微服務能夠單獨部署,測試和運行,微服務之間耦合度是較為松散的。各個微服務模塊只關(guān)心該服務所關(guān)聯(lián)的業(yè)務,也即每個獨立的微服務模塊負責傳統(tǒng)ERP系統(tǒng)中一個或多個關(guān)聯(lián)的業(yè)務系統(tǒng)。 

【文章來源】：制造業(yè)自動化. 2020,42(06)CSCD

【文章頁數(shù)】：3 頁

【部分圖文】：

微服務架構(gòu)的系統(tǒng)整體設計

在ERP系統(tǒng)的使用初期階段，由于各個業(yè)務的數(shù)據(jù)量并不大，系統(tǒng)的各個模塊并沒有到滿載負荷，系統(tǒng)中的有關(guān)數(shù)據(jù)的查詢，以及業(yè)務的計算，歷史數(shù)據(jù)的處理等運行得很流暢。但是隨著功能的完善以及公司業(yè)務的發(fā)展，訂單量、庫存量的積累，以及后期各業(yè)務部門的數(shù)據(jù)查詢、數(shù)據(jù)導出需求的多樣性，使得系統(tǒng)運行得越來越慢，用戶的體驗越來越差。于是我們可能最先會想到的問題就是數(shù)據(jù)庫系統(tǒng)的負載問題，因為傳統(tǒng)ERP應用架構(gòu)都是將應用所涉及的數(shù)據(jù)存放在單一全局數(shù)據(jù)庫中，隨著業(yè)務數(shù)據(jù)的增加，最終導致數(shù)據(jù)庫系統(tǒng)的負荷滿載，針對這種情況，我們常用到的解決方案就是，優(yōu)化數(shù)據(jù)庫系統(tǒng)。我們可能會將應用和數(shù)據(jù)庫做物理分離，也可能會采用讀寫分離的方式緩解壓力，再或者是優(yōu)化數(shù)據(jù)庫等方法。但這些方法都只是緩兵之計，真正需要我們做的是如何將龐大的應用或數(shù)據(jù)分散化，再集中化，也就如何將復雜的系統(tǒng)化整為零。為了提升ERP系統(tǒng)的運行性能，負責底層架構(gòu)的部門通常也會主動從一些互聯(lián)網(wǎng)公司獲取技術(shù)經(jīng)驗，其中就包括一些解決性能和擴展性的方案，包括高并發(fā)、高性能、讀寫分離、數(shù)據(jù)庫分庫分表等方案。但會發(fā)現(xiàn)有些方案可能不適合企業(yè)信息系統(tǒng)，這是由于互聯(lián)網(wǎng)應用和傳統(tǒng)企業(yè)信息系統(tǒng)的業(yè)務有很大的不同。對于ERP系統(tǒng)來講，它的并發(fā)量并不高，主要的區(qū)別在于業(yè)務的復雜性，各種業(yè)務耦合度遠高于互聯(lián)網(wǎng)應用，對于這種復雜的數(shù)據(jù)依賴，想要做數(shù)據(jù)庫層面的分庫分表是比較困難的。ERP系統(tǒng)中的業(yè)務執(zhí)行邏輯比互聯(lián)網(wǎng)系統(tǒng)要復雜的多，單個頁面需要的數(shù)據(jù)，通常需要關(guān)聯(lián)的表高達兩張及以上。

在微服務架構(gòu)的設計過程中，服務的拆分是必不可少的，拆分的原則可以有多種方式，但大多數(shù)都是圍繞業(yè)務進行拆分的。但對于服務的拆分粒度，沒有一個統(tǒng)一的標準。所以按照業(yè)務劃分的各個微服務應做到高內(nèi)聚，盡量減少分布式事務。服務粒度劃分很難有統(tǒng)一的標準，當服務粒度過粗時，服務內(nèi)部的代碼容易產(chǎn)生耦合。服務的粒度也不是劃分的越細越好，拆的越細，系統(tǒng)之間的依賴關(guān)系就會變得復雜，出現(xiàn)問題時也很難以定位。對于服務的拆分粒度，應盡量保證服務本身所具有的業(yè)務獨立性和完整性，應盡量減少服務間的依賴，特別是多層依賴以及鏈式調(diào)用。5.2 服務間的通信


本文編號：3321941