基于集中采購的分布式系統的設計與實現

吳香蘭

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

[關鍵詞]集中采購；分布式系統；宕機；負載均衡

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

一、引言

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

二、基于集中采購的分步式系統提出

（一）什么是分布式系統

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

（二）集中采購行業軟件弊端

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

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

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

三、分布式系統在集中采購行業中的設計與應用

（一）分布式系統架構

分布式集中采購系統的架構徹底打破了傳統集中采購的四層設計，采用五層的系統架構的設計，從上到下分別是頁面層、頁面交互層、控制層、數據交互層和持久化存儲層，并且通過一定的開發工具和外部技術的配合使用來實現分布式的優越性能。

（二）軟件內部架構設計

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

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

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

數據交互層：由于Hibernate簡化了持久層的開發，可以運用面向對象的語言操作數據庫，且具有平臺無關性開發的產品更具移植性。所以數據交互層選用Hibernate。設計文件存儲模塊。

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

（三）外部工具

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

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

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

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

（四）開發工具

由于Eclipse的程序更加面向對象、提高了生產率、方便移植（修改配置文件）、無侵入性等優點，開發工具選用了Eclipse，數據庫可以使用plSql。

四、分布式系統的好處

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

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

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

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

（四）由于緩存是各個應用服務器都會使用到的，需要一個集中的區域將緩存管理起來，現在采用JVM的外部緩存，可以將緩存數據集中管理，各個應用服務器從一個入口獲取緩存。

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

（六）采用多服務器部署后，使得每個服務器的資源都得以充分的利用。可以將動態資源和靜態資源分開部署。

五、分布式系統的未來展望

由于分布式系統的優越性能，未來大有可為，未來在以下方面將得到較大的發展：

（一）數據庫、操作系統、應用服務器未來免費和開源的情況肯定會越來越多。

（二）關系型數據庫不能完全滿足業務增長的需求，未來的系統會是關系型數據庫和NOSQL數據庫并存。對于事務操作要求高的業務采用關系型數據庫，對于事務要求不高的業務可以采用NOSQL數據庫。

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

（四）未來的應用程動靜分離的情況會越來越多，對于系統中變化不多的信息，以靜態頁面展示，對于業務數據的獲取使用動態的應用服務器去獲取數據信息。

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

（六）由于可以連接網絡的設備越來越多，而各種不同設置的屏幕尺寸又不統一，系統頁面需要同時滿足這些不同的屏幕展示。為了不開發多套頁面，未來的頁面將以響應式布局為主。

六、結論

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

（責任編輯：章樊）