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

胡 波

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

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

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

1 技術介紹

1.1 大數(shù)據(jù)技術

1.1.1 Hadoop

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

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

1.1.2 Spark

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

1.1.3 Kerberos

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

1.2 Elastic Search

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

1.3 微服務架構

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

2 總體建設思路

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

3 系統(tǒng)體系架構

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

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

系統(tǒng)體系架構如圖1所示.

圖1 系統(tǒng)總體體系架構

4 關鍵技術應用

4.1 大數(shù)據(jù)技術應用

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

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

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

4.2 微服務架構設計應用

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

圖2 大數(shù)據(jù)應用示意圖

4.2.1 系統(tǒng)分層微服務架構

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

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

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

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

4.2.2 微服務應用關鍵步驟

系統(tǒng)微服務應用關鍵步驟具體如下:

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

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

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

圖3 系統(tǒng)分層微服務架構

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

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

4.2.3 微服務設計關鍵要求

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

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

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

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

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

5 實現(xiàn)成果

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

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

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

5.2 資金流程監(jiān)督全覆蓋

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

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

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

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

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

5.3 扶助對象識別更加精準

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

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

5.4 全民參與監(jiān)督

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

圖7 數(shù)據(jù)展示信息

5.5 精準扶貧試驗田

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

6 系統(tǒng)建設經(jīng)驗

6.1 數(shù)據(jù)庫選用

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

6.2 微服務最佳顆粒度

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

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

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

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

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

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

圖8 顆粒度與并發(fā)量關系圖

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

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

6.3 微服務容器使用

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

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

7 小結

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