城市轨道交通自主可控云平台业务系统迁移探析

吕广杰，刘庆良，吴 超，范义波

（浪潮电子信息产业股份有限公司，济南 250101）

1 研究背景

1.1 城轨云的发展历程

中国城市轨道交通云平台(以下简称“城轨云”)项目的建设主要经历了以下几个阶段：

1) 单业务探索阶段。该阶段主要是单业务系统上云尝试，围绕单个业务系统建设云计算平台，提升资源利用率和运营运维效率，典型项目包括温州轨道交通S1 线的综合监控、沈阳地铁iAFC 云和昆明地铁1、2 号线综合监控云化改造项目等[1]。

2) 线路融合阶段。该阶段以单条线路为上云单位，将线路内的多套系统统一上云，依托虚拟化技术，实现线路内多个专业间的资源共享和数据交互，典型项目包括金义东城际和深圳轨道交通6、10 号线中的线路云平台等[2]。

3) 线网融合阶段。该阶段将多条线路的安全生产业务系统进行融合，实现多条线路、多个专业间的资源与数据共享，统一地铁信息化系统[3]。

4) 体系规范化阶段。由中国城市轨道交通协会牵头组织，陆续发布了包括《市域快轨技术规范》[4]和《智慧城市轨道交通信息技术架构及网络安全规范》[5]等一系列城轨云相关技术规范，将城轨云建设上升到体系建设层面，典型项目有呼和浩特城轨云、太原城轨云等。

1.2 城轨云架构及特点

《中国城市轨道交通智慧城轨发展纲要》定义了“1 3 5 3 1”的城轨信息化总体架构，即打造一个门户，构建三个中心，拓展五大领域，依托三张网络，搭建一个平台[6]。该架构具有如下特点：

1) 在进行云化和数据化改造过程中，安全生产、内部管理和外部服务三个业务域既要充分考虑安全隔离，也要最大限度地实现数据的共享。

2) 稳定性、安全性和易用性是城轨云最重要的诉求，保障乘客的生命财产安全是首要的原则。

3) 城轨业务场景根据实际需求可由云、边、端构成，要满足云边协同场景诉求。

城轨云通过融合底层资源，打破信息孤岛，实现跨线路、跨专业、跨系统、跨功能的整合联动，提高地铁业务系统的资源利用率和可靠性。基于云架构底层，与人工智能、大数据、5G、物联网、区块链等新兴信息技术结合，可有效促进智慧城轨创新应用的诞生，如智慧车站、智慧运维、智慧乘客服务等[7]，使城轨业务更加灵活，服务更加智能。

1.3 城轨云面临的问题

当前，城轨云相关技术规范已相对成熟，但基础设施和应用系统缺乏核心技术，业务系统多采用Oracle或DB2 作为核心数据库，服务器采用POWER 小型机或X86服务器，操作系统采用AIX、RedHat或Windows等系统，对国外产品依存度高，关键环节存在“卡脖子”风险[8]。

为此，笔者提出面向城市轨道交通的自主可控云平台迁移方案，将城轨云基础设施逐步迁移到可掌控、可研究、可发展、可生产的信创平台，从根本上解决城轨业务系统的自主可控、安全可信问题。

2 平台迁移

2.1 平台构成

如图1 所示，城轨自主可控云平台，即依托信创软硬件体系搭建的云计算平台。按照业务性质和网络安全等级保护要求，划分为安全生产、内部管理、外部服务三大业务域，分别构建基础设施、IaaS、PaaS、SaaS 层。其中，基础设施层采用基于ARM、MIPS、Alpha、X86 等信创架构的设备组成；IaaS 层基于虚拟化能力，将基础设施层的设备进行统一抽象池化，提供虚拟机、裸机、容器、VPC、块存储等IaaS 服务；PaaS 层提供信创版本数据库、中间件、大数据、适配验证、开发测试等平台服务；SaaS 层承载具体的软件 业务系统，如安全生产域的ACC、ISCS，内部管理域的运营管理、企业管理，外部服务域的视频监控、公务电话等；建设标准规范体系和安全防护体系，保障城轨云的合规性。

图1 城轨自主可控云平台的逻辑架构 Figure 1 Logical architecture of independent controllable cloud platform of urban rail transit

将城轨业务系统迁移到自主可控云平台上，涵盖基础设施(如服务器、存储、网络、安全设备)、操作系统、软件(数据库、中间件等)的迁移，具体如表1 所示。

表1 自主可控云平台系统的运行环境对比 Table 1 Comparison of operating environment of independent controllable cloud platform

2.2 迁移原则

城轨业务系统迁移，应遵循“试点先行，先低后高，先前再后，关联同批”的原则。

1) 试点先行。选择典型业务系统进行小规模试点，运行稳定后逐步切换。

2) 先低后高。按照业务重要性的低高逐步迁移。3 个业务域中，建议先进行外部服务业务(如邮箱、公务电话)的迁移，再进行内部管理业务(如企业管理、运营管理)的迁移，最后进行安全生产业务(如ACC、PIS)的迁移。在一个业务域内部，也要按照业务的重要性由低向高的方向迁移。

3) 先前再后。对于前后端分离的业务系统，先迁移前端中间件，再迁移数据库，最后迁移后端应用。

4) 关联同批，制定具体的迁移计划时，要考虑各业务系统间的关联性，尽量把具有强关联性的系统放在同一批次里[9]。

2.3 迁移流程

业务系统迁移是一个复杂的系统工程，整个流程至少包括迁移评估与准备、资源规划、中间件迁移、数据库迁移、应用迁移、测试验证、应用上线等几个阶段，如图2 所示。

2.4 迁移准备

基于信息化建设项目的实践经验，针对业务系统的业务属性、访问量、开发语言、依赖组件等指标，设计业务系统迁移难度评分表(见表2)和业务系统迁移难易度说明表(见表3)。

图2 迁移流程 Figure 2 Migration flowchart

表2 业务系统迁移难度评分 Table 2 Scoring of difficulty for business system migration

表3 业务系统迁移难易度说明 Table 3 Difficulties for business system migration

以某乘客信息系统为例，该系统为重要类业务(3分)，并发访问量较小(1 分)，开发语言Java(1 分)，中间件WebLogic(3 分)，数据库MySql(1 分)，操作系统CentOS(1 分)，得分为3+1+1+3+1+1=10 分。依照迁移难易度说明，该系统易于迁移。

根据城轨各业务系统的特点和发展现状，分析其迁移难易度，综合评估确定迁移业务系统的业务范围、迁移难易度，制定迁移整体计划，并将整体计划细化拆分，梳理出每个应用系统的详细迁移计划。注意事项如下：

1) 由于大部分应用系统迁移时需要中断正常业务，因此迁移时间最好在业务压力较小的晚间或周末进行，并确保业务应用原厂工程师、迁移实施人员以及业务系统用户三方均到场。

2) 由于迁移并不能保证一次性成功，所以在开始迁移之前，应对待迁移的业务数据进行完全备份，以保证迁移过程中意外情况的数据完整性恢复。

3) 在新迁移的业务系统正式上线之前，原有业务系统的中间件、数据库、应用系统等组件务必完全保留，不要随意删除。

3 实施路径

城轨云平台承载的3 个业务域是根据等保要求进行安全隔离的，虽然承载不同的业务系统，但其在IT层面依赖的基础软硬件大同小异，通用的迁移实施路径如下。

3.1 资源规划

收集待迁移业务系统信息，如表4 所示。

表4 业务系统信息 Table 4 Business system information

1) 迁移业务资源需求总量的计算方法：CPU/内存/存储需求总量 = 每个业务系统所需的CPU/内存/存储×平均利用率总和，单台服务器CPU 总量 = CPU 个数×CPU 核心数×单核CPU(GHz)[10]。

2) 根据计算推导集群配置：需求的服务器数量 = (CPU 需求总量/单台服务器CPU 总量)×1.25(预留25%资源)+1(集群冗余)，每台服务器内存配置 = 内存需求总量/需求的服务器数量。

3) 每个业务系统所需虚拟机的规格：单个业务系统所需的vCPU = 单个业务所需CPU(GHz)×CPU 平均利用率/单核CPU(GHz)，单个业务系统所需的内存/存储 = 单个业务所需内存/存储×平均利用率。

根据以上公式，可推算出迁移业务系统所需的集群规模(集群节点数、服务器配置和存储配置)，以及单个业务所需的虚拟机配置。

在迁移业务系统时，根据源端系统配置情况，规划目的端资源配置(CPU、内存、磁盘以及网络IP 等)，默认和源端保持一致。当后续业务负载变化需要扩/缩资源时，可在云环境修改相应的虚拟机配置。某项目中典型业务系统的配置信息如表5 所示。

3.2 中间件迁移

城轨业务用得比较多的中间件是Web 中间件和消息中间件。中间件的迁移，主要是将应用系统与信创CPU 环境下的目的中间件(如中创、金蝶、东方通等)进行对接，将原有业务系统的中间件配置参数在目的中间件重新设定。以从 Weblogic 迁移到中创InforSuite AS 为例，相应的配置信息对应如表6 所示。

表5 业务系统配置信息 Table 5 Configuration information for business system

表6 Weblogic 与InforSuite AS 配置信息对应 Table 6 Configuration information correspondence between Oracle Weblogic Server and InforSuite Application Server

配置信息迁移完成后，由中间件厂商技术人员与应用系统供应商技术人员共同进行中间件功能验证、测试及性能调优。

3.3 数据库迁移

城轨业务系统使用的数据库主要是Oracle 和DB2，数据库厂商技术人员利用数据迁移工具，可完成源数据库到达梦、人大金仓、南大通用等数据库的数据结构迁移工作，包括表、索引、视图、序列等对象，并手工完成触发器、函数、存储过程的迁移。将应用系统与目的数据库进行对接，修改应用系统中的数据库操作部分源码，以满足目的数据库的方言要求。

完成迁移后，数据库厂商技术人员配合应用厂商负责人进行数据完整性校验。

3.4 应用迁移

需要根据不同的业务系统开发语言，制定适配迁移的具体方案。目前，大部分开发语言能够支持迁移，但迁移复杂度不同，具体可应用迁移适配策略表，如表7 所示。

表7 应用迁移适配策略 Table 7 Strategy of application migration adaptation

3.4.1 解释型语言应用迁移

对于Java、PHP、Python 等解释型语言，仅需在新的CPU 架构环境下重新编译即可使用。以Java 为例，其迁移过程如下：

1) 获取源码：获取应用系统的Java 源码；

2) 准备编译环境：选择目的CPU 架构(如FT、龙芯等)的编译环境，建议选择jdk1.8 及以上版本； 3) 重新编译：将Java 源码编译成类文件； 4) JVM 运行：启动应用程序进行功能调试。

3.4.2 编译型语言应用迁移

对于C、C++、Go 等编译型语言，需要对依赖库、操作系统、平台、数据库相关的兼容适配进行改造，并进行重新编译，才能完成迁移。以C 语言为例，其迁移过程如下：

1) 获取源码：获取应用系统的C 源码；

2) 准备编译环境：选择目的CPU 架构(如FT、龙芯等)的编译环境，建议选择gcc7.3 以上的版本；

3) 编译脚本修改：使用开源软件源码中的cmake 或autoconfig 脚本生产makefile，需要修改适配至目标架构；

4) 编译：执行makefile 进行编译；

5) 替换依赖库：通过开源软件的readme 文件、自身软件产品的依赖库、编译时的so 库缺失或链接错误，重新编译或替换依赖库；

6) 编译优化：对于不同的架构，相同的编译参数可能带来性能的差异，需要根据不同架构平台，增加或修改编译选项；

7) 发布应用：生成应用的安装包或镜像。

完成应用程序的迁移后，可以采用原有的中间件、数据库等其他组件，进行初步的测试，以保证应用系统可以正常使用。

3.5 测试验证

迁移过程结束后，打开相应的云环境资源(如虚拟机、裸机等)，以检验迁移完整性以及业务能否正常运行。

在业务系统正式上线前，需检测其功能需求、设计方案、性能指标等是否可以达到正常的运行要求。在独立的测试验证区域，对业务系统进行完整充分的测试，包括但不限于单元测试、集成测试、系统测试、压力测试、稳定性测试、安全性测试以及云资源的扩/缩测试等[11]，在确保业务软件运行正常的前提下，对迁移后的业务进行问题修复及性能调优。

3.6 应用上线

在业务系统迁移完成后，需要进行至少3～6 个月的试运行。通过试运行，发现应用系统存在的问题，以便进一步完善和修复。

在业务系统试运行期间，将原有环境保留一段时间，待试运行通过后，新环境正式启用上线。原环境根据实际情况，保留一段时间之后再清理回收。

4 应用案例

4.1 项目简介

在某信创云项目中，笔者采用云平台统一管理飞腾、鲲鹏、龙芯等国产CPU 设备，协助业主完成100+套应用系统的技术分析、编译移植、应用上云、性能调优，实现了操作系统由RedHat 迁移到UOS、麒麟操作系统，应用中间件由Weblogic 迁移到中创InforSuite AS 企业版，数据库由Oracle 迁移到达梦数据库，提供了从IaaS 到SaaS 的全面自主可控云数据中心的管理和服务功能。

通过自主可控的云平台，提供稳定、可靠、弹性、敏捷的云服务，统一提供计算资源、存储资源、网络资源、安全资源、业务应用、运行维护等云服务，提高了资源利用效率，降低了总体使用成本。

4.2 经验总结

总结项目迁移过程中的典型问题及解决方案，如表8 所示。

表8 典型问题及解决方案 Table 8 Solutions to typical problems

5 结语

城轨云作为新基建的重要组成部分，在当前的国际形势下，信创迁移适配的需求逐渐迫切。除本研究提到的方案外，自主可控云平台的业务系统迁移还需考虑系统的性能、稳定性、复杂度、应用拆分、程序改造等多项因素，是一个循序渐进的系统性工程。因此，建议在既有城轨云的基础上，构建小规模的自主可控云环境进行试点，待解决方案和迁移技术成熟后，再分阶段有序地进行规模化迁移。