“大數據+云計算+微服務”在福建省精準扶貧中的應用①

胡 波

(福建省財政信息中心,福州 350003)

大數據、云計算是目前較為前沿的信息技術,被廣泛用于智慧城市、物聯網、金融分析、軍事、公檢法等各個領域;微服務技術是近年興起的先進信息技術,我國目前雖然有在一些小領域、小規模應用該技術,但仍處于試驗探索階段,特別是如何利用微服務技術優勢,解決傳統SOA 架構普遍存在的并發量瓶頸和無法充分利用云計算資源動態分配功能等問題,還在進一步探索中.如何將大數據、云計算、微服務等信息技術同國家建設過程有機結合,解決國家政策執行過程無法及時監督、執行效果無法及時掌握、出現問題無法及時發現和處理結果無法及時了解等一系列“及時”問題,提高政策執行效率和人民滿意度,成為目前信息領域研究的重點課題.

在全國精準扶貧、精準脫貧背景下,本文以福建省扶貧(惠民)資金在線監管系統為例,介紹如何運用大數據、云計算、微服務等信息技術解決扶貧對象精準、項目安排精準、資金使用精準等問題,實現對扶貧(惠民)資金全流程精準監控,確保扶貧資金精準發放.

1 技術介紹

1.1 大數據技術

1.1.1 Hadoop

Hadoop 是由Apache 基金會開發的一個分布式系統架構[1],由HDFS (Hadoop Distributed File System,分布式文件系統)、MapReduce (并行運算編程模型)、HBase (Hadoop Database,數據庫)、ZooKeeper (分布式協調服務)和Hive (數據倉庫架構)等成員組成,提供分布式數據存儲和并行處理數據方式,高效實現對海量數據的分布式存儲和處理,并為應用程序提供高可靠性透明接口.

其中HDFS 是專門為海量數據處理分析而設計的高容錯性分布式文件系統[2].MapReduce 用于計算海量數據[3,4].HBase 是建立在HDFS 之上面向列的分布式存儲系統[5,6],它利用MapReduce 處理HBase 中的海量數據[7,8].Hive 為數據倉庫使用者提供海量數據存儲、數據ETL、數據查詢和分析[9].ZooKeeper 為分布式應用提供域名、分布式同步等一致性服務[10].

1.1.2 Spark

Spark 是專為大規模數據處理設計的快速通用計算引擎,是Hadoop MapReduce 通用并行框架.它啟用了內存分布數據集,不僅能夠提供交互式查詢,還能優化迭代工作負載,因此能更好適用于數據挖掘與機器學習等需要迭代的MapReduce 的算法[11].

1.1.3 Kerberos

Kerberos 是一種網絡認證協議,認證過程不依賴主機操作系統認證,無需基于主機地址信任,不要求網絡上所有主機物理安全,并假定網絡上傳送的數據包可被任意地讀取、修改和插入數據.

1.2 Elastic Search

Elastic Search (ES),一種基于Lucene 構建的全文搜索引擎、數據分析引擎和分布式文檔數據庫,每個字段均可被索引和搜索,能在極短時間內存儲、搜索和分析大量數據,通常用于復雜搜索場景下的全文檢索、結構化檢索和分析.相對于傳統搜索引擎,ES 具有高擴展性、高實時性、高可用性等三大明顯優勢,通過分片分布處理方式提升處理效能,可橫向擴展至數以百計的服務器存儲以及處理PB 級數據.

1.3 微服務架構

微服務是一些協同工作的,具有高內聚性和高自治性的小而自治服務[12],核心理念在于將復雜應用拆分成多個可單獨構建和部署的功能,每個功能稱之為服務[13].微服務架構旨在實現對復雜應用的快速開發,本質是由一組可獨立交付的微服務業務單元構成的分布式系統[14].相對于SOA 架構來說,微服務架構具有復雜度可控、架構靈活、技術多元化、功能易擴展、獨立自治等主要特點[15].

2 總體建設思路

利用大數據、云計算、微服務等信息技術,建立覆蓋省、市、縣、鄉四級的扶貧(惠民)資金在線監管系統,及時掌握項目和資金動態,實現對資金各環節無死角在線跟蹤監督,加強對政策和資金的審計監督檢查,消除監管“盲區”,強化信息主動公開,讓老百姓由被動參與變為主動監督,讓扶貧(惠民)工作在陽光下運行,確保資金精準安全有效使用,實現精準扶貧和脫貧.

3 系統體系架構

考慮扶貧(惠民)資金涉及省、市、縣、鄉四級財政,為及時獲取全省資金動態執行情況,實現對資金的全流程監管,系統采用全省集中部署模式,部署在福建政務云上.系統體系架構從縱橫兩個方向保障系統安全、穩定、高效運行,縱向分為應用軟件服務層 (SaaS)、平臺服務層(PaaS)及基礎設施服務層(IaaS)等三層,橫向包括運維體系和安全體系等兩個體系.

其中SaaS 云應用,基于云架構,微服務構建扶貧(惠民)資金在線監管云應用.PaaS 云平臺,提供云中間件服務、微服務治理、運行時應用管理和能力共享中心等.以PaaS 平臺為核心構建大數據平臺,并預留規劃相關專題技術平臺能力,全面支撐SaaS 應用.IaaS 云基礎設施,基于OpenStack 產品,實現計算、存儲、網絡資源虛擬化和資源管理功能,按需為PaaS 云平臺提供資源.運維體系和安全體系作為全局公共能力貫穿各個層面,為整個系統長期穩定運行提供運維和安全保障服務.

系統體系架構如圖1所示.

圖1 系統總體體系架構

4 關鍵技術應用

4.1 大數據技術應用

扶貧(惠民)資金覆蓋省、市、縣、鄉四級財政,涉及全省所有關心扶貧(惠民)信息的人員.系統除預算編制,預算執行等內生數據外,為防止出現扶貧(惠民)資金冒領騙領現象發生,系統外接工商、稅務、社保、公安、住建、19 家代理銀行等部門,分別獲取企業工商登記注冊、企業和個人納稅、個人社保、住房購買、車輛購買、銀行到賬等外生數據,構建精準扶貧大數據分析庫,后期還將接入火化人口、公積金繳納等數據,因此系統數據量和訪問量都相當巨大.為保證系統穩定和時效性,特別是公眾訪問系統的響應速度,系統采用Hadoop+Hive+Spark+ES 等大數據技術,確保響應時間控制在5 ms 以內,大數據應用示意圖如圖2所示.

如圖2所示,系統使用Hadoop 平臺做為基礎平臺部署,提供資源調度及HDFS 存儲服務,采用Hive 做為數據倉庫來存儲原始業務數據以及各分層匯總數據.使用Spark 做ETL 處理引擎,由Spark 讀取Hive 元數據做ETL 清洗、轉換及匯總操作.匯總數據存放在Hive 數據庫的匯總結果表中.使用ES 做搜索引擎,提供查詢檢索功能,ES 讀取Hive 庫結果表數據,創建索引庫.應用Nginx 代理服務器等成熟中間件產品,提高查詢效力.使用Kerberos 做大數據集群安全框架.

數據展現層分為傳統PC 網站和微信小程序+手機APP 等兩種展現形式.系統通過Spring Cloud 微服務提供Restful 方式的對外數據訪問接口,供展現層調用.ES 提供統一數據查詢接口為展現層提供數據服務.

4.2 微服務架構設計應用

為減少數據量和負載因素對系統性能的影響,系統采用微服務架構,將系統按功能拆分為多個獨立的服務組件;同時利用云計算技術,根據負載情況動態合理分配系統資源.政務云通過公共組件微服務化,避免業務應用對接公共組件時,因特定技術要求給業務應用開發帶來更多工作量和架構靈活性限制.各功能均以微服務方式獨立部署,平臺、應用、運維能力均實現微服務化,實現平臺和應用徹底解耦.

圖2 大數據應用示意圖

4.2.1 系統分層微服務架構

結合業務管理特征和發展趨勢,統一規劃業務應用系統,將系統劃分為前臺、中臺、后臺3 層,每層包含相應的微服務,解耦業務辦理、公共支撐、業務管控和決策分析等能力,使它們有效協同.同時系統采用前端輕應用、后端微服務的前后端分離模式,具體系統業務分層微服務架構圖如圖3.

如圖3所示:前臺以業務和角色為中心構建作業平臺,支撐靈活高效運作.前臺連接財政用戶、扶貧相關部門、社會公眾等3 類用戶,構建以OA 為基礎的統一門戶,快速響應業務變化和業務應用,支持彈性伸縮.

中臺以公共組件為核心為微服務提供支撐,實現業務、技術能力共享化和服務化,支撐前臺生產類應用作業平臺構建.中臺面向前臺應用,構建服務中心和API 中心,實現服務治理和數據治理;構建通用應用能力,包括公共業務、公共辦公、應用支撐等服務,實現業務運作服務化、共享化.

后臺面向領導和決策層,實現作業過程與結果透明可視,如資金流可視、業務流可視、扶貧(惠民)對象畫像等.后臺圍繞數據資產,建設統一的數據底座,基于大數據構建決策支持、監控預警、查詢分析3 類應用,實現業務洞察和監管能力.

4.2.2 微服務應用關鍵步驟

系統微服務應用關鍵步驟具體如下:

(1)構建接口契約優先的運作機制,協同工作.微服務設計堅持契約優先原則,即先有契約后有微服務實現.首先基于Swagger Open API 規范定義接口契約,契約以人與機器均可讀懂格式描述微服務及其API 接口,作為服務提供方對外功能和服務水平的承諾.服務提供方基于契約實現微服務,微服務使用方基于契約調用微服務,各方基于契約協同工作.微服務均可基于契約進行替換,即當微服務出現嚴重問題時,可按契約無縫替換,不影響系統運行,并形成以微服務為核心的可拆可合、開放的“扶貧(惠民)信息化生態”.

(2)構建服務中心、API 中心,管理和運營“扶貧(惠民)信息化生態”.將微服務注冊到服務中心,微服務API 接口注冊到API 中心,通過在線、統一排錯和度量評價體系,界定問題邊界,識別需要改進或替換的微服務,保證各方有效協作,為“信息化生態”運營提供支撐,機制如圖4所示.

如圖4所示,服務中心提供服務市場,供管理用戶在線瀏覽、查詢服務詳情,支持線上評價和提出改進建議;提供微服務治理,通過調用鏈功能,支持端到端定位排錯、界定問題邊界和責任.API 中心對API 接口全生命周期進行管理,管控微服務和接入應用之間的調用關系,并對API 接口調用情況進行監控,提供各種性能指標、異常指標、SLA 指標及運營報表,全面度量微服務及其API 接口質量.通過上述機制,避免在公共微服務集成過程中可能出現的問題定位不清、互相推諉等情況,支持對公共微服務持續改進.

圖3 系統分層微服務架構

對于標準存儲、基礎數據等核心公共微服務,由用戶統一定義微服務接口契約,并將接口契約發布到API 中心.微服務接口契約經用戶審核后將接口契約發布到API 中心.軟件開發商根據契約提供微服務,并由微服務中心、API 中心提供相關度量和改進機制,最終形成一個完整的生態管理體系.

(3)構建包括應用支撐服務在內的服務化中臺,規范和支撐業務應用建設公共能力服務化設計,包括公共業務、公共辦公、應用支撐和管控等服務,最終構建服務化平臺,是業務應用建設的一個關鍵點.

4.2.3 微服務設計關鍵要求

在設計微服務時,需遵循或注意幾個原則和要求,以達到采用微服務最佳效果.

(1)系統遵循前后端分離原則,即前端輕量級應用、后端微服務.前端輕應用采用成熟的前端單頁面技術開發,通過ajax 異步請求與后臺微服務交互,快速響應業務變化的輕量級應用;后端微服務為獨立部署運行的業務邏輯單元,通過統一的API 網關供前端輕應用調用,數據交換格式為JSON 格式.前后端分離優勢在于前后端獨立打包發布,相互獨立,互不影響,便于系統開發維護,同時前端頁面靜態化,便于使用客戶端緩存,提高系統并發性能.

(2)遵循業務驅動原則,將業務應用分解為微服務.

(3)微服務治理要求,所有業務微服務統一注冊到服務中心.所有微服務接口統一采用REST 通信協議,均注冊到API 中心.微服務須采用平臺統一用戶、角色、權限管理體系,統一SSO 認證.

(4)運維服務化設計,依靠服務化工具鏈,在運維階段實現高效服務化運維.前后端應用實現容器化部署,所有配置通過統一配置服務獲取.

5 實現成果

5.1 全省扶貧部門、人員全覆蓋

按照“橫向到邊,縱向到底”要求,系統橫向覆蓋扶貧(惠民)資金涉及的12 個主管部門,并與福建省內19 家商業銀行實現數據對接;縱向貫穿省市縣鄉四級,包括9 個設區市和平潭綜合實驗區、83 縣(市、區)、1105 個鄉鎮.目前系統操作用戶達1.8 萬人,幫扶對象涉及1.7 萬個村居、628 萬人.

圖4 扶貧(惠民)信息化生態管理圖

5.2 資金流程監督全覆蓋

系統對扶貧(惠民)資金的流向、流量和流速進行全方位監督.其中:流向監督主要是運用工商登記、養老保險、醫保、稅收、車輛、住房等數據,對建檔立卡貧困戶、低保戶進行精準識別.流量監督主要是將銀行反饋到賬數據與鄉鎮填報的應發放數據比對,確保應發盡發,足額到位.流速監督主要是動態監控資金分配、審批、下達全過程運轉時效,確保資金及時發放到位.

為及時從系統中發現資金問題節點,按照“共性+個性”思路和各類扶貧資金管理辦法要求,通過設置預警規則、預警閾值,按預警級別對資金項目申報、審批、下達等環節進行實時動態查驗.根據嚴重程度不同,將預警級別分為紅黃兩種顏色,紅色表示嚴重預警,包括發放對象不精準和發放金額與銀行反饋數據不一致等情況.黃色表示一般預警,包括資金下達不夠及時、銀行反饋數據不完整等情況.

2018年系統對21 項扶貧資金、2 項救災資金實行全流程監管,涉及資金40 億元,惠及118 萬幫扶對象;2019年系統增加對14 項惠民資金監管,涉及資金70.1 億元以上,惠及614 萬幫扶對象.

圖5及圖6為福建省扶貧(惠民)資金監管結果圖.

圖5 扶貧(惠民)資金監管總體圖

5.3 扶助對象識別更加精準

系統通過大數據技術核查建檔立卡貧困戶信息和資金發放信息是否準確無誤,對于在城市務工獲取社保、購買房屋、擁有車輛或成立公司等可能已經脫貧人員,經核對查實后,將從建檔立卡貧困戶名單中移除并相應處理;對于未準確發放或者核實為冒領、騙領的,紀委將根據程序移送司法機關.2018年系統上線以來,通過大數據識別對比,發現大量貧困低保戶人員存在異常信息,主要為系統顯示貧困低保戶有注冊為公司法人或在企業繳納社保金額已經超出低保范圍等.經核實,大部分注冊為公司法人的情況為其親戚或朋友借用其身份證注冊公司,本人不知情或并未從中獲取利益,對于這種情況則要求本人到工商局注銷公司法人身份;目前系統發現低保對象異常信息10 176 條,由省民政廳分類核實身份信息,確定繼續保障對象4337 人,延保漸退2147 人,取消退保3692 人.以每低保戶每月300 元計算,每年將節省財政資金2000 多萬元,維護了公平和正義,大大提高了政府公信力和群眾滿意度.

圖6 扶貧(惠民)項目績效主要產出圖

5.4 全民參與監督

為實現全民參與監督,系統將專項管理辦法、項目信息、審批信息、補助資金發放信息等通過網站和手機APP、微信小程序等進行全面有效的信息公開.為方便群眾及時知道和下載微信小程序和手機APP,通過短信、電視、二維碼等多種途徑向全省公眾推送.為方便群眾發現問題能及時反饋,系統通過接口與省紀委監委舉報網站對接,實現一鍵舉報.目前微信小程序和手機APP 訪問量超兩千萬,日均訪問量超10 萬,網站、微信小程序和手機APP 樣例如圖7.

圖7 數據展示信息

5.5 精準扶貧試驗田

本系統建設獲得國務院和財政部的充分肯定,財政部指出該系統建起來后,有利于明晰責任,是財政管理的重大成果和制度創新,以后各方面資金都可以用來監管,因此系統帶有“試驗田”的作用,并以本系統為樣板建設了全國財政扶貧資金動態監控平臺,在全國推廣應用.

6 系統建設經驗

6.1 數據庫選用

系統在完成微服務改造并部署到云上后,能否利用云計算優勢,根據負載情況動態合理為微服務分配系統資源,提高系統并發性和時效性,還有一個關鍵因素,即是否采用支持云化服務的數據庫,這是很多人忽視的地方.在分別使用傳統數據庫和支持云化服務數據庫時,并發量和系統性能之間會呈現一定關系.使用傳統數據庫時,系統在性能不影響的情況下,并發數最多只能達到300 個,如果超過300 個,系統響應速度急劇下降,系統出現不動或者白屏狀態.但使用支持云化服務數據庫時,系統在性能不影響的情況下,并發量可以達到2000 個.目前政府機關建設大型信息化系統大部分使用Oracle 數據庫,但Oracle12C 數據庫之前的版本均不支持云化服務,因此如果要到達理想的并發性和時效性,需要使用Oracle12C 及之后的版本.

6.2 微服務最佳顆粒度

目前微服務概念在國內興起也好幾年,但真正將微服務用好的大型政務系統,在國內幾乎沒有,大部分都處于嘗試階段,包括本系統在內.從目前已經嘗試采用微服務架構的國內某些系統來看,效果不一定優于采用SOA 系統架構的系統,主要原因是大家僅在概念上理解微服務,微服務到底微到什么程度最為合適,效果最好,目前沒有明確說法,也很難判斷.本系統在建設初期,為防止出現因微服務顆粒度選擇不合適導致大量無用功情況的發生,在此先開展微服務顆粒度合適程度測試,并使用4 種顆粒度分法.

第1 種顆粒度分法,將每個細小的功能環節,比如預算指標下達,計劃審核,公文起草等,都設計成微服務.按照這種分法,本系統需設計的微服務數量將達到幾千個.

第2 種顆粒度分法,變大微服務顆粒度,對每一個完整的功能服務,比如預算指標服務,對賬服務,“小額貸款”資金申報服務等設計成微服務,采用該種分法,微服務數量縮小到不到100 個.

第3 種顆粒度分法,繼續變大微服務顆粒度,對每一個完整的管理服務,比如專項資金項目管理,專項資金分配管理,系統設置服務,監控預警和風險防控服務,外網信息公開服務,OA 管理服務等設計成微服務.依照此種分法,微服務數量將進一步縮小到僅15 個.

第4 種顆粒度分法,綜合第2 和第3 種顆粒度分法,將并發量大,訪問頻繁的模塊按照第2 種顆粒度拆分,比如預算指標服務和對賬服務等;對于并發量小,訪問不是太頻繁的功能模塊按照第3 種顆粒度拆分,比如系統設置服務和OA 管理服務等.這種拆分方式,微服務數據量可以控制在50 個以內.

圖8為采用Oracle12C 數據庫,不同顆粒度微服務與并發量、系統性能(用系統響應時間代表系統性能)之間關系圖,其中橫坐標表示并發量,縱坐標為系統響應時間,曲線A～D 分別代表第1～4 種顆粒度.

圖8 顆粒度與并發量關系圖

從圖8可以看出,在并發量不超過500 時,4 種顆粒度的系統性能差距不大.但是超過500 后,系統的性能和并發量并沒有因為顆粒度越細而使系統性能越好;相反,采用第一種顆粒度,微服務最多,但是系統性能不僅沒有明顯提高,反而表現最差,在達到1000 并發量后,系統性能迅速變差.采用第2、3、4 種顆粒度的系統性能和穩定性明顯高于第1 種顆粒度,其中系統性能最好的是采用第2 種顆粒度的,在并發量達到2000 時,系統性能依然在1 s 范圍內,其次是第4 種,介于第2 種與第3 種之間.

隨著顆粒度的增加,系統開發時間將會變長,同時部署難度也將隨著增大.在綜合考慮開發成本、時間效率以及后期系統在政務云平臺部署難度等一些列因素后,本系統最終決定采用第4 種顆粒度分法.因此在選擇微服務顆粒度大小時,要根據系統實際業務場景情況來劃分,到底要拆的多細,絕不僅僅只是個技術問題,而是一個技術和業務理解相結合的問題,一定要選擇適應自己的顆粒度,才能達到即節省成本和資源,又能充分發揮微服務優勢的建設效果.

6.3 微服務容器使用

在微服務實際部署過程中,為了能夠真正實現隨著需求的變化自動調配微服務數量,更好的發揮微服務效果,還必須使用微服務容器對微服務進行管理和監控.

目前普遍使用的是Docker 微服務容器.使用微服務容器不僅可以實現自動調配微服務數量的目的,還可以通過管理界面直觀看到每個微服務數量和運行健康狀態,容器的使用大大提高了微服務的管理效率.微服務容器以集群的方式部署,讓系統服務部署變得簡單、高效.如果不使用微服務容器,則需要在每臺服務器上安裝運行環境,如果需求的服務器數量龐大,在每臺服務器上安裝運行環境將是一項無比繁重的工作,一旦運行環境發生改變,就不得不重新配置.而使用容器技術,微服務是以鏡像的形式運行在容器中,只要將所需的基礎鏡像和微服務生成一個新的鏡像,將這個最終鏡像部署在容器中.在此創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像,在鏡像倉庫中對所有鏡像進行管理.

7 小結

實現全國精準扶貧和精準脫貧,是完成中央“兩個一百年”奮斗目標的前提條件.如何解決扶貧對象精準、項目安排精準、資金使用精準等一些列精準問題,及時發現違規違紀行為,確保扶貧資金精準、及時發放,成為政府部門亟需解決的問題.福建省積極響應中央精神,利用大數據、云計算、微服務等前沿先進技術,在全國率先研究開發福建省扶貧(惠民)資金在線監管系統,實現對扶貧資金的全流程精準監控,確保扶貧資金精準及時發放.系統建設成果得到國務院和財政部的充分肯定,并獲得第二屆數字中國建設峰會數字福建電子政務十佳案例成果獎,同時在全國推廣使用,為我國早日實現精準脫貧奠定了基礎.本文詳細描述了該系統的體系架構和關鍵技術,對實現效果和建設經驗進行了分享,該系統建設思路可以為其他政府部門解決其他領域建設問題提供參考和借鑒.