鐵路運(yùn)輸應(yīng)用云原生技術(shù)優(yōu)化路線研究

李貝貝，閻志遠(yuǎn)，戴琳琳

（中國鐵道科學(xué)研究院集團(tuán)有限公司 電子計(jì)算技術(shù)研究所，北京 100081）

2017年，中國國家鐵路集團(tuán)有限公司（簡(jiǎn)稱：國鐵集團(tuán)）發(fā)布的《鐵路信息化總體規(guī)劃》對(duì)鐵路運(yùn)輸生產(chǎn)領(lǐng)域的信息化系統(tǒng)的業(yè)務(wù)分類、建設(shè)任務(wù)及目標(biāo)進(jìn)行了描述，并指出鐵路運(yùn)輸生產(chǎn)信息化的業(yè)務(wù)范圍包括客運(yùn)管理、貨運(yùn)物流管理、運(yùn)輸調(diào)度、生產(chǎn)作業(yè)、安全監(jiān)測(cè)與安全監(jiān)管六大板塊。

鐵路運(yùn)輸生產(chǎn)領(lǐng)域的信息系統(tǒng)已經(jīng)建立了覆蓋國鐵集團(tuán)、鐵路局集團(tuán)公司和主要站段的業(yè)務(wù)應(yīng)用系統(tǒng)[1]。各業(yè)務(wù)系統(tǒng)在建設(shè)的過程中，根據(jù)其自身業(yè)務(wù)特點(diǎn)，使用的技術(shù)棧存在交叉性[2]。部署于國鐵集團(tuán)的應(yīng)用系統(tǒng)多為系統(tǒng)數(shù)據(jù)沉淀的核心，部分信息系統(tǒng)已經(jīng)實(shí)現(xiàn)了業(yè)務(wù)與信息的集成，但是未能對(duì)鐵路運(yùn)輸信息形成數(shù)據(jù)產(chǎn)業(yè)整體能力，沒有實(shí)現(xiàn)公共數(shù)據(jù)共享與融合，各組織之間依然需要針對(duì)業(yè)務(wù)進(jìn)行溝通和開展二次開發(fā)，二次開發(fā)過程中一般沿用原有的技術(shù)架構(gòu)，開發(fā)與運(yùn)維效率上具有提升空間。

鐵路運(yùn)輸生產(chǎn)領(lǐng)域的信息系統(tǒng)內(nèi)部積累了大量業(yè)務(wù)數(shù)據(jù)，因設(shè)備、人員、技術(shù)等原因，部分業(yè)務(wù)系統(tǒng)的歷史數(shù)據(jù)并沒有實(shí)現(xiàn)有效的管理、統(tǒng)計(jì)與分析，數(shù)據(jù)的潛在價(jià)值有待挖掘。各業(yè)務(wù)系統(tǒng)內(nèi)部的差異化流程[3]，使得相關(guān)信息系統(tǒng)的計(jì)劃、標(biāo)準(zhǔn)規(guī)范、審核等工作較為復(fù)雜，給項(xiàng)目開發(fā)團(tuán)隊(duì)與管理人員帶來挑戰(zhàn)，不利于鐵路運(yùn)輸信息化整體優(yōu)化建設(shè)。本文結(jié)合云原生技術(shù)路線進(jìn)行鐵路運(yùn)輸信息化優(yōu)化研究，為鐵路運(yùn)輸企業(yè)業(yè)務(wù)系統(tǒng)工作流程標(biāo)準(zhǔn)的建立提供參考。

1 云原生技術(shù)概述

1.1 云原生技術(shù)定義

云原生技術(shù)生態(tài)是一個(gè)龐大的技術(shù)集合，云原生計(jì)算基金會(huì)（CNCF）把云原生的概念更廣泛地定義為讓應(yīng)用更有彈性、容錯(cuò)性、觀測(cè)性的基礎(chǔ)技術(shù)，讓應(yīng)用更易部署、管理的基礎(chǔ)軟件，讓應(yīng)用更易編寫、編排的運(yùn)行框架等，讓開發(fā)者更好地利用云的資源、產(chǎn)品和交付能力[4]。

結(jié)合云原生的鐵路運(yùn)輸生產(chǎn)領(lǐng)域的信息系統(tǒng)，需要在云計(jì)算的基礎(chǔ)上不斷發(fā)展壯大，遵循新的軟件定義、開發(fā)、部署和運(yùn)維模式，通過發(fā)揮云的能力，使鐵路運(yùn)輸企業(yè)的信息服務(wù)能力最大化。

1.2 云原生技術(shù)范疇

云原生的技術(shù)范疇主要包含以下幾方面。

（1）云應(yīng)用的范圍與開發(fā)流程：主要指微服務(wù)、應(yīng)用消息、配置持續(xù)集成與部署、自動(dòng)化運(yùn)維、定義與鏡像制作、容器以及數(shù)據(jù)庫等；

（2）云應(yīng)用編排與管理流程：主要指遠(yuǎn)程調(diào)用、API網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)治理、應(yīng)用編排與調(diào)度以及服務(wù)網(wǎng)格等技術(shù)，是Kubernetes相關(guān)應(yīng)用的價(jià)值體現(xiàn)點(diǎn)[5]；

（3）監(jiān)控與可觀測(cè)性：主要包括云上應(yīng)用日志采集、追蹤、度量、監(jiān)控以及混沌工程等概念；

（4）云原生的底層技術(shù)：主要指容器運(yùn)行時(shí)的網(wǎng)絡(luò)、文件系統(tǒng)與存儲(chǔ)等技術(shù)；

（5）云原生工具集：包括配套生態(tài)及周邊工具鏈，如配置管理、流程管理、鏡像倉庫、云原生密碼及安全技術(shù)等；

（6）無服務(wù)器計(jì)算：通過構(gòu)建或使用一個(gè)微服務(wù)或微功能來響應(yīng)一個(gè)事件，定義了一種更為抽象的應(yīng)用編寫方式，包含功能即服務(wù)（FaaS，F(xiàn)unction as a Service）和后端即服務(wù)（BaaS，Backend as a Service）等概念，典型的特點(diǎn)是按實(shí)際消費(fèi)的資源計(jì)費(fèi)。

2 云原生技術(shù)優(yōu)化路線

本文結(jié)合鐵路運(yùn)輸信息化應(yīng)用架構(gòu)的現(xiàn)狀，主要分析應(yīng)用運(yùn)行容器化、應(yīng)用移植復(fù)用性及應(yīng)用微服務(wù)改造3方面內(nèi)容。

2.1 應(yīng)用運(yùn)行容器化

鐵路運(yùn)輸領(lǐng)域信息化系統(tǒng)的應(yīng)用運(yùn)行載體容器化問題，著眼于解決差異化的業(yè)務(wù)應(yīng)用，使之具備容器化的基本條件。鐵路運(yùn)輸信息化應(yīng)用系統(tǒng)種類繁多，架構(gòu)與技術(shù)棧復(fù)雜，是否具備容器化條件，主要考量以下3方面。

（1）容器對(duì)操作系統(tǒng)的內(nèi)核功能支持有依賴，鐵路運(yùn)輸信息化應(yīng)用開發(fā)依賴的技術(shù)應(yīng)符合容器的支持情況。

Linux是主流的容器運(yùn)行平臺(tái)，對(duì)Windows的支持能力尚未成熟，因此應(yīng)考慮應(yīng)用自身的技術(shù)棧是否具備運(yùn)行于Linux操作系統(tǒng)的能力，假如不具備，則應(yīng)考慮應(yīng)用是否具備跨平臺(tái)化改造的條件。同時(shí)，服務(wù)間接口調(diào)用如果使用非標(biāo)準(zhǔn)協(xié)議，一般無法通過負(fù)載均衡器進(jìn)行有效負(fù)載，應(yīng)考慮是否可通過TCP或HTTP協(xié)議進(jìn)行此類應(yīng)用的容器化改造。

（2）容器技術(shù)較好地解決了應(yīng)用敏捷發(fā)布、彈性擴(kuò)展、計(jì)算資源利用率等問題，因此，信息化應(yīng)用是否適合容器化需要考慮持續(xù)發(fā)布等問題[6]。

一些非服務(wù)類的應(yīng)用，如數(shù)據(jù)庫系統(tǒng)，生命周期長，沒有頻繁發(fā)布的需求，彈性擴(kuò)展要面臨數(shù)據(jù)一致性和大量數(shù)據(jù)同步的額外開銷。同時(shí)，數(shù)據(jù)實(shí)體的存儲(chǔ)是一個(gè)可預(yù)估且持續(xù)增量的過程，不涉及浪費(fèi)大量基礎(chǔ)資源的情況。這樣的應(yīng)用組件，一般不需要進(jìn)行容器化。通常，只包含后端服務(wù)邏輯的業(yè)務(wù)服務(wù)，隨著業(yè)務(wù)需求擴(kuò)充、業(yè)務(wù)負(fù)載等變化，存在頻繁更新功能邏輯、彈性擴(kuò)展的需求，則可通過容器化改造獲得業(yè)務(wù)能力的較大提升，如12306互聯(lián)網(wǎng)售票系統(tǒng)、調(diào)度管理系統(tǒng)等客戶服務(wù)類應(yīng)用。

（3）軟件產(chǎn)權(quán)模式是影響容器化改造的必要評(píng)估問題。

在云原生的技術(shù)生態(tài)里，由社區(qū)廣泛參與驅(qū)動(dòng)的都是開源技術(shù)組件和軟件，主要受限于商業(yè)軟件授權(quán)許可證技術(shù)[7]。部分商業(yè)軟件的授權(quán)模式，會(huì)限制其它商業(yè)軟件的依賴及版本，其它軟件授權(quán)會(huì)綁定主機(jī)的物理識(shí)別信息，如MAC地址等。但是容器調(diào)度技術(shù)的本質(zhì)是舊容器的銷毀與新容器的創(chuàng)建，會(huì)導(dǎo)致依賴底層物理識(shí)別信息的商業(yè)軟件授權(quán)失效。因此，如果鐵路運(yùn)輸生產(chǎn)領(lǐng)域中的信息系統(tǒng)是商業(yè)軟件，需要慎重考慮，需與軟件制造商溝通其是否具備容器化的基礎(chǔ)條件。

2.2 應(yīng)用移植復(fù)用性

容器在外部條件差異較大的情況下是否具備可移植性，主要取決于容器對(duì)不同運(yùn)行環(huán)境的可移植性，和容器對(duì)不同編排平臺(tái)的可移植性。

容器技術(shù)來源于LXC（Linux Container），是一種通過namespcae和cgroup實(shí)現(xiàn)進(jìn)程級(jí)別的虛擬化技術(shù)。容器技術(shù)的關(guān)鍵特點(diǎn)是容器封裝帶來的高度可移植性[8]。從容器技術(shù)自身來講，將應(yīng)用程序的自身依賴庫全部打包為一個(gè)整體，具備可移植性，屏蔽外部因素的情況下，容器可以在任意互相兼容的內(nèi)核中正常運(yùn)行。

2.3 應(yīng)用微服務(wù)化改造

云原生應(yīng)用一般基于單一職責(zé)原則，將應(yīng)用架構(gòu)設(shè)計(jì)為細(xì)粒度的應(yīng)用服務(wù)。將鐵路運(yùn)輸信息化應(yīng)用架構(gòu)中的業(yè)務(wù)優(yōu)化型技術(shù)盡可能從復(fù)雜的業(yè)務(wù)與技術(shù)耦合中脫離出來，形成分層清晰、架構(gòu)松散的各類微型業(yè)務(wù)服務(wù)類應(yīng)用[9]。

2.3.1 業(yè)務(wù)功能拆分

通常情況下，微服務(wù)是根據(jù)業(yè)務(wù)發(fā)展需要逐步被拆分出來的。在業(yè)務(wù)持續(xù)推進(jìn)過程中，微服務(wù)劃分的合理性需要被進(jìn)一步審視。拆分的原則可以從業(yè)務(wù)維度、技術(shù)維度及團(tuán)隊(duì)架構(gòu)維度進(jìn)行審視。

微服務(wù)拆分是為了更好的橫向擴(kuò)展性。系統(tǒng)的每個(gè)服務(wù)可以根據(jù)業(yè)務(wù)需要進(jìn)行擴(kuò)展，從而實(shí)現(xiàn)高性能、高可用性和高擴(kuò)展性。業(yè)務(wù)功能微服務(wù)拆分常用的方法為AKF擴(kuò)展立方體與領(lǐng)域驅(qū)動(dòng)建模（DDD，Domain-Driven Design）。根據(jù)《架構(gòu)即未來》一書[10]對(duì)AKF擴(kuò)展立方體可擴(kuò)展模型的講述，一個(gè)單一系統(tǒng)若從水平復(fù)制、數(shù)據(jù)分區(qū)和拆分模式3個(gè)維度進(jìn)行分析，可進(jìn)行無限擴(kuò)展。

DDD同時(shí)提供了戰(zhàn)略和戰(zhàn)術(shù)上的建模工具，是一個(gè)自上而下的架構(gòu)設(shè)計(jì)方法。通過與業(yè)務(wù)領(lǐng)域?qū)＜疫M(jìn)行溝通，建立統(tǒng)一的語言，以明確、可行的方式對(duì)領(lǐng)域進(jìn)行建模，確定業(yè)務(wù)邊界與邊界上下文，幫助實(shí)現(xiàn)高價(jià)值的軟件和系統(tǒng)。基于DDD拆分微服務(wù)的步驟通常為：基于領(lǐng)域事件建立領(lǐng)域模型，基于模型和領(lǐng)域?qū)＜医⒔y(tǒng)一語言，業(yè)務(wù)分析確定上下文映射，尋找聚合邊界，確定服務(wù)調(diào)用關(guān)系，業(yè)務(wù)流程驗(yàn)證，持續(xù)優(yōu)化。

2.3.2 業(yè)務(wù)邏輯改造

很多業(yè)務(wù)服務(wù)存在狀態(tài)信息，在數(shù)據(jù)庫中設(shè)計(jì)觸發(fā)器和存儲(chǔ)過程解決業(yè)務(wù)底層邏輯問題。這些問題一般不利用業(yè)務(wù)微服務(wù)化改造，需要根據(jù)一定的邏輯和原則進(jìn)行解決。

（1）無狀態(tài)化

無狀態(tài)化指運(yùn)行服務(wù)實(shí)例不需要將數(shù)據(jù)在本地持久化存儲(chǔ)，多個(gè)實(shí)例對(duì)同一個(gè)服務(wù)請(qǐng)求的響應(yīng)結(jié)果是完全一致的。無狀態(tài)化通過把數(shù)據(jù)狀態(tài)或抽象的復(fù)雜度狀態(tài)信息，統(tǒng)一外置到數(shù)據(jù)庫或分布式緩存中，可解決有狀態(tài)化的服務(wù)伸縮問題，但是對(duì)那些建立長連接的業(yè)務(wù)服務(wù)，一般無法進(jìn)行無狀態(tài)化設(shè)計(jì)。

當(dāng)出現(xiàn)定時(shí)任務(wù)、本地存儲(chǔ)或本地緩存等業(yè)態(tài)時(shí)，需要將其與業(yè)務(wù)服務(wù)進(jìn)行拆分，否則擴(kuò)展性將受到較大限制。

（2）去觸發(fā)器、存儲(chǔ)過程

在鐵路運(yùn)輸生產(chǎn)領(lǐng)域部分信息化系統(tǒng)發(fā)展初期，系統(tǒng)規(guī)模較小，對(duì)觸發(fā)器、存儲(chǔ)過程的使用較為普遍。隨著業(yè)務(wù)的持續(xù)發(fā)展，系統(tǒng)規(guī)模逐漸變得龐大，由于觸發(fā)器、存儲(chǔ)過程難以擴(kuò)展，整體業(yè)務(wù)的伸縮受到限制，尤其當(dāng)存在水平分表時(shí)，業(yè)務(wù)擴(kuò)展的靈活性受到了較大限制。為解決此類情況，通常通過增加外部業(yè)務(wù)服務(wù)及定時(shí)任務(wù)等操作，替換觸發(fā)器及存儲(chǔ)過程。

2.3.3 改造策略

鐵路運(yùn)輸生產(chǎn)信息化當(dāng)前已完成了應(yīng)用技術(shù)棧、應(yīng)用架構(gòu)、底層云平臺(tái)等多項(xiàng)基礎(chǔ)建設(shè)。但是基礎(chǔ)設(shè)施云、容器云、業(yè)務(wù)云等代表先進(jìn)生產(chǎn)力的云原生技術(shù)方式還沒有被廣泛整合與運(yùn)用。基于鐵路運(yùn)輸信息化應(yīng)用架構(gòu)的發(fā)展趨勢(shì)，本文對(duì)業(yè)務(wù)優(yōu)化型技術(shù)和信息化支撐型技術(shù)領(lǐng)域，有著不同的改造策略。

（1）業(yè)務(wù)優(yōu)化型技術(shù)

鐵路運(yùn)輸信息化業(yè)務(wù)優(yōu)化型技術(shù)的微服務(wù)改造，無法一開始就對(duì)全部應(yīng)用進(jìn)行統(tǒng)一的升級(jí)改造，應(yīng)隨著業(yè)務(wù)的發(fā)展與技術(shù)的沉淀，在漫長周期中逐步迭代完成。具體執(zhí)行方法可采用微服務(wù)技術(shù)體系中的絞殺者策略。

絞殺者策略一般保持既有系統(tǒng)不變，當(dāng)有新的業(yè)務(wù)功能需要建設(shè)與開發(fā)時(shí)，不單純的在原有項(xiàng)目上進(jìn)行修改，而是重新開發(fā)服務(wù)，實(shí)現(xiàn)新的功能，涉及遺留系統(tǒng)改造的，將相關(guān)的功能從遺留系統(tǒng)遷移到新服務(wù)中。通過不斷構(gòu)建新的系統(tǒng)與服務(wù)，使遺留系統(tǒng)的功能逐漸減弱至失效，最終得以替換。

（2）信息化支撐型技術(shù)

信息化支撐型技術(shù)與業(yè)務(wù)屬性耦合性低，但業(yè)務(wù)應(yīng)用的大規(guī)模發(fā)展，容易使信息化支撐技術(shù)負(fù)載過高，不利于系統(tǒng)架構(gòu)的整體演進(jìn)，如果不對(duì)信息化支撐型技術(shù)進(jìn)行優(yōu)化與升級(jí)，容易導(dǎo)致業(yè)務(wù)風(fēng)險(xiǎn)。針對(duì)底層的信息化支撐技術(shù)的改造一般遵循3步走：小規(guī)模應(yīng)用試點(diǎn)，技術(shù)工程規(guī)范建設(shè)研究，大規(guī)模復(fù)制推廣。

改造業(yè)務(wù)優(yōu)化型技術(shù)與信息化支撐型技術(shù)，將平滑有序地推進(jìn)鐵路運(yùn)輸信息化整體建設(shè)。

2.4 網(wǎng)絡(luò)梳理

應(yīng)用容器化后，鐵路運(yùn)輸生產(chǎn)領(lǐng)域的信息化還需要關(guān)注網(wǎng)絡(luò)規(guī)劃。容器平臺(tái)一般會(huì)建設(shè)計(jì)算集群、管理集群以及其它涉及日志、監(jiān)控、鏡像倉庫等的服務(wù)集群。通常通過業(yè)務(wù)IP網(wǎng)段的劃分來區(qū)別管理集群、服務(wù)集群與計(jì)算集群，并對(duì)每臺(tái)宿主機(jī)的應(yīng)用組件進(jìn)行端口規(guī)劃。

容器化過程中根據(jù)應(yīng)用特性的不同，還需考慮網(wǎng)絡(luò)模式。例如，Bridge網(wǎng)絡(luò)模式更多的應(yīng)用于無狀態(tài)化容器，Host網(wǎng)絡(luò)模式更多的應(yīng)用于特定端口或?qū)W(wǎng)絡(luò)性能要求高的應(yīng)用，但Host模式的使用，還需要進(jìn)行網(wǎng)絡(luò)端口資源規(guī)劃。

3 中臺(tái)化長期戰(zhàn)略

3.1 長期戰(zhàn)略基本思路

結(jié)合云原生的應(yīng)用架構(gòu)優(yōu)化策略，解決當(dāng)下鐵路運(yùn)輸信息化應(yīng)用系統(tǒng)平臺(tái)化程度低、信息孤島的問題。通過構(gòu)建統(tǒng)一的應(yīng)用支撐載體，在物理架構(gòu)上為各應(yīng)用系統(tǒng)創(chuàng)建信息共享的技術(shù)基礎(chǔ)，在現(xiàn)有兩級(jí)部署、三級(jí)應(yīng)用的模式上，強(qiáng)化國鐵集團(tuán)級(jí)平臺(tái)化應(yīng)用服務(wù)能力，將各鐵路局集團(tuán)公司、客運(yùn)站的通用業(yè)務(wù)與數(shù)據(jù)進(jìn)行匯集，多級(jí)應(yīng)用共享各自上級(jí)系統(tǒng)的關(guān)鍵技術(shù)服務(wù)，是實(shí)現(xiàn)技術(shù)沉淀及中臺(tái)服務(wù)的長期基本思路。

3.2 長期戰(zhàn)略運(yùn)用案例

（1）在鐵路運(yùn)輸信息化客運(yùn)領(lǐng)域中，客運(yùn)管理信息系統(tǒng)（簡(jiǎn)稱：客管系統(tǒng)）就是典型的垂直覆蓋三級(jí)應(yīng)用，橫跨管控與服務(wù)等不同業(yè)務(wù)領(lǐng)域的大型信息系統(tǒng)。對(duì)此類系統(tǒng)的中臺(tái)化沉淀，可遵循微服務(wù)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的模式，將跨領(lǐng)域的應(yīng)用能力再次內(nèi)聚，并沉淀為國鐵集團(tuán)級(jí)部署的通用服務(wù)能力。在降低業(yè)務(wù)調(diào)用鏈路長度，顯著減少數(shù)據(jù)同步開銷的同時(shí)，提升客管系統(tǒng)數(shù)據(jù)與其他信息系統(tǒng)數(shù)據(jù)交互的能力。

（2）客票領(lǐng)域內(nèi)，車次和席位兩組強(qiáng)耦合數(shù)據(jù)可構(gòu)成領(lǐng)域事件主體，而圍繞這一主體展開的則是用戶、交易等外部事件，過程中都會(huì)調(diào)用追蹤定位、無線通信等通用技術(shù)組件。這一系列活動(dòng)可視為客票中心、用戶中心、交易中心、通用技術(shù)支撐中心等幾個(gè)不同的中臺(tái)化沉淀服務(wù)能力的統(tǒng)一部署，而二、三級(jí)應(yīng)用僅需實(shí)現(xiàn)必須的前置連接與人機(jī)交互服務(wù)能力即可，其他服務(wù)能力均通過調(diào)用中臺(tái)服務(wù)能力獲取。

4 結(jié)束語

云原生技術(shù)的引入，旨在通過應(yīng)用微服務(wù)改造、復(fù)用性移植、運(yùn)行容器化、網(wǎng)絡(luò)規(guī)劃等角度，實(shí)現(xiàn)軟硬件資產(chǎn)統(tǒng)一管控，標(biāo)準(zhǔn)化開發(fā)運(yùn)維技術(shù)棧，中臺(tái)化服務(wù)能力沉淀，以及各終端業(yè)務(wù)生態(tài)的廣泛協(xié)同建設(shè)。提升鐵路運(yùn)輸企業(yè)業(yè)務(wù)服務(wù)能力，解決鐵路運(yùn)輸生產(chǎn)領(lǐng)域信息化業(yè)務(wù)系統(tǒng)面臨的信息孤島、運(yùn)維差異、服務(wù)應(yīng)急能力等問題。鐵路運(yùn)輸生產(chǎn)領(lǐng)域的中臺(tái)長期戰(zhàn)略，能更好地輔助鐵路運(yùn)輸信息化由傳統(tǒng)應(yīng)用架構(gòu)向數(shù)字化轉(zhuǎn)型。但鐵路運(yùn)輸信息化、數(shù)字化運(yùn)營的成功轉(zhuǎn)型，只有技術(shù)支持是不夠的，還需要人員、制度等各方面的協(xié)調(diào)發(fā)展。