鐵路運輸應用云原生技術優化路線研究

李貝貝，閻志遠，戴琳琳

（中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081）

2017年，中國國家鐵路集團有限公司（簡稱：國鐵集團）發布的《鐵路信息化總體規劃》對鐵路運輸生產領域的信息化系統的業務分類、建設任務及目標進行了描述，并指出鐵路運輸生產信息化的業務范圍包括客運管理、貨運物流管理、運輸調度、生產作業、安全監測與安全監管六大板塊。

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

鐵路運輸生產領域的信息系統內部積累了大量業務數據，因設備、人員、技術等原因，部分業務系統的歷史數據并沒有實現有效的管理、統計與分析，數據的潛在價值有待挖掘。各業務系統內部的差異化流程[3]，使得相關信息系統的計劃、標準規范、審核等工作較為復雜，給項目開發團隊與管理人員帶來挑戰，不利于鐵路運輸信息化整體優化建設。本文結合云原生技術路線進行鐵路運輸信息化優化研究，為鐵路運輸企業業務系統工作流程標準的建立提供參考。

1 云原生技術概述

1.1 云原生技術定義

云原生技術生態是一個龐大的技術集合，云原生計算基金會（CNCF）把云原生的概念更廣泛地定義為讓應用更有彈性、容錯性、觀測性的基礎技術，讓應用更易部署、管理的基礎軟件，讓應用更易編寫、編排的運行框架等，讓開發者更好地利用云的資源、產品和交付能力[4]。

結合云原生的鐵路運輸生產領域的信息系統，需要在云計算的基礎上不斷發展壯大，遵循新的軟件定義、開發、部署和運維模式，通過發揮云的能力，使鐵路運輸企業的信息服務能力最大化。

1.2 云原生技術范疇

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

（1）云應用的范圍與開發流程：主要指微服務、應用消息、配置持續集成與部署、自動化運維、定義與鏡像制作、容器以及數據庫等；

（2）云應用編排與管理流程：主要指遠程調用、API網關、服務發現治理、應用編排與調度以及服務網格等技術，是Kubernetes相關應用的價值體現點[5]；

（3）監控與可觀測性：主要包括云上應用日志采集、追蹤、度量、監控以及混沌工程等概念；

（4）云原生的底層技術：主要指容器運行時的網絡、文件系統與存儲等技術；

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

（6）無服務器計算：通過構建或使用一個微服務或微功能來響應一個事件，定義了一種更為抽象的應用編寫方式，包含功能即服務（FaaS，Function as a Service）和后端即服務（BaaS，Backend as a Service）等概念，典型的特點是按實際消費的資源計費。

2 云原生技術優化路線

本文結合鐵路運輸信息化應用架構的現狀，主要分析應用運行容器化、應用移植復用性及應用微服務改造3方面內容。

2.1 應用運行容器化

鐵路運輸領域信息化系統的應用運行載體容器化問題，著眼于解決差異化的業務應用，使之具備容器化的基本條件。鐵路運輸信息化應用系統種類繁多，架構與技術棧復雜，是否具備容器化條件，主要考量以下3方面。

（1）容器對操作系統的內核功能支持有依賴，鐵路運輸信息化應用開發依賴的技術應符合容器的支持情況。

Linux是主流的容器運行平臺，對Windows的支持能力尚未成熟，因此應考慮應用自身的技術棧是否具備運行于Linux操作系統的能力，假如不具備，則應考慮應用是否具備跨平臺化改造的條件。同時，服務間接口調用如果使用非標準協議，一般無法通過負載均衡器進行有效負載，應考慮是否可通過TCP或HTTP協議進行此類應用的容器化改造。

（2）容器技術較好地解決了應用敏捷發布、彈性擴展、計算資源利用率等問題，因此，信息化應用是否適合容器化需要考慮持續發布等問題[6]。

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

（3）軟件產權模式是影響容器化改造的必要評估問題。

在云原生的技術生態里，由社區廣泛參與驅動的都是開源技術組件和軟件，主要受限于商業軟件授權許可證技術[7]。部分商業軟件的授權模式，會限制其它商業軟件的依賴及版本，其它軟件授權會綁定主機的物理識別信息，如MAC地址等。但是容器調度技術的本質是舊容器的銷毀與新容器的創建，會導致依賴底層物理識別信息的商業軟件授權失效。因此，如果鐵路運輸生產領域中的信息系統是商業軟件，需要慎重考慮，需與軟件制造商溝通其是否具備容器化的基礎條件。

2.2 應用移植復用性

容器在外部條件差異較大的情況下是否具備可移植性，主要取決于容器對不同運行環境的可移植性，和容器對不同編排平臺的可移植性。

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

2.3 應用微服務化改造

云原生應用一般基于單一職責原則，將應用架構設計為細粒度的應用服務。將鐵路運輸信息化應用架構中的業務優化型技術盡可能從復雜的業務與技術耦合中脫離出來，形成分層清晰、架構松散的各類微型業務服務類應用[9]。

2.3.1 業務功能拆分

通常情況下，微服務是根據業務發展需要逐步被拆分出來的。在業務持續推進過程中，微服務劃分的合理性需要被進一步審視。拆分的原則可以從業務維度、技術維度及團隊架構維度進行審視。

微服務拆分是為了更好的橫向擴展性。系統的每個服務可以根據業務需要進行擴展，從而實現高性能、高可用性和高擴展性。業務功能微服務拆分常用的方法為AKF擴展立方體與領域驅動建模（DDD，Domain-Driven Design）。根據《架構即未來》一書[10]對AKF擴展立方體可擴展模型的講述，一個單一系統若從水平復制、數據分區和拆分模式3個維度進行分析，可進行無限擴展。

DDD同時提供了戰略和戰術上的建模工具，是一個自上而下的架構設計方法。通過與業務領域專家進行溝通，建立統一的語言，以明確、可行的方式對領域進行建模，確定業務邊界與邊界上下文，幫助實現高價值的軟件和系統。基于DDD拆分微服務的步驟通常為：基于領域事件建立領域模型，基于模型和領域專家建立統一語言，業務分析確定上下文映射，尋找聚合邊界，確定服務調用關系，業務流程驗證，持續優化。

2.3.2 業務邏輯改造

很多業務服務存在狀態信息，在數據庫中設計觸發器和存儲過程解決業務底層邏輯問題。這些問題一般不利用業務微服務化改造，需要根據一定的邏輯和原則進行解決。

（1）無狀態化

無狀態化指運行服務實例不需要將數據在本地持久化存儲，多個實例對同一個服務請求的響應結果是完全一致的。無狀態化通過把數據狀態或抽象的復雜度狀態信息，統一外置到數據庫或分布式緩存中，可解決有狀態化的服務伸縮問題，但是對那些建立長連接的業務服務，一般無法進行無狀態化設計。

當出現定時任務、本地存儲或本地緩存等業態時，需要將其與業務服務進行拆分，否則擴展性將受到較大限制。

（2）去觸發器、存儲過程

在鐵路運輸生產領域部分信息化系統發展初期，系統規模較小，對觸發器、存儲過程的使用較為普遍。隨著業務的持續發展，系統規模逐漸變得龐大，由于觸發器、存儲過程難以擴展，整體業務的伸縮受到限制，尤其當存在水平分表時，業務擴展的靈活性受到了較大限制。為解決此類情況，通常通過增加外部業務服務及定時任務等操作，替換觸發器及存儲過程。

2.3.3 改造策略

鐵路運輸生產信息化當前已完成了應用技術棧、應用架構、底層云平臺等多項基礎建設。但是基礎設施云、容器云、業務云等代表先進生產力的云原生技術方式還沒有被廣泛整合與運用。基于鐵路運輸信息化應用架構的發展趨勢，本文對業務優化型技術和信息化支撐型技術領域，有著不同的改造策略。

（1）業務優化型技術

鐵路運輸信息化業務優化型技術的微服務改造，無法一開始就對全部應用進行統一的升級改造，應隨著業務的發展與技術的沉淀，在漫長周期中逐步迭代完成。具體執行方法可采用微服務技術體系中的絞殺者策略。

絞殺者策略一般保持既有系統不變，當有新的業務功能需要建設與開發時，不單純的在原有項目上進行修改，而是重新開發服務，實現新的功能，涉及遺留系統改造的，將相關的功能從遺留系統遷移到新服務中。通過不斷構建新的系統與服務，使遺留系統的功能逐漸減弱至失效，最終得以替換。

（2）信息化支撐型技術

信息化支撐型技術與業務屬性耦合性低，但業務應用的大規模發展，容易使信息化支撐技術負載過高，不利于系統架構的整體演進，如果不對信息化支撐型技術進行優化與升級，容易導致業務風險。針對底層的信息化支撐技術的改造一般遵循3步走：小規模應用試點，技術工程規范建設研究，大規模復制推廣。

改造業務優化型技術與信息化支撐型技術，將平滑有序地推進鐵路運輸信息化整體建設。

2.4 網絡梳理

應用容器化后，鐵路運輸生產領域的信息化還需要關注網絡規劃。容器平臺一般會建設計算集群、管理集群以及其它涉及日志、監控、鏡像倉庫等的服務集群。通常通過業務IP網段的劃分來區別管理集群、服務集群與計算集群，并對每臺宿主機的應用組件進行端口規劃。

容器化過程中根據應用特性的不同，還需考慮網絡模式。例如，Bridge網絡模式更多的應用于無狀態化容器，Host網絡模式更多的應用于特定端口或對網絡性能要求高的應用，但Host模式的使用，還需要進行網絡端口資源規劃。

3 中臺化長期戰略

3.1 長期戰略基本思路

結合云原生的應用架構優化策略，解決當下鐵路運輸信息化應用系統平臺化程度低、信息孤島的問題。通過構建統一的應用支撐載體，在物理架構上為各應用系統創建信息共享的技術基礎，在現有兩級部署、三級應用的模式上，強化國鐵集團級平臺化應用服務能力，將各鐵路局集團公司、客運站的通用業務與數據進行匯集，多級應用共享各自上級系統的關鍵技術服務，是實現技術沉淀及中臺服務的長期基本思路。

3.2 長期戰略運用案例

（1）在鐵路運輸信息化客運領域中，客運管理信息系統（簡稱：客管系統）就是典型的垂直覆蓋三級應用，橫跨管控與服務等不同業務領域的大型信息系統。對此類系統的中臺化沉淀，可遵循微服務領域驅動設計的模式，將跨領域的應用能力再次內聚，并沉淀為國鐵集團級部署的通用服務能力。在降低業務調用鏈路長度，顯著減少數據同步開銷的同時，提升客管系統數據與其他信息系統數據交互的能力。

（2）客票領域內，車次和席位兩組強耦合數據可構成領域事件主體，而圍繞這一主體展開的則是用戶、交易等外部事件，過程中都會調用追蹤定位、無線通信等通用技術組件。這一系列活動可視為客票中心、用戶中心、交易中心、通用技術支撐中心等幾個不同的中臺化沉淀服務能力的統一部署，而二、三級應用僅需實現必須的前置連接與人機交互服務能力即可，其他服務能力均通過調用中臺服務能力獲取。

4 結束語

云原生技術的引入，旨在通過應用微服務改造、復用性移植、運行容器化、網絡規劃等角度，實現軟硬件資產統一管控，標準化開發運維技術棧，中臺化服務能力沉淀，以及各終端業務生態的廣泛協同建設。提升鐵路運輸企業業務服務能力，解決鐵路運輸生產領域信息化業務系統面臨的信息孤島、運維差異、服務應急能力等問題。鐵路運輸生產領域的中臺長期戰略，能更好地輔助鐵路運輸信息化由傳統應用架構向數字化轉型。但鐵路運輸信息化、數字化運營的成功轉型，只有技術支持是不夠的，還需要人員、制度等各方面的協調發展。