基于微服務的遙感數(shù)據處理與共享平臺設計

韋二龍 黨執(zhí)政 李峰 王永安

摘要：隨著遙感技術的快速發(fā)展，遙感數(shù)據處理與共享應用于越來越多的領域，然而，業(yè)務功能的快速增長對遙感數(shù)據處理與共享平臺的建設帶來了新挑戰(zhàn)，傳統(tǒng)的基于單服務架構的遙感數(shù)據處理與共享服務已經無法滿足人們對高可用、易擴展服務的需求。提出了基于微服務架構的遙感數(shù)據處理與共享平臺設計方案，并基于微服務設計理念對平臺架構、服務注冊發(fā)現(xiàn)、服務交互、容錯處理、統(tǒng)一配置管理及服務部署等提出了具體的技術解決方案，保證了平臺的高可用性和易擴展性，滿足當前遙感數(shù)據快速增長對數(shù)據處理與共享的需求。

關鍵詞：遙感數(shù)據；數(shù)據處理；數(shù)據共享；微服務；架構設計；Docker容器

中圖分類號：TP311.52文獻標志碼：A文章編號：1008-1739（2019）12-56-4

0引言

當前我國遙感數(shù)據分散于不同業(yè)務部門，通過長期業(yè)務沉淀，形成了全國覆蓋、要素齊全、精度較高的土地、地礦、海洋資源和地理過程數(shù)據，應用于陸地觀測、海洋觀測、測繪行業(yè)、土地行業(yè)以及地礦行業(yè)等領域[1]。遙感數(shù)據處理與共享平臺具備多源遙感數(shù)據產品的接入處理、可視化、共享和分析能力[2-3]，但在遙感數(shù)據處理與共享架構設計，特別是結合微服務構建高可用、易擴展服務架構方面，暫時還是空白。

本文探討了傳統(tǒng)遙感數(shù)據處理與共享服務的不足，闡述了微服務架構的優(yōu)勢。基于微服務設計理念，提出構建低耦合、高可用、易擴展的遙感數(shù)據處理與共享平臺設計方案，可支撐遙感數(shù)據在信息處理與共享領域的建設，滿足遙感數(shù)據快速增長對數(shù)據處理與共享的需求。

1傳統(tǒng)遙感數(shù)據處理與共享服務的不足

隨著遙感技術的快速發(fā)展，遙感數(shù)據處理與共享平臺需要為越來越多的領域提供支持，傳統(tǒng)的遙感數(shù)據處理與共享服務基于單服務架構設計，所有功能模塊部署在同一服務中，隨之暴露出很多問題，主要包含以下3個方面[4]：

（1）服務穩(wěn)定性差

遙感數(shù)據處理與共享平臺普遍基于單服務架構搭建，整個服務包含數(shù)據接入、處理、統(tǒng)計、分析、傳輸、共享及展示等多個業(yè)務模塊，不同業(yè)務模塊相互關聯(lián)、依存，共同維持遙感數(shù)據處理與共享服務正常運轉，任何一個模塊出現(xiàn)問題都可能對整個平臺造成影響。

（2）可擴展性不足

基于單服務架構的遙感數(shù)據處理與共享平臺不同的業(yè)務模塊代碼部署在同一服務器中，業(yè)務代碼之間相互關聯(lián)、耦合性高。隨著數(shù)據共享平臺的業(yè)務發(fā)展，對模塊的增加和更改都可能影響其他功能模塊的功能和穩(wěn)定，更新和修復服務變得越來越困難。

（3）開發(fā)標準不統(tǒng)一

當前遙感數(shù)據來源標準不統(tǒng)一，模塊開發(fā)語言和架構多種多樣，導致遙感數(shù)據的接入、處理和共享服務沒有統(tǒng)一的標準。

2微服務在遙感數(shù)據處理與共享平臺方面的優(yōu)勢

2.1微服務

微服務架構是當前系統(tǒng)開發(fā)領域的熱點技術，可解決單體應用部署、配置、維護的復雜性。微服務架構是將一個單體應用拆分為一組微服務的方法，每個服務獨立運行并相互協(xié)同，服務間采用輕量級的通信機制，所有的微服務共同構建起整個系統(tǒng)[5]，易于開發(fā)和維護、業(yè)務模塊技術不受限制、穩(wěn)定性高、可伸縮性強，充分體現(xiàn)了高內聚、低耦合的軟件設計理念。

SpirngCloud是當前微服務主流的開發(fā)框架[6]，具備開箱即用的特性，可極大提高開發(fā)效率。同時SpringCloud基于SpringBoot構建，為微服務架構提供了整套的解決方案。微服務不強行依賴于運行平臺，可根據需求部署在本地Server、阿里云及百度云等服務平臺。考慮輕量、靈活等方面，微服務通常通過Docker容器進行部署[7]。

2.2微服務在遙感數(shù)據處理與共享平臺方面的優(yōu)勢

微服務在構建遙感數(shù)據處理與共享平臺的優(yōu)勢主要包含以下4個方面[8]：

①服務穩(wěn)定性高。不同服務單獨部署，單個微服務故障只對平臺的部分功能造成影響，同時基于微服務的快速恢復機制，能有效保證整個平臺的穩(wěn)定性。

②快速部署、按需伸縮。單個服務的修改只需重新部署相應的微服務，不影響平臺的整體運行，有效保證服務的可用性?？梢愿鶕I(yè)務需求，實現(xiàn)細粒度擴展，有效利用計算機硬件和軟件資源。

③統(tǒng)一接入標準。開發(fā)人員可以根據不同業(yè)務模塊的特點，合理選擇開發(fā)語言、框架和數(shù)據庫等。通過統(tǒng)一的服務調用接口，方便不同來源數(shù)據接入。

④易于開發(fā)和維護。將整個平臺進行業(yè)務拆分，單個微服務只關注特定的業(yè)務功能，業(yè)務邏輯清晰，方便工作人員對服務進行快速開發(fā)和維護。

3基于微服務遙感數(shù)據處理與共享平臺設計

通過平臺整體架構設計、平臺業(yè)務模塊拆分和平臺架構關鍵技術詳細介紹基于微服務架構的遙感數(shù)據處理與共享平臺的設計方案。

3.1平臺整體架構設計

基于微服務架構的特點，通過將傳統(tǒng)的遙感數(shù)據處理與共享平臺業(yè)務進行合理拆分，設計高可用、易擴展以及可伸縮部署的遙感數(shù)據處理與共享平臺微服務架構[9-11]，架構設計如圖1所示。

基于微服務設計的遙感數(shù)據處理與共享平臺架構主要包括應用層、服務層和容器3個部分。應用層主要通過RESTful接口為第三方應用提供統(tǒng)一的調用服務；服務層主要包括拆分后的微服務、網關服務、負載均衡服務、注冊發(fā)現(xiàn)服務、斷路器容錯和統(tǒng)一配置管理等模塊，共同保證遙感數(shù)據處理與共享平臺的穩(wěn)定性；容器層基于Docker服務集群對微服務進行部署，便于微服務的擴展和伸縮。

3.2平臺業(yè)務模塊

基于微服務架構構建遙感數(shù)據處理與共享平臺必然涉及業(yè)務模塊拆分，根據傳統(tǒng)遙感數(shù)據處理與共享平臺的業(yè)務需求，將平臺拆分為數(shù)據接入和傳輸、數(shù)據處理、數(shù)據統(tǒng)計和分析、數(shù)據共享、數(shù)據查詢和展示以及用戶權限管理服務集群。

（1）數(shù)據接入和傳輸

遙感數(shù)據信息來源于不同的領域，遵循不同的行業(yè)標準，遙感數(shù)據處理與共享平臺提供統(tǒng)一的接入標準和規(guī)范，方便各類遙感數(shù)據的接入。傳輸服務負責數(shù)據傳輸任務的具體執(zhí)行。

（2）數(shù)據處理

數(shù)據處理服務包括典型遙感數(shù)據算法服務和基于業(yè)務驅動的遙感應用生產流程定制服務等。當前主要的遙感處理算法包括輻射校正、幾何校正、正射校正、影像融合、目標檢測以及地物分類等。在遙感處理算法基礎上對已有服務進行組合，設計服務執(zhí)行次序以及配置服務輸入輸出參數(shù)，形成可以執(zhí)行的數(shù)據生產流程，完成定義的遙感數(shù)據生產過程。

（3）數(shù)據統(tǒng)計和分析

在遙感數(shù)據處理的基礎上，可以對數(shù)據進行統(tǒng)計和分析，為數(shù)據的共享和展示提供依據。

（4）數(shù)據共享

在數(shù)據共享方面，提供數(shù)據主題訂閱、數(shù)據變更通知和數(shù)據下載服務，并提供主題聚類和基于場景和偏好的數(shù)據推薦服務，同時研究多樣化的遙感信息共享服務模式，提高遙感信息共享服務的效率。

（5）數(shù)據查詢和展示

基于數(shù)據查詢服務，構建云+端的遙感數(shù)據自適應精準服務，面向各類用戶提供多源遙感信息產品的可視化展示、在線交互和精準保障服務。

（6）用戶權限管理

實現(xiàn)用戶注冊、用戶信息查詢、用戶信息管理、用戶刪除、用戶編輯及用戶角色分配等功能。

3.3關鍵技術

基于微服務架構的遙感數(shù)據處理與共享平臺架構通過注冊發(fā)現(xiàn)組件、服務交互、容錯機制、負載均衡、統(tǒng)一配置管理和Docker集群部署等關鍵技術共同保證了平臺的高可用性和易擴展性。

（1）注冊和發(fā)現(xiàn)組件

服務的注冊和發(fā)現(xiàn)組件主要包括服務提供者、服務消費者和服務發(fā)現(xiàn)組件。服務在啟動時將自己的信息注冊到服務發(fā)現(xiàn)組件中，服務消費者通過服務注冊表獲取服務提供者的網絡地址進行調用，業(yè)務模塊的注冊信息會隨著服務提供者信息的改變自動更新到注冊表中，無需人工修改。SpringCloud支持多種服務發(fā)現(xiàn)組件，如Zookeeper和Eureka等，注冊和發(fā)現(xiàn)組件工作原理如圖2所示。

（2）服務交互

基于微服務架構的服務交互分為2種：客戶端與服務器端交互和平臺內部微服務之間交互服務交互結構如圖3所示。

客戶端與服務器端的交互采用API Gateway方式，API Gateway是介于客戶端和服務器端的中間層，所有客戶端請求都經過API Gateway與服務器端進行通信。API Gateway封裝了服務器端的具體服務細節(jié)，提供了標準的API進行調用，減少了客戶端與各個微服務之間的交互次數(shù)。

平臺不同微服務之間使用輕量級的通信機制RESTful API進行通信，服務提供者注冊自己的服務接口，服務消費者通過服務發(fā)現(xiàn)組件調用服務提供者的服務接口實現(xiàn)微服務之間的通信。

（3）容錯機制

遙感數(shù)據處理與共享平臺各服務之間相互依賴，任一服務發(fā)生故障都有可能造成整個系統(tǒng)崩潰。平臺采用斷路器模式實現(xiàn)強大的容錯機制，斷路器可以實現(xiàn)快速失??；如果斷路器在同一段時間檢測到很多類似錯誤就會強迫該服務的調用快速失敗，直接返回錯誤信息，避免對整個服務造成影響。同時斷路器還可以自動診斷服務是否恢復正常，實現(xiàn)微服務的自我修復。

（4）負載均衡

為了保證各個微服務的穩(wěn)定性，對每個微服務進行分布式部署，平臺通過負載均衡機制將服務消費者的請求分攤到多個服務提供者的實例上。平臺采用Ribbon負載均衡器實現(xiàn)微服務的負載均衡，并提供輪詢、隨機、最小連接數(shù)及加權等負載均衡算法。負載均衡保證了單個微服務的穩(wěn)定性，進而保證平臺的可用性。

（5）統(tǒng)一配置管理

遙感數(shù)據處理與共享平臺使用SpringCloud Config統(tǒng)一管理微服務配置，為分布式系統(tǒng)外部化配置提供了服務器和客戶端支持。通過統(tǒng)一配置管理可以實現(xiàn)整個平臺的集中配置管理，微服務運行期間可以動態(tài)對配置進行調整，配置修改后可以自動進行更新，統(tǒng)一配置管理結構如圖4所示。

（6）服務部署

基于微服務的特性，遙感數(shù)據處理與共享平臺將選擇Docker部署微服務。Docker是一個開源的容器引擎，將應用程序和依賴的運行環(huán)境打包成鏡像，實現(xiàn)應用程序和基礎設施層有效隔離，可以更快地對服務進行打包、測試和部署[12]。使用Docker可以有效提高平臺的可伸縮性，實現(xiàn)服務的快速擴容。

4結束語

本文通過分析傳統(tǒng)基于單服務架構的遙感數(shù)據處理與共享服務的不足，闡述微服務在構建遙感數(shù)據處理與共享平臺方面的優(yōu)勢，提出了基于微服務架構的遙感數(shù)據處理與共享平臺設計方案。整個微服務架構基于注冊和發(fā)現(xiàn)、服務交互、容錯處理、負載均衡、統(tǒng)一配置管理和Docker集群部署等模塊，為構建高可用、易擴展的遙感數(shù)據處理與共享平臺提供技術支持和解決方案。

參考文獻

[1]戴芹，劉建波，劉士彬.海量衛(wèi)星遙感數(shù)據共享的關鍵技術[J].計算機工程，2008（6）：283-285.

[2]馮春，郭偉，龍小祥，等.我國遙感數(shù)據共享探討[J].中國科技資源導刊，2010，42（3）：66-72.

[3]史園莉，申文明，熊文成，等.遙感數(shù)據集群處理作業(yè)調度管理系統(tǒng)研究[J].計算機工程與應用，2012，48（25）：77-82.

[4]杜圣東，楊燕，滕飛.交通大數(shù)據：一種基于微服務的敏捷處理架構設計[J].大數(shù)據，2017，3（3）：53-67.

[5]王志勃，王麒森，畢艷茹.互聯(lián)網環(huán)境下微服務框架分析與研究[J].信息與電腦（理論版），2017，（22）：23-25.

[6]張峰.微服務技術構建大規(guī)模web系統(tǒng)的研究[J].科技創(chuàng)新與應用，2017，（22）：48-49.

[7]段嘉騰. Docker技術在軟件開發(fā)過程中的應用研究[J].中小企業(yè)管理與科技（中旬刊），2016，（9）：152-153.

[8]李春陽，劉迪，崔蔚，等.基于微服務架構的統(tǒng)一應用開發(fā)平臺[J].計算機系統(tǒng)應用，2017， 26（4）：43-48.

[9]譚一鳴.基于微服務架構的平臺化服務框架的設計與實現(xiàn)[D].北京：北京交通大學，2017.

[10]黃小鋒，張晶.微服務框架介紹與實現(xiàn)[J].電腦與信息技術， 2016，24（6）：14-16.

[11]歐陽榮彬，王倩宜，龍新征.基于微服務的數(shù)據服務框架設計[J].華中科技大學學報（自然科學版），2016，（S1）：143-147.

[12]高賢康.淺析Docker技術在Web服務系統(tǒng)中的應用[J].電腦迷，2017，（6）：55.