韓 超

(衢州市氣象局, 浙江 衢州 324000)

淺談在線內(nèi)容管理系統(tǒng)的業(yè)務(wù)化改造

韓 超

(衢州市氣象局, 浙江 衢州 324000)

結(jié)合氣象部門的業(yè)務(wù)環(huán)境特點，通過對在線內(nèi)容管理系統(tǒng)內(nèi)部URL機制的分析、數(shù)據(jù)模型的拓展以及功能模塊的改造構(gòu)建一個基于Web Service技術(shù)的數(shù)據(jù)交互平臺。讓運行在移動平臺、桌面系統(tǒng)平臺和網(wǎng)頁平臺的氣象業(yè)務(wù)系統(tǒng)能夠跨平臺、跨語言并且無需任何第三方附加得進(jìn)行數(shù)據(jù)交互，讓分布于不同節(jié)點以及不同類型的數(shù)據(jù)庫在這個交互系統(tǒng)中能夠協(xié)同調(diào)用。讓這個交互系統(tǒng)能夠基于網(wǎng)絡(luò)進(jìn)行針對性的優(yōu)化開發(fā)。

業(yè)務(wù)平臺；數(shù)據(jù)交互；CMS;Web Service

0 引 言

在線數(shù)據(jù)的交互機制對于一些基于網(wǎng)絡(luò)服務(wù)的氣象業(yè)務(wù)來說，起著至關(guān)重要的作用。尤其是近年來移動互聯(lián)技術(shù)的迅猛發(fā)展，伴隨著移動智能終端數(shù)量的急劇增加，給網(wǎng)絡(luò)內(nèi)容推送的流暢性和穩(wěn)定性帶來了空前的壓力。一個沒有緩存機制和交互邏輯的網(wǎng)絡(luò)內(nèi)容管理系統(tǒng)，不僅會大幅增加我們的硬件維護(hù)成本，更讓我們的網(wǎng)絡(luò)服務(wù)平臺在面對大量數(shù)據(jù)請求時陷入癱瘓。目前一些基于PHP語言開發(fā)的內(nèi)容管理系統(tǒng)，雖然在工作邏輯和認(rèn)證方法上有著較為成熟的解決方案，但卻無法滿足氣象部門復(fù)雜數(shù)據(jù)環(huán)境的要求。因而了解這些內(nèi)容管理系統(tǒng)的工作機制，并結(jié)合氣象部門自身的網(wǎng)絡(luò)環(huán)境特點加以改造，將對氣象網(wǎng)絡(luò)平臺的服務(wù)體驗有著極其重要的意義。

1 系統(tǒng)概述與選擇

內(nèi)容管理系統(tǒng)也叫“Content Management System”,一般簡稱為CMS系統(tǒng)。是一種介于Web服務(wù)器和辦公流程之間的軟件系統(tǒng)。它重點解決了各種非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)字資源的采集、管理、利用、傳遞和增值，并能有機集成到結(jié)構(gòu)化數(shù)據(jù)的商業(yè)智能環(huán)境中。隨著網(wǎng)絡(luò)服務(wù)復(fù)雜度和功能性需求的不斷增長，如今以內(nèi)容管理為應(yīng)用核心的CMS產(chǎn)品大有百花爭艷的感覺。這些CMS大致上基于兩套框架編寫：PHP+MySQL和.NET+MSSQL。前者相比后者更具開放性和便攜性，能運行于UNIX、LINUX、WINDOWS下，且PHP和MySQL兼具開源免費的特點，使得基于PHP+MySQL的CMS在市場采用率和系統(tǒng)成熟度上要優(yōu)于.Net+MSSQL的CMS。

近年來我國氣象事業(yè)的不斷發(fā)展使氣象業(yè)務(wù)發(fā)生了根本性的變化。如今的氣象部門以高分辨率、多方位連續(xù)監(jiān)測的觀測方式為主。這決定了氣象資料采集的高密度和龐大的數(shù)據(jù)量，并形成了資料存儲以結(jié)構(gòu)化數(shù)據(jù)庫為主非結(jié)構(gòu)化數(shù)據(jù)資料并重的現(xiàn)狀。Access、MsSQL、Oracle等多種數(shù)據(jù)庫在不同的氣象業(yè)務(wù)領(lǐng)域都發(fā)揮著不同的作用。氣象服務(wù)也從傳統(tǒng)的天氣預(yù)報領(lǐng)域向環(huán)境領(lǐng)域不斷拓展，伴隨而來的則是服務(wù)平臺、服務(wù)內(nèi)容和受眾群體的持續(xù)增長。氣象部門在新形勢下的諸多特點要求一個合格的內(nèi)容管理系統(tǒng)因當(dāng)具備以下3點特質(zhì)：首先，系統(tǒng)不能局限于單一的數(shù)據(jù)庫類型，要具備將不同的數(shù)據(jù)表內(nèi)容分散到不同數(shù)據(jù)庫中的功能。優(yōu)化系統(tǒng)實現(xiàn)負(fù)載均衡的同時，還連接了分散在不同氣象領(lǐng)域的各個數(shù)據(jù)庫。其次，內(nèi)容管理系統(tǒng)對于氣象資料的推送不能局限于純靜態(tài)或動態(tài)生成的方式，應(yīng)當(dāng)能夠響應(yīng)不同軟件平臺的要求分類推送不同性質(zhì)的內(nèi)容。擁有這種靈活的內(nèi)容緩存機制，才能通過網(wǎng)絡(luò)流暢穩(wěn)定得將氣象數(shù)據(jù)推送到性質(zhì)不同的終端上去。第三，系統(tǒng)還應(yīng)該擁有Web Service技術(shù)的一些特質(zhì)，支持跨語言跨系統(tǒng)平臺之間的數(shù)據(jù)交互。綜合考慮這些特質(zhì)，決定采用對二次開發(fā)比較友好的Phpcms系統(tǒng)作為業(yè)務(wù)化改造的基礎(chǔ)系統(tǒng)，借由這個系統(tǒng)的數(shù)據(jù)交互邏輯并在數(shù)據(jù)模型的支持上加以改造。

2 運作模式

Phpcms是一個基于MVC框架模式設(shè)計的CMS系統(tǒng)。它采用單一的入口文件，并且系統(tǒng)中的數(shù)據(jù)邏輯、數(shù)據(jù)顯示和用戶交互的處理部分都相互獨立。這種低耦合的構(gòu)建方式使得系統(tǒng)本身的視圖層和業(yè)務(wù)層分離，讓我們能以最小的代價對系統(tǒng)業(yè)務(wù)邏輯進(jìn)行拓展和改造。

系統(tǒng)啟動從入口文件index.php開始，在這里加載并初始化了位于phpcms目錄下的框架入口文件base.php，在base.php里完成了一系列的系統(tǒng)變量及模型文件加載機制定義，最后進(jìn)入phpcm/lisbs/classes目錄下的應(yīng)用程序創(chuàng)建類application.class.php，實例化application之后系統(tǒng)實現(xiàn)了MVC框架里最重要的控制器功能并進(jìn)入了真正的程序邏輯部分：至此系統(tǒng)初始化工作基本完成，其邏輯流程如圖1所示。

圖1 系統(tǒng)初始化流程

2.1 URL路由機制

PHPCMS的控制器指向是由URL路由機制實現(xiàn)的，它是整個系統(tǒng)最關(guān)鍵的部分。這種路由機制是URL鏈接和系統(tǒng)模塊之間的橋梁，負(fù)責(zé)將進(jìn)入瀏覽器的請求映射到系統(tǒng)的各個控制器，以此讓系統(tǒng)作出不同的邏輯處理。它從系統(tǒng)入口文件index.php開始，附加3個名為“m”、“c”、“a”的固定url參數(shù)，用來表示請求執(zhí)行模型“M”下名為“C”的控制器中名為“A”的方法。系統(tǒng)內(nèi)部的各個模型統(tǒng)一存放在modules文件夾下，所以一個形如index.php?m=content&c=index&a=show&catid=9&id=1鏈接的具體實現(xiàn)為， Url傳入后在application類的實例中對各個參數(shù)進(jìn)行拆解分類，篩選出“M”、“C”和“A”3個變量為系統(tǒng)固定參數(shù)其余變量為函數(shù)參數(shù)，然后通過在base.php中定義的方法，在系統(tǒng)固定路徑下以變量“M”為文件名的模型文件夾中，找到以變量“C”為文件名的控制器文件，并最后在此文件中執(zhí)行以變量“A”為方法名的函數(shù)。所以這個鏈接的具體含義為執(zhí)行系統(tǒng)路徑下modules/content/index.php文件中的index->show方法，并且執(zhí)行的同時給show方法傳入catid=9和id=1兩個參數(shù)。

這種簡便有效的控制器載入機制不僅局限于在網(wǎng)頁瀏覽器上展示網(wǎng)站內(nèi)容，它更支持通過HTTP協(xié)議的post和get方法與遠(yuǎn)程服務(wù)器進(jìn)行交互，以此可以在氣象業(yè)務(wù)網(wǎng)絡(luò)環(huán)境中建立一系列跨平臺跨語言的數(shù)據(jù)交互接口。例如一個氣象數(shù)據(jù)查詢平臺，它的界面展示部分由delphi或C#語言開發(fā)，它的數(shù)據(jù)查詢和數(shù)據(jù)邏輯部分基于CMS系統(tǒng)開發(fā)并通過Url的形式獲取。此時CMS系統(tǒng)不僅可以方便得對所有桌面程序的請求內(nèi)容和請求頻率進(jìn)行統(tǒng)計，還可以基于統(tǒng)計的結(jié)果進(jìn)行優(yōu)化并以緩存的形式推送，即是將請求頻率較高的查詢內(nèi)容以xml、xsd、json文件的形式事先打包緩存在服務(wù)器。此外這個氣象數(shù)據(jù)查詢平臺的服務(wù)端URL請求鏈接可以用API文檔的形式組織起來并在氣象內(nèi)網(wǎng)上共享，其它業(yè)務(wù)開發(fā)或者平臺自身向ios、android系統(tǒng)拓展時都能作為一種寶貴資源被再次利用。

3 數(shù)據(jù)模型的改造

3.1 工廠模式

氣象部門基于數(shù)據(jù)庫所開發(fā)的業(yè)務(wù)平臺有很多，但能用多態(tài)性的編程理念，做到各類數(shù)據(jù)庫統(tǒng)一調(diào)用管理的平臺卻并不多見。PHPCMS系統(tǒng)雖然用工廠模式實現(xiàn)了這個機制，但系統(tǒng)本身的數(shù)據(jù)庫擴(kuò)展只停留在了MySql這一個類型上。所以理解CMS系統(tǒng)數(shù)據(jù)庫的多態(tài)性擴(kuò)展方式，并針對氣象部門擁有的數(shù)據(jù)庫類型進(jìn)行擴(kuò)展，成了業(yè)務(wù)改造工作中的重點。

PHPCMS數(shù)據(jù)庫操作的工廠模式通俗來說就是用一個能夠創(chuàng)建多種數(shù)據(jù)庫實例的提供者類，根據(jù)配置設(shè)置或者程序邏輯來決定實例化哪一種數(shù)據(jù)庫。所以在PHPCMS系統(tǒng)內(nèi)部主要由以下4種類來實現(xiàn)數(shù)據(jù)庫的多態(tài)性機制：1)能夠根據(jù)配置提供不同數(shù)據(jù)庫實例的工廠類。以db_factory.class.php命名，位于phpcms/libs/classes/目錄下；2)負(fù)責(zé)告訴工廠類應(yīng)該實例化哪種數(shù)據(jù)庫的配置類。以database.php命名，位于caches/configs/目錄下；3)用來被工廠類實例化并且負(fù)責(zé)實現(xiàn)數(shù)據(jù)庫具體操作的產(chǎn)品類。這種類文件的命名以數(shù)據(jù)庫名稱開頭，后面附加.class.php，形如mssql.class.php，位于phpcms/libs/classes/目錄下；4)根據(jù)工廠類可能提供的不同數(shù)據(jù)庫實例，實現(xiàn)不同數(shù)據(jù)庫實例同一化操作的模型類，為向后基于功能模塊的擴(kuò)展提供基類。以model.class.php命名，位于phpcms/libs/classes/目錄下。以上4種文件共同構(gòu)成了系統(tǒng)數(shù)據(jù)庫操作的基石，其功能布局和業(yè)務(wù)邏輯如圖2所示。

圖2 數(shù)據(jù)庫多態(tài)性擴(kuò)展的實現(xiàn)邏輯

3.2 數(shù)據(jù)庫操作模型的拓展

系統(tǒng)數(shù)據(jù)操作方面的改造工作首先應(yīng)當(dāng)從底層驅(qū)動的擴(kuò)展開始。PHP作為開源免費的項目多年來一直受到各大IT廠商的青睞，所以PHP對各類數(shù)據(jù)庫都有很不錯的驅(qū)動支持。在PHP官方主頁https://pecl.php.net的Database專欄下提供了55種功能各異特性不同的數(shù)據(jù)庫驅(qū)動，包括在氣象業(yè)務(wù)工作中可能用到的Mssql、Oracle、Mysql、Sqlite甚至是DB2和Lotus Notes的驅(qū)動。對同一種數(shù)據(jù)庫的驅(qū)動選擇上，盡管以PDO為代表的驅(qū)動能在不同數(shù)據(jù)庫之間提供統(tǒng)一的API接口，但非統(tǒng)一接口的驅(qū)動在運行效率、功能性和版本兼容性上都要優(yōu)于PDO驅(qū)動。在獲得所需的驅(qū)動文件后，手動修改PHP的配置文件php.ini，加載相應(yīng)驅(qū)動文件即可實現(xiàn)對數(shù)據(jù)庫驅(qū)動的拓展支持。在服務(wù)平臺有了對各類數(shù)據(jù)庫的基本支持后，相應(yīng)代碼的編寫工作可以從工廠模式下的四種類庫著手，重點是新建mysql.class.php為代表的產(chǎn)品類，小幅修改db_factory.class.php工廠類和model.class.php模型基類。

首先是產(chǎn)品類的拓展。一系列的產(chǎn)品類不僅關(guān)系到各種數(shù)據(jù)庫的直接操作，在系統(tǒng)內(nèi)部更負(fù)責(zé)向工廠類提供一致的實例化接口，向模型類model.class.php提供一致的數(shù)據(jù)庫操作方法，所以在代碼組織上要求各種產(chǎn)品類的方法函數(shù)要有一致的名稱，以及產(chǎn)品類之間的功能交集要大于等于模型類中調(diào)用到的方法函數(shù)，只有這樣才能保證后面的模型類在拿到工廠類提供的數(shù)據(jù)庫實例后，能用統(tǒng)一的函數(shù)名實現(xiàn)功能一致的方法。所以在函數(shù)方法名稱上必須以mysql.class.php類為參照標(biāo)準(zhǔn)，用“open”、“close”作為開啟和關(guān)閉數(shù)據(jù)庫連接資源的名稱標(biāo)識以備db_factory.class.php在實例化時調(diào)用，并以“select、get_one、query、insert、update、delete、count、affected_rows、get_primary、get_fields、table_exists、field_exists”為數(shù)據(jù)查詢的功能布局。在整個產(chǎn)品類的功能交集中，除了“select”方法所涉及到的分表查詢在不同數(shù)據(jù)庫中略有區(qū)別外，其它功能方法都能在各自的驅(qū)動接口API上找到。在mysql數(shù)據(jù)庫中分表查詢可以通過“l(fā)imit”語句輕松實現(xiàn)，而在mssql和oracle中則需分別通過“ROW_NUMBER”和“RANK”來實現(xiàn)。在Oracle中需通過如圖3所示方式實現(xiàn)。

圖3 Oracle實現(xiàn)Limit分頁查詢的方法

在mssql中需通過圖4所示方式實現(xiàn)。

圖4 Mssql實現(xiàn)Limit分頁查詢的方法

產(chǎn)品類編寫完畢后，需要對PHPCMS系統(tǒng)原有的工廠類文件db_factory.class.php做小幅的改動，以適應(yīng)新增數(shù)據(jù)庫類型的實例化工作。db_factory.class.php類是基于單件模式設(shè)計的，類成員函數(shù)“get_database”通過接收一個代表數(shù)據(jù)庫類型的字符串參數(shù)，來決定向外界傳遞何種類型的數(shù)據(jù)庫實例。

而這種類型初始化的選擇機制是通過一個switch-case語言來實現(xiàn)的。所以想要拓展工廠類所能支持的數(shù)據(jù)庫類型，只需在類函數(shù)“connect“內(nèi)的switch語句中，新增case選擇條件即可。例如“case′ mssql′:

pc_base::load_sys_class('mssql','',0);＄object=new mssql();break;”這樣簡單的幾行語句即可完成一類數(shù)據(jù)庫的擴(kuò)展工作。

在完成db_factory.class.php工廠類的改造工作后，再配合原系統(tǒng)的model.class.php模型基類，可以說基本已經(jīng)完成了數(shù)據(jù)庫平臺支持的拓展工作。但鑒于部分?jǐn)?shù)據(jù)庫對于數(shù)據(jù)庫表名稱大小寫的特殊要求，還需要模型基類在讀取數(shù)據(jù)庫參數(shù)設(shè)置時做一些針對性的處理。例如在模型基類的構(gòu)造函數(shù)里添加“if(＄this->db_config[＄this->db_setting]['type']=='oracle');＄this->table_name=strtoupper(＄this->table_name);”，用來將database.php里的數(shù)據(jù)庫表名統(tǒng)一成大寫字母。

4 功能模塊的開發(fā)設(shè)計

在系統(tǒng)數(shù)據(jù)操作類庫拓展完畢之后，可基于這種多態(tài)性的數(shù)據(jù)模型結(jié)構(gòu)，并結(jié)合氣象業(yè)務(wù)的特點進(jìn)一步開展氣象業(yè)務(wù)模塊的開發(fā)工作。由于phpcms系統(tǒng)是基于MVC框架構(gòu)建的，受益于這種高內(nèi)聚、低耦合的代碼組織方式，我們的模塊開發(fā)工作可清晰的分為兩個部分：1)數(shù)據(jù)庫操作模型的拓展，在系統(tǒng)路徑“phpcms/mode/”下派生模型基類model.class.php，并且在database.php中完成相關(guān)參數(shù)配置；2)功能模塊的開發(fā)，在系統(tǒng)路徑“phpcms/modules/”下新建以模塊名稱命名的文件夾，并在此文件中完成數(shù)據(jù)交互邏輯相關(guān)類庫的開發(fā)。

4.1 數(shù)據(jù)庫操作模型的拓展

拓展工作主要涉及database.php和model.class.php這兩個類文件。database.php并不是一個類文件，它僅作為一個代碼片段存在于phpcms系統(tǒng)的配置文件夾下，主要功能是向包含它的類庫文件返回一個數(shù)據(jù)庫配置信息列表以供變量成員挑選并賦值。database.php的代碼結(jié)構(gòu)由一個二維數(shù)組構(gòu)成，數(shù)據(jù)庫的連接參數(shù)以庫為單位存儲在這個數(shù)組里。數(shù)組的第一個維度是配置參數(shù)的自定義名稱，第二個維度則是這個名稱所對應(yīng)的具體參數(shù)。所以在database.php中新增數(shù)據(jù)庫參數(shù)配置，只需在文件返回的二維數(shù)組中新增一條形如“test=>array(…數(shù)據(jù)庫參數(shù)…)”的記錄即可。其次是在model.class.php類的基礎(chǔ)上派生新的數(shù)據(jù)模型。這個數(shù)據(jù)模型是基于表設(shè)計并且能被高度重用的。它僅表示數(shù)據(jù)庫操作層面的一種模型并不確切指向前臺的某種交互邏輯。數(shù)據(jù)模型與功能模塊之間的低耦合性，使得一個模塊功能的數(shù)據(jù)操作可以由多個指向不同類型數(shù)據(jù)庫的模型共同組成。model.class.php類的派生編寫工作也很簡單，新的子類只需要在重載構(gòu)造函數(shù)時重新定義參數(shù)配置名和數(shù)據(jù)表名即可。

4.2 模塊的開發(fā)

系統(tǒng)模塊的根目錄位于“phpcms/modules/”路徑下，目錄中是以具體功能為分類命名的各個模塊文件夾，文件夾內(nèi)包含的類文件則是各類數(shù)據(jù)交互的執(zhí)行邏輯。在類文件的執(zhí)行方法中，以“＄this->db = pc_base::load_model('xsweb_168_nowcasting');”的形式，在加載相應(yīng)數(shù)據(jù)模型的同時即可完成數(shù)據(jù)模型的初始化工作，然后根據(jù)model.class.php類中提供的方法函數(shù)，便可完成數(shù)據(jù)庫的交互操作。只要熟知系統(tǒng)的URL機制和模塊加載機制，模塊類可按需推送圖片鏈接、二進(jìn)制文件鏈接或者直接推送明文或二進(jìn)制文件等各類數(shù)據(jù)格式。

模塊的開發(fā)工作可充分利用網(wǎng)絡(luò)語言的特點進(jìn)行深度優(yōu)化。僅以推送不同時間跨度的降水量統(tǒng)計數(shù)據(jù)為例：1)可在推送數(shù)據(jù)的同時，模塊向系統(tǒng)自身提交一條url鏈接以統(tǒng)計請求的頻率和數(shù)量。如此可在不影響數(shù)據(jù)推送的同時完成統(tǒng)計工作；2)基于這種統(tǒng)計，當(dāng)某時間跨度的雨量請求數(shù)量達(dá)一定量級時，系統(tǒng)在更新請求數(shù)值的同時，在特定目錄生成一個以時間戳和特定ID命名的內(nèi)容為空的標(biāo)識文件，并以此文件為信號決定是否在響應(yīng)請求時生成json或xml等格式的靜態(tài)文件緩存在服務(wù)器，在第二次響應(yīng)相同的請求時將靜態(tài)文件的內(nèi)容直接發(fā)送給客戶端；3)系統(tǒng)平臺可以是分布式存在于多個節(jié)點之中的。用一臺服務(wù)器作為響應(yīng)請求的入口，以請求客戶端的地理分布為條件向其它服務(wù)器分別發(fā)送請求信息并最終獲取請求結(jié)果反饋給客戶端；4)可將特定內(nèi)容提前生成緩存文件，在響應(yīng)請求時不經(jīng)過數(shù)據(jù)庫和其它執(zhí)行邏輯直接發(fā)送給客戶端。

5 Web Service帶來的改變

“歷史上的今天”是衢州氣象內(nèi)網(wǎng)頁面中的一個數(shù)據(jù)展示模塊，欄目內(nèi)容包含“歷史上的今天”、“歷史上的明天”、“歷史上的未來三天”和“歷史上的未來十天”4個方面，欄目數(shù)據(jù)涉及衢州各縣市建站以來各項溫度數(shù)據(jù)，降水?dāng)?shù)據(jù)以及降水頻率的分類統(tǒng)計。由于網(wǎng)站本身通過對phpcms改造而構(gòu)建出一個Web Service平臺，所以給欄目本身的多平臺拓展和優(yōu)化帶來了巨大的改變。

5.1 多平臺的拓展

從欄目內(nèi)容上看，這類歷史均值、極值統(tǒng)計模塊的應(yīng)用范圍比較廣泛，在各類氣象網(wǎng)站、手機APP終端或桌面業(yè)務(wù)平臺中都非常常見。然而對于開發(fā)者來說，要在特性和編程語言都不盡相同的各個平臺中開發(fā)功能相近的項目，意味著大量重復(fù)且無法避免的數(shù)據(jù)庫編程工作。但基于web service平臺開發(fā)后，欄目在安卓平臺上推出時可由欄目現(xiàn)成的Url獲取數(shù)據(jù)并直接介入界面UI的開發(fā),其開發(fā)流程如圖5所示。

圖5 基于WebService技術(shù)的系統(tǒng)多平臺開發(fā)流程

5.2 優(yōu)化和效益評估

項目的跨平臺工作通常會帶來兩個不可避免的問題。首先是支撐服務(wù)器維護(hù)的工作量會成倍增加。其次，隨著平臺數(shù)量的增加和客戶端系統(tǒng)的差異化加劇，系統(tǒng)的整體穩(wěn)定性會受到嚴(yán)峻的考驗，并導(dǎo)致系統(tǒng)優(yōu)化的難度不斷加大。然而通過改造Phpcms系統(tǒng)構(gòu)建一套基于web service技術(shù)的數(shù)據(jù)推送平臺，能夠?qū)⑦@些難題化零為整，統(tǒng)一優(yōu)化一勞永逸。

在“歷史上的今天”這個欄目中，為了提高欄目本身的穩(wěn)定性和應(yīng)對大量客戶端并發(fā)請求的負(fù)載性能。

我設(shè)計了這樣一個簡單而有效的php進(jìn)程協(xié)同模式：應(yīng)對短時間內(nèi)大量的并發(fā)請求時，數(shù)百個各自獨立的php處理進(jìn)程并不會搶著向數(shù)據(jù)庫服務(wù)器要統(tǒng)計數(shù)據(jù)，眾多進(jìn)程間會等待第一個向服務(wù)器發(fā)出請求的進(jìn)程，直至該進(jìn)程拿到統(tǒng)計數(shù)據(jù)并形成緩存文件，其他進(jìn)程再獲取這個緩存文件內(nèi)的統(tǒng)計結(jié)果。

為檢驗欄目在如此改造后的工作效率，特別設(shè)計了這樣一個對比實驗：實驗通過并發(fā)線程的方式模擬數(shù)百個客戶端在500 ms的時間內(nèi)隨機向服務(wù)器請求欄目所需的統(tǒng)計數(shù)據(jù)，隨著并發(fā)客戶端數(shù)量的增加記錄每個客戶端完成統(tǒng)計需要的毫秒數(shù)并取平均值。實驗的前提：1)實驗的客戶端都是通過j2se編程的桌面程序；2)客戶端向服務(wù)器請求數(shù)據(jù)之前，服務(wù)器端不存在任何現(xiàn)成的緩存數(shù)據(jù)。

圖6 常規(guī)平臺與WebService優(yōu)化平臺對于短時并發(fā)請求的查詢效率對比

實驗結(jié)果如圖6所示。其中，運用常規(guī)方法統(tǒng)計數(shù)據(jù)的客戶端在并發(fā)數(shù)量達(dá)到400個時，出現(xiàn)了大量數(shù)據(jù)庫連接超時的情形，并且隨著并發(fā)請求數(shù)量的不斷增加，單個線程完成統(tǒng)計所需的平均耗時從最初的3～5 s延遲到了1 min多鐘，甚至無法完成統(tǒng)計。但基于web service技術(shù)來請求數(shù)據(jù)的客戶端因為收益于web平臺本身的并發(fā)特性優(yōu)勢和一系列的優(yōu)化措施，其工作效率幾乎不受請求客戶端數(shù)量的影響。最后，基于web service的客戶端再次向服務(wù)器請求相同的統(tǒng)計數(shù)時，由于服務(wù)器已有統(tǒng)計完成的緩存數(shù)據(jù)，400個并發(fā)線程請求完成的平均時間只需要15 ms。

6 結(jié) 語

通過對Phpcms系統(tǒng)的分析和內(nèi)部數(shù)據(jù)模型的改造，建立了一個基于phpcms系統(tǒng)內(nèi)核并且能夠?qū)崿F(xiàn)Web Service技術(shù)的數(shù)據(jù)交互平臺。新平臺基于URL的路由機制使得數(shù)據(jù)交互能夠跨語言跨操作系統(tǒng)，新平臺基于數(shù)據(jù)庫多態(tài)性的機制實現(xiàn)了不同數(shù)據(jù)庫的協(xié)同開發(fā)。新平臺基于網(wǎng)絡(luò)語言的優(yōu)化使得來自不同特性的客戶端請求有了一個高度整合和統(tǒng)一維護(hù)的平臺。

改造后的新平臺能使運行在不同機器上的不同應(yīng)用無須借助附加的、專門的第三方軟件或硬件，就可相互交換數(shù)據(jù)或集成。系統(tǒng)本身也很容易部署， 因為它們基于一些常規(guī)的產(chǎn)業(yè)標(biāo)準(zhǔn)以及已有的一些技術(shù)，諸如XML、HTTP、PHP。它不僅具有良好的維護(hù)性和擴(kuò)展性，它更為氣象部門的各個業(yè)務(wù)平臺在數(shù)據(jù)交互上提供了一個通用的機制，使得移動氣象平臺，桌面氣象平臺和網(wǎng)頁氣象平臺在交互上形成一個統(tǒng)一的整體，使我們的開發(fā)維護(hù)工作能夠基于3種平臺統(tǒng)籌兼顧。

[1] Ethan Cerami(美).Web Services Essentials[M].美國：O′Reilly,2003

[2] 沈伯青,楊宗凱.WEB服務(wù)的基石:UDDI技術(shù)[J].計算機工程與應(yīng)用,2003:147-150.

[3] 鄧 瑩，馮向科.探討Web Service的關(guān)鍵技術(shù)及其實現(xiàn)[J].電腦知識與技術(shù)，2006(35):28.

2015-04-22