章仕鋒,潘善亮

(寧波大學(xué) 信息科學(xué)與工程學(xué)院,寧波 315211)

隨著軟件體系架構(gòu)的發(fā)展,選擇合適的軟件架構(gòu)成為軟件開(kāi)發(fā)過(guò)程中的關(guān)鍵要點(diǎn),國(guó)土檔案系統(tǒng)是不動(dòng)產(chǎn)登記信息化工作中的重要工具,傳統(tǒng)的國(guó)土檔案系統(tǒng),一般采用單體架構(gòu)設(shè)計(jì)開(kāi)發(fā),單體架構(gòu)將整個(gè)系統(tǒng)功能和數(shù)據(jù)作為一個(gè)整體,統(tǒng)一地進(jìn)行設(shè)計(jì)、開(kāi)發(fā)和部署,單體架構(gòu)設(shè)計(jì)的檔案系統(tǒng)有著明顯的缺陷,首先,單體架構(gòu)設(shè)計(jì)的檔案系統(tǒng)內(nèi)部緊密耦合,難以根據(jù)業(yè)務(wù)需求變化進(jìn)行靈活調(diào)整,其次,單體架構(gòu)設(shè)計(jì)的系統(tǒng)所有部分采用同一技術(shù)路線,無(wú)法與其他信息系統(tǒng)之間進(jìn)行協(xié)同與共享從而產(chǎn)生“信息孤島”現(xiàn)象.

針對(duì)單體架構(gòu)存在的問(wèn)題,面向服務(wù)的架構(gòu)(Service-Oriented Architecture,SOA)[1]隨之出現(xiàn),不同于單體架構(gòu),SOA 架構(gòu)將業(yè)務(wù)服務(wù)作為整個(gè)系統(tǒng)設(shè)計(jì)的核心,設(shè)計(jì)時(shí)可以根據(jù)具體的業(yè)務(wù)需求為每個(gè)服務(wù)選擇特定的技術(shù)路線,通過(guò)Web 服務(wù)統(tǒng)一標(biāo)準(zhǔn)協(xié)議,將定義封裝好的服務(wù)接口進(jìn)行發(fā)布,各個(gè)服務(wù)接口組件之間通過(guò)輕量級(jí)通信協(xié)議進(jìn)行交互,從而實(shí)現(xiàn)一個(gè)靈活互通松耦合的信息系統(tǒng).

雖然SOA 架構(gòu)實(shí)現(xiàn)國(guó)土檔案系統(tǒng)跨平臺(tái)開(kāi)發(fā)及松耦合度,但隨著國(guó)土檔案系統(tǒng)業(yè)務(wù)需求日趨多樣化和復(fù)雜化,SOA 架構(gòu)設(shè)計(jì)的系統(tǒng)局限性開(kāi)始顯現(xiàn),主要面臨的問(wèn)題如下:

(1) 安全性不足:國(guó)土檔案數(shù)據(jù)作為國(guó)土業(yè)務(wù)工作的核心,數(shù)據(jù)安全和保密性要求較高,SOA 架構(gòu)在異構(gòu)平臺(tái)下進(jìn)行Web 服務(wù)的調(diào)用,由于異構(gòu)環(huán)境下各平臺(tái)技術(shù)安全標(biāo)準(zhǔn)的不統(tǒng)一,缺乏調(diào)用時(shí)應(yīng)有加密保護(hù)措施來(lái)進(jìn)行對(duì)調(diào)用者的權(quán)限驗(yàn)證,導(dǎo)致服務(wù)可能被惡意調(diào)用,系統(tǒng)數(shù)據(jù)的安全性不足.

(2) 負(fù)載均衡問(wèn)題:SOA 架構(gòu)設(shè)計(jì)的檔案系統(tǒng)將一些業(yè)務(wù)功能做成服務(wù)的形式發(fā)布,最大化的提高服務(wù)的重用性,然而業(yè)務(wù)量的拓展和使用人數(shù)的增加將導(dǎo)致對(duì)特定服務(wù)負(fù)載壓力過(guò)大,當(dāng)某一服務(wù)發(fā)生錯(cuò)誤就會(huì)導(dǎo)致整個(gè)系統(tǒng)受到影響,系統(tǒng)無(wú)法根據(jù)當(dāng)前狀態(tài)進(jìn)行 負(fù)載上的調(diào)整,系統(tǒng)穩(wěn)定性將會(huì)下降.

(3) 伸縮拓展性不足:在國(guó)土業(yè)務(wù)部門(mén)大數(shù)據(jù)、云平臺(tái)的功能需求背景下,應(yīng)用系統(tǒng)對(duì)計(jì)算機(jī)資源的使用日益靈活,業(yè)務(wù)高峰時(shí)需要增加應(yīng)用部署、分配存儲(chǔ)資源等操作來(lái)滿足使用需求,業(yè)務(wù)低谷時(shí)則應(yīng)對(duì)相應(yīng)的資源進(jìn)行回收再利用,傳統(tǒng)SOA 檔案系統(tǒng)緊密耦合難以根據(jù)需要進(jìn)行靈活的伸縮,運(yùn)維部署難度大.

本文提出一種基于微服務(wù)架構(gòu)的分布式檔案系統(tǒng)設(shè)計(jì)方案,通過(guò)微服務(wù)架構(gòu)解決了傳統(tǒng)SOA 架構(gòu)中存在的服務(wù)易崩潰、負(fù)載不均衡和服務(wù)調(diào)用不安全等問(wèn)題,引入Docker 容器級(jí)虛擬化技術(shù),提高了系統(tǒng)運(yùn)維部署的可伸縮性.微服務(wù)架構(gòu)化后的國(guó)土檔案系統(tǒng),顯著提升了系統(tǒng)的可靠性、穩(wěn)定性,滿足了國(guó)土檔案系統(tǒng)在現(xiàn)今和未來(lái)海量業(yè)務(wù)數(shù)據(jù)功能的需求.

1 總體架構(gòu)

系統(tǒng)整體架構(gòu)如圖1所示,系統(tǒng)架構(gòu)具體可分為數(shù)據(jù)層、索引層、Docker 微服務(wù)群、業(yè)務(wù)層和網(wǎng)關(guān)層,系統(tǒng)各個(gè)部分按照電子政務(wù)統(tǒng)一平臺(tái)建設(shè)標(biāo)準(zhǔn)規(guī)范進(jìn)行設(shè)計(jì)開(kāi)發(fā),作為電子政務(wù)云平臺(tái)組成部分可以與其他政務(wù)系統(tǒng)進(jìn)行銜接和共享.

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

數(shù)據(jù)層將各個(gè)區(qū)縣的數(shù)據(jù)庫(kù)通過(guò)國(guó)土局專用內(nèi)網(wǎng)連接整合,同時(shí)結(jié)合市局OA 系統(tǒng),對(duì)上層提供統(tǒng)一數(shù)據(jù)接口,采用Redis 數(shù)據(jù)庫(kù)保存緩存數(shù)據(jù),根據(jù)需要利用緩存來(lái)直接對(duì)上提供數(shù)據(jù)來(lái)提高查詢效率.索引層是對(duì)接收的數(shù)據(jù)信息建立倒排索引機(jī)制,上層服務(wù)進(jìn)行關(guān)鍵字查詢時(shí),利用倒排索引提供的關(guān)鍵字文檔,能夠快速找到相關(guān)的文件信息并定位到文件的存儲(chǔ)位置,最大化的提高查詢速率和準(zhǔn)確性.Docker 原子微服務(wù)將業(yè)務(wù)功能劃分為細(xì)粒度的微小服務(wù),每個(gè)Docker 容器承載一個(gè)原子微服務(wù),利用集群部署的方式來(lái)提高系統(tǒng)可用性,每個(gè)Docker 服務(wù)都會(huì)在服務(wù)注冊(cè)中心進(jìn)行注冊(cè),通過(guò)心跳包的方式維持與服務(wù)注冊(cè)中心的聯(lián)系.業(yè)務(wù)層將Docker 原子微服務(wù)提供的服務(wù)進(jìn)行組合封裝,形成具體業(yè)務(wù)功能的粗粒度服務(wù),這些粗粒度的服務(wù)同樣利用Docker 容器進(jìn)行部署運(yùn)行,提供相應(yīng)的服務(wù)接口進(jìn)行服務(wù)調(diào)用,服務(wù)注冊(cè)中心實(shí)時(shí)監(jiān)控各個(gè)接口狀態(tài)信息,根據(jù)服務(wù)調(diào)用情況進(jìn)行負(fù)載限流調(diào)整.服務(wù)網(wǎng)關(guān)控制前后端路由轉(zhuǎn)發(fā),通過(guò)對(duì)請(qǐng)求進(jìn)行權(quán)限驗(yàn)證來(lái)決定是否轉(zhuǎn)發(fā),丟棄驗(yàn)證不通過(guò)的數(shù)據(jù)請(qǐng)求.

2 系統(tǒng)設(shè)計(jì)

2.1 數(shù)據(jù)層設(shè)計(jì)

檔案系統(tǒng)的核心數(shù)據(jù)主要包括檔案文件條目及對(duì)應(yīng)的電子文件,地籍類(lèi)檔案數(shù)據(jù)來(lái)源各區(qū)縣Oracle 數(shù)據(jù)庫(kù)和市局已有Oracle 數(shù)據(jù)庫(kù),市局中部署OA 系統(tǒng)服務(wù)器和Redis 緩存服務(wù)器,OA 系統(tǒng)保存并提供各類(lèi)日常辦公數(shù)據(jù),如會(huì)計(jì)、文書(shū)等,Redis 緩存服務(wù)器保存數(shù)據(jù)層被頻繁訪問(wèn)的數(shù)據(jù),提高系統(tǒng)查詢速率,同時(shí),業(yè)務(wù)數(shù)據(jù)接口匯總采集相關(guān)業(yè)務(wù)部門(mén)數(shù)據(jù),集成如住建、測(cè)繪、海洋等數(shù)據(jù),數(shù)據(jù)層完成對(duì)數(shù)據(jù)的綜合利用,為上層形成利用具體的檔案提供數(shù)據(jù)支持.數(shù)據(jù)層動(dòng)作主要分為數(shù)據(jù)采集和數(shù)據(jù)處理兩個(gè)部分,完成對(duì)數(shù)據(jù)的預(yù)處理和封裝.

2.1.1 數(shù)據(jù)采集

數(shù)據(jù)采集是指將物理上分布于各個(gè)區(qū)縣的異構(gòu)來(lái)源的數(shù)據(jù)資源進(jìn)行集成,各區(qū)縣原有檔案文件條目是建立在不同技術(shù)路線的信息系統(tǒng)之上,針對(duì)各區(qū)縣數(shù)據(jù)庫(kù)條目字段差異,在市局?jǐn)?shù)據(jù)庫(kù)建立統(tǒng)一條目查詢視圖,查詢視圖將分布式環(huán)境下各個(gè)數(shù)據(jù)庫(kù)條目進(jìn)行整合,對(duì)上層提供統(tǒng)一的數(shù)據(jù)庫(kù)查詢接口.

對(duì)于檔案電子文件,建立統(tǒng)一電子檔案?jìng)鬏斀涌诜?wù),各個(gè)區(qū)縣檔案業(yè)務(wù)部門(mén)進(jìn)行業(yè)務(wù)歸檔后,統(tǒng)一電子檔案?jìng)鬏斀涌诜?wù)通過(guò)ftp 協(xié)議將分散在各地的電子文檔發(fā)送到市局服務(wù)器中保存.

2.1.2 數(shù)據(jù)處理

數(shù)據(jù)層完成數(shù)據(jù)采集后將對(duì)數(shù)據(jù)資源進(jìn)行數(shù)據(jù)處理,將對(duì)于檔案數(shù)據(jù)條目進(jìn)行數(shù)據(jù)清洗[2],從各個(gè)區(qū)縣采集到的數(shù)據(jù)條目存在著各種系統(tǒng)冗余和錯(cuò)誤數(shù)據(jù),因此數(shù)據(jù)清洗時(shí)主要包括檢查數(shù)據(jù)一致性[3]、處理檔案條目中存在的無(wú)效和缺失記錄,處理后的檔案數(shù)據(jù)條目為上層索引提供統(tǒng)一的資源利用視圖,從上層來(lái)看,各數(shù)據(jù)不再是分布于各個(gè)不同物理平臺(tái)之中,而是存在于數(shù)據(jù)層封裝好的虛擬視圖之中.

從各區(qū)縣采集的電子檔案文件,在存儲(chǔ)格式上存在各種差異,通過(guò)在線格式轉(zhuǎn)換模塊,將不同格式來(lái)源的電子檔案文件統(tǒng)一轉(zhuǎn)換成PDF 格式文檔,轉(zhuǎn)換完成后的電子檔案文件進(jìn)行統(tǒng)一的備份保存.

2.2 索引層設(shè)計(jì)

索引層的作用在于提高系統(tǒng)對(duì)電子檔案進(jìn)行關(guān)鍵字查詢時(shí)的速度和準(zhǔn)確度,索引層數(shù)據(jù)來(lái)自于數(shù)據(jù)層整理集成后的數(shù)據(jù)庫(kù)檔案條目,每個(gè)檔案條目對(duì)應(yīng)各自的電子檔案文件,檔案條目中包含電子檔案信息的關(guān)鍵字條目,對(duì)關(guān)鍵字條目建立數(shù)據(jù)文檔作為索引數(shù)據(jù)來(lái)源,索引層將數(shù)據(jù)層獲得的數(shù)據(jù)利用Hadoop MapReduce 技術(shù)建立倒排索引[4],根據(jù)檔案各個(gè)案卷文件中的關(guān)鍵字出現(xiàn)頻率及位置,能夠快速為查詢服務(wù)提供關(guān)鍵字匹配率由高到低的所有結(jié)果.

在Hadoop 平臺(tái)上利用MapReduce 編程模型,首先對(duì)檔案中各案卷進(jìn)行Map 過(guò)程,形成＜key,value＞形式鍵值對(duì),其中key 表示案卷中包含的各個(gè)字段的信息以及案卷對(duì)應(yīng)的URL,value 表示案卷中各個(gè)關(guān)鍵詞出現(xiàn)的頻率,然后進(jìn)行Combine 過(guò)程,將Map 過(guò)程輸出結(jié)果作為自己的輸入,把同一案卷中的同一關(guān)鍵字作累加統(tǒng)計(jì)運(yùn)算,得到各個(gè)關(guān)鍵詞出現(xiàn)的案卷位置及頻率結(jié)果,最后進(jìn)行Reduce 過(guò)程,把Combine 過(guò)程輸出的結(jié)果作為輸入,形成以關(guān)鍵詞對(duì)應(yīng)的案卷位置和在關(guān)鍵詞在各個(gè)案卷中出現(xiàn)的頻率為格式的倒排索引文檔,檔案系統(tǒng)在進(jìn)行關(guān)鍵字查詢時(shí),查詢服務(wù)優(yōu)先查詢倒排索引文檔記錄,關(guān)鍵字匹配時(shí)直接返回查詢結(jié)果來(lái)提高查詢速率.案卷索引建立過(guò)程如圖2所示.

2.3 Docker 原子微服務(wù)設(shè)計(jì)

2.3.1 Docker 容器設(shè)計(jì)

Docker 容器池主要由Docker 鏡像倉(cāng)庫(kù)、基礎(chǔ)資源設(shè)施、容器調(diào)度編排、容器管理運(yùn)維組成,大量Docker 容器部署在相同或者不同宿主服務(wù)器中[5],各個(gè)容器之間相互獨(dú)立,通過(guò)輕量級(jí)通信機(jī)制進(jìn)行溝通,檔案系統(tǒng)功能被劃分為細(xì)粒度的原子功能,每個(gè)原子功能服務(wù)部署在Docker 容器中,其中重要服務(wù)采用多個(gè)容器部署的方式來(lái)最大化的提高服務(wù)可用性.

圖2 案卷索引建立過(guò)程

(1)Docker 鏡像倉(cāng)庫(kù)

鏡像倉(cāng)庫(kù)主要用于存儲(chǔ)和擴(kuò)展業(yè)務(wù)鏡像,通過(guò)從Docker 服務(wù)器端下載初始系統(tǒng)鏡像,然后將微服務(wù)程序打包移植到系統(tǒng)鏡像上,形成一個(gè)新的獨(dú)立業(yè)務(wù)鏡像.將鏡像部署到Docker 容器之中,容器之間可以通過(guò)輕量級(jí)的網(wǎng)絡(luò)協(xié)議進(jìn)行交互.

(2)基礎(chǔ)資源設(shè)施

基礎(chǔ)資源設(shè)施提供微服務(wù)程序所需的各種計(jì)算機(jī)資源,包括計(jì)算機(jī)存儲(chǔ)、通信網(wǎng)絡(luò)、服務(wù)器資源等.

(3)容器調(diào)度編排

容器調(diào)度編排是將部署了微服務(wù)應(yīng)用的Docker容器通過(guò)Kubernetes 集群[6]進(jìn)行調(diào)度,Kubernetes 集群主要分為Master 節(jié)點(diǎn)和Node 節(jié)點(diǎn),Master 節(jié)點(diǎn)對(duì)外提供控制管理服務(wù),節(jié)點(diǎn)包括管理集群的API 接口,Node 節(jié)點(diǎn)負(fù)責(zé)運(yùn)行實(shí)際的Docker 容器,對(duì)節(jié)點(diǎn)中的Docker 容器提供代理交互功能.

(4)容器管理運(yùn)維

管理運(yùn)維模塊中包含容器狀態(tài)監(jiān)控、容器網(wǎng)絡(luò)配置、容器版本控制和日志監(jiān)控等部分,通過(guò)自動(dòng)化運(yùn)維工具為容器用戶提供容器資源監(jiān)管控制等功能.

2.3.2 微服務(wù)集群

微服務(wù)集群如圖3所示,主要分為微服務(wù)注冊(cè)中心、分布式配置中心、原子微服務(wù)群、微服務(wù)狀態(tài)監(jiān)控和錯(cuò)誤熔斷機(jī)制等部分,采用Spring Cloud 微服務(wù)框架體系[7]來(lái)設(shè)計(jì)實(shí)現(xiàn)各個(gè)組成部分.

圖3 微服務(wù)集群

微服務(wù)注冊(cè)中心負(fù)責(zé)所有微服務(wù)組件的注冊(cè)和調(diào)用,提供集群負(fù)載和微服務(wù)可用性的控制,Eureka 高可用的組件來(lái)具體實(shí)現(xiàn)微服務(wù)注冊(cè)中心的功能,根據(jù)去中心化的思想,采用多個(gè)Eureka 組件互相注冊(cè)的方式,防止單一組件發(fā)生崩潰導(dǎo)致整體無(wú)法運(yùn)行,每個(gè)微服務(wù)在服務(wù)注冊(cè)中心進(jìn)行注冊(cè),注冊(cè)的微服務(wù)通過(guò)心跳包的方式維持與服務(wù)注冊(cè)中心之間聯(lián)系.

原子微服務(wù)群主要實(shí)現(xiàn)微服務(wù)粒度和劃分和獨(dú)立部署,將檔案系統(tǒng)功能劃分為基本的原子功能,利用Docker 容器進(jìn)行原子服務(wù)的部署,部署后的原子微服務(wù)群為業(yè)務(wù)層的業(yè)務(wù)組合提供相應(yīng)的接口.

微服務(wù)狀態(tài)監(jiān)控包含對(duì)單個(gè)微服務(wù)可用狀態(tài)和微服務(wù)群接口狀態(tài)及使用頻率的監(jiān)控,利用Spring Boot Admin 來(lái)實(shí)現(xiàn)單個(gè)服務(wù)可用狀態(tài)的監(jiān)控,Hystrix Dashboar 來(lái)完成接口狀態(tài)及使用頻率的監(jiān)控.

分布式配置中心用于統(tǒng)一管理各個(gè)微服務(wù)配置設(shè)置,能夠通過(guò)本地或者遠(yuǎn)程的方式,對(duì)微服務(wù)配置進(jìn)行實(shí)時(shí)更新.服務(wù)錯(cuò)誤熔斷機(jī)制是指當(dāng)某個(gè)微服務(wù)調(diào)用發(fā)生錯(cuò)誤后對(duì)其進(jìn)行隔離,防止調(diào)用出錯(cuò)而造成的網(wǎng)絡(luò)阻塞,設(shè)計(jì)斷路器模型利用Hystrix 組件[8],對(duì)特定微服務(wù)的調(diào)用不可用達(dá)到閾值后,打開(kāi)斷路器對(duì)服務(wù)調(diào)用返回一個(gè)固定值避免連鎖反應(yīng),同時(shí)利用Hystrix 組件提供可視化界面來(lái)進(jìn)行數(shù)據(jù)監(jiān)控.

2.4 業(yè)務(wù)層設(shè)計(jì)

業(yè)務(wù)層的作用是對(duì)整個(gè)系統(tǒng)的業(yè)務(wù)功能進(jìn)行組合發(fā)布,根據(jù)微服務(wù)架構(gòu)思想,將檔案系統(tǒng)的數(shù)據(jù)管理、業(yè)務(wù)功能、系統(tǒng)管理三個(gè)主要功能模塊拆分成細(xì)粒度的微服務(wù)組件,對(duì)外提供統(tǒng)一的微服務(wù)接口,根據(jù)不同接口的負(fù)載情況,對(duì)于負(fù)載壓力大的接口采用集群的方式來(lái)發(fā)布.

業(yè)務(wù)層設(shè)計(jì)的核心思想在于其弱耦合度,業(yè)務(wù)層在整個(gè)系統(tǒng)架構(gòu)中有著承上啟下的作用,對(duì)下層Dokcer 原子微服務(wù)提供的服務(wù)進(jìn)行組合,為上層服務(wù)網(wǎng)關(guān)提供業(yè)務(wù)接口,通過(guò)對(duì)接口的封裝,上層對(duì)于下層來(lái)說(shuō)是不可見(jiàn)的,改變業(yè)務(wù)層的設(shè)計(jì)對(duì)Docker 原子微服務(wù)的調(diào)用不會(huì)產(chǎn)生影響.

組合服務(wù)時(shí),服務(wù)調(diào)用者向服務(wù)網(wǎng)關(guān)發(fā)出具體業(yè)務(wù)功能接口請(qǐng)求,服務(wù)網(wǎng)關(guān)根據(jù)微服務(wù)注冊(cè)中心反饋的服務(wù)列表向業(yè)務(wù)層發(fā)出微服務(wù)組合請(qǐng)求,業(yè)務(wù)層根據(jù)負(fù)載情況將微服務(wù)注冊(cè)中心反饋的可用原子服務(wù)集群列表中選擇相應(yīng)的Docker 服務(wù),通過(guò)對(duì)服務(wù)集群提供的原子服務(wù)進(jìn)行組合,封裝成檔案系統(tǒng)所需的粗粒度業(yè)務(wù)服務(wù),業(yè)務(wù)服務(wù)以Docker 容器的方式部署,組合后的業(yè)務(wù)服務(wù)將服務(wù)接口反饋給服務(wù)網(wǎng)關(guān),服務(wù)網(wǎng)關(guān)向服務(wù)調(diào)用者提供調(diào)用接口.

業(yè)務(wù)層還包括負(fù)載均衡模塊和消息隊(duì)列模塊,負(fù)載均衡模塊在服務(wù)調(diào)用組合過(guò)程中,通過(guò)判斷比較程序,設(shè)定閾值,對(duì)超出閾值的調(diào)用請(qǐng)求選擇集群中負(fù)載較低的服務(wù)處理或者棄用請(qǐng)求,消息隊(duì)列模塊將一些無(wú)需即時(shí)返回且耗時(shí)的操作提取出來(lái),進(jìn)行了異步處理[9].

2.5 服務(wù)網(wǎng)關(guān)設(shè)計(jì)

服務(wù)網(wǎng)關(guān)的主要作用是對(duì)前端路由請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)和請(qǐng)求處理過(guò)濾,流程如圖4所示,利用Node.js 技術(shù)[10]來(lái)實(shí)現(xiàn)服務(wù)網(wǎng)關(guān)功能,采用Nginx 作為系統(tǒng)Web服務(wù)器[11].

圖4 服務(wù)網(wǎng)關(guān)流程圖

2.5.1 路由轉(zhuǎn)發(fā)

服務(wù)網(wǎng)關(guān)負(fù)責(zé)接收外界對(duì)系統(tǒng)的一切請(qǐng)求,并將請(qǐng)求轉(zhuǎn)發(fā)到業(yè)務(wù)層上去,在整個(gè)過(guò)程中,服務(wù)網(wǎng)關(guān)首先從服務(wù)注冊(cè)中心獲取業(yè)務(wù)層接口狀態(tài)信息,判斷業(yè)務(wù)層接口是否存在及是否可用,當(dāng)業(yè)務(wù)接口可用時(shí)獲取接口信息,通過(guò)Web 服務(wù)器執(zhí)行反向代理過(guò)程之后[12],將業(yè)務(wù)接口提供給請(qǐng)求者.

2.5.2 請(qǐng)求處理過(guò)濾

服務(wù)網(wǎng)關(guān)作為整個(gè)系統(tǒng)與外界的門(mén)戶,負(fù)責(zé)外界對(duì)系統(tǒng)請(qǐng)求處理過(guò)程進(jìn)行過(guò)濾,主要實(shí)現(xiàn)了權(quán)限校驗(yàn)、業(yè)務(wù)接口監(jiān)控、訪問(wèn)限流和日志收集等功能,當(dāng)外界首次訪問(wèn)時(shí),進(jìn)行權(quán)限校驗(yàn),利用JWT 技術(shù)通過(guò)首次登陸時(shí)返回一個(gè)加密請(qǐng)求token,調(diào)用服務(wù)時(shí)進(jìn)行驗(yàn)證通過(guò)后才允許調(diào)用,從系統(tǒng)前端與后臺(tái)交互時(shí)進(jìn)行限流,當(dāng)服務(wù)網(wǎng)關(guān)檢測(cè)到前端對(duì)業(yè)務(wù)層接口訪問(wèn)量過(guò)大時(shí),將請(qǐng)求轉(zhuǎn)入等待隊(duì)列,待接口空閑后再進(jìn)行訪問(wèn).同時(shí),監(jiān)控業(yè)務(wù)層功能接口狀態(tài),當(dāng)檢測(cè)到接口錯(cuò)誤時(shí),將信息反饋到服務(wù)注冊(cè)中心,形成錯(cuò)誤日志保存錯(cuò)誤信息.

3 關(guān)鍵模塊設(shè)計(jì)

3.1 鑒權(quán)服務(wù)模塊

微服務(wù)集群中設(shè)計(jì)鑒權(quán)服務(wù)來(lái)保證服務(wù)調(diào)用的安全性,鑒權(quán)服務(wù)就是通過(guò)JWT 技術(shù)(Json Web Token,JWT)[13]來(lái)實(shí)現(xiàn)服務(wù)安全調(diào)用的單獨(dú)服務(wù)模塊,JWT 是一種無(wú)狀態(tài)的安全驗(yàn)證機(jī)制,JWT 通過(guò)自包含的特性讓用戶無(wú)需在服務(wù)器內(nèi)存中存儲(chǔ)用戶的狀態(tài),減少了查詢數(shù)據(jù)庫(kù)來(lái)驗(yàn)證用戶的次數(shù).

圖5 JWT 驗(yàn)證過(guò)程

如圖5所示,鑒權(quán)服務(wù)每次服務(wù)調(diào)用時(shí)驗(yàn)證Token 來(lái)判斷調(diào)用是否合法.JWT 根據(jù)微服務(wù)請(qǐng)求者首次登錄信息生成相應(yīng)的加密Token,向微服務(wù)請(qǐng)求者返回生成的Token,服務(wù)器不保存任何用戶信息,微服務(wù)再次調(diào)用時(shí),在請(qǐng)求頭中加入Token 信息,鑒權(quán)服務(wù)驗(yàn)證請(qǐng)求頭中Token 的正確性,驗(yàn)證通過(guò)后返回服務(wù)調(diào)用給請(qǐng)求者.

3.2 負(fù)載均衡模塊

負(fù)載均衡模塊主要通過(guò)Spring Cloud 微服務(wù)體系框架中Zuul 和Ribbon 框架[14],來(lái)實(shí)現(xiàn)對(duì)服務(wù)網(wǎng)關(guān)及微服務(wù)客戶端軟負(fù)載,Ribbon 框架內(nèi)置多種負(fù)載均衡規(guī)則,主要包括輪詢、服務(wù)器忽略、權(quán)值判斷和隨機(jī)選擇等方式,Zuul 服務(wù)網(wǎng)關(guān)主要通過(guò)限制客戶端請(qǐng)求速率的方式來(lái)避免大量服務(wù)調(diào)用使系統(tǒng)阻塞,利用服務(wù)注冊(cè)中心配合服務(wù)網(wǎng)關(guān)Zuul 和Ribbon 框架能夠較好滿足系統(tǒng)負(fù)載均衡性能需求.

如圖6所示關(guān)鍵業(yè)務(wù)功能對(duì)應(yīng)的原子微服務(wù)通過(guò)在多個(gè)Docker 容器中部署的方式來(lái)提高服務(wù)的可用性,Ribbon 客戶端通過(guò)輪詢的方式從服務(wù)注冊(cè)中心獲取可用服務(wù)列表,選擇負(fù)載較低的微服務(wù)組件來(lái)進(jìn)行組合,Zuul 網(wǎng)關(guān)對(duì)客戶端的請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)和過(guò)濾,根據(jù)服務(wù)調(diào)用情況進(jìn)行流量上的控制.

圖6 通過(guò)Zuul、Ribbon 來(lái)完成負(fù)載流量控制

3.3 容器伸縮模塊

容器資源池中設(shè)計(jì)容器伸縮模塊來(lái)滿足系統(tǒng)應(yīng)對(duì)業(yè)務(wù)高峰低谷時(shí)的需求,通過(guò)響應(yīng)式混合伸縮對(duì)業(yè)務(wù)需求已使用的容器數(shù)進(jìn)行檢測(cè),建立伸縮策略,當(dāng)檢測(cè)到數(shù)值超過(guò)或低于設(shè)定的閾值時(shí),向系統(tǒng)運(yùn)維發(fā)送提醒,運(yùn)維人員可以根據(jù)設(shè)定的步長(zhǎng)進(jìn)行手動(dòng)或自動(dòng)的增加或減少容器數(shù)量,同時(shí)向Kubernetes 集群發(fā)出指令,調(diào)整相應(yīng)的節(jié)點(diǎn)數(shù)量.

響應(yīng)式混合伸縮過(guò)程策略:

(1)根據(jù)業(yè)務(wù)運(yùn)行性能情況為系統(tǒng)設(shè)定伸縮調(diào)整檢測(cè)閾值范圍,設(shè)置伸縮步長(zhǎng).

(2)垂直伸縮階段:當(dāng)檢測(cè)到的業(yè)務(wù)負(fù)載偏離閾值范圍時(shí),對(duì)容器進(jìn)行垂直伸縮,調(diào)整分配給相應(yīng)容器的資源配額,增加或減少內(nèi)存、CPU 核數(shù)等資源.

(3) 水平伸縮階段:水平伸縮階段主要利用Kubernetes 集群Master 節(jié)點(diǎn)來(lái)完成對(duì)節(jié)點(diǎn)數(shù)量的控制,用戶通過(guò)向Master 節(jié)點(diǎn)發(fā)送相應(yīng)的API 指令,增加或減少容器實(shí)例數(shù)來(lái)滿足系統(tǒng)的性能需求.

4 系統(tǒng)運(yùn)行效果測(cè)試

4.1 查詢響應(yīng)時(shí)間

查詢響應(yīng)時(shí)間是國(guó)土檔案系統(tǒng)的重要性能指標(biāo),完成系統(tǒng)部署后,對(duì)國(guó)土局原SOA 架構(gòu)檔案系統(tǒng)和微服務(wù)架構(gòu)檔案系統(tǒng)進(jìn)行實(shí)驗(yàn),比較系統(tǒng)間在不同檔案條目數(shù)量下,查詢響應(yīng)時(shí)間的變化情況.

實(shí)驗(yàn)選取國(guó)土局虛擬檔案室原檔案系統(tǒng)(SOA)和微服務(wù)架構(gòu)設(shè)計(jì)的檔案系統(tǒng)進(jìn)行比較,數(shù)據(jù)庫(kù)選擇統(tǒng)一的Oracle10g 版本,服務(wù)器硬件配置為16 GB 內(nèi)存,4 核i7 處理器,服務(wù)器運(yùn)行環(huán)境為Windows Server 2008.

測(cè)試實(shí)驗(yàn)結(jié)果圖7表明,在檔案條目數(shù)量較少時(shí),系統(tǒng)之間查詢效率相差不大,但隨著檔案條目數(shù)量不斷增加,微服務(wù)架構(gòu)設(shè)計(jì)的檔案系統(tǒng)查詢響應(yīng)時(shí)間增量要明顯低于原SOA 架構(gòu)設(shè)計(jì)的檔案系統(tǒng),顯示了微服務(wù)檔案系統(tǒng)查詢效率要高于原SOA 系統(tǒng),從結(jié)果說(shuō)明,相對(duì)于直接利用Oracle 數(shù)據(jù)庫(kù)查詢,微服務(wù)系統(tǒng)架構(gòu)設(shè)計(jì)中的倒排索引及Redis 緩存能夠較有效的提高系統(tǒng)關(guān)鍵字查詢時(shí)的速率.

圖7 查詢響應(yīng)時(shí)間比較

4.2 系統(tǒng)界面

本系統(tǒng)設(shè)計(jì)滿足了國(guó)土檔案業(yè)務(wù)部門(mén)基本的需求,主要是全市檔案的查詢、顯示、各類(lèi)檔案的歸檔、后臺(tái)權(quán)限管理等業(yè)務(wù)需求,系統(tǒng)運(yùn)行效果如圖8所示,當(dāng)前系統(tǒng)運(yùn)行良好,不僅可以在國(guó)土檔案業(yè)務(wù)部門(mén)使用,也可滿足其他業(yè)務(wù)部門(mén)檔案管理需求,較好的解決了檔案數(shù)據(jù)的集成問(wèn)題.

5 結(jié)論與展望

隨著信息系統(tǒng)規(guī)模和復(fù)雜度的不斷提升,微服務(wù)架構(gòu)成了越來(lái)越多應(yīng)用系統(tǒng)架構(gòu)的首選,許多原有系統(tǒng)也紛紛進(jìn)行微服務(wù)化改造.本文介紹了微服務(wù)架構(gòu)的優(yōu)勢(shì)和特點(diǎn),將Docker 技術(shù)與微服務(wù)架構(gòu)結(jié)合起來(lái),設(shè)計(jì)實(shí)現(xiàn)了一套基于微服務(wù)架構(gòu)的分布式檔案系統(tǒng),相較傳統(tǒng)SOA 架構(gòu)開(kāi)發(fā)的系統(tǒng),主要解決了傳統(tǒng)系統(tǒng)中面臨的安全性低、負(fù)載不均衡和伸縮性不足等問(wèn)題,新系統(tǒng)的穩(wěn)定性、易拓展性和可維護(hù)性等方面大大加強(qiáng),有效降低了原先系統(tǒng)在運(yùn)行部署和后期維護(hù)上的復(fù)雜度,未來(lái)將進(jìn)一步在系統(tǒng)查詢效率優(yōu)化、系統(tǒng)流暢性等方面進(jìn)行改進(jìn).

圖8 系統(tǒng)查詢界面