基于Docker的作戰(zhàn)應(yīng)用微服務(wù)化架構(gòu)研究?

（海軍研究院 北京 100063）

1 引言

Docker容器是一種輕量級虛擬化技術(shù)［1～2］，自誕生以來獲得高速發(fā)展，目前已經(jīng)在云計算領(lǐng)域得到充分實踐檢驗［3～4］。微服務(wù)架構(gòu)系統(tǒng)基于Docker容器進行集成部署和運維，可以實現(xiàn)容器編排、服務(wù)自動彈性伸縮、自動修復、監(jiān)控管理等功能，降低用戶的運維成本和難度［5］。微服務(wù)架構(gòu)的應(yīng)用可以實現(xiàn)軟件的松耦合、跨區(qū)域開發(fā)，傳統(tǒng)的軟件系統(tǒng)設(shè)計、開發(fā)、測試、部署與運維等各個環(huán)節(jié)，因為容器和微服務(wù)架構(gòu)正在被逐步改變。目前已有眾多研究人員開展相關(guān)研究。

文獻［6］基于Docker容器技術(shù)開發(fā)了數(shù)據(jù)庫微服務(wù)系統(tǒng)，系統(tǒng)具有快速，擴展性高等優(yōu)勢，為大數(shù)據(jù)處理提供了可靠的技術(shù)保障。文獻［7］設(shè)計了基于Docker的計算機應(yīng)用快速部署系統(tǒng)，該系統(tǒng)通過利用Docker響應(yīng)速度快，資源消耗少的特點，實現(xiàn)了短時間內(nèi)的彈性伸縮功能。文獻［8］提出了一種基于Docker技術(shù)來搭建企業(yè)私有PaaS云平臺的方案，該平臺支持動態(tài)伸縮，在高效遷移部署方面有較好效果，能提升運維效率和資源利用率。

2 傳統(tǒng)作戰(zhàn)應(yīng)用架構(gòu)與微服務(wù)架構(gòu)

傳統(tǒng)的艦載指控系統(tǒng)作戰(zhàn)應(yīng)用基于“應(yīng)用框架+應(yīng)用構(gòu)件”的設(shè)計模式，采用全分布式的體系結(jié)構(gòu)設(shè)計［9］。應(yīng)用構(gòu)件包括顯控構(gòu)件、計算服務(wù)構(gòu)件、接口適配構(gòu)件等，各個業(yè)務(wù)模塊由獨立的功能構(gòu)件實現(xiàn)，構(gòu)件間使用DDS（Data Distribution Service）數(shù)據(jù)分發(fā)服務(wù)進行通信。應(yīng)用構(gòu)件依賴開放式的應(yīng)用框架運行，框架屏蔽了底層操作系統(tǒng)差異，并對構(gòu)件的生命周期進行管理。

這種設(shè)計模式對系統(tǒng)軟件解耦，集中監(jiān)控管理起到一定促進作用，但仍存在一些不足：

1）由于對應(yīng)用的劃分粒度較大，單個構(gòu)件功能復雜，集成效率較低，特別對于新研的系統(tǒng)集成困難，不利于系統(tǒng)敏捷開發(fā)和部署；

2）受限于物理機或虛擬機的環(huán)境，難以實現(xiàn)資源的靈活彈性伸縮；

3）系統(tǒng)缺乏有效的運維管理工具，對各個構(gòu)件的運行狀態(tài)監(jiān)控不足，構(gòu)件不具備自修復、自擴容能力。

近年來開展微服務(wù)架構(gòu)研究的人越來越多，微服務(wù)架構(gòu)為敏捷開發(fā)和部署提供了巨大的幫助。微服務(wù)是一些小而自治、協(xié)同工作的服務(wù)，具有獨立部署、復雜度可控、技術(shù)選型靈活和高擴展性的優(yōu)點［10］。通過對應(yīng)用進行細粒度的劃分，每一個微服務(wù)只專注于單一功能，單個業(yè)務(wù)可拆分為多個獨立開發(fā)，軟件開發(fā)效率得以提高，縮短了應(yīng)用交付周期。同時，微服務(wù)之間邊界表述清晰，去除中心化，服務(wù)變更升級對系統(tǒng)整體影響較小，降低了系統(tǒng)升級風險。由于技術(shù)選型靈活，各個服務(wù)的開發(fā)人員可以自由選擇合適的技術(shù)棧，避免了技術(shù)棧升級對系統(tǒng)整體的影響。圖1是微服務(wù)架構(gòu)體系圖，包括云平臺、容器、服務(wù)、接入、應(yīng)用共五層。

圖1 微服務(wù)架構(gòu)體系圖

1）云平臺層處于架構(gòu)最底層，用于提供基礎(chǔ)硬件資源或虛擬化資源，主要包括計算、存儲和網(wǎng)絡(luò)等資源。

2）容器層位于云平臺之上，為微服務(wù)提供輕量級虛擬化后的運行環(huán)境，容器是系統(tǒng)管理的基本單元，容器層對容器集群提供監(jiān)控、資源調(diào)度、彈性伸縮、容器編排等功能，鏡像倉庫用于鏡像存儲。

3）服務(wù)層由各類微服務(wù)組成，例如服務(wù)注冊、發(fā)現(xiàn)，目標分析服務(wù)、情報管理服務(wù)等。

4）接入層負責接入外部應(yīng)用的服務(wù)請求，提供系統(tǒng)負載均衡，網(wǎng)關(guān)等。

5）應(yīng)用層位于架構(gòu)最頂層，是實際的業(yè)務(wù)應(yīng)用。

傳統(tǒng)作戰(zhàn)應(yīng)用架構(gòu)與微服務(wù)架構(gòu)在諸多方面存在差異：

在系統(tǒng)開發(fā)階段，構(gòu)件化與微服務(wù)化對系統(tǒng)的劃分粒度不一致，微服務(wù)對系統(tǒng)的劃分更加細粒度。微服務(wù)架構(gòu)使得開發(fā)人員只需要專注于自己負責的某個服務(wù)，只要服務(wù)遵守約定的API即可。開發(fā)人員也可以不受限于使用過時的技術(shù)開發(fā)新的項目。微服務(wù)架構(gòu)促進了軟件的敏捷開發(fā)。

在系統(tǒng)部署階段，傳統(tǒng)架構(gòu)依賴人工部署，運維人員需要針對不同應(yīng)用對生產(chǎn)環(huán)境進行配置，部署效率較低。當軟件發(fā)生升級變更后，需要經(jīng)過重新部署、修改環(huán)境配置、進行生產(chǎn)環(huán)境測試等步驟，導致軟件升級效率較低。微服務(wù)架構(gòu)采用Docker容器技術(shù)，以鏡像的方式進行部署，應(yīng)用軟件及其依賴環(huán)境被打包為鏡像，運維人員不需要再根據(jù)應(yīng)用調(diào)整環(huán)境配置。各類軟件變更在測試完成后即可通過灰度部署等方式部署到生產(chǎn)環(huán)境，可支持升級過程中業(yè)務(wù)不中斷。微服務(wù)架構(gòu)讓持續(xù)部署更易于實現(xiàn)。

在系統(tǒng)運維階段，傳統(tǒng)架構(gòu)系統(tǒng)中只具備對各個構(gòu)件的監(jiān)控能力以及生命周期管理能力，缺乏其他有效的運維手段。在微服務(wù)架構(gòu)中，可基于容器集群管理工具對系統(tǒng)進行運維，支持容器集群調(diào)度、編排，服務(wù)級的負載均衡，服務(wù)資源自動彈性伸縮，服務(wù)異常自恢復等功能。此外，微服務(wù)架構(gòu)在運行控制中存在熔斷、限流、降級等機制，保證系統(tǒng)中單一服務(wù)出現(xiàn)異常時，系統(tǒng)整體資源不被異常占用，保護核心業(yè)務(wù)的資源使用量。微服務(wù)架構(gòu)使得系統(tǒng)運維能力得到加強，降低了系統(tǒng)運維難度，大大提高了系統(tǒng)的穩(wěn)定性、可靠性及抗壓能力。

3 作戰(zhàn)籌劃微服務(wù)架構(gòu)

3.1 作戰(zhàn)籌劃系統(tǒng)分解

作戰(zhàn)籌劃是對作戰(zhàn)活動的預先設(shè)計和總體籌劃，是指揮員及其指揮機關(guān)對作戰(zhàn)行動進行的運籌和謀劃，是在綜合分析判斷情況的基礎(chǔ)上，對作戰(zhàn)目的、作戰(zhàn)方針、作戰(zhàn)部署、作戰(zhàn)時間、戰(zhàn)法等重大問題進行創(chuàng)造性思維，進而形成作戰(zhàn)基本構(gòu)想的過程。

作戰(zhàn)籌劃任務(wù)參與方主要由指揮員，作戰(zhàn)、情報、通信等各域軍官組成。指揮員領(lǐng)受上級命令后，綜合分析戰(zhàn)場情況，下達作戰(zhàn)命令，各級軍官根據(jù)作戰(zhàn)命令擬定作戰(zhàn)技術(shù)，生成作戰(zhàn)方案后上報指揮員審批，繼續(xù)上報?；谝陨狭鞒?，可對系統(tǒng)進行劃分，設(shè)計以下幾類微服務(wù)：

1）服務(wù)注冊中心：實現(xiàn)微服務(wù)注冊中心；

2）監(jiān)控面板：實現(xiàn)微服務(wù)的可視化監(jiān)控；

3）系統(tǒng)入口：作為系統(tǒng)起始入口；

4）作戰(zhàn)計劃制定管理服務(wù)：負責管理當前任務(wù)的敵方目標、我方目標、集結(jié)點和展開點等；

5）武器及傳感器管理服務(wù)：負責管理當前我方參與兵力的設(shè)備列表和武器列表；

6）作戰(zhàn)力量全集管理服務(wù)：管理我方作戰(zhàn)力量列表和敵方作戰(zhàn)力量列表；

7）作戰(zhàn)力量信息管理服務(wù)：管理位置信息、部隊類型、設(shè)備類型、武器類型、任務(wù)類型、任務(wù)狀態(tài)等；

8）作戰(zhàn)任務(wù)管理服務(wù)：管理任務(wù)列表。

其中1）為微服務(wù)注冊中心，2）為監(jiān)控界面，與業(yè)務(wù)功能不相關(guān)，3）至8）為業(yè)務(wù)相關(guān)服務(wù)。圖2展示了業(yè)務(wù)相關(guān)服務(wù)間的關(guān)系。

圖2 作戰(zhàn)籌劃微服務(wù)關(guān)系圖

3.2 微服務(wù)部署

3.2.1 容器集群框架

Docker可以實現(xiàn)微服務(wù)的容器化封裝和應(yīng)用隔離，容器的啟動和關(guān)閉速度遠遠快于虛擬機［11］，同時不增加額外的資源消耗［12～13］。目前作戰(zhàn)籌劃微服務(wù)系統(tǒng)由三臺服務(wù)器組成，均采用中標麒麟服務(wù)器版5操作系統(tǒng)，基于此搭建了跨節(jié)點的Docker容器集群，容器作為微服務(wù)的運行載體。

容器集群搭建采用了多種技術(shù)，服務(wù)發(fā)現(xiàn)存儲工具etcd實現(xiàn)服務(wù)自注冊，網(wǎng)絡(luò)工具flannel簡化容器集群中的網(wǎng)絡(luò)環(huán)境，實現(xiàn)覆蓋網(wǎng)絡(luò)，鏡像庫registry集中存放鏡像，便于鏡像管理與容器調(diào)度，由可視化工具dashboard提供web界面，便于運維人員監(jiān)控與管理容器集群。容器集群工具kubernetes對容器集群進行調(diào)度，其中集成metrics server實現(xiàn)集群中容器組的自動彈性伸縮，容器集群框架如圖3所示。

圖3 容器集群架構(gòu)圖

3.2.2 容器化封裝

Docker鏡像是容器技術(shù)的核心組件之一，使用Dockerfile文件可以將微服務(wù)及其依賴環(huán)境封裝為鏡像，存入鏡像倉庫中。下面截取了構(gòu)建微服務(wù)鏡像時的Dockerfile文件中的部分內(nèi)容。

其中描述了需要向鏡像中添加的文件，設(shè)置了環(huán)境變量和容器啟動入口等。鏡像構(gòu)建完成后，即可通過Docker push指令推送到鏡像倉庫registry中。

3.3 系統(tǒng)驗證

3.3.1 異常自恢復功能驗證

由于kubernetes副本控制器的存在，集群中每個微服務(wù)的副本數(shù)量會保持為設(shè)定的值，當某一個微服務(wù)容器組發(fā)生異常而停止，副本控制器會自動啟動同一個微服務(wù)容器組，使副本數(shù)量保持與設(shè)定值一致，保障了微服務(wù)的異常恢復功能，如圖4所示。

圖4 異常自恢復功能驗證

微服務(wù)task-service容器組設(shè)置副本數(shù)為2，兩個容器組分別在節(jié)點1和節(jié)點2上運行。斷開節(jié)點1網(wǎng)絡(luò)連接，模擬節(jié)點1異常情況，副本控制器無法監(jiān)測節(jié)點1上的容器組，task-service-flj5m容器組被置灰，隨即在節(jié)點2上啟動相同服務(wù)容器組，保證副本數(shù)量滿足要求，實現(xiàn)系統(tǒng)異常自恢復。

3.3.2 伸縮性驗證

對于設(shè)置了HPA的服務(wù)，當微服務(wù)容器的資源消耗達到閾值，會觸發(fā)自動彈性伸縮，增多微服務(wù)容器副本數(shù)來應(yīng)對突然增加的負載。

在系統(tǒng)驗證過程中，通過yaml文件創(chuàng)建hpa，設(shè)置task-service微服務(wù)部署的最大最小副本數(shù)，以及hpa對應(yīng)的CPU和內(nèi)存指標，然后使用busybox進行負載模擬。如圖5所示，在負載增加后，task-service容器組開始擴展，表明服務(wù)具備彈性伸縮能力。

4 結(jié)語

基于Docker容器的微服務(wù)架構(gòu)在敏捷迭代開發(fā)、資源消耗、系統(tǒng)可靠性等方面具有優(yōu)良的性能，針對傳統(tǒng)作戰(zhàn)應(yīng)用系統(tǒng)面臨的問題，本文對Docker容器技術(shù)和微服務(wù)架構(gòu)開展研究，設(shè)計了作戰(zhàn)籌劃系統(tǒng)微服務(wù)架構(gòu)，并采用Docker容器進行系統(tǒng)部署，該架構(gòu)支持微服務(wù)獨立開發(fā)，提高了開發(fā)效率，同時通過容器集群工具降低系統(tǒng)運維難度，提升系統(tǒng)可靠性。