基于廣東電網(wǎng)資產(chǎn)管理系統(tǒng)模塊化部署與無共享架構的研究

摘要：廣東電網(wǎng)公司資產(chǎn)管理系統(tǒng)是全省大集中系統(tǒng)，橫跨電網(wǎng)計劃、物資采購、項目建設、設備運行維護、退役報廢的全過程管理，于2010年上線。隨著業(yè)務量與日俱增及業(yè)務的不斷更新，各模塊之間的耦合度越來越高，原系統(tǒng)集群架構采用集中式部署，Session共享，單節(jié)點性能故障易在集群中擴散；同時單節(jié)點程序代碼包越來越大，單個server代碼內存占用率高、利用率低等問題日益凸顯。針對系統(tǒng)部署架構進行了模塊化部署改造和無共享架構的應用研究。實驗表明，新的部署架構提高了可擴展性、部署靈活性、Web吞吐量和訪問性能，優(yōu)化了資產(chǎn)管理系統(tǒng)部署架構，為公司其他應用系統(tǒng)模塊化部署改造和無共享架構的應用提供了經(jīng)驗。

關鍵詞：模塊化部署；無共享架構；分布式系統(tǒng)；廣東電網(wǎng)公司資產(chǎn)管理系統(tǒng)

作者簡介：唐亮亮（1985-），男，廣西桂林人，廣東電網(wǎng)公司信息中心，助理工程師。（廣東 廣州 510600）

中圖分類號：TM73 文獻標識碼：A 文章編號：1007-0079（2014）15-0220-04

以往集群架構采用Session共享模式的設計，通過集群節(jié)點間Session復制方式實現(xiàn)，而Session復制的成本隨著集群服務器的數(shù)量增加線性增長，部署的集群服務器越多，集群服務器的Session復制代價越大。為滿足系統(tǒng)靈活部署，減少系統(tǒng)模塊間的相互影響，提升系統(tǒng)開發(fā)效率和整體性能，為使資產(chǎn)管理系統(tǒng)設計更加符合SOA服務設計理念，采用了無共享架構（Shared Nothing Architecture，以下簡稱SNA）。它是一個分布式的架構，每個節(jié)點都是獨立的，不需要保存狀態(tài)信息。由SNA集中保存狀態(tài)信息在緩存或數(shù)據(jù)庫中，滿足Session不共享的無狀態(tài)服務、與服務請求者到服務提供者的綁定與服務之間松耦合的設計要求。SNA架構思想無論對企業(yè)應用還是大型互聯(lián)網(wǎng)站都極大提高了web應用的吞吐量和性能。

在廣東電網(wǎng)業(yè)務應用不斷增長的背景下，需要一種能適應系統(tǒng)快速升級和功能擴展系統(tǒng)架構，同時保障系統(tǒng)性能不因業(yè)務增長而受影響。結合資產(chǎn)管理系統(tǒng)的業(yè)務功能模塊多、系統(tǒng)功能變更需求多等特點，本文探索了系統(tǒng)模塊化部署與無共享架構在資產(chǎn)管理系統(tǒng)上的應用，使資產(chǎn)管理系統(tǒng)性能提升，各子系統(tǒng)松耦合，各子系統(tǒng)運行更穩(wěn)定，滿足SOA設計理念。

一、資產(chǎn)管理系統(tǒng)現(xiàn)狀分析

1.資產(chǎn)管理系統(tǒng)子系統(tǒng)依賴關系及部署現(xiàn)狀

圖1的箭頭方向表示依賴方向，藍色表示單向依賴，黑色表示雙向依賴。如圖1表示物資子系統(tǒng)依賴項目子系統(tǒng)的7個接口，項目子系統(tǒng)依賴物資子系統(tǒng)的21個接口。從圖1可以看出，目前資產(chǎn)管理系統(tǒng)各子系統(tǒng)之間是網(wǎng)狀依賴的關系。

圖2是資產(chǎn)管理系統(tǒng)集中式的部署邏輯結構圖。資產(chǎn)管理系統(tǒng)的項目、物資、設備、財務等子系統(tǒng)代碼包發(fā)布在同一個Weblogic域中，資產(chǎn)管理系統(tǒng)應用采用集中式集群部署方式，部署9個節(jié)點，單個域發(fā)布全部資產(chǎn)系統(tǒng)代碼。

2.目前的問題

從目前資產(chǎn)管理系統(tǒng)的現(xiàn)狀可得知，在這種復雜的網(wǎng)狀依賴關系的背景下，整個資產(chǎn)系統(tǒng)部署在單個weblogic域中存在以下問題：

（1）可靠性方面：系統(tǒng)功能集中在單個域，故障影響面大。當其中一個子系統(tǒng)某個代碼存在性能缺陷導致宕機，不僅該子系統(tǒng)會產(chǎn)生故障，整個集群其他子系統(tǒng)也會發(fā)生同樣的故障。

（2）部署成本方面：在集群部署中，Session復制的成本隨著集群服務器數(shù)量增加而線性增長，部署的集群節(jié)點數(shù)越多，集群服務器的壓力越大。而SNA的實現(xiàn)與服務器的數(shù)量無關系。部署的服務器越多，SNA的優(yōu)勢越明顯。

（3）資源利用率：代碼包在域內內存占有率高，穩(wěn)定性差、影響響應性能。由于子系統(tǒng)間業(yè)務依賴關系較復雜，系統(tǒng)功能集中在單個域中，每個子系統(tǒng)的代碼需要冗余其他子系統(tǒng)的代碼，才能保證子系統(tǒng)間相互調用接口，代碼的大量冗余，導致域內內存占有率高。

（4）開發(fā)效率：所有業(yè)務模塊的代碼集中，影響開發(fā)效率，代碼保存、編譯、發(fā)布等待時間過長，排錯復雜。通常編譯一次全部系統(tǒng)代碼，并重啟服務需要近2個小時，而在開發(fā)階級各業(yè)務模塊重新編譯或重啟服務卻不可避免，當其中一個業(yè)務模塊需要重新編譯和重啟服務，必然會干擾其他業(yè)務模塊的開發(fā)工作進展。

（5）可擴展性：SOA架構的五個特征是可重用、松耦合、明確定義的接口、無狀態(tài)的服務設計、基于開放的標準，而目前各模塊之間是緊耦合，且集群不符合SOA架構的部分特征。

二、模塊化部署與無共享架構應用研究

1.無共享架構技術

無共享架構（Shared Nothing Architecture，以下簡稱SNA）是一個分布式的架構，每個節(jié)點都是獨立的，不需要保存狀態(tài)信息。由SNA系統(tǒng)集中保存狀態(tài)信息在緩存或數(shù)據(jù)庫中。SNA在web層的集群主要依賴的技術是負載均衡和session共享。

session的共享方面，如在應用服務層處理，各節(jié)點的session復制將會極大影響性能。替換的一種可行方案是保持每個節(jié)點的無狀態(tài)性，不再使用session來保持全局狀態(tài)。用戶唯一標識從 cookie取得，session放在分布式cache或是數(shù)據(jù)庫中，只要通過用戶唯一標識，無論在哪個服務器上都能夠獲取到該用戶的session信息。SNA實現(xiàn)原理如圖3所示：

（1）當客戶端發(fā)起請求時會被SNAfilter（SNA過濾器）攔截，SNAfilter將原始請求對象的獲取會話的方法進行重寫，并封裝為新的請求對象。

（2）WebApp應用在進行會話的查詢和存儲信息的操作（SessionOperation）時會從SNA服務器查找和存儲信息。

（3）此外，為了提高性能，服務器對信息進行了緩存（Local-Cache），避免每次訪問都從SNA服務器中讀取信息。

由此可見，無共享架構（SNA）有如下優(yōu)勢：

第一，性能優(yōu)勢：各應用服務節(jié)點無狀態(tài)，因此可以不斷增加服務節(jié)點來滿足性能需求，解決了因用戶增加而帶來的服務器壓力問題。

第二，穩(wěn)定性優(yōu)勢：由于可以部署多個無狀態(tài)的服務，因此當某個服務器出現(xiàn)宕機等情況，用戶的請求可以轉發(fā)到其他節(jié)點上，不會有任何信息丟失，系統(tǒng)的穩(wěn)定性得到了極大提高。

第三，成本優(yōu)勢：SNA的實現(xiàn)對系統(tǒng)的實現(xiàn)影響接近于0，部署簡單，可以以極低的成本完成。

第四，分布式部署優(yōu)勢：由于狀態(tài)統(tǒng)一保存，因此可以接入不同的子系統(tǒng)，安全、徹底地解決了大集中部署帶來的Session共享問題。

第五，成熟的行業(yè)應用案例：新浪、阿里巴巴等大型互聯(lián)網(wǎng)網(wǎng)站都在大規(guī)模應用SNA。

2.系統(tǒng)模塊化改造與無共享架構應用

（1）資產(chǎn)管理系統(tǒng)模塊化改造，首先需要進行資產(chǎn)管理系統(tǒng)拆分。將系統(tǒng)按業(yè)務拆分成多個子系統(tǒng)，每個子系統(tǒng)部署獨立的服務節(jié)點，同時子系統(tǒng)拆分本著一體化的設計原則，以保證系統(tǒng)業(yè)務邏輯清晰，避免一個業(yè)務數(shù)據(jù)邏輯在子系統(tǒng)間多次交互，通信中以不處理復雜的計算為前提，進行資產(chǎn)管理系統(tǒng)拆分和系統(tǒng)集成。資產(chǎn)管理系統(tǒng)拆分以項目、物資、設備、財務等主營業(yè)務為拆分的基礎進行拆分。按照資產(chǎn)現(xiàn)有業(yè)務耦合程度確定子系統(tǒng)拆分為投資計劃、項目、物資、供應商、財務、預算、設備及基礎平臺等10個子系統(tǒng)。

通過對資產(chǎn)管理系統(tǒng)進行模塊化改造，預期會達到以下效果：

第一，開發(fā)高效率：各子系統(tǒng)開發(fā)人員只需更新和編碼各自子系統(tǒng)的代碼，避免長時間等待代碼更新編譯和本地weblogic服務啟動，從而提高開發(fā)效率。

第二，系統(tǒng)高可用：各子系統(tǒng)的部署、發(fā)布、故障互不影響，系統(tǒng)發(fā)布期間可單獨停止某個子系統(tǒng)，進行更新并重新啟動，避免影響其他子系統(tǒng)的正常運行。如果某個子系統(tǒng)宕機，其它子系統(tǒng)也可以正常運行，從而避免某個子系統(tǒng)的問題造成整個資產(chǎn)管理系統(tǒng)宕機。

（2）資產(chǎn)管理系統(tǒng)應用主從方式SNA共享架構。在進行資產(chǎn)管理系統(tǒng)模塊化改造的同時，在資產(chǎn)管理系統(tǒng)上應用主從方式的SNA共享架構，其SNA邏輯架構如圖4所示：

SNA服務通過VIP（虛擬IP）對外提供服務，在SNA的主服務與備份之間建立心跳檢測，當主服務宕機時備份服務立即接管VIP，對外提供服務，實現(xiàn)故障轉移。當主服務修復后，重新加入，作為當前主服務的備份，依此反復。

Keepalived是Linux下面實現(xiàn)備份路由的高可靠性運行件。基于Keepalived設計的服務模式能夠真正做到主服務器和備份服務器故障時IP瞬間無縫交接。使用Keepalived的虛擬IP（VIP）來對外提供服務，客戶端始終連接VIP。SNA使用Master Slave模式（主從模式），服務啟動時VIP綁定在SNA主服務上，并對外提供服務，SNA從服務作為當前主服務的熱備，并且從服務并不提供數(shù)據(jù)讀取服務，當主服務掛掉，從服務正常時，從服務接管虛擬IP，并提供服并發(fā)送SLAVEOF NO ONE關閉主從復制功能，同時自己提升為主服務，當（原）主服務修復重新加入時，作為當前主服務的從服務，提供備份功能，依此反復，實現(xiàn)SNA服務的故障轉移。

3.系統(tǒng)模塊化部署

在資產(chǎn)管理系統(tǒng)以項目、物資、設備、財務等主要業(yè)務基礎進行拆分后，其模塊化部署邏輯架構，如圖5模塊化部署邏輯圖。系統(tǒng)拆分后的模塊化集成部署：各子系統(tǒng)部署獨立的weblogic域，每個域由一個或多個weblogic Server集群，并共用同一數(shù)據(jù)庫；資產(chǎn)管理系統(tǒng)增加主、從SNA共享緩存服務器，采用Redis作為緩存存儲系統(tǒng)；資產(chǎn)管理系統(tǒng)建立集群以滿足高并發(fā)需求；通過F5實現(xiàn)負載均衡，AdminServer和受管Server均部署在管理服務器上；通過F5將請求轉發(fā)關聯(lián)各模塊子系統(tǒng)。

從圖5模塊化部署邏輯圖中可以看出，資產(chǎn)管理系統(tǒng)未來擴展新業(yè)務功能，可以很方便地橫向擴展，增加獨立的weblogic域，且不影響原有的業(yè)務子系統(tǒng)。

基于資產(chǎn)管理系統(tǒng)的Session緩存服務應用實驗。

集群環(huán)境中需實現(xiàn)多個應用對Session的共享，以達到能夠共用Session中存儲內容的目的。實驗將借助Redis緩存服務能夠將Session緩存在服務器內存中，對session進行統(tǒng)一管理，所有應用都訪問和修改緩存中的Session，而無需在Session發(fā)生改變時，為每一個應用都進行Session的拷貝。同時由于借助Redis緩存Session時，Session被存儲于內存中，訪問和修改的速度較存儲于數(shù)據(jù)庫中要更快。

表1 基于資產(chǎn)管理系統(tǒng)的Session緩存服務應用實驗

用例名稱 事務 在線用戶 事務交易時間（秒） 響應指標

MIX AVG MAX

拆分前

（集中式集群） 登錄 1 0.329 0.393 1.291 ≤2秒

50 0.366 2.836 9.302 ≤3秒

100 0.564 3.134 9.642 ≤4秒

200 0.765 3.836 12.916 ≤5秒

訪問菜單管理 1 0.38 0.426 0.684 ≤2秒

50 0.145 2.835 7.653 ≤3秒

100 0.123 3.574 13.492 ≤4秒

200 0.039 4.997 13.239 ≤5秒

訪問桌面窗口管理 1 0.328 0.379 0.69 ≤2秒

50 0.246 2.925 6.695 ≤3秒

100 0.298 3.993 8.904 ≤4秒

200 0.031 4.807 9.935 ≤5秒

拆分后

（基于Redis緩存服務的無共享架構） 登錄 1 0.262 0.371 1.241 ≤2秒

50 0.301 1.771 5.732 ≤3秒

100 0.513 2.818 9.876 ≤4秒

200 0.665 3.344 12.758 ≤5秒

訪問菜單管理 1 0.108 0.14 0.23 ≤2秒

50 0.059 0.18 3.336 ≤3秒

100 0.071 0.254 4.127 ≤4秒

200 0.01 1.664 8.695 ≤5秒

訪問桌面窗口管理 1 0.029 0.041 0.109 ≤2秒

50 0.024 0.06 1.754 ≤3秒

100 0.023 0.068 1.874 ≤4秒

200 0.025 0.072 2.588 ≤5秒

表1中數(shù)據(jù)實驗表明，基于Redis緩存服務的無共享架構的應用時事務的響應時間優(yōu)于集中式部署下的訪問。

4.系統(tǒng)模塊化部署改造與無共享架構應用的效果

資產(chǎn)管理系統(tǒng)進行模塊化部署改造，并應用無共享架構后，經(jīng)過測試驗證，系統(tǒng)在可靠性、可擴展性、資源利用率、開發(fā)效率等方面均有顯著改善和提高。

（1）其中資源利使用狀況改善。

應用層內存資源利用率提高：86.26%（拆分后）-43.01%（拆分前）=43.25%

DB CPU高峰期平均使用率降低：優(yōu)化前高峰期平均使用率-優(yōu)化后高峰期平均使用率=（35%+65%/2）-（8%+30%）/2=31%

應用架構部署調整：代碼占用內存大幅度減少，內存利用率提高顯著，如表2所示：

表2 應用架構部署調整前后內存利用率

分配總內存（M） 代碼占總內存（M） 運行可使用內存（M）=分配總內存-代碼占用內存 利用率

拆分前 71680.00 40852 30828 43.01%

拆分后 94720.00 13016 81704 86.26%

（2）開發(fā)效率提高。

開發(fā)效率提高：集中式部署（人力投入×工時投入×每月下載編次數(shù)）-模塊化部署（人力投入×工時投入×每月下載編次數(shù)）/集中式部署（人力投入×工時投入×每月下載編次數(shù)）×100%=（200×2×2）-（80×0.5×2）/（200×2×2）×100%=80%

表3 代碼下載、編譯的（等待）成本

人力投入

（人） 工時投入

（小時） 每月平均代碼下載、編譯次數(shù)

（經(jīng)驗值） 運維工時

（小時）

集中式部署 200 2 2 800

模塊化部署 80 0.5 2 80

（3）系統(tǒng)可靠性提高：通過廣東電網(wǎng)公司資產(chǎn)系統(tǒng)模塊化部署，達到了如下效果：

1）子系統(tǒng)之間直接調用業(yè)務節(jié)點接口集成，降低子系統(tǒng)間耦合度。

2）通過SNA服務器共享Session，避免節(jié)點間相互復制Session，有效解決了Session保持問題，解決了分布式系統(tǒng)的Session共享；因此，子系統(tǒng)業(yè)務代碼單獨部署成為接口服務節(jié)點供其他子系統(tǒng)調用集成，為系統(tǒng)功能擴展提供架構保障。

3）子系統(tǒng)對外接口服務可獨立打包，不依賴于子系統(tǒng)其他原有業(yè)務代碼，每個子系統(tǒng)應用節(jié)點發(fā)布全部接口服務包，子系統(tǒng)調用接口服務可以跟調用本地代碼一樣方便。

4）資產(chǎn)管理系統(tǒng)模塊化部署可有效阻止故障在節(jié)點間蔓延。故障蔓延指集群中一個節(jié)點發(fā)生性能缺陷時導致宕機，相應的性能缺陷請求轉移到其他節(jié)點會依次宕機。系統(tǒng)拆分前集中式部署，共用9節(jié)點服務器進行集群，有蔓延時會導致所有依次宕機；系統(tǒng)拆分后進行模塊化部署，假定每個子系統(tǒng)采用2個服務器集群（實際中有子系統(tǒng)超過2個節(jié)點的），共18個節(jié)點，故障蔓延時只造成子系統(tǒng)內部宕機。故障蔓延度：故障節(jié)點數(shù)/節(jié)點總數(shù)×100%。如表4對比拆分前后兩種部署方式的故障蔓延度。

表4 故障蔓延度

節(jié)點總數(shù)

（個） 故障節(jié)點數(shù)

（個） 故障蔓延節(jié)點數(shù)

（個） 故障蔓延度

（%）

集中式部署 9 1 9 100%

模塊化部署 18 1 2 11%

三、結論

從資產(chǎn)管理系統(tǒng)模塊化部署改造和無共享架構應用的效果分析得出，通過將集中式部署的資產(chǎn)管理系統(tǒng)拆分并模塊化部署改造，同時采用無共享架構技術極大提高了系統(tǒng)的擴展性、部署靈活性、系統(tǒng)性能，有效提高了應用系統(tǒng)吞吐量和訪問性能，優(yōu)化了廣東電網(wǎng)公司資產(chǎn)管理系統(tǒng)架構。

參考文獻：

[1][美]PaulC.Brown.SOA實踐指南：應用整體架構[M].北京：機械工業(yè)出版社，2009.

[2][美]Kirk Knoernschild.Java應用架構設計：模塊化模式與OSGi[M].北京：機械工業(yè)出版社，2013.

[3]李偉，吳慶海.軟件架構的藝術[M].北京：電子工業(yè)出版社，2009.

[4]楊傳輝.大規(guī)模分布式存儲系統(tǒng)：原理解析與架構實戰(zhàn)[M].北京：機械工業(yè)出版社，2009.

[5]李智慧.大型網(wǎng)站技術架構：核心原理與案例分析[M].北京：電子工業(yè)出版，2013.

[6]張世明.數(shù)字教育資源共享生態(tài)系統(tǒng)研究[M].上海：復旦大學出版社，2011.

[7]蘭鋒.網(wǎng)站集群架構[EB/OL].[2013-12-16].http：//wenku.it168.com/d_000056770.shtml.

[8]Wang Yu.Scaling Your Java EE. Applications[EB/OL].[2008-07-01].http：//www.theserverside.com/news/1363681/Scaling-Your-Java-EE-Applications.

（責任編輯：王祝萍）