基于容器技術的指控軟件快速部署應用研究

摘 要：針對傳統指揮控制軟件部署應用現狀，著眼于指揮控制軟件部署方法及實現方式，重點對應用的快速部署進行研究。分析傳統部署方式的不足，引入經過互聯網實踐檢驗的容器技術，研究其在指控軟件部署方面的應用前景，提出容器化快速部署指控軟件的設計理念，進行邏輯架構設計，歸納實現快速部署的關鍵技術及需要解決的難點問題，為指控軟件進一步改良升級提供參考借鑒。

關鍵詞：指揮控制軟件；容器技術；微服務；Docker；Kubernetes

中圖分類號：E917 文獻標志碼：A DOI：10.3969/j.issn.1673-3819.2025.02.015

Research on rapid deployment for command and

control software based on container technology

MEN Hongshuan， LI Zhaorui， GUO Baofeng， YIN Wenlong

（Army Engineering University of PLA， Shijiazhuang 050003， China）

Abstract：This paper focuses on the deployment method and implementation of command and control software， and focuses on the rapid deployment of applications. Based on the practical testing of container technologys technical conditions and advantages， this paper analyzes the potential application prospects of container technology in charge software. It proposes a design concept for rapidly deploying charge software using containers， while also analyzing the shortcomings and defects of traditional deployment methods. Furthermore， it designs a logical architecture and summarizes key technologies that need to be addressed for rapid deployment and solving difficult problems. This provides valuable reference for further improving and upgrading the software.

Key words：command and control software； container technology； microservice； Docker； Kubernetes

在軍事競爭中，率先充分挖掘技術創新成果并加以軍事化應用的一方，將開啟新的競爭機制并搶占制高點。在智能化為背景的信息化戰爭中，指揮控制行為主要依托指揮控制軟件來實現，實現指控軟件快速部署是打贏現代信息化戰爭的重要一環。傳統指控系統軟件部署量大，部署效率不高。在指控集群部署過程中，需操作人員手動執行每一個步驟，不僅容易出錯，而且耗時較長，在添加新設備或進行重大配置更改時，又需要手動重新部署整個集群，導致軟件系統快速響應能力不夠迅捷。并且軟件部署采用逐機下載或介質復制安裝方式，面對終端類型復雜的指控集群，這種方式耗時耗力，若軟件運行環境配置不當還會導致未知的錯誤，從而不得不進行重新部署。

強化指控軟件面對戰場環境變化時的即時重構能力和自主調優能力，有利于提升指控軟件動態抗毀能力，持續保障作戰任務完成。容器是物理機虛擬化過程中一種標準的軟件單元，它將程序運行所需的代碼及其所有依賴環境打包成鏡像，使得應用程序能夠實現更加便捷、高效、準確的部署[1]。容器化部署方式更適用于軟件應用安裝配置繁雜的部署場景，引入容器技術為指控軟件快速部署提供了新思路。

1 容器化技術分析

1.1 容器技術概念

容器（container）技術是一種輕量級的操作系統層面的虛擬化技術， 能夠為軟件應用及其依賴環境提供一個資源獨立的虛擬運行空間[2]。容器借鑒了現實生活中“集裝箱”的含義，為應用程序部署運行提供了統一的、標準化的、隔離的運行環境，應用程序及其依賴環境在容器中運行，而各容器對外有統一的API接口標準。容器技術使得應用程序的部署不再需要單獨預配置其依賴環境，容器內的應用程序與底層操作系統實現解耦， 并可在不同宿主機上敏捷部署[3]。部署方式如圖1所示。

在眾多容器技術中，Docker[4]是目前使用范圍最廣的容器引擎。Docker容器平臺使用C/S（client-server）架構，主要由客戶端、守護進程、鏡像、容器、鏡像倉庫五個部分組成。它們之間的交互如圖2所示。

Docker容器最初是在Linux系統上開發和廣泛使用的，但隨著技術的發展，通過使用適當的工具和解決方案，現在也可通過Docker Desktop在Windows操作系統上構建和運行容器鏡像，使得容器技術在各類裝備的嵌入式系統中應用成為可能。

1.2 容器編排部署工具

為了更好地自動化管理和拓展容器，我們需要使用容器編排工具。目前使用最廣泛的容器編排工具是Kubernetes[5]，它使得部署和管理容器化的應用更加簡單高效。Kubernetes采用聲明式接口設計理念，用戶通過定義資源對象的期望狀態來管理Kubernetes集群中的資源，資源對應的控制器則負責保證資源對象從“當前狀態”遷移到“期望”狀態。這種思想將資源定義與具體實現解耦，提升了Kubernetes的自愈能力，使其更易于使用和擴展。Pod是Kubernetes中的基本單位，是在容器之上抽象出的一個概念。如果將Pod比作一顆花生，容器可以比作花生內部的種皮，鏡像可比作花生最內部的種子。單個Pod內可包含若干個容器，所有容器共享Pod的資源[6]。

傳統指控軟件運行中，如果IP地址發生變化，需重新配置并全部重啟后，才可正常使用。但容器彼此之間是隔離的，每個容器都擁有自己獨立的文件系統、網絡棧和進程空間，更新域只需Kubernetes將對應的容器進行重新配置后重啟容器即可。對于戰損或故障的指控節點，Kubernetes可通過自動控制將其剔除出指控集群，防止資源浪費和系統整體癱瘓。

2 引入容器技術優勢

傳統的指控軟件部署方式是通過存儲介質或網絡傳輸的方式，復制指控應用軟件各安裝包至目標計算機，然后在相應宿主機中配置軟件運行所需的依賴環境，環境配置正確后， 執行應用包來運行程序，整個流程完成后，指控應用才可對外提供指控服務。在部署過程中，部署、安裝、調試的工作量大，尤其環境的配置非常繁瑣且細致，稍有疏忽就會造成配置錯誤，后期對于軟件集群的調整部署不夠友好。

容器化技術日益成熟，阿里巴巴[7]、騰訊[8]、華為[9]等一線互聯網公司在實踐中廣泛應用，進一步驗證了容器技術的可靠性。指控軟件部署研究可吸納互聯網實踐中的先進技術與研究成果。與傳統部署方式相比，容器技術具有以下優勢：

部署難度降低。容器技術不再需要單獨配置應用程序運行所需的運行環境，降低了部署軟件的復雜度，在宿主機中安裝相應的容器引擎，通過拉取鏡像便可進行各設備終端的一致部署，減少環境依賴的配置環節，確保了指控軟件部署的質量和效率。

資源利用率高。由于部分裝備硬件資源有限，導致可裝應用軟件的數量和大小受限。容器通過共享主機系統的資源（如CPU、內存和網絡）來運行，從而實現了資源的最大化利用。這使得利用容器在相同的硬件資源下可以運行更多的應用程序實例，進一步提高了裝備硬件資源的利用率。

快速啟動。由于輕量級的特性，容器的啟動和停止速度更快，可達到秒級啟動，這使得指控應用程序部署過程中更加快速高效，在緊急情況下，可迅速啟動新裝備以替換戰損裝備。

隔離性好。容器的實質是進程，但與直接在宿主機執行的進程不同，容器進程運行于獨立的命名空間[10]。由于指控過程的復雜性，各指控應用間調用瞬時并發較高，各應用間通過容器隔離，有利于減少單個應用故障導致的系統癱瘓。

可彈性伸縮。容器化就是將應用程序及其依賴打包成一個可重復拉取的鏡像（image），部署到某個容器中，從而確保應用程序在不同環境中能夠一致地運行。這種容器為構建可伸縮的集群管理提供了完美的粒度水平。由于每個容器服務在獨立空間中運行，單個容器變化理論上不會影響其他容器，在Kubernetes編排功能的運行下，可實現集群中成員的添加或縮減，新的裝備設備可隨時加入戰斗，戰損裝備也可及時退出指揮集群，減少指控資源占用，提高了指控軟件的可用性和靈活性。

3 指揮控制軟件快速部署分析

3.1 實現快速部署的功能性需求

運用容器技術須將原有指控應用軟件根據業務功能和領域模型進行微服務拆分，將每個微服務的代碼及依賴環境打包成鏡像，并通過戰術云平臺完成鏡像的傳遞和儲存。戰術云平臺采用B/S架構，部署在戰場前沿服務車內，操作人員在瀏覽器的網頁上進行相關操作，觸發云端請求，經由網關后，由Kubernetes平臺統一管理調度。一組服務部署在一個Pod內，Pod中運行著支持這組服務各項功能實現的容器。

指控應用各微服務部署完成后最終運行于各容器內，部署方式為鏡像拉取和運行。為便于鏡像的存儲與管理，應建立專有的私有鏡像倉庫。客戶端與云端系統的交互模塊，前端和后端功能實現分離，與客戶端的各類交互接口部署于前端，便于客戶端人員通過瀏覽器對指控軟件部署進行操作。

3.2 實現快速部署的非功能性需求

從靈活可擴展角度分析。由于裝備設備的差異性，不同應用部署的服務存在差異，微服務拆分時各模塊之間耦合度應足夠低，實現共有功能的下沉，以便于既能針對不同業務功能靈活部署應用，又能實現不同級別指揮平臺和不同裝備間的互聯互通，使得指控軟件具有足夠的靈活度以支持復雜的應用場景。

從便于部隊操作使用角度分析。部署過程應實現操作界面窗口化，便于一個不懂運維和開發的一線保障人員根據操作手冊也能夠快速、便捷地將指控軟件部署到相應的設備，而不需要尋求專業軟件開發人員的幫助。

從節省資源角度分析。對于某節點指控軟件的部署過程，需要根據各席位不同的應用需求來選擇合適的配置鏡像。在實際執行過程中，應支持各席位自定義依賴，即通過存儲卷將已下載好的應用進行掛載，以便于同一指揮車上的各席位對軟件運行的相同依賴環境進行復用，避免同一車組人員重復下載相同的環境依賴數據，造成網絡及存儲資源的浪費。

從運行可靠性角度分析。單個指控節點的指控應用包含多個功能，數個微服務的功能組合起來才能支持應用實現全部需求，一旦某個容器運行出現異常，可能導致部署完成后應用某項功能異常或無法使用，甚至整個指控節點無法運行，因此，各容器間之間應具備強大的異常檢測和故障自愈能力，提升可靠性。

3.3 實現快速部署的邏輯架構設計

基于傳統的指揮信息系統，將各項指控軟件業務合理拆分為相應的微服務模塊，進而運用容器化技術進行部署。以某級指揮集群為例，將某級指揮平臺打造為輕量戰術云平臺，本級服務器作為戰術云端服務器，數據通過各級交換機進行中轉，下屬各級指揮車及各類裝備終端為客戶端。快速部署邏輯架構設計如圖 3所示。

軟件科研單位完成指控軟件的微服務開發后，進行鏡像封裝，供應至本級指揮平臺，鏡像經本級指揮平臺由保障人員推送至鏡像倉庫服務器。在服務器內部依據私有鏡像倉庫規范，搭建鏡像倉庫服務器，負責管理和存儲本級指揮集群的全部鏡像，并向各指揮層級裝備設備群提供鏡像下載服務。為保證鏡像存儲的高可靠性，鏡像倉庫服務器宜采用主備集群策略。

服務器集群需預置Kubernetes和容器環境，各級指揮車設備群和各類裝備終端群需預置容器引擎及環境。根據戰時網絡環境，可采取在線部署和離線部署兩種方式，在網絡不暢時，可采用離線方式進行容器化環境的安裝與部署[11]。云端服務器集群由Kubernetes管理，一線指揮保障人員通過簡單的命令行操作或可視化窗口進行鏡像拉取和運行，使指控應用微服務實例正常運行于各自的容器中并保持良好的交互，完成指控軟件各應用的部署和管理，從而使指控節點中的整個應用正常運行，達到相應指揮效果，保障戰斗任務圓滿完成。

基于容器輕量、敏捷的技術特性，保障人員可在較短時間內完成各終端設備指控軟件的部署任務，若某裝備設備發生故障，也便于新裝備及時進行軟件部署后替換，保障指揮控制系統在故障狀態中快速恢復。且Kubernetes具有跨數據中心的可移植性，使得指控軟件系統可具備云端應用級的容災方案。

4 關鍵技術實現

基于容器技術部署指控軟件，關鍵技術主要包括微服務拆分、鏡像推送及拉取、鏡像部署和容器編排管理4個階段，如圖4所示。

指揮車及各裝備宿主機為各指控節點提供硬件及基礎操作系統支持。配置中心集中管理指控集群中不同節點的微服務應用的配置，配置修改后能實時推送到裝備設備端，容器運行使用過程中的各項配置均在配置中心進行管理，確保配置的安全性和可控性。服務注冊中心提供了服務注冊、服務發現、心跳檢測和數據同步、客戶端緩存等功能，確保本級指揮中心對下級各指控節點的實時指揮和控制以及各節點間進行信息交互。當容器中的微服務啟動后，首先讀取容器中包含注冊中心地址信息的文件，根據地址連接到注冊中心的配置中心，從配置中心讀取服務注冊地址，然后將容器地址登記到注冊中心。注冊中心還會提供其他微服務的注冊信息，微服務通過注冊信息與其他微服務實現交互[12]。在運行過程中，各節點會緩存其他節點的注冊地址，如本機指揮中心受敵打擊失去效能，各指揮節點仍可根據緩存中的地址進行交互，確保后續戰斗任務繼續進行。

4.1 微服務拆分階段

指控軟件科研開發人員將傳統指控軟件根據軟件功能領域，按照最優的拆分策略進行微服務拆分。軟件集成采用使用廣泛的Spring Cloud微服務架構[13]，開發人員完成微服務應用的開發后，將代碼上傳至本地的GitLab版本管理平臺進行代碼版本管理。Jenkins為自動化開源服務器，它功能強大，提供了自動化集成和部署的框架[14]。代碼開發過程中的版本控制及鏡像制作，均在保密良好的局域網中進行，確保指控軟件的絕對安全性。基于容器技術的軟件開發采用標準化的API接口進行交互，有利于推進行業級的標準化，克服目前指控領域各單位進行散點開發和重復建設的弊端，促進科研團隊集中力量研發打贏亟需的關鍵組件。

4.2 鏡像推送和拉取階段

按照專網分離的原則，打包好的鏡像包以離線方式推送至指揮平臺的鏡像倉庫服務器，在服務器中形成運行著的多個Pod，預制的Kubernetes環境對所有鏡像文件進行統一的管理和調度。指揮保障人員在穩定的戰術局域網環境中，通過簡單的命令行代碼拉取各自作戰對應功能的鏡像。

4.3 鏡像部署階段

鏡像拉取成功后，保障人員在容器中運行鏡像，鏡像程序會自動配置應用程序運行所需的依賴環境，同車組席位人員可共享其他席位依賴配置項。運行環境配置完成后，執行服務運行命令運行該程序，各微服務啟動運行，并通過API接口與其他容器中的微服務進行交互和調度，形成完備的功能模塊，應用程序部署成功。

4.4 容器編排管理階段

各項應用實例最終運行在Kubernetes部署的Pod容器中[15]，各指控節點上運行著多個Pod。 API 服務器會攔截處理所有指控節點的請求，并與控制器管理器和調度器交互共同處理請求。通過一系列認證和授權等操作后， Kubernetes會將請求信息存儲到分布式鍵值存儲系統中，保障人員通過Kubelet命令與API 服務器交互，從而對節點內Pod或者其他資源的操作，如圖5所示。

4.5 試驗論證

本研究基于本地局域網服務器，以離線方式安裝部署了Kubernetes軟件和Docker軟件，引入微服務架構應用進行試驗論證。

試驗采用微服務框架，應用容器化技術部署了基于百度飛槳深度學習框架構建的PP-LiteSeg智能語義分割模型，實現對偵察圖片的語義化處理，并從本地服務器拉取語義分割后的處理結果。模型軟件架構圖如圖6所示。

模型鏡像通過容器化方式部署到服務器后，在局域網內的3臺計算機通過鏡像拉取的方式，拉取模型鏡像到本機。鏡像中包含模型運行所需完整環境配置，在計算機內部署模型過程中，無須再配置模型運行所需環境依賴，運行鏡像文件便可快速完成模型部署。部署完成后，可在Windows終端界面（如圖7所示）或Docker Desktop軟件界面（如圖8所示）查看鏡像部署情況和容器運行情況。

通過Kubernetes平臺，服務器端可調度3臺計算機中的Pod，實現計算資源的負載均衡。計算機端輸入圖片，語義化處理后，服務器端及其他計算機均可靈活調取。處理效果如圖9所示。

通過試驗論證，Kubernetes軟件平臺和Docker軟件離線部署使用效果良好，在局域網狀態下，容器化部署更加便捷、快速、高效。Kubernetes對負載資源進行平衡調度， PP-LiteSeg智能語義分割模型運行穩定，達到了試驗的預期效果，為下步指控軟件容器化部署積累了經驗。

5 面臨挑戰

5.1 微服務拆分較為困難

信息化作戰指揮層級分布廣，各兵種專業多樣，武器平臺復雜，傳統指控軟件系統本身非常龐大和復雜。因此在對指控軟件進行微服務拆分重構過程中，應做好完整的模塊劃分，在確保軟件應用功能不中斷的前提下，采用“絞殺應用”模式[16]，逐步將原有應用程序重構為微服務，重構過程需要數月甚至數年，是一項龐大而系統的工程。

5.2 容器技術使用的局限性

容器化技術本身存在一定的操作系統適配局限性，對操作系統的版本要求比較高，對于一些版本較低的操作系統并不友好，甚至無法使用。雖然容器技術具有輕量級的特點，但部署一定數量的容器仍會占用大量硬件資源，部分基于嵌入式操作系統的裝備在有些場景不便于拉取鏡像進行部署，無法利用容器的優點，我們只能以現行方式將應用部署到裝備的物理機或者虛擬機上，這有待國產化廠家對容器技術的進一步優化改進。

5.3 速率瓶頸

容器化提升了物理機的硬件資源利用率，但數據交互所需網絡資源隨之增大。各指控應用業務高峰期并行數量大時，物理主機用來支撐容器的服務資源就會緊張，甚至造成隊列堵塞[17]，指控末端會感受到應用卡頓。戰術云服務器端通過內部網絡進行訪問讀寫操作，網絡帶寬與數據吞吐速率是制約指控軟件數據處理能力上限的瓶頸。

6 結束語

容器技術在互聯網開發部署應用中扮演著越來越重要的角色，本文對指控軟件快速部署應用進行探索，以解耦的思路從根源上提升指控系統的靈活性和穩定性，從而提升指控軟件的部署效率，有利于從體系架構層面對現行指控軟件系統改造調優，在未來戰場爭得“快敵一秒、先敵一步、勝敵一籌”的指控效果。

參考文獻：

[1] 王瓊. 微服務與容器化在圖文包裝集群中的應用[J]. 現代電視技術， 2020（1）： 115-121.

WANG Q. Application of microservices and containerization in graphic packaging cluster[J]. Advanced Television Engineering， 2020（1）： 115-121.

[2] 嚴亮亮. 面向輕量云的嵌入式系統容器化資源管理技術研究[D]. 北京： 北京郵電大學， 2020.

YAN L L. Research on containerized resource management technology of embedded system for lightweight cloud[D]. Beijing： Beijing University of Posts and Telecommunications， 2020.

[3] 鄭國慶. 容器云平臺上應用自動化部署系統的設計與實現[D]. 杭州： 浙江大學， 2021.

ZHENG G Q. Design and implementation of application automated deployment system on container cloud platform[D]. Hangzhou： Zhejiang University， 2021.

[4] 盧西亞諾·巴雷西，喬瓦尼·夸特羅基，尼古拉斯·拉西.關于容器引擎的定性與定量分析[J].軟件工程，2024，210：111 965.

BARESI L，QUATTROCCHI G，RASI N.A qualitative and quantitative analysis of container engines[J].The Journal of Systems and Software，2024，210：111 965.

[5] 卡門·卡里翁.基于Kubernetes的容器編排標準——文獻統計分析[J].網格計算，2022，20（4）：42.

CARMENC.Kubernetes as a standard container orchestrator-A bibliometric analysis[J].Journal of Grid Computing，2022，20（4）：42.

[6] 卡洛斯·德·阿方索， 阿曼達·卡拉特拉瓦， 赫爾曼·莫爾托.基于容器的虛擬彈性集群[J].系統與軟件， 2017，127：1-11.

ALFONSO D C，CALATRAVA A，MOLTG.Container-based virtual elastic clusters[J].The Journal of Systems and Software，2017，127：1-11.

[7] 阿里云[EB/OL].https：//www.aliyun.com/.

Aliyun[EB/OL].https：//www.aliyun.com/.

[8] 騰訊云[EB/OL].https：//cloud.tencent.com/.

Tencent cloud[EB/OL].https：//cloud.tencent.com/.

[9] 華為云[EB/OL].https：//activity.huaweicloud.com/.

Hicloud[EB/OL].https：//activity.huaweicloud.com/.

[10]田源， 李樊， 汪曉臣， 等. Docker技術在乘客信息系統部署中的應用[J]. 鐵路計算機應用， 2019， 28（5）： 69-72.

TIAN Y， LI F， WANG X C， et al. Docker technology applied to deployment of passenger information system[J]. Railway Computer Application， 2019， 28（5）： 69-72.

[11]喜度， 殷笑茹， 牛靄琛. 基于關聯挖掘的自動站數據質控方法的改進[J]. 氣象水文海洋儀器， 2018， 35（4）： 73-78.

XI D， YIN X R， NIU A C. Improvement for automatic station data quality control method based on association mining[J]. Meteorological， Hydrological and Marine Instruments， 2018， 35（4）： 73-78.

[12]邁克爾·索爾弗蘭克， 弗里德爾·洛赫， 斯蒂夫·登特尼爾，等.對Docker在工業自動化中分布式和時間敏感型應用的輕量級虛擬化的評估[J].IEEE工業信息學報，2021，17（5）：3 566-3 576.

MichaelS，Frieder L，Steef D，et al.Evaluating Docker for lightweight virtualization of distributed and time-sensitive applications in industrial automation[J].IEEE Transaction on Industrial Informatics，2021，17（5）：3 566-3 576.

[13]S.萊恩-沃爾什， J.斯蒂勒曼， F.桑托羅，等.基于Docker的MDSplus導論[J].融合工程與設計， 2021，165：112 121.

S.L，J.S，F.S，et al. Introduction to MDSplus using Docker[J].Fusion Engineering and Design，2021，165：112 121.

[14]董子奇， 劉淇， 高原， 等. 基于容器技術的微服務部署研究[J]. 信息技術與標準化， 2023（1）： 93-98.

DONG Z Q， LIU Q， GAO Y， et al. Research of microservice deployment based on container technology[J]. Information Technology amp; Standardization， 2023（1）： 93-98.

[15]曼尼什·阿比謝克， D.拉杰斯瓦拉·拉奧， K.蘇布拉馬尼亞姆.利用Kubernetes和CI/CD流水線部署容器的框架[J]. 國際高級計算機科學及應用期刊，2022，13（4）：522-526.

Abhishek K M，Rao R D，Subrahmanyam K. Framework to deploy containers using Kubernetes and CI/CD Pipeline[J].International Journal of Advanced Computer Science and Applications，2022，13（4）：522-526.

[16]（美）克里斯·理查森. 微服務架構設計模式[M]. 喻勇，譯.北京：機械工業出版社，2023：417-420.

CHRISR.Microservices patterns：with examples in Java[M]. Translated by YU Y. Beijing：China Machine Press，2023：417-420.

[17]劉宏娟， 黃煒， 李文吉， 等. 基于Kubernetes的衛星遙感數據容器云平臺[J]. 計算機測量與控制， 2022， 30（1）： 209-214， 220.

LIU H J， HUANG W， LI W J， et al. A Kubernetes based container cloud-platform of satellite remote sensing data[J]. Computer Measurement amp; Control， 2022， 30（1）： 209-214， 220.

（責任編輯：許韋韋）