上官霞
摘 要:省級電力企業日計費平臺需要支撐千萬級用戶在一個自然日內完成所有電費計算相關任務,傳統技術架構無法實現業務目標;數據處理與計算是平臺技術設計的關鍵,本文重點分析數據處理與計算技術關鍵設計思路,以及在與微服務架構的融合設計,實現業務的快速響應、IT資源的動態擴展,支撐業務目標的實現。
關鍵詞:省級電力企業;數據計算體系;分布式架構;微服務
中圖分類號:TM912 文獻標識碼:A 文章編號:1671-2064(2018)18-0203-04
1 傳統架構計費系統遇到技術瓶頸
傳統電力計費業務是在手工業務基礎上發展起來的按月計費,具體操作時是按照用戶行業、所在區域及地理位置等屬性,將不同的用戶劃分到一個月中的不同日期進行抄表、計費、收費,習慣上稱這種計費模式為按抄表例日計費;隨著智能電表的普及和用戶對計費實時性的要求越來越高,傳統按抄表例日計費的模式已越來越不能滿足用戶對電力消費實時性感知的需求。現階段電力計費技術正朝著按日計費、甚至實時計費的方向發展。省級電力企業計費業務復雜度高、用戶基數大、需求變化快、性能要求高,特別是近幾年,隨著社會生活水平的進步,用戶在應用體驗、實時性、智能化等方面要求越來越高,促使電力計費業務呈現變化更快、形式更多樣化的特征。
經測試,如果采用傳統架構進行按日計費,應用服務器CPU使用超過60%、內存使用率達到99%,大部分時間超過警戒指標,性能趨于飽和。數據庫服務器內存使用率高達93%,CPU使用率高達80%,性能趨于飽和,且無法簡單增加服務器實現性能擴展,只能通過增加內存、CPU個數實現性能擴展,性能擴展的空間小。
基于業務發展需求和集團公司信息化方向指引,采用分布式微服務技術路線,建設了高效率、高可靠的創新型省級電力企業實時日計費平臺,實現IT資源動態分配、性能彈性伸展、功能逐步注入,滿足全省千萬級數量的用戶當日抄表采集、當日完成計費的業務要求和計費業務的快速變化發展要求。
2 數據處理與計算體系總體設計思路
按照信息結構化設計方法論中的IPO設計思路,數據處理環節可以分為輸入(Input)、加工(Processing)、輸出(Output)三類,省級電力企業日計費平臺數據處理與計算體系總體框架如圖1所示。
數據輸入環節主要是各類業務數據和智能電表數據以合適的方式輸入到電力企業日計費平臺,數據加工環節主要是指電力企業日計費平臺的數據存儲、數據計算、數據應用,輸出環節主要是指電力企業日計費平臺將數據輸出到各業務系統。
3 數據交互關鍵技術
數據交互技術是指數據輸入(Input)、輸出(Output)過程中涉及到的技術,對于省級計費平臺涉及用戶超過千萬,數據記錄數超過億級,發何有效、及時、有序、準確地處理大數據量的輸入、輸出,對平臺是個挑戰。
3.1 數據交互技術
日計費平臺主要使用營銷基礎檔案數據及計費參數、抄表示數三大類主要數據,通過邏輯運算完成整個計費過程,與營銷系統間的數據交互簡圖如圖2所示。
3.1.1 業務基礎數據實時獲取
采用成熟可靠的商業化復制軟件,保障業務基礎數據從源系統中實時可靠同步至本系統。滿足上層業務開展的數據需求。商業化復制軟件基于數據庫日志分析原理,能高效的獲取源端系統的數據變化情況,實現增量數據的實時復制,保障目標業務系統的實時性需求。
3.1.2 業務結果數據可控回寫
營銷系統為核心的業務系統,涉及多套外圍系統數據復制軟件,如管理庫復制,災備中心復制、基礎數據平臺復制、國網客戶復制、稽查系統復制等。全省計費結果數據需采用平穩可控的回寫策略,消除對營銷及外圍系統的沖擊。
回寫方式優先級:主要區別常規回寫和緊急回寫,如表1所示。
回寫數據分類優先級:依據業務對數據的需求不同,對各類數據回寫優化級設計如表2所示。
數據回寫時段可控設計:
1號當天大數據量數據生產發生在下午14點后持續到凌晨3點左右,最高峰值為45GB每小時,復制軟件OGG處理能力:55GB/H(4extract\4replicat)。
數據回寫組件依據以上曲線規律,回寫時避開高峰時段,加大低谷時段回寫量作到可控回寫,保持營銷系統平穩的處理數據。
3.1.3 數據回寫對原業務影響
全省電費業務數據集中在1天完成,必然會對原來業務產生影響,為保障業務系統平穩,將對受影響業務功能進行調整設計,如表3所示。
3.2 分布式緩存數據訪問技術
通過分布式緩存的高速存儲及訪問技術,提高熱點數據的訪問效率。分布式緩存是基于內存的緩存服務,支持海量數據的高速訪問,支持Key-Value的數據結構,兼容Memcached協議的客戶端都可與之通信。同時分布式緩存支持即開即用的方式快速部署;對于服務應用,可通過緩存服務減輕對數據庫的壓力,從而提高整體的響應速度。平臺支撐提供公共的緩存服務,并對外提供公共API。應用開發者開發的微應用,通過公共API,調用訪問緩存服務,與分布式緩存交互。
平臺支撐功能提供公用的分布式消息集成服務,對外提供公共API。開發者無需關心底層實現,只要調用接口就可以完成消息的發送和接收等功能。如圖4所示。
4 數據存儲關鍵技術設計
4.1 通過分布式數據庫設計,解決數據庫性能瓶頸
為解決單機數據性能瓶頸,在TPS/QPS/內存容量/磁盤容量等等一系列系統資源上會碰到各類限制。本架構上運用了分布式數據庫的讀寫分離和數據庫切分技術。
分布式數據庫與傳統數據庫訪問協議一樣,都采用JDBC協議。應用通過持久化框架,并實現了支持多數據源操作事物控制框架。應用開發者,可以通過公共API,可以調用訪問分布式數據庫。系統監控數據庫性能瓶頸時,可以根據秒級擴容切換,對應用影響極小。如圖5所示。
4.2 數據拆分存儲
為提升數據讀寫性能,需要根據業務邏輯、數據關聯需求及系統特性進行的數據邏輯拆分存儲,常用的數據拆分方式有分表和分區。
本系統為提升程序通用性,提升開發效率采用分區處理方式對大表數據進行邏輯拆分。
4.2.1 數據拆分原則
以業務應用需求為依據,均衡拆分數據。單表數據量大于2GB的表,需要進行拆分。
4.2.2 拆分區域存儲思路
數據拆分主要針對數據大表,電費計算業務大表主要是“基礎檔案”、“檔案快照”、“計費快照”、“電度電費”,“電價電費”。電費計算業務的開展以管理單位下的抄表段為基礎,業務數據應用均在同一單位范圍,以管理單位為條件將數據拆分到多個邏輯分區中。電費計算以月為工作周期,需處理近1600萬用戶的電費測算,單個邏輯分區內以時間為條件將數據拆分到多個表,從而實現數據的多級分區。如圖6所示:
具體拆分設計如下:
(1)基礎檔案類數據大表,按單位字段作一級拆分(以范圍拆分方法,將數據按單位拆分)。如:用戶檔案表C_CONS數據1600萬,以范圍拆分方法,將數據按單位拆分成多個邏輯分區,分散存儲IO壓力加快數據查詢速度。
(2)電費計算類數據大表,按單位和時間字段作兩級拆分(先以范圍拆分方法,將數據按單位拆分,再列表拆分方法,將數據按天拆分)。如:用電客戶快照ARC_E_CONS_SNAP每月費控用戶按1600萬計算,按單位拆分為多個一級分區,再按月拆分成多個二級分區,分散存儲IO壓力加快數據查詢速度。
4.2.3 數據存儲及分布
營銷集中抄表核算應用數據存儲主要分布于兩大區域:高速存儲區、數據持久層。
全省1600萬用戶,一天完成全省計算需要反復并發讀取檔案快照、計費快照等快照數據,數據讀取形成熱點,此部分數據在作冗余設計之后,采用高速存儲技術,提升數據響應時間,加快測算速度。
檔案數據、抄表數據以及計算之后的電費數據,量體較大且數據批量加載,對存儲IO能力及存儲容量要求壓力較大,需要分散存儲解決IO及存儲上限。此部分數據應用采用具備橫向擴展能力存儲設備進行管理。
全省計算結果數據量較大,系統僅保留3個月電費計算結果數據,不作歷史數據存儲。所有結果數據回寫營銷業務系統存儲,作持久層存儲。如圖7所示。
5 數據計算及應用關鍵技術
基于微服務的分布式技術。微服務架構的優點是服務作為工作單元可以非常便利的管理、可以非??焖俚膭討B擴展,服務之間解除耦合,減少依賴,極大的提供了穩定性,為運維管理動態發布提供了良好的架構支持。微服務功能單一,服務接口友好,為業務系統升級和擴展提供了良好的技術基礎。微服務粒度小,輕便靈活,實現快速靈活部署,提高運維效率和系統性能。
(1)單一的微服務功能盡可能實現單一獨立的功能,業務邊界清晰,避免業務耦合。
(2)服務間的交互通過輕量級的API接口實現。
(3)采用容器化技術進行微服務的封裝、部署、管控。為不同類型的微服務提供差異化的管理策略,并對服務進行服務設計、編排、授權、配置,以實現復雜多樣的應用場景能夠快速交付、獨立部署、實現高可用、彈性擴展。同時,對微服務設計了整套應用程序部署流程,包括服務注冊和發布、服務接入管控、服務調度、服務恢復和服務監控等。
6 結語
本文主要分析省級電力企業日計費平臺在數據處理與計算方面的實踐,通過數據交互技術、數據存儲技術、數據計算與應用技術的成功實踐應用,支撐千萬級用戶當日計費的業務需求,從而最終實現業務服務化轉型,開啟電力營銷業務應用全面微服務化轉型的大門,促進微服務理念在電力企業的應用,為營銷業務應用整體微服務改造提供借鑒經驗。
參考文獻
[1]Eric Evans.《領域驅動設計:軟件核心復雜性應對之道》[M].人民郵電出版社,2016.
[2]王磊.《微服務架構與實踐》[M].電子工業出版社,2016.
[3]李林鋒.《分布式服務框架原理與實踐》[M].電子工業出版社,2016.
[4]Sam Newman.《微服務設計》[M].人民郵電出版社,2016.
[5]馬丁 L.阿伯特.《架構即未來》[M].機械工業出版社,2016.