基于衛(wèi)星網(wǎng)的機(jī)載內(nèi)容自動(dòng)更新系統(tǒng)的設(shè)計(jì)與可行性分析

楊君屹，趙 杰，王逸璇，陳瑞揚(yáng)，劉新剛，李宗寶，張弘喆

（1. 星航互聯(lián)（北京）科技有限公司，北京 100094；2. 中國(guó)衛(wèi)通集團(tuán)股份有限公司，北京 100190）

1 概述

1.1 研究背景及其意義

機(jī)載覆蓋衛(wèi)星網(wǎng)絡(luò)使乘客在機(jī)上體驗(yàn)實(shí)時(shí)的空地互聯(lián)一直是一個(gè)很火爆的話題，在機(jī)載端開發(fā)應(yīng)用也是最近各公司及航空公司首要解決的相關(guān)事項(xiàng)。這一舉措非常有利于國(guó)內(nèi)的網(wǎng)絡(luò)覆蓋和上網(wǎng)人員數(shù)量的提升。目前，衛(wèi)星互聯(lián)網(wǎng)在荒漠、海洋都有著不錯(cuò)的前景和覆蓋面積，只需要安裝一套衛(wèi)星接收裝置，即可體驗(yàn)衛(wèi)星網(wǎng)絡(luò)覆蓋，這對(duì)于飛機(jī)上手機(jī)無網(wǎng)絡(luò)的情況是非常重要的措施。截止到2020年底，國(guó)內(nèi)飛機(jī)合計(jì)3 903架，國(guó)內(nèi)空地互聯(lián)網(wǎng)的普及率僅為5.5%，這對(duì)于國(guó)內(nèi)機(jī)載互聯(lián)網(wǎng)的發(fā)展是十分不利的[1]。

1.2 國(guó)內(nèi)外研究現(xiàn)狀

根據(jù)民航局公布的數(shù)據(jù)，截至2020年年終，國(guó)內(nèi)的20家航空公司有654架飛機(jī)可以提供面向全體乘客的網(wǎng)絡(luò)服務(wù)，其中三分之二都是局域網(wǎng)服務(wù)，不可以直接聯(lián)通互聯(lián)網(wǎng)。真正意義上的互聯(lián)網(wǎng)飛機(jī)，目前統(tǒng)計(jì)有11家航司的213架飛機(jī)。目前來看，2020年國(guó)內(nèi)飛機(jī)合計(jì)3 903架，可以說經(jīng)過8年的準(zhǔn)備工作，國(guó)內(nèi)空地互聯(lián)網(wǎng)普及率為5.5%。北美地區(qū)航空互聯(lián)網(wǎng)起于2009年，并于2013年開始高速發(fā)展，7～8年時(shí)間里，國(guó)內(nèi)與北美仍存在有10倍左右的差距。根據(jù)中金研究院數(shù)據(jù)，2016年美國(guó)達(dá)美航空、美國(guó)航空和美聯(lián)航機(jī)隊(duì)的旅客上網(wǎng)覆蓋率分別達(dá)93%、71%和48%，并且美國(guó)西南航空和捷藍(lán)航空，機(jī)隊(duì)覆蓋率也達(dá)到了80%和61%?，F(xiàn)在國(guó)內(nèi)空地互聯(lián)網(wǎng)公司最早也是在2015年左右出現(xiàn)的，并且目前技術(shù)方案并不成熟，由此可見，國(guó)內(nèi)的航空互聯(lián)網(wǎng)市場(chǎng)有著充足的發(fā)展前景與發(fā)展空間[1]。

2 相關(guān)技術(shù)說明

衛(wèi)星互聯(lián)網(wǎng)技術(shù)依賴于機(jī)載接收發(fā)送設(shè)備、衛(wèi)星和地面站這三個(gè)重要組成部分。本系統(tǒng)中使用的衛(wèi)星互聯(lián)網(wǎng)技術(shù)需要的衛(wèi)星是指Ka頻段的高通量衛(wèi)星，主要依賴于中星16號(hào)衛(wèi)星。Ka頻段抗干擾能力很強(qiáng)，并且具有自動(dòng)功率控制技術(shù)用以解決雨衰問題。地面站位于國(guó)內(nèi)不同區(qū)域，不同位置的信關(guān)站通過光纖網(wǎng)絡(luò)相互鏈接，用來形成完整的信息網(wǎng)絡(luò)。機(jī)載接收發(fā)送設(shè)備主要是調(diào)制解調(diào)器，它主要用于控制衛(wèi)星信號(hào)的發(fā)送與接收工作，是機(jī)上終端和機(jī)載天線之間連接的橋梁。

2.1 軟件技術(shù)

機(jī)載軟件及內(nèi)容自動(dòng)更新系統(tǒng)分為地面端和機(jī)上端兩部分，地面平臺(tái)需要對(duì)多個(gè)飛機(jī)進(jìn)行統(tǒng)一管理，這種模式需要地面及機(jī)上采用分布式方案。并且由于飛機(jī)較多，所以也會(huì)產(chǎn)生較多的數(shù)據(jù)用于存儲(chǔ)，涉及文件存儲(chǔ)服務(wù)器MinIO。其次，在支持軟件自動(dòng)上機(jī)并部署啟動(dòng)時(shí)，需要把機(jī)上的前端和后端服務(wù)生成Docker鏡像用于維護(hù)，所以這里也用到了Docker技術(shù)和Docker鏡像存儲(chǔ)技術(shù)Harbor。由于機(jī)上與地面網(wǎng)絡(luò)的特性，需要維持一個(gè)穩(wěn)定的機(jī)上地面通信方式，所以采用了大數(shù)據(jù)消息通道Kafka。下面會(huì)對(duì)這些技術(shù)分別闡述。

2.1.1 Spring Cloud

Spring Cloud作為分布式框架的整合適用于當(dāng)前系統(tǒng)對(duì)于地面平臺(tái)的技術(shù)特性，它的各個(gè)組件依賴于Spring Boot，可以簡(jiǎn)化分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)工作。在本系統(tǒng)中應(yīng)用到的Spring Cloud組件如下所示。

（1）Nacos（注冊(cè)與配置中心）。Nacos是針對(duì)分布式架構(gòu)的微服務(wù)提供的服務(wù)發(fā)現(xiàn)與負(fù)載均衡、統(tǒng)一配置管理和服務(wù)治理的強(qiáng)大綜合性解決方案的組件。

作為配置中心，它可以對(duì)注冊(cè)到其中的微服務(wù)進(jìn)行統(tǒng)一的發(fā)布與修改配置。在配置中心修改或發(fā)布了相關(guān)微服務(wù)的配置后，它將主動(dòng)向注冊(cè)進(jìn)來的微服務(wù)進(jìn)行通知，然后微服務(wù)會(huì)自動(dòng)從配置中心獲得最新修改的配置并應(yīng)用。

作為注冊(cè)中心，它可以對(duì)注冊(cè)到其中的微服務(wù)進(jìn)行服務(wù)發(fā)現(xiàn)并動(dòng)態(tài)負(fù)載均衡使請(qǐng)求分配到不同的微服務(wù)實(shí)例中，同時(shí)對(duì)注冊(cè)進(jìn)來的微服務(wù)進(jìn)行健康檢查。

（2）Gateway（請(qǐng)求網(wǎng)關(guān)）。Gateway是一個(gè)針對(duì)分布式架構(gòu)路由層面的提供統(tǒng)一路由訪問與相關(guān)攔截機(jī)制的統(tǒng)一API路由管理方式組件。

它的基本功能是，動(dòng)態(tài)路由基本上可以匹配任何訪問其的請(qǐng)求、并將其轉(zhuǎn)發(fā)到在Nacos中注冊(cè)的微服務(wù)中；針對(duì)路由指定斷言與攔截機(jī)制，能夠判斷并對(duì)請(qǐng)求進(jìn)行處理，靈活地判斷是否讓請(qǐng)求放行。

（3）Open Feign服務(wù)間調(diào)用。Open Feign是Spring Cloud提供的聲明式調(diào)用組件，常用于各個(gè)微服務(wù)之間相互調(diào)用，在使用Nacos作為注冊(cè)中心時(shí)，Open Feign也會(huì)到Nacos注冊(cè)中心中，進(jìn)行服務(wù)查詢并選取符合條件的服務(wù)隨后調(diào)用其接口進(jìn)行訪問。

2.1.2 Docker技術(shù)

（1）機(jī)載軟件技術(shù)D o c k e r及鏡像存儲(chǔ)服務(wù)Harbor。Docker是運(yùn)行在操作系統(tǒng)的一個(gè)提供容器環(huán)境的軟件。它可以使同一套編程語(yǔ)言下的軟件運(yùn)行在不同的操作系統(tǒng)中。因?yàn)闄C(jī)上環(huán)境的后臺(tái)代碼是用Java語(yǔ)言編寫的，機(jī)載服務(wù)器的系統(tǒng)與品牌多種多樣。利用Docker技術(shù)可以很好的滿足同一套Java程序在不同的操作系統(tǒng)中的部署操作。

（2）Docker的基礎(chǔ)組成部分為Image鏡像和Container容器。①Image鏡像：程序打成的包加上可以運(yùn)行的最小化環(huán)境組成了一個(gè)鏡像，它是一個(gè)只讀的模板。②Container容器：容器是Docker獨(dú)立運(yùn)行的一個(gè)或一組應(yīng)用。容器是利用鏡像創(chuàng)建出來的并且每個(gè)容器之間相互隔離。

Harbor就是幫助公司搭建企業(yè)級(jí)Docker Repository鏡像倉(cāng)庫(kù)的服務(wù)，并提供了用于管理的UI界面和角色訪問控制，也提供了一些獲取信息的API。它是對(duì)于鏡像倉(cāng)庫(kù)的一個(gè)封裝并增強(qiáng)的項(xiàng)目。

2.1.3 機(jī)上地面通信消息隊(duì)列（Kafka）

消息隊(duì)列是分布式系統(tǒng)中重要的組成部分，它主要解決的是應(yīng)用解耦、發(fā)送異步消息、削峰填谷等問題，還具有分布式事務(wù)的功能。在本系統(tǒng)中主要使用的是異步消息這一個(gè)功能，它聯(lián)通了機(jī)上和地面，是空地互聯(lián)的重中之重?？紤]到通信穩(wěn)定性、支持大數(shù)據(jù)量和高并發(fā)操作這幾項(xiàng)核心功能，本系統(tǒng)選擇使用Kafka作為消息中間件。kafka名詞解釋和工作方式如下。

（1）Producer：消息生產(chǎn)者，向Kafka發(fā)送消息的服務(wù)。

（2）Consumer：消息消費(fèi)者，從Kafka中獲取數(shù)據(jù)的服務(wù)。

（3）Topic：生產(chǎn)者和消費(fèi)者之間進(jìn)行連接的通道主題。可以簡(jiǎn)單理解為就是一個(gè)隊(duì)列。

（4）Consumer Group（CG）：由于Kafka可以廣播也可以單播的特性，本質(zhì)上就是用來發(fā)送消息的一種手段。發(fā)送給一個(gè)消息消費(fèi)者就會(huì)使用一個(gè)Group。

（5）Broker：部署的Kafka實(shí)例就是一個(gè)Broker。

（6）Partition：在多個(gè)Kaf ka之間形成分布式K af ka集群時(shí)，通常一個(gè)Topic可以分布到不同的Kaf ka實(shí)例當(dāng)中。在每個(gè)實(shí)例中的同一個(gè)Topic依靠Partition分區(qū)來指定。

（7）Offset：記錄了Kafka消息在某一個(gè)Topic中消息的順序。

3 系統(tǒng)需求與架構(gòu)設(shè)計(jì)

3.1 系統(tǒng)特點(diǎn)

機(jī)載服務(wù)器內(nèi)容更新具有安全性、實(shí)時(shí)性、穩(wěn)定性、數(shù)據(jù)量大等特點(diǎn)，且非常依賴于衛(wèi)星網(wǎng)絡(luò)的連接。這就導(dǎo)致了機(jī)上地面通信機(jī)制設(shè)計(jì)非常重要，并且考慮到機(jī)載服務(wù)器不能開啟端口使地面直接聯(lián)通機(jī)載服務(wù)器，因此所有的內(nèi)容都需要采用機(jī)載服務(wù)器主動(dòng)拉取的方式獲取。下面介紹本系統(tǒng)的功能需求。

3.2 系統(tǒng)功能需求

（1）地面端內(nèi)容采集。內(nèi)容如新聞、短視頻、音樂、電影等資源需要先通過地面平臺(tái)采集到本系統(tǒng)指定的文件服務(wù)（MinIO）服務(wù)器中。

（2）機(jī)載服務(wù)器軟件生成鏡像并上傳至Harbor服務(wù)器。開發(fā)好的機(jī)載服務(wù)器前端和后端代碼需要先打包成Docker鏡像等待機(jī)載服務(wù)器拉取并啟動(dòng)。

（3）地面平臺(tái)對(duì)內(nèi)容及軟件進(jìn)行審核。只有已經(jīng)審核通過的內(nèi)容及軟件才可以進(jìn)行上機(jī)操作。

（4）地面平臺(tái)推送指令。這里的推送不是指內(nèi)容和軟件直接發(fā)送到機(jī)上，而是給機(jī)載服務(wù)器發(fā)送一條拉取內(nèi)容或是刪除內(nèi)容的指令。

（5）將機(jī)上拉取成功或失敗回執(zhí)通知地面。機(jī)載服務(wù)器在接收到內(nèi)容和軟件上機(jī)的指令后拉取內(nèi)容和軟件是否成功的狀態(tài)，需要及時(shí)發(fā)送到地面。

（6）機(jī)載服務(wù)器拉取內(nèi)容存入本地。機(jī)載服務(wù)器在接到指令后拉取內(nèi)容和軟件并存入本地服務(wù)器中。

（7）機(jī)載服務(wù)器拉取軟件并在判斷版本后部署。機(jī)載服務(wù)器在拉取到軟件后可以對(duì)Docker鏡像進(jìn)行部署操作。

3.3 系統(tǒng)功能性需求分析

本節(jié)對(duì)本系統(tǒng)上述功能進(jìn)行需求分析并加以說明。

3.3.1 地面平臺(tái)需求分析

一個(gè)地面平臺(tái)對(duì)應(yīng)所有飛機(jī)的內(nèi)容管控與內(nèi)容更新，也是所有運(yùn)營(yíng)機(jī)上內(nèi)容及軟件的入口，它主要提供獲取內(nèi)容、發(fā)布軟件等功能，還集成了通信功能，負(fù)責(zé)主動(dòng)向機(jī)載服務(wù)器進(jìn)行通知。地面平臺(tái)需求列表如表1所示。

表1 地面平臺(tái)需求列表

3.3.2 機(jī)載平臺(tái)需求分析

機(jī)載平臺(tái)需要對(duì)旅客進(jìn)行內(nèi)容展示及軟件服務(wù)，主要面向C端，且機(jī)上對(duì)安全性非常注重，所以它的需求是只需要從地面端獲取內(nèi)容及接收地面端的消息通知。它負(fù)責(zé)上機(jī)軟件、內(nèi)容的獲取，內(nèi)容展示、軟件部署、消息通知等功能。機(jī)載平臺(tái)需求如表2所示。

表2 機(jī)載平臺(tái)需求列表

3.4 系統(tǒng)非功能性需求

非功能性需求與功能分析的功能無關(guān)，但是與系統(tǒng)運(yùn)行流暢程度和健壯性有關(guān)。本節(jié)會(huì)對(duì)系統(tǒng)的兼容性、流暢性、可移植性加以描述。

（1）兼容性。地面平臺(tái)用戶可能通過不同的瀏覽器登錄地面平臺(tái)操作界面，不同瀏覽器之間可能會(huì)產(chǎn)生一些兼容性問題。

（2）流暢性。地面平臺(tái)不同用戶之間可能會(huì)有并發(fā)操作產(chǎn)生，需要對(duì)接口的流暢性進(jìn)行支持。

（3）可移植性。機(jī)載平臺(tái)需要適配多個(gè)飛機(jī)的不同服務(wù)器，滿足一套代碼多種部署環(huán)境的條件。

3.5 可行性分析

當(dāng)前系統(tǒng)分析基于Spring Cloud架構(gòu)，集成了文件服務(wù)器、消息通信、容器化部署方案等多個(gè)技術(shù)點(diǎn)。適用于目前機(jī)上端與地面端的管理、維護(hù)需求。該系統(tǒng)可以滿足正常的內(nèi)容及軟件上機(jī)。

4 結(jié)束語(yǔ)

4.1 總結(jié)

本文主要討論了衛(wèi)星互聯(lián)網(wǎng)接入機(jī)載服務(wù)器后，機(jī)載服務(wù)器如何更新機(jī)上可以給用戶展示的內(nèi)容。包括但不限于新聞、電影、短視頻等內(nèi)容資源。這也是機(jī)載互聯(lián)網(wǎng)主流的發(fā)展趨勢(shì)。由于機(jī)載互聯(lián)網(wǎng)的必須使用衛(wèi)星網(wǎng)絡(luò)的特殊性，并且需要滿足內(nèi)容與軟件版本的不斷迭代與更新。所以才有了本文介紹的系統(tǒng)主要內(nèi)容。本文主要內(nèi)容介紹如下：①介紹了目前機(jī)載互聯(lián)網(wǎng)行業(yè)發(fā)展與國(guó)內(nèi)機(jī)載互聯(lián)網(wǎng)大概覆蓋率。總結(jié)系統(tǒng)相關(guān)的技術(shù)與互聯(lián)網(wǎng)工作模式。②對(duì)本系統(tǒng)的需求進(jìn)行梳理與分析。

4.2 展望

機(jī)載互聯(lián)網(wǎng)行業(yè)是當(dāng)下的熱門，涉及許多機(jī)上與地面的應(yīng)用技術(shù)。本文主要討論了內(nèi)容與軟件的更新，其實(shí)最重要的還是在機(jī)上接入互聯(lián)網(wǎng)的方案的實(shí)施與這一技術(shù)的穩(wěn)定發(fā)展。目前本系統(tǒng)還需要優(yōu)化的事項(xiàng)有：一是對(duì)各個(gè)飛機(jī)進(jìn)行分區(qū)域劃分和落地城市的內(nèi)容推廣；二是各個(gè)飛機(jī)單獨(dú)進(jìn)行內(nèi)容及軟件的發(fā)布；三是內(nèi)容審核制度還依賴于人工完成，可以接入自動(dòng)評(píng)判機(jī)制，減少人工審核工作量。