铁路运输应用云原生技术优化路线研究

李贝贝，阎志远，戴琳琳

（中国铁道科学研究院集团有限公司 电子计算技术研究所，北京 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 结束语

云原生技术的引入，旨在通过应用微服务改造、复用性移植、运行容器化、网络规划等角度，实现软硬件资产统一管控，标准化开发运维技术栈，中台化服务能力沉淀，以及各终端业务生态的广泛协同建设。提升铁路运输企业业务服务能力，解决铁路运输生产领域信息化业务系统面临的信息孤岛、运维差异、服务应急能力等问题。铁路运输生产领域的中台长期战略，能更好地辅助铁路运输信息化由传统应用架构向数字化转型。但铁路运输信息化、数字化运营的成功转型，只有技术支持是不够的，还需要人员、制度等各方面的协调发展。