方暉 蔣堅(jiān)迪 姜富強(qiáng)

（1.寧波市軌道交通集團(tuán)有限公司 浙江省寧波市 315040 2.浙江浙大網(wǎng)新眾合軌道交通工程有限公司 浙江省杭州市 310051）

近年來(lái)，基于虛擬化的云計(jì)算技術(shù)風(fēng)起云涌，大有橫掃一切傳統(tǒng)后臺(tái)系統(tǒng)的態(tài)勢(shì)。最早，公有云一枝獨(dú)秀，公有云提供商希望后臺(tái)系統(tǒng)都運(yùn)行在公有云。但是實(shí)際上，出于安全、可控等因素，大量企業(yè)新建的應(yīng)用系統(tǒng)部署的是私有云，或者混合云。然而，當(dāng)基于虛擬化的云技術(shù)被企業(yè)逐漸接受后，容器和容器云技術(shù)又席卷而來(lái)。容器類似虛擬化技術(shù)，也實(shí)現(xiàn)了資源隔離，但更加輕量級(jí)，結(jié)合K8S 等編排技術(shù)，容器云能輕松實(shí)現(xiàn)秒級(jí)部署和伸縮。但是，容器本身無(wú)法替代虛擬機(jī)，公有云、私有云、混合云、容器云等技術(shù)，必然長(zhǎng)期共存。技術(shù)需要以正確的方式服務(wù)社會(huì)，在設(shè)計(jì)地鐵MLC系統(tǒng)時(shí)，必須考慮各種云化技術(shù)的技術(shù)特點(diǎn)，根據(jù)項(xiàng)目場(chǎng)景進(jìn)行合理規(guī)劃。

1 地鐵MLC系統(tǒng)

對(duì)整個(gè)地鐵MLC系統(tǒng)進(jìn)行分析，可以得知地鐵MLC系統(tǒng)即可以完成運(yùn)營(yíng)多條線路的共同管理，是線路中心，同時(shí)更是線路的組成核心部分。在MLC系統(tǒng)中，該運(yùn)營(yíng)主體所管轄的線路通過(guò)同一個(gè)MLC 與ACC 接口，確保能夠真正實(shí)現(xiàn)軌道交通網(wǎng)絡(luò)運(yùn)營(yíng)化的需求以及運(yùn)輸服務(wù)。在目前的MLC系統(tǒng)中，以北京市為例，北京市已然構(gòu)成MLC系統(tǒng)，包含兩個(gè)在建MLC系統(tǒng)，一個(gè)運(yùn)輸MLC系統(tǒng)。這三個(gè)MLC 運(yùn)輸系統(tǒng)隸屬兩家運(yùn)營(yíng)公司，為地鐵的運(yùn)行提供良好的建議以及改良措施。

MLC系統(tǒng)在建立過(guò)程中，蘊(yùn)含豐富的邏輯架構(gòu)，其包含備份子系統(tǒng)、報(bào)表子系統(tǒng)、歷史數(shù)據(jù)子系統(tǒng)、系統(tǒng)管理子系統(tǒng)、融合數(shù)據(jù)庫(kù)。隨后，在交易數(shù)據(jù)處理子系統(tǒng)中，對(duì)設(shè)備運(yùn)行狀態(tài)進(jìn)行監(jiān)控，返回至業(yè)務(wù)處理子系統(tǒng)，以便完成整個(gè)數(shù)據(jù)的傳輸。在MLC 的系統(tǒng)軟件架構(gòu)中，結(jié)合虛擬機(jī)，其可以完成系統(tǒng)功能，包含但不限于訪問(wèn)控制系統(tǒng)、監(jiān)督數(shù)據(jù)備份、網(wǎng)絡(luò)管理、時(shí)鐘同步、防病毒管理、參數(shù)管理。而在業(yè)務(wù)應(yīng)用層中，其包含了報(bào)表應(yīng)用、數(shù)據(jù)運(yùn)營(yíng)、管理監(jiān)控。而在數(shù)據(jù)儲(chǔ)存層中，其包含了生產(chǎn)數(shù)據(jù)庫(kù)以及歷史數(shù)據(jù)庫(kù)。在業(yè)務(wù)處理層中，其包含了業(yè)務(wù)處理、交易處理以及設(shè)備狀態(tài)、客流監(jiān)視。而在外部通訊層中，其包含了SC 接口以及ACC 接口。

MLC系統(tǒng)包含了全方面的運(yùn)營(yíng)體系，其不僅可以對(duì)地鐵線路進(jìn)行統(tǒng)一監(jiān)控，同時(shí)更可以就以往的監(jiān)控模式完成點(diǎn)、線、面的立體監(jiān)控。就整個(gè)設(shè)備的圖標(biāo)進(jìn)行表達(dá)，分析設(shè)備出現(xiàn)異常聲音完成報(bào)警提示，并就設(shè)備的屬性敏感度進(jìn)行突出顯示。

2 地鐵MLC系統(tǒng)現(xiàn)狀

分析地鐵MLC系統(tǒng)現(xiàn)狀，可以得知目前其城市交通軌道大多數(shù)在建設(shè)過(guò)程中均按照“一線一中心”的傳統(tǒng)設(shè)計(jì)方法進(jìn)行構(gòu)建。此方案在運(yùn)行時(shí)，根據(jù)整個(gè)系統(tǒng)構(gòu)建五層體系：

其一層，為清算系統(tǒng)；

其二層，則是整個(gè)項(xiàng)目中心；

其四層，是車站終端設(shè)備；

而第五層，就是車票。

按照五層架構(gòu)，形成全新的建設(shè)方案，以確保整個(gè)地鐵運(yùn)行能夠精準(zhǔn)、合理。但在后續(xù)發(fā)展中，此種方法僅適用于初級(jí)線路或少數(shù)線路，若整個(gè)城市發(fā)展步伐加快，以一線城市北京、深圳、上海、廣州為例，城市規(guī)劃建設(shè)均設(shè)置MLC系統(tǒng)，這將會(huì)導(dǎo)致投資以及其資源出現(xiàn)極大浪費(fèi)。針對(duì)于整個(gè)計(jì)算系統(tǒng)層面，有可能會(huì)導(dǎo)致清算層面收集到的必要信息數(shù)據(jù)較少，無(wú)法確保在數(shù)據(jù)清算層面能夠?qū)崿F(xiàn)線路共享，無(wú)形中增加了運(yùn)行管理、票務(wù)管理、維修管理的壓力，使整個(gè)管理的效率嚴(yán)重降低。在對(duì)MLC系統(tǒng)進(jìn)行建設(shè)過(guò)程中，有必要建設(shè)合理的系統(tǒng)模式，以便對(duì)整個(gè)MLC系統(tǒng)展開分析研究。

3 地鐵MLC云化設(shè)計(jì)

地鐵MLC 的云化設(shè)施層運(yùn)行于硬件資源之上，并服務(wù)于上層軟件，因此云化方案的設(shè)計(jì)，必須考慮整個(gè)系統(tǒng)的軟硬件情況。地鐵MLC系統(tǒng)的硬件包括網(wǎng)絡(luò)設(shè)備、通用服務(wù)器、SAN 存儲(chǔ)設(shè)備等。其中，單臺(tái)服務(wù)器的性能通常都比較強(qiáng)大，云化設(shè)施層必須能夠充分利用其硬件性能。軟件方面，現(xiàn)在的地鐵MLC系統(tǒng)，通常包含大量基礎(chǔ)中間件，且業(yè)務(wù)系統(tǒng)采用微服務(wù)設(shè)計(jì)，每個(gè)微服務(wù)實(shí)例需要的資源不多，但是數(shù)量龐大。

基于以上軟硬件特點(diǎn)，寧波MLC系統(tǒng)的總體云化方案如圖1。

圖1：寧波MLC系統(tǒng)的總體云化方案

圖1 中，核心數(shù)據(jù)庫(kù)直接部署在物理機(jī)上。MLC系統(tǒng)中的核心數(shù)據(jù)庫(kù)承載了大量的IO 壓力和部分計(jì)算，在裸金屬上直接部署，有利于發(fā)揮其最大性能。同時(shí)，Oracle、DB2 等數(shù)據(jù)庫(kù)，均自帶高可用方案，不需要云平臺(tái)支持。然后，在剩余物理機(jī)上劃分虛擬機(jī)。其中一部分虛擬機(jī)運(yùn)行中間件，這些中間件采用集群或者主備部署，不與具體業(yè)務(wù)綁定，只向業(yè)務(wù)軟件提供通用服務(wù)。另一部分虛擬機(jī)部署容器云。容器云基于Rancher 和K8S，包含若干管理節(jié)點(diǎn)、鏡像倉(cāng)庫(kù)節(jié)點(diǎn)，以及最重要的K8S 工作節(jié)點(diǎn)。其中，在地鐵MLC 場(chǎng)景下，管理節(jié)點(diǎn)的數(shù)量基本固定，對(duì)資源的需求也不高，一般2 核CPU、4G 內(nèi)存即可滿足要求。K8S 工作節(jié)點(diǎn)分配的資源可以盡量放大，比如一臺(tái)物理機(jī)平均劃分兩個(gè)虛機(jī)，因此，K8S 工作節(jié)點(diǎn)的虛機(jī)數(shù)量也不多，大約是物理機(jī)數(shù)量的1-2 倍。最后，K8S 工作節(jié)點(diǎn)中運(yùn)行多個(gè)K8S Pod，每個(gè)Pod 執(zhí)行一個(gè)MLC 業(yè)務(wù)進(jìn)程。

可以看到，以上方案不是純粹的裸金屬方案、虛擬機(jī)方案、容器方案，甚至也不是在虛擬機(jī)上統(tǒng)一運(yùn)行容器的方案，而是各個(gè)方案的融合。該方案是綜合考慮MLC 項(xiàng)目的實(shí)際因素的結(jié)果，下面逐條分析。

采用三種測(cè)量工具收集研究數(shù)據(jù)；(1)The Quick Placement Test(QPT),(2)The Vocabulary Levels Test(Nation,1990),and (3)The Productive Vocabulary Levels Test(PVLT)(Laufer&Nation,1999)。

（1）本方案降低了虛擬機(jī)的數(shù)量，提高了資源利用率。由于采用微服務(wù)設(shè)計(jì)，MLC 業(yè)務(wù)系統(tǒng)需要幾百個(gè)服務(wù)實(shí)例，如果采用純虛機(jī)方案，則需要?jiǎng)澐謳装賯€(gè)虛機(jī)，而每個(gè)虛機(jī)都需要運(yùn)行一整套操作系統(tǒng)，會(huì)造成大量的資源浪費(fèi)。

（2）本方案利用K8S 編排功能，簡(jiǎn)化了軟件的部署，而鏡像倉(cāng)庫(kù)中則包含了MLC 各服務(wù)的所有歷史版本，可通過(guò)命令實(shí)現(xiàn)快速的版本升級(jí)和回退。

（3）本方案把IO 密集的、基礎(chǔ)性的中間件部署在虛機(jī)上，而不是部署在容器中，保證了中間件的性能。這類軟件部署好之后，不會(huì)輕易修改配置、更新版本，不存在升級(jí)麻煩的問(wèn)題。

（4）本方案利用Keepalived 的VRRP技術(shù)和nginx，以高可用的方式向?qū)覯LC 的外部系統(tǒng)，發(fā)布訪問(wèn)接口。通常，K8S 通過(guò)Ingress 將容器云中的服務(wù)暴露到外部，但是K8S 本身不提供虛IP，Ingress 的訪問(wèn)地址只能是單點(diǎn)的。在公有云環(huán)境中，通常由公有云服務(wù)商的負(fù)載均衡器來(lái)保證Ingress 高可用，而本方案通過(guò)Keepalived 和nginx 完成相同的功能。

需要說(shuō)明的是，以上方案最大可能的壓縮了虛機(jī)需求，但是無(wú)法完全規(guī)避，原因如下。

首先，各類中間件一般都是多服務(wù)節(jié)點(diǎn)組成集群，為了隔離故障域，要求每個(gè)服務(wù)節(jié)點(diǎn)運(yùn)行在不同的物理機(jī)上，而且最好是不同機(jī)架的物理機(jī)上。比如Kafka 集群，通常需要5 或者7 個(gè)節(jié)點(diǎn)，每個(gè)服務(wù)節(jié)點(diǎn)占用不同的物理機(jī)。但是，根據(jù)MLC 的數(shù)據(jù)壓力，每個(gè)Kafka 服務(wù)節(jié)點(diǎn)需要的資源，大約是6 核心、32G 內(nèi)存，但是單個(gè)物理機(jī)一般是幾十核心、幾百G 內(nèi)存。如果每臺(tái)物理機(jī)只跑Kafka 服務(wù)，則極度浪費(fèi)資源。但是，如果在一臺(tái)物理機(jī)上部署多類服務(wù)，比如同時(shí)跑Kafka 和Redis 緩存，兩類服務(wù)之間難免會(huì)爭(zhēng)奪CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源，無(wú)法保證各自的服務(wù)質(zhì)量。在運(yùn)維過(guò)程中，修改一個(gè)服務(wù)的配置，也容易導(dǎo)致對(duì)另一個(gè)服務(wù)的誤操作。因此最佳的方式仍然是，在物理機(jī)上劃分若干虛機(jī)，在虛機(jī)中各自運(yùn)行中間件服務(wù)。

其次，雖然K8S 工作節(jié)點(diǎn)直接運(yùn)行在裸金屬上也可以，但考慮到資源劃分的靈活性，一般還是建議劃分虛機(jī)。比如一臺(tái)物理機(jī)，可以把30%的資源劃分為三臺(tái)虛機(jī)運(yùn)行中間件，剩余70%的資源劃分為一臺(tái)虛機(jī)運(yùn)行K8S 工作節(jié)點(diǎn)。

但是，總體而言本方案中的虛擬機(jī)的數(shù)量較少，因此企業(yè)可根據(jù)自身技術(shù)能力選擇合適的虛擬化方案，既可以選擇商業(yè)產(chǎn)品，也可以選擇采用開源技術(shù)，比如KVM。

4 非性能指標(biāo)分析

運(yùn)行在虛擬機(jī)內(nèi)的中間件，均采用集群或者主備模式工作，即使單節(jié)點(diǎn)失敗，系統(tǒng)仍然能夠正常運(yùn)行，此時(shí)可以通過(guò)把虛擬機(jī)遷移到新的物理機(jī)來(lái)修復(fù)。系統(tǒng)擴(kuò)容需要人工介入，新增虛擬機(jī)，調(diào)整中間件參數(shù)，一般需要若干小時(shí)。但考慮到維護(hù)期間業(yè)務(wù)正常執(zhí)行，且地鐵MLC 中，一般是在引入新業(yè)務(wù)或者開通新線路時(shí)才進(jìn)行中間件擴(kuò)容，此維護(hù)時(shí)間可以接受。

對(duì)于運(yùn)行在容器的業(yè)務(wù)軟件，K8S 會(huì)自動(dòng)監(jiān)測(cè)各個(gè)Pod 的執(zhí)行情況。如果K8S 發(fā)現(xiàn)失敗的Pod，會(huì)自動(dòng)在可用的工作節(jié)點(diǎn)上重啟該P(yáng)od，通常秒級(jí)完成，保證業(yè)務(wù)可用。各個(gè)服務(wù)的擴(kuò)容和縮容，既可以采用手工修改K8S 的編排文件、增加Pod 的副本的方式，也可以采用讓K8S 根據(jù)各個(gè)Pod 的負(fù)載情況，自動(dòng)調(diào)整Pod 的數(shù)量的方式。

5 MLC系統(tǒng)運(yùn)行優(yōu)勢(shì)

分析整個(gè)MLC系統(tǒng)的運(yùn)行優(yōu)勢(shì)，其具備以下四點(diǎn)：

（1）完全適應(yīng)系列化標(biāo)準(zhǔn)需求。隨著整個(gè)地鐵MLC系統(tǒng)的運(yùn)營(yíng)，在全新的監(jiān)管體系下，可以確保地鐵相關(guān)部門能夠共同參與制定全新的規(guī)范措施，以保障整個(gè)MLC系統(tǒng)能夠?qū)嵭袠?biāo)準(zhǔn)化運(yùn)行，為后續(xù)中心建設(shè)提供全新的基礎(chǔ)。充分實(shí)現(xiàn)建設(shè)標(biāo)準(zhǔn)化成果，具有非常重要的現(xiàn)實(shí)意義；

（2）滿足網(wǎng)絡(luò)化運(yùn)營(yíng)需求。針對(duì)于實(shí)現(xiàn)MLC系統(tǒng)的城市，均歷經(jīng)了單條線路的轉(zhuǎn)換過(guò)程。因此，在后續(xù)建設(shè)中，為了避免其弊端，更好的滿足運(yùn)營(yíng)化需求，MLC 建立完畢后可實(shí)現(xiàn)一卡通管理方案，使乘客在各線路之間可以達(dá)成無(wú)障礙換乘，確保能夠及時(shí)的完成地鐵線路的管理，以便實(shí)現(xiàn)互聯(lián)互通。就整個(gè)線網(wǎng)建設(shè)以及運(yùn)營(yíng)角度，考慮進(jìn)行MLC系統(tǒng)項(xiàng)目建設(shè)具有極佳的重要性；

（3）節(jié)省項(xiàng)目建設(shè)投資。采用MLC系統(tǒng)后，整個(gè)項(xiàng)目的總投資量將會(huì)顯著減少，以便于后續(xù)完成地鐵的運(yùn)維建設(shè)；

（4）提高整個(gè)系統(tǒng)經(jīng)濟(jì)效益。通過(guò)建立MLC系統(tǒng)，其可以最大限度地實(shí)現(xiàn)資源共享，降低運(yùn)營(yíng)成本。在現(xiàn)有的采購(gòu)上，可以按照我國(guó)供貨商的特長(zhǎng)選擇商品自行組成系統(tǒng)，降低其建設(shè)投資，做到投資利益最大化。

6 總結(jié)

隨著技術(shù)的成熟，虛擬化、容器最終會(huì)變成和通用服務(wù)器一樣，成為大部分企業(yè)應(yīng)用系統(tǒng)依賴的基礎(chǔ)設(shè)施。本文結(jié)合地鐵MLC系統(tǒng)，提出了企業(yè)應(yīng)用系統(tǒng)云化的一個(gè)可用方案，可為類似系統(tǒng)提供參考。