摘要：當(dāng)電力故障發(fā)生時，普通用戶通常求助于供電部門的服務(wù)熱線，但其只負(fù)責(zé)戶外公共用電設(shè)備的維護(hù)，無法介入戶內(nèi)進(jìn)行維修，無效的報修請求造成了公共報修資源的浪費，同時普通用戶也沒有專業(yè)的渠道能及時尋找到有可靠資質(zhì)的維修師傅。為了解決這一社會問題，該項目依托所屬地公司，整合具備資質(zhì)的第三方維修公司、用戶報修渠道、供電公司管控等資源構(gòu)建了一個以Web應(yīng)用、安卓端App、微信小程序與可視化數(shù)據(jù)分析中心四方互聯(lián)的電力全流程報修平臺，同時集成云端集群，實現(xiàn)了電力維保的科學(xué)化、精確化與智能化。

　　關(guān)鍵詞：電力報修;監(jiān)控平臺;云集群;可視化

　　1引言

　　近年來，隨著經(jīng)濟的高速發(fā)展，人們對電力的依賴程度不斷加大[1]。當(dāng)電力故障發(fā)生時，普通用戶通常會撥打供電公司的報修電話尋求幫助，但是供電公司維護(hù)的是戶外的公共用電設(shè)備，而非入戶的電力設(shè)備與線路，無效的報修請求造成用戶對供電公司不作為的誤解，也造成了公共報修資源的浪費。面對急需解決的用電故障，普通用戶會求助于社區(qū)論壇等一些信息平臺或街邊小廣告。這些信息中往往存在著資質(zhì)可靠工人少、服務(wù)范圍窄、反饋時間長等諸多問題。另一方面，社會上對普通用戶的家庭用電故障的維修服務(wù)沒有統(tǒng)一的標(biāo)準(zhǔn)與監(jiān)管渠道，維修過程始終處于無監(jiān)管狀態(tài)，維修質(zhì)量完全取決于各個維修師傅的態(tài)度認(rèn)真程度，其中產(chǎn)生的價格糾紛和質(zhì)量問題往往處于不可控狀態(tài)。因此，基于供電公司整合社會上符合資質(zhì)的維修維護(hù)人員構(gòu)建一個高效、權(quán)威、全流程監(jiān)管的電力報修平臺，實現(xiàn)電力維保的科學(xué)化與精準(zhǔn)化就顯得尤為重要。

　　2需求分析

　　通過對各方的走訪調(diào)查，得出各方需求具體如下：

　　1)針對客戶

　　①專業(yè)的維修工人。

　　②完善的投訴監(jiān)管渠道。

　　③迅速的訂單處理速度。

　　④易操作的提交訂單程序。

　　2)針對工人

　　①完善的考評機制。

　　②簡易的故障問題梳理。

　　③易操作的接單應(yīng)用。

　　3)針對管理人員與決策高層

　　①分流無用報修電話。

　　②全流程監(jiān)控業(yè)務(wù)訂單狀況。

　　③科學(xué)化管理報修基礎(chǔ)數(shù)據(jù)。

　　④圖例化展示電力維保信息，提高工作效率。

　　⑤基于歷史數(shù)據(jù)進(jìn)行相應(yīng)數(shù)據(jù)分析，提高決策支持能力。

　　3總體設(shè)計

　　本平臺依托所屬地供電公司，整合社會上符合資質(zhì)的電力維保人員構(gòu)建了一個以Web應(yīng)用、安卓端、微信小程序與可視化大屏四方互聯(lián)的電力全流程報修平臺。在平臺中，用戶可通過微信小程序進(jìn)行及時的故障報修與反饋評價;工人可以通過安卓端及時接收服務(wù)推送并對維修全流程進(jìn)行跟蹤記錄;管理員可以通過后臺管理端對工人資質(zhì)進(jìn)行審核，打通95598服務(wù)和相關(guān)內(nèi)部用電維修資源。同時項目集成云端集群，采用分布式存儲與并行數(shù)據(jù)分析，實現(xiàn)對維修資源的智能調(diào)度與全流程監(jiān)管，真正實現(xiàn)電力維保的科學(xué)化、精確化與智能化。

　　3.1平臺總體架構(gòu)

　　本平臺的總體架構(gòu)如圖1所示，主要由防火墻服務(wù)，一臺 Nginx服務(wù)器，兩臺后臺服務(wù)器，一臺Redis服務(wù)器，一臺MySQL 服務(wù)器以及云服務(wù)器集群構(gòu)成。下面將從實際場景切入，一一介紹每一個技術(shù)點的作用及意義。

　　1)防火墻：安卓端、小程序端、Web管理端以及可視化大屏向后臺服務(wù)器發(fā)送請求，請求首先會被防火墻攔截。這里的防火墻作用有兩點：一是抵擋了大部分DDos和XSS攻擊，二是避免SQL注入引發(fā)的數(shù)據(jù)庫崩潰問題。

　　2)負(fù)載均衡：經(jīng)防火墻過濾之后的請求會通過 Nginx 服務(wù)器，即負(fù)載均衡服務(wù)器。Nginx會綜合考慮兩臺后臺服務(wù)器的各類因素(內(nèi)存占用，CPU利用率等)來選擇合適的服務(wù)器將請求轉(zhuǎn)發(fā)。有效解決大部分請求涌入同一臺服務(wù)器而造成服務(wù)器內(nèi)存長時間占用過高的問題[2]。

　　3)設(shè)置兩臺后臺服務(wù)器有兩點原因：

　　①如果只有一臺服務(wù)器，在程序沒有優(yōu)化得足夠好的情況下，大量的請求涌入可能會出現(xiàn)上述內(nèi)存占用過高的問題，進(jìn)一步可能導(dǎo)致服務(wù)器的崩潰。

　　②使用兩臺服務(wù)器實際上采用fallback機制，當(dāng)系統(tǒng)需要更新時，可以在服務(wù)器A上進(jìn)行更新，而服務(wù)器B則繼續(xù)接收請求，當(dāng)服務(wù)器A更新完后再更新服務(wù)器B，轉(zhuǎn)由服務(wù)器A接收請求，這樣的需求在一臺服務(wù)器上是不可以實現(xiàn)的。

　　4)冷熱數(shù)據(jù)切換：在設(shè)計本平臺的過程中，發(fā)現(xiàn)有多類數(shù)據(jù)需要被頻繁訪問(如：訂單，客戶評價等數(shù)據(jù))，考慮到平臺將來的落地背景，在使用的用戶有一定規(guī)模的情況下，如此頻繁地向數(shù)據(jù)庫訪問這些熱點數(shù)據(jù)會造成MySQL性能的下降。所以考慮使用Redis來和MySQL進(jìn)行冷熱數(shù)據(jù)的切換，當(dāng)用戶上線時，把一些用戶可能需要頻繁訪問的熱點數(shù)據(jù)從MySQL轉(zhuǎn)移到Redis 中。這樣，當(dāng)用戶訪問這些熱點數(shù)據(jù)時，直接可以從 Redis服務(wù)器中抽取數(shù)據(jù)，獲取數(shù)據(jù)的速度有較大提升。在每天凌晨，或是用戶很久不上線的時候再把這些熱點數(shù)據(jù)回傳到 MySQL服務(wù)器中變成冷數(shù)據(jù)，實現(xiàn)數(shù)據(jù)的持久化。

　　5)云服務(wù)器集群：本平臺為方便管理員與決策高層清晰地觀察系統(tǒng)的運行狀況及用戶、工人的使用情況，集成了可視化展示功能。考慮到平臺未來落地的背景，且對數(shù)據(jù)分析算法性能的高度要求，本平臺進(jìn)一步引進(jìn)基于 Hadoop 的云服務(wù)器集群，實現(xiàn)聯(lián)機并行的統(tǒng)計分析。同時，一些圖片、視頻、json等存儲占用率高的數(shù)據(jù)也存儲在云端，充分減輕后臺數(shù)據(jù)庫的存儲壓力。

　　3.2數(shù)據(jù)庫設(shè)計

　　本平臺數(shù)據(jù)庫針對決策人員所提出的數(shù)據(jù)統(tǒng)計分析需求，同時為滿足用戶與工人業(yè)務(wù)即時性的需要，合理設(shè)定索引，有效提升平臺的數(shù)據(jù)分析與信息檢索效率。各表屬性設(shè)定滿足范式要求，并通過相應(yīng)存儲過程的設(shè)置對客戶的電話、住址等個人信息進(jìn)行有效性檢測，充分加強平臺信息的真實性與可靠性，具體數(shù)據(jù)庫E-R 圖如圖2示。