基于集中采購的分布式系統(tǒng)的設(shè)計與實現(xiàn)

吳香蘭

[摘要]近年來，隨著反腐政策的不斷深入，政府行業(yè)預(yù)算控制日益嚴格，為了更加規(guī)范政府行業(yè)的采購行為，使之更加公開和透明，政府行業(yè)的集中采購規(guī)模將不斷加大。各個單位企業(yè)紛紛建立自己的電商網(wǎng)站，進行集中采購行為，并采用分布式系統(tǒng)設(shè)計優(yōu)化性能，提升整體采購量。

[關(guān)鍵詞]集中采購；分布式系統(tǒng)；宕機；負載均衡

[中圖分類號]G642 [文獻標識碼]A [文章編號]1671-5918（2017）06-0108-03

一、引言

隨著大型企業(yè)集中采購范圍的不斷拓展和集中采購模式的不斷創(chuàng)新完善，大型企業(yè)集中采購正朝著專業(yè)化、集約化、信息化、標準化、規(guī)范化方向發(fā)展。集中采購適用于大型企業(yè)、集團或跨國公司中能夠形成一定規(guī)模優(yōu)勢的大宗、批量且標準化程度較高的同類貨物和服務(wù)，如大批量主要零部件、生產(chǎn)原材料或戰(zhàn)略資源貨物。隨著反腐政策的不斷深入，政府行業(yè)預(yù)算控制日益嚴格，為了更加規(guī)范政府行業(yè)的采購行為，使之更加公開和透明，政府行業(yè)的集中采購規(guī)模將不斷加大。集中采購是政府采購的主要形式，是指由在政府設(shè)立的集中采購機構(gòu)依據(jù)政府制定的集中采購目錄，包括由中央財政部預(yù)算直接劃撥和地方省份財政預(yù)算劃撥。為實現(xiàn)集中采購模式，各集團紛紛采用成立集中采購類的電商公司來專門運作，并且拉入更多的集團外公司一同提升采購量，特別是集采量，并在這個基礎(chǔ)上整理出各個行業(yè)的數(shù)據(jù)分析等功能，為集團提供一手數(shù)據(jù)，提供決策能力。

二、基于集中采購的分步式系統(tǒng)提出

（一）什么是分布式系統(tǒng)

分布式系統(tǒng)（distributed system）是建立在網(wǎng)絡(luò)之上的軟件系統(tǒng)。正是因為軟件的特性，所以分布式系統(tǒng)具有高度的內(nèi)聚性和透明性。因此，網(wǎng)絡(luò)和分布式系統(tǒng)之間的區(qū)別更多的在于高層軟件（特別是操作系統(tǒng)），而不是硬件。內(nèi)聚性是指每一個數(shù)據(jù)庫分布節(jié)點高度自治，有本地的數(shù)據(jù)庫管理系統(tǒng)。透明性是指每一個數(shù)據(jù)庫分布節(jié)點對用戶的應(yīng)用來說都是透明的，看不出是本地還是遠程。在分布式數(shù)據(jù)庫系統(tǒng)中，用戶感覺不到數(shù)據(jù)是分布的，即用戶不須知道關(guān)系是否分割、有無副本、數(shù)據(jù)存于哪個站點以及事務(wù)在哪個站點上執(zhí)行等。

（二）集中采購行業(yè)軟件弊端

傳統(tǒng)的集中采購系統(tǒng)架構(gòu)比較簡單，采用四層設(shè)計，從上到下分別是Web瀏覽器、界面層、業(yè)務(wù)層（數(shù)據(jù)訪問層）和數(shù)據(jù)存儲層，根據(jù)實際可以是B/S模式，也可以是C/S模式。

在各個集團成立了電商公司專門運作集中采購系統(tǒng)，借助這個架構(gòu)的平臺，各個集團的采購量不斷上升，系統(tǒng)運營效果較好，但是隨著用戶量不斷增大后，系統(tǒng)出現(xiàn)宕機情況也不斷增多，即使生產(chǎn)環(huán)境的操作系統(tǒng)及JDK都升級到64位，并且擴展了JVM管理的內(nèi)存，宕機情況有所減少，但是還是無法達到不宕機的要求，這長期困擾著集中采購的電商平臺，也極大地影響了集中采購系統(tǒng)的使用效果和推廣進程。

在這種情況下，嘗試采用分布式系統(tǒng)架構(gòu)來滿足其日益增長的業(yè)務(wù)需求，解決宕機的困擾，真正讓電商網(wǎng)站服務(wù)于集中采購，提高采購的便捷性。

三、分布式系統(tǒng)在集中采購行業(yè)中的設(shè)計與應(yīng)用

（一）分布式系統(tǒng)架構(gòu)

分布式集中采購系統(tǒng)的架構(gòu)徹底打破了傳統(tǒng)集中采購的四層設(shè)計，采用五層的系統(tǒng)架構(gòu)的設(shè)計，從上到下分別是頁面層、頁面交互層、控制層、數(shù)據(jù)交互層和持久化存儲層，并且通過一定的開發(fā)工具和外部技術(shù)的配合使用來實現(xiàn)分布式的優(yōu)越性能。

（二）軟件內(nèi)部架構(gòu)設(shè)計

頁面層：EXT-JS的不僅大而全，而且太過重量級，頁面風格也太過單一，在網(wǎng)站端開發(fā)使用起來比較麻煩，比較適合于傳統(tǒng)企業(yè)級應(yīng)用，不適合分布式電商系統(tǒng)架構(gòu)。由于JavaScript庫里的JQUERY的開源性和共享的特點，使用起來會更方便，所以頁面層選用了JQUERY，主要使用了easyui、jqgrid等工具。開發(fā)報表選用了EcCade。

頁面交互層：采用Servlet接收前端數(shù)據(jù)，json作為傳遞數(shù)據(jù)的功能，自己通過過濾器實現(xiàn)安全管理，同時設(shè)計緩存借口模塊。

控制層：由于J2EE的Spring是一個輕量級的DI和AOP容器框架，并且Spring的高度可開放性，并不強制依賴于spring，開發(fā)者可以自由選擇spring部分或全部選用，所以控制層選用了Spring，Spring Core進行依賴注入，Spring Aop進行事務(wù)管理，同時設(shè)計流程管理模塊。

數(shù)據(jù)交互層：由于Hibernate簡化了持久層的開發(fā)，可以運用面向?qū)ο蟮恼Z言操作數(shù)據(jù)庫，且具有平臺無關(guān)性開發(fā)的產(chǎn)品更具移植性。所以數(shù)據(jù)交互層選用Hibernate。設(shè)計文件存儲模塊。

持久化存儲：由于傳統(tǒng)的系統(tǒng)使用的是oracle，所以電商平臺繼續(xù)使用Oracle。由于加入了電商網(wǎng)站，需要更多的圖片存放，所以需要架設(shè)了一個Http Server，這個服務(wù)器可以展示靜態(tài)資源，其中文件存放在共享的磁盤陣列上，通過Http Server對其進行訪問，將其訪問地址存放在Oracle數(shù)據(jù)庫中，網(wǎng)站或者內(nèi)部應(yīng)用訪問圖片等文件資源時，就直接通過地址進行訪問即可，同時也避免了網(wǎng)站或者內(nèi)部應(yīng)用重新發(fā)布時，還需要備份這些文件（特別是文件太大后，根本無法備份）。數(shù)據(jù)庫連接池管理使用DBCP。

（三）外部工具

操作系統(tǒng)：由于傳統(tǒng)的系統(tǒng)是一個集中部署的系統(tǒng)，一般采用的是IBM小型機作為應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器，使用AIX操作系統(tǒng)?，F(xiàn)在將系統(tǒng)修改為分步式系統(tǒng)，將原來的集中部署系統(tǒng)修改為企業(yè)內(nèi)部系統(tǒng)、供應(yīng)商管理系統(tǒng)、第三方采購系統(tǒng)、集團領(lǐng)導決策分析系統(tǒng)和電商網(wǎng)站（B2B）五個系統(tǒng)。而對于客戶全部購買IBM小型機可能是一個巨大的經(jīng)費壓力，所以整個系統(tǒng)在保留傳統(tǒng)的AIX服務(wù)器的基礎(chǔ)上，增加的服務(wù)器可以全部采用RedHat Linux作為操作系統(tǒng)。

應(yīng)用服務(wù)器：由于客戶的IBM的WPS免費服務(wù)已經(jīng)過期，續(xù)費太貴（20萬每年）。所以放棄使用了，改用免費版的JBOSS。由于2008年為他們部署系統(tǒng)時采用的是IBM JDK 32位，現(xiàn)在改用了64位的JDK。因為32位JDK最多只能管理1.5G內(nèi)存，而64位JDK理論上可以管理128G的內(nèi)存。

緩存服務(wù)：采用EcCache，將原有的JVM內(nèi)部緩存移植到EcCache中。由于有多臺服務(wù)器，所以需要安裝多個EcCache，并且之間數(shù)據(jù)需要共享，可以考慮做一個EcCache集群。但是這個緩存最大的缺點就是緩存需要被多次拷貝，占用更多的服務(wù)器的內(nèi)存空間。

負載均衡：選擇了市場上使用的比較流行的Apache HttpServer作為負載均衡服務(wù)器，同時也可以作為靜態(tài)網(wǎng)站的服務(wù)器來使用。

（四）開發(fā)工具

由于Eclipse的程序更加面向?qū)ο蟆⑻岣吡松a(chǎn)率、方便移植（修改配置文件）、無侵入性等優(yōu)點，開發(fā)工具選用了Eclipse，數(shù)據(jù)庫可以使用plSql。

四、分布式系統(tǒng)的好處

集中采購系統(tǒng)采用了分布式系統(tǒng)架構(gòu)的設(shè)計后，隨著用戶量不斷增大系統(tǒng)宕機的問題徹底解決，并且具有以下好處：

（一）實現(xiàn)了數(shù)據(jù)庫的讀寫分離，將數(shù)據(jù)庫操作的讀操作和寫操作分離到不同的數(shù)據(jù)庫實例上面去了，即使由于數(shù)據(jù)庫讀操作的腳本執(zhí)行效率太低，也不會造成寫操作無法進行。

（二）由于使用了負載均衡，不再僅依靠一臺JVM來實現(xiàn)應(yīng)用程序的內(nèi)存管理，即使是64位JDK可以管理很大的內(nèi)存，但是內(nèi)存太大會降低JVM的回收時間，拖慢系統(tǒng)的整體性能。

（三）采用了負載均衡后，應(yīng)用程序可以被部署到多個服務(wù)器上面，每個服務(wù)器上面可以部署多個應(yīng)用服務(wù)器，每個應(yīng)用服務(wù)器可以使用一個JVM，每個JVM可以設(shè)置的比較合適，從而保證系統(tǒng)的整體運行性能。

（四）由于緩存是各個應(yīng)用服務(wù)器都會使用到的，需要一個集中的區(qū)域?qū)⒕彺婀芾砥饋恚F(xiàn)在采用JVM的外部緩存，可以將緩存數(shù)據(jù)集中管理，各個應(yīng)用服務(wù)器從一個入口獲取緩存。

（五）由于有了負載均衡，各個應(yīng)用服務(wù)器可以作為相互備份了，即使一臺服務(wù)器宕機或者性能很慢了，負載均衡服務(wù)器會通過訪問的響應(yīng)速度，將新的訪問指向到性能更優(yōu)的服務(wù)器上面。

（六）采用多服務(wù)器部署后，使得每個服務(wù)器的資源都得以充分的利用?？梢詫討B(tài)資源和靜態(tài)資源分開部署。

五、分布式系統(tǒng)的未來展望

由于分布式系統(tǒng)的優(yōu)越性能，未來大有可為，未來在以下方面將得到較大的發(fā)展：

（一）數(shù)據(jù)庫、操作系統(tǒng)、應(yīng)用服務(wù)器未來免費和開源的情況肯定會越來越多。

（二）關(guān)系型數(shù)據(jù)庫不能完全滿足業(yè)務(wù)增長的需求，未來的系統(tǒng)會是關(guān)系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫并存。對于事務(wù)操作要求高的業(yè)務(wù)采用關(guān)系型數(shù)據(jù)庫，對于事務(wù)要求不高的業(yè)務(wù)可以采用NOSQL數(shù)據(jù)庫。

（三）緩存技術(shù)的發(fā)展會形成不再是本地緩存，而是遠程緩存，緩存還可以在多臺服務(wù)器上互相備份。

（四）未來的應(yīng)用程動靜分離的情況會越來越多，對于系統(tǒng)中變化不多的信息，以靜態(tài)頁面展示，對于業(yè)務(wù)數(shù)據(jù)的獲取使用動態(tài)的應(yīng)用服務(wù)器去獲取數(shù)據(jù)信息。

（五）隨著數(shù)據(jù)量越來越大，系統(tǒng)必須引入全文檢索工具，以滿足用戶快速搜索信息的需求。

（六）由于可以連接網(wǎng)絡(luò)的設(shè)備越來越多，而各種不同設(shè)置的屏幕尺寸又不統(tǒng)一，系統(tǒng)頁面需要同時滿足這些不同的屏幕展示。為了不開發(fā)多套頁面，未來的頁面將以響應(yīng)式布局為主。

六、結(jié)論

集中采購電商系統(tǒng)引入分布式系統(tǒng)后，隨著用戶量不斷增大后，系統(tǒng)出現(xiàn)宕機情況徹底杜絕了，同時由于引入了jQuery技術(shù)，可以快速的引入很多前端的技術(shù)框架，比如jqGrid、AutoComplete等。通過oracle的同義詞技術(shù)可以實現(xiàn)多個數(shù)據(jù)庫之間的數(shù)據(jù)同步，引入了Http Server較好的實現(xiàn)了靜態(tài)資源展示和負載均衡。這樣整個集中采購系統(tǒng)就能夠很好地滿足企業(yè)的要求，更好地服務(wù)于采購企業(yè)。

（責任編輯：章樊）