基于Kubernetes的列控系統(tǒng)測(cè)試容器云平臺(tái)設(shè)計(jì)

馬勤政，徐中偉，梅 萌

(同濟(jì)大學(xué) 電子與信息工程學(xué)院，上海 201804)

0 引 言

隨著國(guó)家鐵路與軌道交通領(lǐng)域的蓬勃發(fā)展，高速鐵路與城市軌道交通中基于通信的列控系統(tǒng)技術(shù)不斷推陳出新，從而使得相應(yīng)的測(cè)試需求也不斷增加。在傳統(tǒng)的列控系統(tǒng)測(cè)試平臺(tái)的軟件開發(fā)過(guò)程中，針對(duì)每一個(gè)不同的測(cè)試任務(wù)，均需要開發(fā)不同的信號(hào)設(shè)備仿真對(duì)象，對(duì)特定的業(yè)務(wù)邏輯與安全通信功能進(jìn)行封裝，再令各仿真對(duì)象獨(dú)立運(yùn)行，組成測(cè)試所需的仿真環(huán)境。仿真對(duì)象軟件的各類功能均集成在一個(gè)應(yīng)用程序之中，使得各個(gè)功能組件之間具有較高的耦合性，難以擴(kuò)展與更新，使得列控系統(tǒng)測(cè)試軟件的開發(fā)與運(yùn)維的時(shí)間與維護(hù)成本難以降低，也難以對(duì)測(cè)試平臺(tái)中軟件的故障問(wèn)題進(jìn)行快速定位與修復(fù)。

通過(guò)建立容器云平臺(tái)，將列控系統(tǒng)測(cè)試軟件依照功能拆分為若干服務(wù)組件，各個(gè)服務(wù)之間僅通過(guò)通信接口進(jìn)行耦合，在集群中的一個(gè)或多個(gè)計(jì)算節(jié)點(diǎn)上作為進(jìn)程獨(dú)立運(yùn)行，組件之間通過(guò)網(wǎng)絡(luò)協(xié)議進(jìn)行通信，通過(guò)各類型服務(wù)之間的組合對(duì)列控系統(tǒng)測(cè)試軟件進(jìn)行開發(fā)，能夠大幅降低列控系統(tǒng)測(cè)試軟件的內(nèi)部耦合度，提升開發(fā)與維護(hù)效率。相較于虛擬機(jī)，容器技術(shù)作為一種輕量級(jí)的虛擬化手段，將服務(wù)與其所需的運(yùn)行環(huán)境打包為鏡像文件，便于部署與修改，具有更高的靈活度，同時(shí)對(duì)I/O、CPU與內(nèi)存等資源的需求均較低。近年來(lái)國(guó)內(nèi)外對(duì)于容器及其編排技術(shù)均有較多研究成果。為提升研發(fā)效率、降低運(yùn)維與操作成本，該文提出了基于Kubernetes容器編排系統(tǒng)的列控系統(tǒng)測(cè)試容器云平臺(tái)的設(shè)計(jì)。

1 Docker與Kubernetes技術(shù)概述

Docker是一種提供輕量級(jí)虛擬化解決方案的開源的引擎，建立在Linux操作系統(tǒng)的Cgroup、Namespace以及rootfs等容器技術(shù)之上。Docker能夠?qū)⒎?wù)應(yīng)用程序及其所需的文件系統(tǒng)按層級(jí)打包為一個(gè)容器鏡像，容器鏡像不依賴操作系統(tǒng)類型，僅要求操作系統(tǒng)具有相同的內(nèi)核，這使得Docker鏡像能夠在任何支持Docker的設(shè)備中進(jìn)行遷移。同時(shí)，Docker鏡像相對(duì)于其他的虛擬化方案具有更快的創(chuàng)建、啟動(dòng)與停止速度，同時(shí)占用更少的操作系統(tǒng)資源，從而降低了應(yīng)用服務(wù)的開發(fā)、部署與遷移成本[1]。

Kubernetes是一種用于在多機(jī)器云環(huán)境，即容器云集群中自動(dòng)管理、部署與擴(kuò)展容器應(yīng)用的開源的容器編排系統(tǒng)。Kubernetes運(yùn)行在Docker容器之上，由Google公司的Borg系統(tǒng)發(fā)展而來(lái)[2]，能夠按照用戶設(shè)定的規(guī)則自動(dòng)化地對(duì)集群進(jìn)行管理，為集群的運(yùn)行提供了穩(wěn)定性與效率的保障。

2 平臺(tái)設(shè)計(jì)

2.1 系統(tǒng)架構(gòu)設(shè)計(jì)

列控系統(tǒng)測(cè)試平臺(tái)使用計(jì)算機(jī)軟件與硬件資源對(duì)列控系統(tǒng)中的一個(gè)或多個(gè)通信實(shí)體進(jìn)行模擬，各個(gè)模擬對(duì)象組成了完整的測(cè)試環(huán)境。測(cè)試環(huán)境能夠與被測(cè)對(duì)象進(jìn)行信息交互，測(cè)試人員通過(guò)在測(cè)試環(huán)境中下達(dá)命令以模擬測(cè)試大綱要求的運(yùn)行環(huán)境，并觀察被測(cè)對(duì)象的行為是否與預(yù)期一致。各個(gè)仿真對(duì)象在業(yè)務(wù)邏輯上具有較大差異，但在本質(zhì)上均能夠被抽象為應(yīng)用層、安全層與通信層三個(gè)邏輯模塊的組合。其中應(yīng)用層負(fù)責(zé)依照測(cè)試大綱生成需要發(fā)送至被測(cè)對(duì)象的原始消息或解析接收到的被測(cè)對(duì)象發(fā)送的消息，安全層負(fù)責(zé)在待發(fā)送的原始消息中加入安全相關(guān)的數(shù)據(jù)或驗(yàn)證收到消息的安全性，而通信層負(fù)責(zé)測(cè)試平臺(tái)與被測(cè)對(duì)象之間消息包的發(fā)送與接收。

鐵路安全通信系統(tǒng)的結(jié)構(gòu)抽象如圖1所示[3]。

圖1 鐵路安全通信系統(tǒng)的結(jié)構(gòu)抽象

在鐵路通信信號(hào)領(lǐng)域，兩個(gè)通信實(shí)體之間的消息傳輸都遵循一定的層級(jí)式的通信協(xié)議。原始消息通過(guò)逐層封裝，形成最終的消息報(bào)文。以RSSP-I協(xié)議與RSSP-II協(xié)議為例，兩類通信協(xié)議中的每一層都是對(duì)某種功能需求的抽象，對(duì)下層的輸出進(jìn)行進(jìn)一步封裝，供上層使用，且僅對(duì)相鄰的上下層負(fù)責(zé)。依照這種低耦合的關(guān)系，能夠?qū)⒘锌叵到y(tǒng)測(cè)試容器云平臺(tái)的計(jì)算機(jī)集群劃分為應(yīng)用服務(wù)子集群、安全服務(wù)子集群以及通信服務(wù)子集群三個(gè)邏輯子集群?；谏鲜鲈O(shè)計(jì)，在列控系統(tǒng)測(cè)試軟件的開發(fā)過(guò)程中，可以將待開發(fā)的仿真對(duì)象按功能拆分為不同的應(yīng)用層、通信層以及安全層服務(wù)，將每個(gè)服務(wù)打包為若干Docker容器鏡像，并部署在同一個(gè)Kubernetes Pod中，同時(shí)相同類的Kubernetes Pod均應(yīng)部署在列控系統(tǒng)測(cè)試容器云平臺(tái)的對(duì)應(yīng)類型的邏輯子集群之中。

在不同的列控系統(tǒng)測(cè)試任務(wù)中，應(yīng)用層服務(wù)往往會(huì)依據(jù)任務(wù)的特性進(jìn)行重新設(shè)計(jì)，安全層服務(wù)則依賴于少量穩(wěn)定的協(xié)議，具有較高的可復(fù)用能力。每一個(gè)應(yīng)用層通常會(huì)需要一個(gè)或多個(gè)通信層服務(wù)的支持。通信層服務(wù)一般可進(jìn)一步分為軟件協(xié)議棧與硬件設(shè)備兩部分。這三類服務(wù)能夠通過(guò)Kubernetes集群提供的內(nèi)部的網(wǎng)絡(luò)通信接口相互進(jìn)行信息交互，從而實(shí)現(xiàn)對(duì)測(cè)試環(huán)境所需的通信實(shí)體的仿真。在測(cè)試任務(wù)執(zhí)行過(guò)程中，應(yīng)用層服務(wù)與通信層服務(wù)均需要同列控系統(tǒng)測(cè)試容器云平臺(tái)外部進(jìn)行通信。依據(jù)被測(cè)對(duì)象類型的不同，通信層服務(wù)與被測(cè)對(duì)象進(jìn)行信息交互需要依賴不同的硬件通信設(shè)備，因此通信層邏輯子集群需要將通信層服務(wù)調(diào)度到具備特定網(wǎng)絡(luò)接口資源的計(jì)算機(jī)節(jié)點(diǎn)上，并且允許服務(wù)實(shí)例直接使用宿主計(jì)算機(jī)節(jié)點(diǎn)上的網(wǎng)絡(luò)接口。為了向測(cè)試平臺(tái)下發(fā)命令或觀測(cè)列控系統(tǒng)測(cè)試的過(guò)程與結(jié)果，測(cè)試人員需要在集群以外編寫可視化界面程序，通過(guò)Kubernetes提供的外部訪問(wèn)機(jī)制訪問(wèn)應(yīng)用層服務(wù)。

在列控系統(tǒng)測(cè)試過(guò)程中，除業(yè)務(wù)邏輯錯(cuò)誤導(dǎo)致的通信信號(hào)數(shù)據(jù)包錯(cuò)誤外，還可能發(fā)生潛在的各類故障，從而導(dǎo)致平臺(tái)運(yùn)行異常。為應(yīng)對(duì)此類故障，列控系統(tǒng)測(cè)試云平臺(tái)還需具有監(jiān)控服務(wù)子集群，負(fù)責(zé)實(shí)時(shí)監(jiān)控平臺(tái)的運(yùn)行狀態(tài)，通過(guò)訪問(wèn)Kubernetes的控制平面以及集群中每個(gè)工作節(jié)點(diǎn)上的Kubelet代理程序提供的應(yīng)用程序接口(API)，實(shí)時(shí)獲取每個(gè)工作節(jié)點(diǎn)上的容器以及計(jì)算、儲(chǔ)存與網(wǎng)絡(luò)資源的健康狀況，對(duì)監(jiān)控信息記錄進(jìn)行保存，通過(guò)對(duì)外提供API的方式為平臺(tái)運(yùn)維人員提供服務(wù)。列控系統(tǒng)測(cè)試容器云平臺(tái)的架構(gòu)如圖2所示。

圖2 列控系統(tǒng)測(cè)試容器云平臺(tái)的架構(gòu)

2.2 平臺(tái)功能設(shè)計(jì)

作為列控系統(tǒng)功能測(cè)試的基礎(chǔ)設(shè)施，列控系統(tǒng)測(cè)試容器云平臺(tái)一方面需要能夠簡(jiǎn)化列控系統(tǒng)測(cè)試軟件的開發(fā)與部署流程，提高研發(fā)效率，另一方面應(yīng)能夠提升測(cè)試流程的自動(dòng)化程度與穩(wěn)定性。同時(shí)，列控系統(tǒng)是一類安全苛求系統(tǒng)，為了滿足平臺(tái)中的仿真對(duì)象與真實(shí)信號(hào)設(shè)備的一致性，平臺(tái)需要保證各類服務(wù)在部署和運(yùn)行過(guò)程中的可靠性與穩(wěn)定性?；谏鲜鰳I(yè)務(wù)需求，對(duì)列控系統(tǒng)測(cè)試云平臺(tái)的功能做出如下設(shè)計(jì)。

(a)服務(wù)的部署與發(fā)現(xiàn)。

列控系統(tǒng)測(cè)試容器云平臺(tái)應(yīng)對(duì)Kubernetes提供的API進(jìn)行再次封裝，為列控系統(tǒng)測(cè)試軟件的開發(fā)者提供一套簡(jiǎn)明完備的命令行界面(CLI)，通過(guò)CLI命令中的參數(shù)支持各層級(jí)的應(yīng)用在其中的部署。開發(fā)者能夠通過(guò)列控系統(tǒng)測(cè)試容器云平臺(tái)的CLI將應(yīng)用程序的容器鏡像部署在集群當(dāng)中，或是對(duì)已經(jīng)部署在集群上的服務(wù)進(jìn)行下線操作。依據(jù)抽象分離的原則，云平臺(tái)應(yīng)成為一個(gè)黑盒(black box)，能夠在平臺(tái)內(nèi)部自行完成應(yīng)用的部署或下線，無(wú)需開發(fā)者了解部署與下線過(guò)程的細(xì)節(jié)，從而降低開發(fā)者的成本。

在服務(wù)的部署過(guò)程中，對(duì)于無(wú)需與外部應(yīng)用或設(shè)備進(jìn)行通信的應(yīng)用(通常為安全層服務(wù))，列控系統(tǒng)測(cè)試容器云平臺(tái)能夠通過(guò)Kubernetes的DNS發(fā)現(xiàn)服務(wù)使之能夠與其集群內(nèi)部的上下層服務(wù)進(jìn)行通信[4]；對(duì)于需要與外部設(shè)備或應(yīng)用通信的應(yīng)用(應(yīng)用層、通信層或其他負(fù)責(zé)監(jiān)控與維護(hù)穩(wěn)定性的服務(wù))，云平臺(tái)允許開發(fā)者在CLI中指定服務(wù)所需要使用網(wǎng)絡(luò)地址，使用Kubernetes提供的Service或Ingress機(jī)制將服務(wù)暴露在所指定的網(wǎng)絡(luò)地址之上[5]。

在對(duì)鐵路信號(hào)設(shè)備的測(cè)試中，通信過(guò)程往往需要建立在不同的物理信道上，如運(yùn)行在以太網(wǎng)上的TCP/UDP通信、串口通信、控制器局域網(wǎng)絡(luò)(CAN)通信或使用特殊的通信網(wǎng)卡來(lái)模擬特定的網(wǎng)絡(luò)環(huán)境，如GSM-R、LTE-R等[6]。不同的物理信道要求需要列控系統(tǒng)測(cè)試容器云平臺(tái)中具有具備各類通信硬件條件的計(jì)算機(jī)節(jié)點(diǎn)，因此Kubernetes集群在建立時(shí)需要為具備不同硬件設(shè)備的節(jié)點(diǎn)做出特定的標(biāo)識(shí)(label)。在通過(guò)CLI部署通信層服務(wù)時(shí)，需要指定所需要部署在其上的節(jié)點(diǎn)應(yīng)具有的硬件資源種類，Kubernetes的節(jié)點(diǎn)選擇控制器便能夠按照開發(fā)者要求將通信層服務(wù)調(diào)度到最佳的符合要求的節(jié)點(diǎn)上。

(b)測(cè)試自動(dòng)化。

在列控系統(tǒng)的測(cè)試任務(wù)中，通常需要通過(guò)對(duì)多種服務(wù)的若干實(shí)例進(jìn)行組合實(shí)現(xiàn)對(duì)多種仿真對(duì)象的模擬，從而能夠依照測(cè)試大綱中的測(cè)試用例對(duì)被測(cè)對(duì)象進(jìn)行測(cè)試。以CTCS-3級(jí)的RBC測(cè)試為例(見圖3)，為了對(duì)RBC對(duì)象進(jìn)行測(cè)試，需要實(shí)現(xiàn)CBI、TSRS、相鄰RBC以及車載ATP設(shè)備的仿真對(duì)象[7]。這四類對(duì)象的應(yīng)用層各不相同，安全層均依賴RSSP_II通信協(xié)議，而在通信功能層面又存在通信協(xié)議與通信物理接口的差異。

圖3 CTCS-3級(jí)列控系統(tǒng)RBC測(cè)試平臺(tái)架構(gòu)

在列控系統(tǒng)測(cè)試容器云平臺(tái)中，通過(guò)對(duì)各層級(jí)服務(wù)的組合，能夠快速實(shí)現(xiàn)仿真對(duì)象的實(shí)現(xiàn)，提升了代碼的利用率，從而提升了測(cè)試工作的效率。

為了對(duì)真實(shí)運(yùn)行環(huán)境中可能出現(xiàn)的變化進(jìn)行仿真，需要不同的仿真對(duì)象進(jìn)行有序的協(xié)同操作。測(cè)試用例是對(duì)多種仿真對(duì)象有序行為以及被測(cè)對(duì)象的預(yù)期行為的描述。每個(gè)測(cè)試用例的流程均可表達(dá)為一個(gè)有向無(wú)環(huán)圖(DAG)，這個(gè)有向無(wú)環(huán)圖是全連通的，具有樹的性質(zhì)，從根節(jié)點(diǎn)出發(fā)能夠訪問(wèn)到圖的全部節(jié)點(diǎn)。描述各個(gè)測(cè)試用例的樹能夠構(gòu)成一個(gè)森林，具有時(shí)序關(guān)系的樹之間具有父子關(guān)系。測(cè)試任務(wù)從樹林的根處開始，并行執(zhí)行不具備時(shí)序關(guān)系的測(cè)試用例，在執(zhí)行每個(gè)測(cè)試用例時(shí)，對(duì)描述任務(wù)的圖進(jìn)行深度優(yōu)先搜索，當(dāng)圖的每條邊均被訪問(wèn)時(shí)，測(cè)試用例即執(zhí)行完畢。全部的測(cè)試用例執(zhí)行完畢后，測(cè)試過(guò)程即完成執(zhí)行。在傳統(tǒng)的測(cè)試過(guò)程中，由于各仿真對(duì)象均為集中式的獨(dú)立應(yīng)用程序，難以通過(guò)計(jì)算機(jī)指令協(xié)同調(diào)度各應(yīng)用程序。因此測(cè)試人員需要依照測(cè)試用例的指示，手動(dòng)對(duì)仿真對(duì)象下達(dá)相應(yīng)的命令。這一過(guò)程繁瑣且容易出錯(cuò)。為了提高測(cè)試的自動(dòng)化程度，列控系統(tǒng)測(cè)試容器云平臺(tái)需要提供一種用于描述測(cè)試案例中有向無(wú)環(huán)圖的領(lǐng)域?qū)Ｓ谜Z(yǔ)言(DSL)[8]。這一領(lǐng)域?qū)Ｓ谜Z(yǔ)言能夠?qū)y(cè)試案例描述為計(jì)算機(jī)可識(shí)別的過(guò)程，同時(shí)能夠?qū)Ω鱾€(gè)測(cè)試案例進(jìn)行優(yōu)化，依照測(cè)試的相關(guān)需求對(duì)它們的執(zhí)行順序進(jìn)行調(diào)整，使得整個(gè)測(cè)試的速度與效率得到提高[9]。通過(guò)計(jì)算機(jī)將從測(cè)試大綱轉(zhuǎn)寫而來(lái)的DSL腳本與各仿真對(duì)象的應(yīng)用層服務(wù)分別作為容器部署在同一個(gè)Kubernetes Pod中，共享相同的Linux Namespace，腳本與各服務(wù)即可在云端協(xié)同運(yùn)作[10]。執(zhí)行該腳本，腳本即可依照測(cè)試大綱的要求通過(guò)進(jìn)程間通信(IPC)向各應(yīng)用層服務(wù)順序下達(dá)命令并接收反饋，從而實(shí)現(xiàn)對(duì)各仿真對(duì)象的協(xié)調(diào)。

容器云平臺(tái)的自動(dòng)化測(cè)試流程如圖4所示。

圖4 容器云平臺(tái)的自動(dòng)化測(cè)試流程

隨著列控系統(tǒng)測(cè)試場(chǎng)景的范圍不斷擴(kuò)大，在一些測(cè)試任務(wù)中，需要通過(guò)較多的測(cè)試案例來(lái)對(duì)列控系統(tǒng)的真實(shí)運(yùn)行場(chǎng)景進(jìn)行仿真，在一些測(cè)試場(chǎng)景中還需要對(duì)一些測(cè)試數(shù)據(jù)進(jìn)行改變以充分模擬可能的運(yùn)行狀況，僅通過(guò)真實(shí)的測(cè)試數(shù)據(jù)與測(cè)試場(chǎng)景進(jìn)行測(cè)試已不能滿足測(cè)試的需要。因此，列控系統(tǒng)測(cè)試容器云平臺(tái)中還需要具備通用測(cè)試案例與測(cè)試數(shù)據(jù)的自動(dòng)生成的功能，能夠通過(guò)對(duì)測(cè)試場(chǎng)景的建模，使用啟發(fā)式或半啟發(fā)式的算法根據(jù)數(shù)據(jù)的不同特征生成所需的測(cè)試案例[11]。同時(shí)，近年來(lái)機(jī)器學(xué)習(xí)技術(shù)在自動(dòng)化測(cè)試領(lǐng)域中的應(yīng)用與研究不斷深入，能夠?yàn)闇y(cè)試提供更充分的、覆蓋范圍更加完備的數(shù)據(jù)[12]。列控系統(tǒng)測(cè)試容器云平臺(tái)也應(yīng)將人工智能技術(shù)引入列控系統(tǒng)的測(cè)試過(guò)程中，進(jìn)一步提升列控系統(tǒng)測(cè)試的效率與自動(dòng)化程度。

(c)服務(wù)的可靠性保障。

在一個(gè)完整的測(cè)試任務(wù)中需要測(cè)試平臺(tái)中的各個(gè)服務(wù)之間協(xié)同配合。在列控系統(tǒng)測(cè)試過(guò)程中，通信層為仿真對(duì)象提供與外部被測(cè)對(duì)象交互信息的接口，通常是無(wú)狀態(tài)的。安全層服務(wù)按照其中安全協(xié)議中是否規(guī)定了上下文關(guān)系，可以是有狀態(tài)或無(wú)狀態(tài)的。而應(yīng)用層服務(wù)通常用來(lái)執(zhí)行仿真對(duì)象的業(yè)務(wù)邏輯，是有狀態(tài)服務(wù)。通信層服務(wù)作為整個(gè)測(cè)試平臺(tái)最基礎(chǔ)的服務(wù)，同一類服務(wù)在同時(shí)可能需要支持多個(gè)測(cè)試任務(wù)同時(shí)進(jìn)行。在多個(gè)任務(wù)同時(shí)執(zhí)行的場(chǎng)景下，為了滿足測(cè)試任務(wù)的實(shí)時(shí)性以及可靠性要求，就需要對(duì)熱點(diǎn)通信層服務(wù)進(jìn)行動(dòng)態(tài)擴(kuò)容，在集群中部署多個(gè)服務(wù)實(shí)例。而在少量任務(wù)同時(shí)執(zhí)行的場(chǎng)景下，過(guò)多的通信層服務(wù)實(shí)例會(huì)占用集群較多的計(jì)算資源，此時(shí)需要平臺(tái)自動(dòng)對(duì)服務(wù)進(jìn)行縮容。借助通信層服務(wù)的無(wú)狀態(tài)特性與Kubernetes提供的彈性伸縮機(jī)制[13]，平臺(tái)運(yùn)維人員既能夠在發(fā)現(xiàn)通信層服務(wù)縮擴(kuò)容需求時(shí)，手動(dòng)調(diào)整服務(wù)實(shí)例個(gè)數(shù)，也能夠在集群層面指定自動(dòng)動(dòng)態(tài)伸縮策略，委托Kubernetes的控制平面代為執(zhí)行。

為了維護(hù)列車信號(hào)系統(tǒng)的可靠性，現(xiàn)行的絕大多數(shù)鐵路信號(hào)協(xié)議均應(yīng)用了冗余技術(shù)，在安全層或通信層上使用多機(jī)冗余，同時(shí)維護(hù)一個(gè)主系通信信道與多個(gè)備系通信信道的正常運(yùn)行，一旦發(fā)生故障，可以立即進(jìn)行主備系切換，保證鐵路信號(hào)設(shè)備之間的通信穩(wěn)定。而在列控系統(tǒng)測(cè)試容器云平臺(tái)中，應(yīng)用層服務(wù)與部分安全層服務(wù)作為有狀態(tài)服務(wù)，一旦出現(xiàn)故障，難以僅通過(guò)替換服務(wù)的方式進(jìn)行恢復(fù)。同時(shí)，云平臺(tái)中還可能存在分布式入侵、系統(tǒng)配置錯(cuò)誤與網(wǎng)絡(luò)故障等可能性[14]，因此，列控系統(tǒng)測(cè)試容器云平臺(tái)需要具備一定的故障恢復(fù)能力。列控系統(tǒng)測(cè)試容器云平臺(tái)能夠通過(guò)Kubernetes的持久化儲(chǔ)存機(jī)制，將服務(wù)的狀態(tài)實(shí)時(shí)保存在節(jié)點(diǎn)當(dāng)中，當(dāng)某一服務(wù)發(fā)生故障需要進(jìn)行恢復(fù)時(shí)，平臺(tái)能夠自動(dòng)部署新的服務(wù)實(shí)例，這一實(shí)例能夠讀取之前實(shí)例故障前的狀態(tài)，并將其作為依據(jù)對(duì)自身狀態(tài)進(jìn)行設(shè)置，從而使得云平臺(tái)中的應(yīng)用實(shí)例具有了一定的冗余備份能力。進(jìn)一步提升測(cè)試平臺(tái)的可靠性。

(d)平臺(tái)故障監(jiān)控與告警。

當(dāng)前國(guó)內(nèi)外已經(jīng)提出了多種成熟的云平臺(tái)監(jiān)控方案[15]，通過(guò)與Kubernetes的API Server交互獲取平臺(tái)中各節(jié)點(diǎn)的性能指標(biāo)，并通過(guò)各節(jié)點(diǎn)上的Kubelet提供的監(jiān)控接口獲取節(jié)點(diǎn)上的容器監(jiān)控信息。監(jiān)控平臺(tái)獲取到的信息均會(huì)被儲(chǔ)存在數(shù)據(jù)庫(kù)中，平臺(tái)提供一個(gè)對(duì)外的圖形化界面，用戶可通過(guò)圖形化界面操作監(jiān)控平臺(tái)，生成并查看所需的監(jiān)控報(bào)告。

對(duì)于列控系統(tǒng)測(cè)試容器云平臺(tái)，除計(jì)算資源與儲(chǔ)存資源容量過(guò)低可能發(fā)生的故障外，還包括通信層服務(wù)所依賴的通信硬件資源的故障、安全層或應(yīng)用層服務(wù)運(yùn)行過(guò)程中未預(yù)期到的潛在故障等。故障監(jiān)控平臺(tái)在監(jiān)測(cè)到常規(guī)故障發(fā)生的可能性(如計(jì)算、儲(chǔ)存資源即將耗盡或某個(gè)服務(wù)的容器長(zhǎng)期異常無(wú)法自動(dòng)恢復(fù)等)后，會(huì)在平臺(tái)提供的可視化界面上進(jìn)行告警，等待平臺(tái)運(yùn)維人員檢查處理。當(dāng)故障發(fā)生后，監(jiān)控平臺(tái)會(huì)暫停故障涉及到的測(cè)試任務(wù)的運(yùn)行，并且通過(guò)告警機(jī)制告知相關(guān)運(yùn)維人員故障的相關(guān)信息，包括故障點(diǎn)的位置、故障現(xiàn)象以及可能的解決方案等。運(yùn)維人員在結(jié)合監(jiān)控平臺(tái)的日志信息與現(xiàn)場(chǎng)情況對(duì)故障進(jìn)行排查與修復(fù)后，能夠根據(jù)故障的嚴(yán)重程度命令尚未完成的受影響的相關(guān)任務(wù)繼續(xù)或重新進(jìn)行。

3 容器云平臺(tái)下的研發(fā)與作業(yè)流程

3.1 研發(fā)與部署流程

通過(guò)對(duì)列控系統(tǒng)測(cè)試軟件的各部分進(jìn)行解耦合，將列控系統(tǒng)測(cè)試的各個(gè)功能拆封為不同層次的服務(wù)后，對(duì)邏輯復(fù)雜的安全層與涉及硬件層面的通信層服務(wù)的開發(fā)可以由較為專業(yè)的開發(fā)者完成，這些服務(wù)一旦開發(fā)部署完成，就能夠保持穩(wěn)定，為應(yīng)用層服務(wù)提供支持。開發(fā)者在絕大多數(shù)只需要進(jìn)行不同測(cè)試任務(wù)中所需的仿真對(duì)象(應(yīng)用層與可視化界面)的開發(fā)，從而簡(jiǎn)化了列控系統(tǒng)測(cè)試軟件的研發(fā)與部署流程。

在進(jìn)行通信層服務(wù)的開發(fā)時(shí)，開發(fā)者首先需要查詢集群中是否具有具備服務(wù)所需的硬件條件，且相關(guān)的計(jì)算、存儲(chǔ)與網(wǎng)絡(luò)資源滿足條件的工作節(jié)點(diǎn)。若當(dāng)前集群中尚不具備上述節(jié)點(diǎn)，那么需要向集群中添加新的滿足條件的工作節(jié)點(diǎn)，或者在現(xiàn)有的工作節(jié)點(diǎn)機(jī)器上加裝所需的硬件。服務(wù)應(yīng)用開發(fā)完成后，開發(fā)者需將服務(wù)打包為Docker鏡像，并提供Kubernetes部署服務(wù)所需的模板文件。模板文件中應(yīng)該允許服務(wù)使用宿主工作節(jié)點(diǎn)的網(wǎng)絡(luò)資源，同時(shí)允許對(duì)服務(wù)與其上層服務(wù)的內(nèi)部通信接口以及服務(wù)與被測(cè)對(duì)象之間的外部通信接口進(jìn)行配置。

在安全層服務(wù)的開發(fā)過(guò)程中需要針對(duì)不同的鐵路信號(hào)安全協(xié)議進(jìn)行實(shí)現(xiàn)。由于安全層服務(wù)的有狀態(tài)特性，安全層服務(wù)除安全相關(guān)業(yè)務(wù)本身的Docker鏡像外，還需一個(gè)用于實(shí)時(shí)記錄服務(wù)運(yùn)行過(guò)程中各個(gè)狀態(tài)的Docker鏡像。這兩個(gè)鏡像容器將運(yùn)行在同一個(gè)Kubernetes Pod中。在安全層服務(wù)部署所需的模板文件中，除了可配置服務(wù)與其上下層服務(wù)的內(nèi)部通信接口外，還需要對(duì)持久化儲(chǔ)存的聲明，要求Kubernetes集群提供一定大小的持久化儲(chǔ)存空間，這一空間能夠被該Kubernetes Pod中的全部容器共享，從而使安全層服務(wù)主容器能夠?qū)⑾嚓P(guān)狀態(tài)信息共享至用于記錄的容器。

應(yīng)用層服務(wù)是對(duì)通信對(duì)象的仿真。作為測(cè)試任務(wù)中的邏輯實(shí)體，各個(gè)應(yīng)用層服務(wù)應(yīng)具備相互通信的接口、與外部可視化界面進(jìn)行通信的接口、與日志服務(wù)通信的接口以及與自動(dòng)化測(cè)試腳本之間的通信接口。在一次測(cè)試任務(wù)中，往往需要同時(shí)對(duì)多個(gè)通信對(duì)象進(jìn)行仿真，因此對(duì)應(yīng)用層服務(wù)的部署通常是對(duì)應(yīng)用層服務(wù)組的部署。這個(gè)服務(wù)組中除了包含各個(gè)應(yīng)用層服務(wù)的Docker鏡像外，還需要一個(gè)具備日志記錄功能的Docker鏡像。為此，應(yīng)用層服務(wù)組的部署也要求Kubernetes集群提供一定大小的用于存放日志的持久化儲(chǔ)存空間。此外，測(cè)試任務(wù)中如果存在進(jìn)行自動(dòng)化測(cè)試的需求，開發(fā)人員還需要編寫相應(yīng)的DSL腳本，并將其打包為一個(gè)Docker鏡像加入應(yīng)用層服務(wù)組之中。日志鏡像與自動(dòng)化測(cè)試鏡像也需要具備與外部可視化程序進(jìn)行通信的接口。上述鏡像均應(yīng)作為容器部署在同一個(gè)Kubernetes Pod中。在部署應(yīng)用層服務(wù)所需的模板文件中，需要能夠?qū)Ψ?wù)與其下層服務(wù)的內(nèi)部通信接口、服務(wù)與可視化界面通信的外部接口以及服務(wù)組中應(yīng)用之間相互通信的接口進(jìn)行配置。同時(shí)，對(duì)于每一個(gè)應(yīng)用層服務(wù)，文件中均應(yīng)能夠制定該服務(wù)所需的安全層與通信層服務(wù)。列控系統(tǒng)測(cè)試容器云平臺(tái)整體的開發(fā)與部署流程如圖5所示。

圖5 列控系統(tǒng)測(cè)試容器云平臺(tái)的研發(fā)部署流程

3.2 列控系統(tǒng)測(cè)試流程

在列控系統(tǒng)信號(hào)設(shè)備的測(cè)試任務(wù)中，測(cè)試人員首先需要依照上述部署流程，選擇相應(yīng)所需的鏡像對(duì)各層服務(wù)進(jìn)行部署。通過(guò)Kubernetes的就緒探針(readiness probe)機(jī)制能夠觀察各服務(wù)的就緒情況。在各層服務(wù)啟動(dòng)完畢后，測(cè)試人員即可在集群外部啟動(dòng)可視化界面，與各應(yīng)用層服務(wù)、日志服務(wù)與自動(dòng)化測(cè)試服務(wù)進(jìn)行連接。若測(cè)試任務(wù)具備自動(dòng)化條件，測(cè)試人員可通過(guò)圖形化界面執(zhí)行自動(dòng)化腳本；反之，測(cè)試人員需通過(guò)手動(dòng)操作圖形化界面依照測(cè)試大綱完成測(cè)試。在測(cè)試完成后，測(cè)試人員能夠通過(guò)圖形化界面獲取測(cè)試結(jié)果的日志，并根據(jù)日志進(jìn)行分析，完成測(cè)試任務(wù)。列控系統(tǒng)測(cè)試容器云平臺(tái)上的測(cè)試任務(wù)流程如圖6所示。

圖6 列控系統(tǒng)測(cè)試容器云平臺(tái)上的測(cè)試任務(wù)流程

4 平臺(tái)性能分析

列控系統(tǒng)測(cè)試容器云平臺(tái)將列控系統(tǒng)測(cè)試軟件的功能拆分為若干微服務(wù)，結(jié)合了Docker容器技術(shù)以及Kubernetes的容器編排能力，相比于傳統(tǒng)的列控系統(tǒng)計(jì)算機(jī)測(cè)試方案，在開發(fā)效率、可靠性、自動(dòng)化程度等方面均有較大幅度提升。列控系統(tǒng)測(cè)試容器云平臺(tái)與傳統(tǒng)方案的性能對(duì)比如表1所示。

表1 列控系統(tǒng)測(cè)試容器云平臺(tái)與傳統(tǒng)測(cè)試方案的性能指標(biāo)對(duì)比

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

該文提出了一種基于Docker與Kubernetes集群的列控系統(tǒng)測(cè)試云平臺(tái)，將列控系統(tǒng)測(cè)試軟件的各類功能作為服務(wù)打包為Docker鏡像，并在Kubernetes集群中部署，通過(guò)DSL編寫的自動(dòng)化測(cè)試腳本與外部的可視化界面進(jìn)行測(cè)試的方案。這一方案降低了列控系統(tǒng)測(cè)試中各個(gè)組件之間的耦合程度、提升了開發(fā)效率與自動(dòng)化程度，同時(shí)也能夠更好地支持多個(gè)測(cè)試任務(wù)的同時(shí)進(jìn)行，推動(dòng)列控系統(tǒng)測(cè)試工作向著規(guī)?；c完全自動(dòng)化的方向發(fā)展。