肖招娣

(廣東電網(wǎng)有限責(zé)任公司 佛山供電局， 佛山 528000)

0 引言

企業(yè)信息化建設(shè)工作由原來(lái)的內(nèi)部技術(shù)人員開(kāi)發(fā)到由于短時(shí)間內(nèi)大規(guī)模信息化建設(shè)需求涌現(xiàn)而以外包為主，目前又轉(zhuǎn)入強(qiáng)調(diào)自主研發(fā)建設(shè)的階段。由于初始階段所積累的開(kāi)發(fā)框架和源代碼已比較落后，目前沒(méi)有太大的借鑒意義。故開(kāi)發(fā)過(guò)程除了個(gè)人積累的代碼，大部分只能從零開(kāi)發(fā)。而對(duì)于新員工而言，他們很難在短期內(nèi)靠自學(xué)快速開(kāi)發(fā)出規(guī)范、高質(zhì)量的代碼。這就造成了重復(fù)開(kāi)發(fā)、效率低下、開(kāi)發(fā)周期長(zhǎng)、開(kāi)發(fā)成本高等問(wèn)題。

而對(duì)于企業(yè)內(nèi)部而言，用戶習(xí)慣基本已經(jīng)形成，大部分的開(kāi)發(fā)也有規(guī)律可循。在這個(gè)“數(shù)據(jù)為王、服務(wù)為本”的時(shí)代，從數(shù)據(jù)角度觀看，軟件系統(tǒng)所支撐的功能無(wú)非是數(shù)據(jù)的獲取、數(shù)據(jù)的加工、數(shù)據(jù)分析、數(shù)據(jù)展示。

而對(duì)于我單位內(nèi)部數(shù)據(jù)而言，大致分為四類：主數(shù)據(jù)、PI實(shí)時(shí)數(shù)據(jù)、實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)。對(duì)于每類數(shù)據(jù)，數(shù)據(jù)的獲取與解析方式和功能基本都確定。故完全可以將這部分代碼固化在二次開(kāi)發(fā)平臺(tái)中共享。

同時(shí)，在互聯(lián)網(wǎng)時(shí)代，移動(dòng)應(yīng)用已成為很多業(yè)務(wù)不可或缺的支撐手段，為了更好、更快地實(shí)現(xiàn)具有更高的網(wǎng)絡(luò)安全性的移動(dòng)應(yīng)用業(yè)務(wù)場(chǎng)景[1，2]，該平臺(tái)還添加了地圖接口、視頻監(jiān)控相關(guān)接口[3]，并對(duì)現(xiàn)有的消息推送工具進(jìn)行了改造。

針對(duì)上述問(wèn)題，本文提出一種以開(kāi)發(fā)組件為基礎(chǔ)的、融合多元化數(shù)據(jù)訪問(wèn)能力及常見(jiàn)移動(dòng)應(yīng)用開(kāi)發(fā)組件的二次開(kāi)發(fā)平臺(tái)[4-7]。

1 二次開(kāi)發(fā)平臺(tái)架構(gòu)及問(wèn)題描述

1.1 二次開(kāi)發(fā)平臺(tái)功能架構(gòu)圖

如圖1所示。

1.2 各部分功能及其實(shí)現(xiàn)

1.2.1 SOA服務(wù)解析

開(kāi)發(fā)框架完全符合公司SOA服務(wù)解析規(guī)范，公司SOA架構(gòu)與本項(xiàng)目開(kāi)發(fā)架構(gòu)視圖能有相應(yīng)的映射。如圖2所示。

SOA集成開(kāi)發(fā)框架提供了快速實(shí)現(xiàn)模塊解耦、跨系統(tǒng)服務(wù)調(diào)用以及與公司企業(yè)信息集成平臺(tái)通信的解決方案。通過(guò)webservice方式，開(kāi)發(fā)SOA接口demo，對(duì)公司SOA技術(shù)規(guī)范進(jìn)行轉(zhuǎn)換[8]。后續(xù)開(kāi)發(fā)需要用到SOA規(guī)范的時(shí)候，引用該組件相關(guān)接口，根據(jù)實(shí)際情況微調(diào)即可使用。

圖1 功能架構(gòu)

圖2 公司SOA架構(gòu)

下圖是通過(guò)該SOA服務(wù)解析組件編寫(xiě)的查詢TBI日志信息的原子服務(wù)，實(shí)現(xiàn)了TBI日志的查詢，如圖3所示。

圖3 TBI日志查詢

1.2.2 PI數(shù)據(jù)庫(kù)解析

PI數(shù)據(jù)庫(kù)解析：PI數(shù)據(jù)庫(kù)由于其固有的優(yōu)勢(shì)，主要用于存放實(shí)時(shí)數(shù)據(jù)和準(zhǔn)實(shí)時(shí)數(shù)據(jù)[9]。通過(guò)轉(zhuǎn)化為java接口，能夠提升多平臺(tái)、多終端的開(kāi)發(fā)效率。解決了已有的基于PI API方式經(jīng)常出現(xiàn)報(bào)錯(cuò)、功能不穩(wěn)定的問(wèn)題。

主要工作包括：AF SDK轉(zhuǎn)換為WebService接口的開(kāi)發(fā)實(shí)現(xiàn)、功能測(cè)試、性能測(cè)試、代碼重構(gòu)整理、工具類提供及注釋驗(yàn)證、demo工程的開(kāi)發(fā)、編寫(xiě)開(kāi)發(fā)文檔使用說(shuō)明。合計(jì)開(kāi)發(fā)整理接口服務(wù)方法36個(gè)，新服務(wù)接口提供XML與json兩種可選數(shù)據(jù)傳輸格式，json格式web前端使用更方便，json體積小且相對(duì)于XML有網(wǎng)絡(luò)傳輸上的優(yōu)勢(shì)。我單位新開(kāi)發(fā)的大客戶移動(dòng)服務(wù)平臺(tái)即從新封裝的服務(wù)接口中獲取負(fù)荷數(shù)據(jù)。對(duì)比表明這種方式比原來(lái)的基于PI API方式的WebService更為穩(wěn)定。PI數(shù)據(jù)庫(kù)作業(yè)原理如圖4所示。

圖4 PI數(shù)據(jù)庫(kù)作業(yè)原理

1.2.3 主數(shù)據(jù)報(bào)文解析

針對(duì)數(shù)據(jù)資源管理平臺(tái)主數(shù)據(jù)報(bào)文解析，降低主數(shù)據(jù)服務(wù)的使用門(mén)檻：主數(shù)據(jù)存放的是各系統(tǒng)、各專業(yè)之間經(jīng)常共享卻很少變化的數(shù)據(jù)[10-13]。提供Java輔助類發(fā)送SOAP請(qǐng)求調(diào)用ws接口，按照數(shù)據(jù)資源管理平臺(tái)的接入規(guī)范解析報(bào)文，此過(guò)程中各個(gè)系統(tǒng)的XSD文檔，將具體的類和字段參數(shù)化，最終解析成對(duì)具體的庫(kù)表和字段的增刪改操作。為后續(xù)二次開(kāi)發(fā)通過(guò)SOA服務(wù)方式對(duì)接數(shù)據(jù)資源管理平臺(tái)進(jìn)行了很好的探試。數(shù)據(jù)資源管理平臺(tái)調(diào)用的流程如圖5所示。

圖5 數(shù)據(jù)流程

1.2.4 非結(jié)構(gòu)化數(shù)據(jù)封裝檢索

通過(guò)對(duì)開(kāi)源的搜索服務(wù)器Apache Solr提供數(shù)據(jù)導(dǎo)入和鏈接功能，并基于引擎進(jìn)行擴(kuò)展[14，15]。

主要的改進(jìn)點(diǎn)包括：支持更多的文件類型，利用Tika分析Office、PDF等富文本內(nèi)容；添加中文分詞支持，借助IKAnalyzer和優(yōu)化的自定義詞庫(kù)分詞功優(yōu)化中文分詞；定制schema優(yōu)化內(nèi)建的dismax查詢，把最相關(guān)的結(jié)果排在前面，提高搜索的效率。且針對(duì)原生的搜索頁(yè)面進(jìn)行了優(yōu)化，使非技術(shù)人員也可以利用頁(yè)面進(jìn)行搜索工作。此研究的開(kāi)展，將對(duì)佛山局海量文件管理、檢索帶來(lái)了巨大的便利；另外提供了定制化高級(jí)查詢、中文分詞查詢調(diào)用接口，利于開(kāi)發(fā)者二次開(kāi)發(fā)實(shí)現(xiàn)業(yè)務(wù)需求。非結(jié)構(gòu)化搜索頁(yè)面，如下圖6所示。

以定制化高級(jí)查詢接口為例：

前置條件：已定制好了專用的schema到Solr中。

路徑示例：

http://localhost:8983/solr/test_local/advquery

參數(shù)(僅列出常用幾個(gè)，也支持其他Solr通用參數(shù))：

q : String 必須，要查詢的關(guān)鍵詞。

rows : Integer 可選，分頁(yè)參數(shù)，最多返回條數(shù)。默認(rèn)為50。

圖6 檢索頁(yè)面

start : Integer 可選，分頁(yè)參數(shù)，開(kāi)始返回?cái)?shù)據(jù)序號(hào)的偏移量。默認(rèn)為0。

hl : String 可選，高亮結(jié)果開(kāi)關(guān)。默認(rèn)不開(kāi)啟。如果設(shè)置為true或者on，返回結(jié)果會(huì)顯示每個(gè)匹配文檔的高亮片段。

返回示例：

{

"response":{"numFound":9,"start":0,"maxScore":0.12659484,"docs":[

{

"size":1540150,

"lastModified":"2014-12-25T12:34:53.056Z",

"filePath":"C:UsersliuzhuangDesktopPDF阿里Hadoop集群架構(gòu)及服務(wù)體系.pdf",

"title":"通過(guò)Ganglia了解集群",

"score":0.12659484},

{

"size":4363706,

"lastModified":"2015-10-22T02:21:27.349Z",

"filePath":"C:UsersliuzhuangDesktopPDFShiro教程.pdf",

"title":"Shiro教程.doc",

"score":0.0117788175},

{

"size":8225992,

"lastModified":"2014-04-16T03:45:03.912Z",

"filePath":"C:UsersliuzhuangDesktopPDF這就是搜索引擎.pdf",

"title":" 這就是搜索引擎：核心技術(shù)詳解",

"score":0.019238723},

{

"size":2026080,

"lastModified":"2013-11-13T09:00:31.031Z",

"filePath":"C:UsersliuzhuangDesktopPDF超越Hadoop的大數(shù)據(jù).pdf",

"title":"PowerPoint Presentation",

"score":0.011354095}]

}}

1.2.5 數(shù)據(jù)流及多媒體數(shù)據(jù)組件

開(kāi)發(fā)數(shù)據(jù)流及多媒體數(shù)據(jù)組件，實(shí)現(xiàn)小帶寬下圖片、音視頻數(shù)據(jù)的快速、保真?zhèn)鬏?，提供各終端快速調(diào)用：

如今對(duì)于 JPEG、PNG 和 GIF 這些圖片格式的優(yōu)化幾乎已經(jīng)達(dá)到了極致， 若想改變現(xiàn)狀開(kāi)辟新局面，Webp則是新的選擇，例如表情包體積較大，在 2G/3G 的網(wǎng)絡(luò)環(huán)境下加載較慢、頁(yè)面圖片多加載慢問(wèn)題，反應(yīng)了針對(duì)圖片壓縮的效果對(duì)比，如圖7所示。

PNG原圖PNG無(wú)損Web P無(wú)損PNG有損(75%)Web P有損(75%)精細(xì)度Alpho透明支持(8-bit)33.8 kb30.1 kb24.1 kb9.34 kb7.16 kb體積減少-10.9%28.7%72.4%78.9%備注備選方案推薦方案

圖7 圖片壓縮的效果對(duì)比

通過(guò)企業(yè)內(nèi)部及時(shí)通信平臺(tái)開(kāi)發(fā)證明：鑒于該平臺(tái)應(yīng)用圖片消耗流量大情況，使用WebP格式，修改圖片縮略圖大小，效果比直接通過(guò)JGP壓縮要好。JPG圖片壓縮對(duì)比，如表1所示。

經(jīng)研究對(duì)比，項(xiàng)目采用了采用WebRTC核心技術(shù)框架實(shí)現(xiàn)包括音視頻采集、捕捉、編解碼、顯示、播放、壓縮等功能。WebRTC優(yōu)點(diǎn)如表2所示。

表1 JPG圖片壓縮對(duì)比

表2 WebRTC優(yōu)點(diǎn)

其中音頻采用VoiceEngine引擎多媒體處理框架，通過(guò)iSAC/iLBC解碼壓縮器方案，達(dá)到語(yǔ)音延遲少、清晰、流暢等特點(diǎn)；視頻采用VideoEngine引擎多媒體處理框架，通過(guò)視頻低延遲圖像編解碼器，視頻抖動(dòng)緩沖器，降低由于視頻抖動(dòng)和視頻信息包丟失帶來(lái)的不良影響，還通過(guò)圖像質(zhì)量增強(qiáng)模塊對(duì)網(wǎng)絡(luò)攝像頭采集到的圖像進(jìn)行處理，包括明暗度檢測(cè)、顏色增強(qiáng)、降噪處理等功能。為了視頻盡可能的保持高效，視頻數(shù)據(jù)通過(guò)不同的編碼進(jìn)行壓縮。WebRTC的核心架構(gòu)圖，如圖8所示。

圖8 WebRTC的核心架構(gòu)

1.2.6 面向移動(dòng)應(yīng)用的組件

地圖接口：改造原有地圖接口，將數(shù)據(jù)由原來(lái)的存在第三方服務(wù)器轉(zhuǎn)為存儲(chǔ)在本地服務(wù)器，規(guī)避收費(fèi)問(wèn)題、提高網(wǎng)絡(luò)安全性；改進(jìn)并開(kāi)發(fā)了多點(diǎn)路徑規(guī)劃算法。

此外，還對(duì)消息推送組件等進(jìn)行了安全性改造。

1.2.7 點(diǎn)對(duì)點(diǎn)文件傳輸技術(shù)研究

點(diǎn)對(duì)點(diǎn)文件傳輸主要應(yīng)用于兩個(gè)PC客戶端之間進(jìn)行，通過(guò)使用了即時(shí)通訊功能、WEBRTC和STUN技術(shù)成功穿透NAT，設(shè)計(jì)出UDP文件傳輸算法。

所需要完成流程的框架圖，如下圖9所示。

圖9 流程架構(gòu)

步驟1：客戶端A產(chǎn)生本地信息(IP和端口)發(fā)送給信號(hào)服務(wù)器S

步驟2：信號(hào)服務(wù)器S將A客戶端信息傳遞給客戶端B

步驟3：客戶端B同樣產(chǎn)生本地信息(IP和端口)發(fā)送給信號(hào)服務(wù)器S

步驟4：信號(hào)服務(wù)器S將客戶端B信息傳遞給客戶端A

步驟5：客戶端A(B)結(jié)合本地信息和客戶端B(A)信息發(fā)送(接收)文件

由于網(wǎng)絡(luò)傳輸層技術(shù)限制，需要穿透NAT，獲取真實(shí)的外網(wǎng)IP地址或端口，建立外網(wǎng)的通訊連接。UDP協(xié)議本身支持?jǐn)?shù)據(jù)傳輸?shù)耐暾院陀行У男ｒ?yàn)。通過(guò)自己設(shè)置算法，提供定制化的校驗(yàn)方法，保障數(shù)據(jù)傳輸?shù)目煽啃?。每次連接建立的端口隨機(jī)，并且分塊傳輸，保障數(shù)據(jù)的安全性。

文件數(shù)據(jù)的傳輸，從兩個(gè)層面上說(shuō)，一是網(wǎng)絡(luò)協(xié)議層傳輸元數(shù)據(jù)塊，二是文件數(shù)據(jù)塊傳輸。元數(shù)據(jù)是由WEBRTC實(shí)現(xiàn)的STCP協(xié)議保證數(shù)據(jù)的有效性和正確性。STCP底層可以基于UDP封裝實(shí)現(xiàn)的。文件數(shù)據(jù)塊，是企信自身設(shè)計(jì)的算法，對(duì)整個(gè)文件劃分為若干數(shù)據(jù)塊，有序的傳輸一個(gè)數(shù)據(jù)塊之后再傳遞下一個(gè)。傳輸?shù)膬蓚€(gè)終端有標(biāo)記位標(biāo)記每個(gè)數(shù)據(jù)塊是否正確接收和傳遞。文件數(shù)據(jù)塊由STCP自動(dòng)實(shí)現(xiàn)，轉(zhuǎn)換為元數(shù)據(jù)塊在網(wǎng)絡(luò)上傳輸和接收。

1.2.8 在線培訓(xùn)中心

完成二次開(kāi)發(fā)平臺(tái)門(mén)戶網(wǎng)站建設(shè)，建設(shè)在線移動(dòng)應(yīng)用開(kāi)發(fā)培訓(xùn)基地：將基于多數(shù)據(jù)格式的“平臺(tái)+組件+應(yīng)用”的移動(dòng)應(yīng)用開(kāi)發(fā)框架、移開(kāi)發(fā)指南進(jìn)行整理，構(gòu)建二次開(kāi)發(fā)平臺(tái)知識(shí)共享庫(kù)。提升了技術(shù)開(kāi)發(fā)效率，為以后佛山其他項(xiàng)目進(jìn)行移動(dòng)開(kāi)發(fā)及項(xiàng)目實(shí)施提供了很好的知識(shí)保障。

3 總結(jié)

目前將上述功能構(gòu)建為一個(gè)二次開(kāi)發(fā)平臺(tái)，有利于快速實(shí)現(xiàn)信息系統(tǒng)的開(kāi)發(fā)。通過(guò)示范性應(yīng)用的開(kāi)發(fā)表明，該平臺(tái)的開(kāi)發(fā)，實(shí)現(xiàn)了最初的出發(fā)點(diǎn)。對(duì)于縮短開(kāi)發(fā)周期、降低開(kāi)發(fā)門(mén)檻、降低開(kāi)發(fā)成本、快速響應(yīng)業(yè)務(wù)需求，具有重要的意義。