一種基于微服務(wù)的飛機(jī)加油調(diào)度系統(tǒng)的架構(gòu)研究

閔曉霜，董巖，劉紅，董敏

(中國電子信息產(chǎn)業(yè)集團(tuán)有限公司第六研究所，北京 100083)

0 引言

民航業(yè)的飛速發(fā)展對為飛機(jī)提供油料保障的飛機(jī)加油業(yè)務(wù)也提出更高的要求。各地區(qū)機(jī)場都建設(shè)有航空加油站，提供飛機(jī)加油保障服務(wù)，但目前該業(yè)務(wù)整體信息化水平較低，大多數(shù)機(jī)場主要依靠對講和手寫油單的方式進(jìn)行傳統(tǒng)加油作業(yè)，除手工錄入油單數(shù)據(jù)到航油ERP 系統(tǒng)之外，與其他系統(tǒng)間缺少數(shù)據(jù)共享與協(xié)作，航油總部、所屬機(jī)場等相關(guān)方面都無法實(shí)時(shí)掌握加油保障的情況。為此，需建立一套飛機(jī)加油調(diào)度系統(tǒng)，依靠先進(jìn)的信息技術(shù)手段，不僅要優(yōu)化飛機(jī)加油的作業(yè)模式，而且要打通機(jī)場與與航油總部的信息共享通道，實(shí)現(xiàn)對加油保障運(yùn)行的全局監(jiān)督監(jiān)控以及銷售、統(tǒng)計(jì)等業(yè)務(wù)，同時(shí)與航空公司進(jìn)行數(shù)據(jù)、業(yè)務(wù)的對接。將在各機(jī)場建立分布式業(yè)務(wù)集群，將系統(tǒng)部署在云平臺(tái)之上。

加油調(diào)度業(yè)務(wù)存在以下特點(diǎn)：(1)涉及航顯信息顯示、基礎(chǔ)信息維護(hù)、加油任務(wù)調(diào)度、加油任務(wù)執(zhí)行、油單上傳結(jié)算等多個(gè)環(huán)節(jié)；(2)對接航油總部、航班信息提供商、機(jī)場系統(tǒng)、航空公司等多個(gè)系統(tǒng)；(3)存在調(diào)度人員Web 端、加油員移動(dòng)端等多端用戶訪問需求；(4)需要部署到多個(gè)機(jī)場。系統(tǒng)需要能夠適應(yīng)軟件的高速迭代以及各機(jī)場的快速部署，并能夠穩(wěn)定運(yùn)行為機(jī)場提供保障服務(wù)。目前流行的微服務(wù)架構(gòu)能夠?qū)⑾到y(tǒng)功能分散到獨(dú)立的微服務(wù)中，每個(gè)微服務(wù)進(jìn)行獨(dú)立部署[1]，彼此之間采用輕量級通信，能夠靈活地開發(fā)、部署以及擴(kuò)展升級，適應(yīng)系統(tǒng)需求，是非常理想的解決方案。

微服務(wù)是隨著信息技術(shù)迅速發(fā)展不斷演進(jìn)而產(chǎn)生的一種設(shè)計(jì)思想[2]，本文詳細(xì)介紹了從單體架構(gòu)、SOA到微服務(wù)架構(gòu)的演進(jìn)，對技術(shù)框架、容器、服務(wù)間通信等相關(guān)技術(shù)進(jìn)行分析，設(shè)計(jì)了一種基于微服務(wù)的飛機(jī)加油調(diào)度系統(tǒng)架構(gòu)，并在中航油智慧加油系統(tǒng)中得到應(yīng)用。

1 微服務(wù)及相關(guān)技術(shù)

1.1 微服務(wù)背景

云計(jì)算、物聯(lián)網(wǎng)等技術(shù)的發(fā)展，以及用戶對軟件系統(tǒng)的多樣化需求，促進(jìn)了設(shè)計(jì)架構(gòu)的一次次改變，經(jīng)歷了從單體架構(gòu)到面向服務(wù)的SOA 架構(gòu)，再到如今靈活的微服務(wù)架構(gòu)成為主流，軟件系統(tǒng)架構(gòu)的演進(jìn)如圖1 所示。

單體架構(gòu)是比較傳統(tǒng)的架構(gòu)風(fēng)格，所有功能模塊都被打包成一個(gè)程序包，連同數(shù)據(jù)資源部署在一臺(tái)服務(wù)器上。在系統(tǒng)規(guī)模小、業(yè)務(wù)簡單時(shí)，采用這種方式簡單實(shí)用，便于開發(fā)、測試、部署以及維護(hù)；但是在用戶量大、功能復(fù)雜且軟件需求不斷迭加時(shí)，系統(tǒng)開發(fā)升級會(huì)非常困難，且一個(gè)故障可能導(dǎo)致整個(gè)系統(tǒng)崩潰。

為解決上述問題，出現(xiàn)了面向服務(wù)的架構(gòu)(Service-Oriented Architecture，SOA)。SOA 根據(jù)業(yè)務(wù)將系統(tǒng)進(jìn)行粗粒度的拆分，形成可獨(dú)立部署的服務(wù)，服務(wù)間通過Web Service 等進(jìn)行網(wǎng)絡(luò)調(diào)用，營造了一種松耦合的環(huán)境。企業(yè)服務(wù)總線(Enterprise Service Bus，ESB)技術(shù)能夠有效實(shí)現(xiàn)不同服務(wù)間的通信與整合，它的引入進(jìn)一步促進(jìn)了SOA的發(fā)展[3]。雖能夠解決大部分問題，但SOA 強(qiáng)調(diào)自上而下的整體架構(gòu)，服務(wù)拆分粒度大。

微服務(wù)架構(gòu)在SOA 之上進(jìn)一步發(fā)展，融合了SOA 服務(wù)架構(gòu)、組件化以及領(lǐng)域建模的思想，提倡“業(yè)務(wù)徹底組件化和服務(wù)化”[4]，對服務(wù)進(jìn)行更細(xì)粒度的劃分，每個(gè)服務(wù)不僅能夠獨(dú)立部署運(yùn)行，還可以采用異構(gòu)的開發(fā)技術(shù)、存儲(chǔ)技術(shù)等，服務(wù)間使用輕量的通信機(jī)制進(jìn)行數(shù)據(jù)交互，如Restful API，引入微服務(wù)網(wǎng)關(guān)對外部請求進(jìn)行路由轉(zhuǎn)發(fā)和過濾，使得系統(tǒng)在開發(fā)、部署以及迭代方面都更為靈活高效，系統(tǒng)整體響應(yīng)速度也更快。

其中，微服務(wù)也被稱作是細(xì)粒度的SOA，但它們之間的差異不只在于服務(wù)粒度，還體現(xiàn)在以下幾個(gè)方面：(1)服務(wù)間通信機(jī)制不同，這也是二者最大的區(qū)別，微服務(wù)通信采用了輕量級設(shè)計(jì)，一般基于REST 協(xié)議實(shí)現(xiàn)，而SOA 采用重量級的網(wǎng)絡(luò)通信協(xié)議，如Web Service；(2)服務(wù)管理方式不同，微服務(wù)強(qiáng)調(diào)服務(wù)的自治性，采用去中心化管理，每個(gè)服務(wù)是獨(dú)立的應(yīng)用，獨(dú)立管理自己的數(shù)據(jù)庫，獨(dú)立部署和運(yùn)行，SOA 則采用集中式的管理，使用統(tǒng)一的數(shù)據(jù)中心；(3)適用系統(tǒng)規(guī)模不同，微服務(wù)更適合互聯(lián)網(wǎng)環(huán)境，與高流量、高并發(fā)、高可用等需求密不可分，適用于軟件高速迭代的系統(tǒng)，SOA 則主要面向企業(yè)計(jì)算，系統(tǒng)靈活性相對較低，服務(wù)更像是子系統(tǒng)，適合對大型企業(yè)應(yīng)用中異構(gòu)子系統(tǒng)的集成。

通過上述分析，采用微服務(wù)架構(gòu)設(shè)計(jì)，針對飛機(jī)加油業(yè)務(wù)進(jìn)行微服務(wù)的劃分，能夠提高系統(tǒng)的開發(fā)效率、方便系統(tǒng)擴(kuò)展，可以很好地滿足軟件功能多樣、高速迭代以及靈活部署等需求。

1.2 相關(guān)技術(shù)

1.2.1 Spring Cloud 微服務(wù)框架

目前，在微服務(wù)開發(fā)框架中Spring Cloud 最為流行[5]。Spring Cloud 是一套基于Spring Boot 的微服務(wù)工具包，為用戶提供了一系列的核心組件，包括：Eureka 服務(wù)發(fā)現(xiàn)組件、Register 服務(wù)注冊組件、Zuul 服務(wù)網(wǎng)關(guān)組件以及Config 分布式配置組件等，這些組件開箱即用，能夠?qū)崿F(xiàn)以Java 作為底層編程語言的微服務(wù)架構(gòu)的核心功能[4]。

其中，微服務(wù)網(wǎng)關(guān)的Zuul 組件承擔(dān)著身份認(rèn)證、動(dòng)態(tài)路由等重要功能，客戶端請求服務(wù)調(diào)用會(huì)通過Zuul轉(zhuǎn)發(fā)到后端微服務(wù)的Restful API，從而可以調(diào)用不同的微服務(wù)。每個(gè)微服務(wù)都有自己專屬的數(shù)據(jù)庫供其存儲(chǔ)查詢，以此來滿足用戶的各種功能需求。

1.2.2 虛擬化與容器技術(shù)

虛擬機(jī)是傳統(tǒng)的虛擬技術(shù)，它模擬了完整的系統(tǒng)軟硬件，相當(dāng)于一個(gè)完整的計(jì)算機(jī)系統(tǒng)?？梢詫?yīng)用部署到虛擬機(jī)上，但是由于虛擬機(jī)攜帶了操作系統(tǒng)，每次啟動(dòng)、運(yùn)行的負(fù)擔(dān)較重。

Docker 是一種輕量化的虛擬技術(shù)，不同于虛擬機(jī)，它可以將應(yīng)用及其依賴包打包到一個(gè)容器中[6]，然后發(fā)布到Linux 主機(jī)上，容器是運(yùn)行在操作系統(tǒng)之上的一個(gè)進(jìn)程，采用沙箱機(jī)制，相互之間隔離。Docker 與虛擬機(jī)的對比如表1 所示。

表1 Docker 與虛擬機(jī)的對比

Docker 的輕量級特性使其非常適合微服務(wù)的部署與維護(hù)。

Docker 有三大核心概念——倉庫、鏡像和容器，幾乎所有操作都是圍繞它們進(jìn)行的。Docker 鏡像相當(dāng)于一個(gè)只讀模板，將應(yīng)用程序及依賴包打包到鏡像文件，文件中還包含著創(chuàng)建Docker 容器的說明；容器是通過鏡像創(chuàng)建的可運(yùn)行實(shí)例，可通過Docker API 來啟動(dòng)、停止、移動(dòng)以及刪除容器[7]；倉庫是用來保存鏡像的地方，鏡像通過push 命令上傳到倉庫，使用時(shí)用pull 命令下載即可。其中，鏡像是容器運(yùn)行的前提，鏡像之于容器，就像面向?qū)ο笏枷胫械念惡蛯ο蟆?/p>

容器運(yùn)行所需資源少，啟動(dòng)快速、運(yùn)行輕量、方便移植、管理簡潔，便于定位與修復(fù)故障[8]。因此，采用Docker容器技術(shù)來實(shí)現(xiàn)微服務(wù)部署優(yōu)勢顯著。

1.2.3 服務(wù)間通信

微服務(wù)都各自運(yùn)行于獨(dú)立的進(jìn)程中，服務(wù)間采用輕量級通信機(jī)制進(jìn)行信息交互與消息傳遞。在微服務(wù)框架下，服務(wù)間的通信模式可分為兩種：同步和異步。

(1)同步模式。即請求/響應(yīng)模式，當(dāng)客戶端發(fā)出請求時(shí)，服務(wù)器能夠即時(shí)進(jìn)行響應(yīng)。該模式要求響應(yīng)是快速即時(shí)的，沒有代理的中間件，實(shí)現(xiàn)簡單，但通信過程中可能會(huì)引起進(jìn)程的阻塞。可以采用REST 協(xié)議和Thrift 協(xié)議，對于Spring Boot 集成的微服務(wù)架構(gòu)，也可以選用RPC，其跨語言性、社區(qū)支持性較好。

(2)異步模式。異步通信時(shí)，對于客戶端的請求，服務(wù)器不必即時(shí)響應(yīng)，也不會(huì)阻塞進(jìn)程。這種模式通過中間件代理[9]，在客戶端與服務(wù)器之間進(jìn)行消息緩沖，實(shí)現(xiàn)了微服務(wù)間的解耦，但是異步通信的復(fù)雜性大大增強(qiáng)，不適合處理太豐富的數(shù)據(jù)主題。消息隊(duì)列是一種主要的異步通信機(jī)制，常見的有Kafka、RabbitMQ等，消息生產(chǎn)者將消息發(fā)送到消息隊(duì)列，然后由消息的消費(fèi)者從消息隊(duì)列中獲取，而后進(jìn)行業(yè)務(wù)處理[10]。對于不頻繁的異步調(diào)用，也可以采用Restful 風(fēng)格的HTTP 協(xié)議。

兩種模式各有優(yōu)缺點(diǎn)與適用的情況，在微服務(wù)框架中，可以采用兩種模式混合的通信方式，根據(jù)實(shí)際情況選用不同的通信機(jī)制，提高系統(tǒng)的整體性能。

2 基于微服務(wù)的飛機(jī)加油調(diào)度系統(tǒng)架構(gòu)

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

飛機(jī)加油調(diào)度系統(tǒng)基于微服務(wù)架構(gòu)構(gòu)建，整體采用前后端分離的設(shè)計(jì)，從架構(gòu)設(shè)計(jì)層面分為前端應(yīng)用層、BFF 機(jī)場渠道服務(wù)層和后臺(tái)無狀態(tài)微服務(wù)層三部分，前端應(yīng)用層包含瀏覽器端Web 應(yīng)用程序與移動(dòng)端App。通過BFF 機(jī)場渠道服務(wù)將業(yè)務(wù)請求轉(zhuǎn)化為無狀態(tài)請求，通過內(nèi)部接口(RPC、HTTP、Kafka)訪問后臺(tái)無狀態(tài)服務(wù)，對業(yè)務(wù)進(jìn)行解耦，使應(yīng)用程序插件化、組件化。系統(tǒng)的微服務(wù)架構(gòu)如圖2 所示。

為了應(yīng)對軟件的高速迭代與機(jī)場系統(tǒng)的快速接入與定制化的需求，系統(tǒng)采用容器技術(shù)結(jié)合DevOps 容器云平臺(tái)構(gòu)建，每個(gè)微服務(wù)均獨(dú)立部署在Docker 容器中。通過創(chuàng)建面向機(jī)場的系統(tǒng)鏡像，當(dāng)需要接入新機(jī)場的時(shí)候通過配置文件與機(jī)場鏡像快速部署新的機(jī)場實(shí)例。

(1)前端應(yīng)用層：前端分為航班調(diào)度、加油員手持調(diào)度和基礎(chǔ)信息管理3 個(gè)系統(tǒng)，其中航班調(diào)度和基礎(chǔ)信息管理在Web端，加油員手持調(diào)度運(yùn)行在移動(dòng)端。

(2)BFF 機(jī)場渠道服務(wù)層：用于前端的后端(Backend For Frontend，BFF)是一種為解決微服務(wù)模式下前后端交互問題而產(chǎn)生的模式，通過增加中間層隔離前端對后端服務(wù)的直接訪問，可以過濾、轉(zhuǎn)發(fā)、組合前端請求，是服務(wù)于前端的后端服務(wù)，相當(dāng)于API 網(wǎng)關(guān)。BFF 機(jī)場渠道服務(wù)層采用BFF 模式并結(jié)合微服務(wù)中服務(wù)網(wǎng)關(guān)的思想，構(gòu)建對應(yīng)于特定機(jī)場特定前端的機(jī)場渠道服務(wù)(在干線機(jī)場要部署本機(jī)場系統(tǒng)及其所管理的所有支線機(jī)場系統(tǒng))，以及過濾各種外部系統(tǒng)訪問的認(rèn)證網(wǎng)關(guān)服務(wù)，建立了系統(tǒng)內(nèi)外訪問接口與后端服務(wù)間的屏障。

(3)后臺(tái)無狀態(tài)微服務(wù)層：后臺(tái)微服務(wù)不對外暴露，是無狀態(tài)的，訪問時(shí)要進(jìn)行token 認(rèn)證。根據(jù)系統(tǒng)業(yè)務(wù)對微服務(wù)進(jìn)行拆分，主要分為業(yè)務(wù)服務(wù)、基礎(chǔ)服務(wù)和其他服務(wù)。業(yè)務(wù)服務(wù)包括航班服務(wù)、任務(wù)服務(wù)、油單服務(wù)等；基礎(chǔ)服務(wù)包括人員服務(wù)、車輛服務(wù)、油料服務(wù)等；其他服務(wù)包括統(tǒng)計(jì)分析服務(wù)、警告服務(wù)等。

2.1.1 數(shù)據(jù)庫分庫

微服務(wù)與數(shù)據(jù)庫通過回調(diào)MyBatis 數(shù)據(jù)庫中間件進(jìn)行數(shù)據(jù)交互。數(shù)據(jù)庫以業(yè)務(wù)作為分庫依據(jù)，為與之相對的微服務(wù)提供支撐，主要采用MySQL 做持久化存儲(chǔ)，采用Redis 進(jìn)行數(shù)據(jù)緩存。系統(tǒng)的數(shù)據(jù)庫架構(gòu)如圖3 所示，整體劃分為基礎(chǔ)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)以及共享數(shù)據(jù)3 個(gè)數(shù)據(jù)區(qū)，與微服務(wù)相對應(yīng)，基礎(chǔ)數(shù)據(jù)區(qū)包含人員、車輛、機(jī)場等基礎(chǔ)信息，這部分信息是進(jìn)行業(yè)務(wù)工作的基礎(chǔ)支撐數(shù)據(jù)；業(yè)務(wù)數(shù)據(jù)區(qū)包含航班、任務(wù)、油單等業(yè)務(wù)數(shù)據(jù)，根據(jù)業(yè)務(wù)產(chǎn)生；Redis 對人員登錄token、權(quán)限等高實(shí)時(shí)性的信息進(jìn)行緩存。

2.1.2 系統(tǒng)內(nèi)部接口

為了保證數(shù)據(jù)在公網(wǎng)中的數(shù)據(jù)安全，從外網(wǎng)接入系統(tǒng)的包括網(wǎng)頁、移動(dòng)端的數(shù)據(jù)都需要進(jìn)行SSL 數(shù)據(jù)加密。

(1)用戶終端到BFF 層

移動(dòng)端App 和瀏覽器向BFF 機(jī)場渠道服務(wù)發(fā)起異步請求，如登錄、業(yè)務(wù)初始化等時(shí)，使用HTTPs；要建立長連接時(shí)，移動(dòng)端采用RPC、瀏覽器采用WebSocket，創(chuàng)建通信隧道進(jìn)行數(shù)據(jù)傳輸。

(2)BFF 層到后臺(tái)無狀態(tài)服務(wù)

BFF 機(jī)場渠道服務(wù)后臺(tái)無狀態(tài)服務(wù)，異步請求如微服務(wù)調(diào)用，使用Restful 的HTTP 協(xié)議；要建立長連接時(shí)，采用RPC 協(xié)議創(chuàng)建通信隧道。

(3)Kafka 消息通信

當(dāng)前后端需要不間斷的發(fā)送數(shù)據(jù)并同時(shí)進(jìn)行處理，如實(shí)時(shí)數(shù)據(jù)采集、判斷、告警等；當(dāng)消息和消費(fèi)者成1 對多關(guān)系的時(shí)候使用消息隊(duì)列來構(gòu)建內(nèi)部接口，如數(shù)據(jù)超過規(guī)定值時(shí)告警等，需要使用Kafka 來建立消息隊(duì)列，對數(shù)據(jù)進(jìn)行處理。

Kafka 消費(fèi)接口：接收外部系統(tǒng)的航班信息。通過實(shí)時(shí)接收Kafka 消息隊(duì)列里的航班信息，解析該航班信息并進(jìn)行一定的數(shù)據(jù)整理，最后將其寫入到數(shù)據(jù)庫中。

Kafka 生產(chǎn)接口：發(fā)送任務(wù)相關(guān)的一些保障數(shù)據(jù)和告警信息。在任務(wù)保障的主要時(shí)間節(jié)點(diǎn)，如任務(wù)下發(fā)、接收、執(zhí)行以及油單生成、上傳等時(shí)刻，將保障數(shù)據(jù)發(fā)送到Kafka 的消息隊(duì)列中由第三方消費(fèi)該數(shù)據(jù)。對于一些告警信息(如油料參數(shù)報(bào)警、任務(wù)延遲報(bào)警、油料不足報(bào)警、航班延誤等)，通過消息對列將實(shí)時(shí)數(shù)據(jù)推送給無狀態(tài)的告警服務(wù)，告警服務(wù)判斷是否報(bào)警并將數(shù)據(jù)存入Redis，然后通過Redis 的發(fā)布訂閱功能推送給相關(guān)工作人員。

2.1.3 系統(tǒng)外部接口

(1)接入信息

當(dāng)需要接入外部系統(tǒng)的實(shí)時(shí)信息時(shí)，提供REST 接口供其調(diào)用。例如從服務(wù)商接入的航班信息；從總部ERP接入人員、車輛、航空公司等基本信息。

考慮到接入的安全性，采用JWT 認(rèn)證網(wǎng)關(guān)進(jìn)行接入驗(yàn)證，通過token+IP 信息進(jìn)行接口驗(yàn)證。

(2)推送信息

向外部系統(tǒng)實(shí)時(shí)推送信息的場景，采用WebHook 接口。例如向航空公司推送實(shí)時(shí)的任務(wù)進(jìn)度以及油單數(shù)據(jù)等；向總部ERP 發(fā)送油單數(shù)據(jù)等；向機(jī)場發(fā)送加油保障進(jìn)度等。

2.2 系統(tǒng)功能架構(gòu)

飛機(jī)加油調(diào)度系統(tǒng)通過收集航班信息的起、落地時(shí)間，結(jié)合加油員、加油車以及停機(jī)坪位置等信息，對機(jī)場內(nèi)所有航班的加油保障任務(wù)進(jìn)行指揮調(diào)度，為加油員派發(fā)調(diào)度任務(wù)，加油員接受任務(wù)并進(jìn)行加油作業(yè)，加油成功后生成電子油單，經(jīng)簽字確認(rèn)后上傳至云平臺(tái)作為結(jié)算的依據(jù)，確保加油作業(yè)安全、高效、及時(shí)。

2.2.1 系統(tǒng)功能

系統(tǒng)主要分為航班任務(wù)調(diào)度、加油員加油調(diào)度、基礎(chǔ)信息管理以及統(tǒng)計(jì)信息顯示4 個(gè)功能，系統(tǒng)功能架構(gòu)如圖4 所示。

(1)航班任務(wù)調(diào)度

調(diào)度員登入航班任務(wù)調(diào)度系統(tǒng)，根據(jù)航班信息對機(jī)場內(nèi)的加油任務(wù)進(jìn)行手動(dòng)或智能化的調(diào)度。功能包括：①列表顯示：對航班、加油員、所屬機(jī)場航班、加油任務(wù)、已下發(fā)任務(wù)等信息分別進(jìn)行列表顯示；②調(diào)度功能：包括調(diào)度員手動(dòng)調(diào)度和智能調(diào)度，手動(dòng)調(diào)度由調(diào)度員根據(jù)各種信息進(jìn)行人工判斷，將任務(wù)派給加油員，智能調(diào)度提供智能任務(wù)計(jì)劃并展示給調(diào)度員，經(jīng)調(diào)度員確認(rèn)后將自動(dòng)下發(fā)任務(wù)給加油員；③油單管理：對已完成任務(wù)生成的油單進(jìn)行管理，可進(jìn)行油單下載、更新等；④管理配置：包括人員登錄登出、航顯配置管理、加油員分組管理等。

(2)加油員加油調(diào)度

加油員采用手持PAD 登入加油員加油調(diào)度系統(tǒng)，駕駛加油車進(jìn)行飛機(jī)加油保障。功能包括：①加油員登錄登出，人車綁定；②任務(wù)列表、任務(wù)詳情、航班列表；③任務(wù)申請，加油員可主動(dòng)申請未下發(fā)的航班加油任務(wù)，經(jīng)調(diào)度員同意后申請成功；④電子簽名、油單管理等。

(3)基礎(chǔ)信息管理

系統(tǒng)管理員對人員、車輛、油料、航班、航空公司、機(jī)場、機(jī)位油井以及常用語等數(shù)據(jù)的設(shè)定管理及油單審核等業(yè)務(wù)，實(shí)現(xiàn)統(tǒng)一的基礎(chǔ)信息管理管控。

(4)統(tǒng)計(jì)信息顯示

對加油業(yè)務(wù)相關(guān)的一些信息進(jìn)行統(tǒng)計(jì)，體現(xiàn)歷史加油情況，為管理提供依據(jù)。功能包括：①航空公司統(tǒng)計(jì)：對航空公司的銷售量、油單數(shù)量等進(jìn)行統(tǒng)計(jì)；②加油員統(tǒng)計(jì)：對加油員的工作時(shí)間、加油量、加油飛機(jī)架次等進(jìn)行統(tǒng)計(jì)；③車輛統(tǒng)計(jì)：對加油車的作業(yè)時(shí)間、加油量、加油飛機(jī)架次等進(jìn)行統(tǒng)計(jì)；④對各類統(tǒng)計(jì)信息的搜索、導(dǎo)出。

2.2.2 系統(tǒng)業(yè)務(wù)流程

飛機(jī)加油調(diào)度業(yè)務(wù)的主要流程分為調(diào)度任務(wù)生成、調(diào)度任務(wù)執(zhí)行、調(diào)度任務(wù)完成3 個(gè)階段，業(yè)務(wù)流程如圖5 所示。

(1)調(diào)度任務(wù)生成階段

系統(tǒng)從外部系統(tǒng)獲取航班信息，生成航班列表，再根據(jù)航班列表生成航班加油任務(wù)并呈現(xiàn)給調(diào)度員，調(diào)度員也可手動(dòng)添加臨時(shí)航班。調(diào)度員可對轄區(qū)內(nèi)加油員進(jìn)行任務(wù)派發(fā)，同時(shí)，加油員也可根據(jù)情況主動(dòng)申請未派發(fā)的任務(wù)，最后由調(diào)度員確認(rèn)是否予以通過。

(2)調(diào)度任務(wù)執(zhí)行階段

接受任務(wù)后，加油員到達(dá)指定機(jī)位并確認(rèn)到位。任務(wù)所屬飛機(jī)停至機(jī)位后，加油員對任務(wù)信息進(jìn)行確認(rèn)，然后開始實(shí)施加油作業(yè)。加油過程中，加油員需按照燃油加注操作流程規(guī)范上報(bào)作業(yè)進(jìn)度，完成加注并確認(rèn)數(shù)據(jù)無誤后，系統(tǒng)將生成電子油單，由飛機(jī)機(jī)長在PAD 上簽字確認(rèn)。

(3)調(diào)度任務(wù)完成階段

通過車載打印機(jī)打印油單，并將油單及任務(wù)數(shù)據(jù)上傳到機(jī)場云服務(wù)器，至此加油任務(wù)完成。機(jī)場云服務(wù)器將接收到的油單數(shù)據(jù)實(shí)時(shí)發(fā)送到總部進(jìn)行結(jié)算。

3 應(yīng)用

本系統(tǒng)在中航油智慧加油系統(tǒng)中應(yīng)用，采用Spring Cloud 微服務(wù)框架實(shí)現(xiàn)。系統(tǒng)前端分為航班調(diào)度(Web端)、加油員手持調(diào)度(PAD 端)和基礎(chǔ)信息管理3 個(gè)系統(tǒng)，以react 為基礎(chǔ)，同時(shí)支持PC 和PAD 兩個(gè)操作環(huán)境；后端采用Spring Cloud 為微服務(wù)提供支持，主要分為業(yè)務(wù)操作、基礎(chǔ)信息管理以及其他功能的微服務(wù)，微服務(wù)均獨(dú)立部署在Docker 容器中。利用Spring Cloud 的Zuul工程作為網(wǎng)關(guān)來訪問服務(wù)器的服務(wù)集群，其中包含了對權(quán)限的相關(guān)處理，通過過濾器filter 實(shí)現(xiàn)權(quán)限的配置與檢查，權(quán)限相關(guān)數(shù)據(jù)在Redis 中緩存；同時(shí)，利用token進(jìn)行分布式的人員狀態(tài)管理，利用WebSocket 進(jìn)行前后端通信，對實(shí)時(shí)性高的數(shù)據(jù)進(jìn)行交換。通過Kafka 和外部接口服務(wù)來與其他系統(tǒng)進(jìn)行數(shù)據(jù)交互。

飛機(jī)加油調(diào)度系統(tǒng)實(shí)現(xiàn)了航班加油任務(wù)的手動(dòng)調(diào)度與智能調(diào)度功能，使得加油員能夠通過手持PAD 接收并執(zhí)行任務(wù)，支持油單的管理與上傳，也實(shí)現(xiàn)了對基礎(chǔ)信息的集中管控以及多項(xiàng)信息的綜合統(tǒng)計(jì)功能，系統(tǒng)部署在各地干線機(jī)場，負(fù)責(zé)本機(jī)場與所管轄支線機(jī)場的加油調(diào)度。

4 結(jié)論

在飛機(jī)加油保障信息化系統(tǒng)建設(shè)的背景下，本文針對飛機(jī)加油調(diào)度業(yè)務(wù)的特點(diǎn)和實(shí)際需求，采用微服務(wù)作為系統(tǒng)的基礎(chǔ)架構(gòu)，詳細(xì)闡述了微服務(wù)架構(gòu)的歷史演進(jìn)過程及各種架構(gòu)的適用場景，對實(shí)現(xiàn)微服務(wù)架構(gòu)的相關(guān)技術(shù)進(jìn)行分析，提出了基于微服務(wù)的飛機(jī)加油調(diào)度系統(tǒng)架構(gòu)，并在中航油智慧加油系統(tǒng)改造項(xiàng)目成功應(yīng)用。系統(tǒng)可用性、可擴(kuò)展性高，部署靈活高效。

目前，微服務(wù)架構(gòu)的應(yīng)用還處于起步階段，隨著系統(tǒng)后期建設(shè)與擴(kuò)展升級，對微服務(wù)的研究與應(yīng)用將更加深入，以期為系統(tǒng)穩(wěn)定運(yùn)行與性能優(yōu)化提供支撐。