城市轨道交通系统迁移至云平台方案研究
2021-01-06林小杰何跃齐
林小杰,何跃齐
(1. 天津轨道交通运营集团有限公司,天津 300392;2. 北京城建设计发展集团股份有限公司,北京 100045)
当前,中国城市轨道交通(简称:城轨)的运营规模逐渐扩大,根据轨道交通网最新统计,截至2019 年底,我国共开通城轨运营线路208 余条,线路规模达6 882.13 km[1]。在城轨网络化运营环境下,需要实现各线路业务流程及操作规则的统一管理,实现业务管理的标准化管理,同时要求业务应用统一部署、数据集中管理。近年来,城轨信息化提出了更高效、更节能的要求,因此,构建信息交互更加频繁、实时性更高、可共享的城轨云需求应运而生。为应对这种趋势,《中国城市轨道交通智慧城轨发展纲要》(简称:《发展纲要》)于2020 年3月12 日正式发布实施[2]。
目前,国内采用云计算技术的城轨线路基本都是以新建线路为主;而对既有城轨线路业务系统虽有更新改造移至城轨云的迁移计划,但多未有具体实际方案付之实施。本文基于天津市中心城区华苑控制中心二期工程这一城轨系统云迁移实例,提出城轨业务系统统一逐步迁移至城轨云的渐进式方案以供大家参考。
1 城轨云建设模式与云迁移背景
1.1 城轨云建设模式
城轨云平台的建设主要呈现以下4 种建设的模式:
(1)专业云模式。以温州S1 线和郑州自动售检票(AFC,Automatic Fare Collection)线网管理中心项目为代表的构建单业务系统专业的云平台。温州S1 线搭建了城轨综合监控系统(ISCS,Integrated Supervision and Control System)云平台,将其中的ISCS 与云平台进行结合,使原本分散孤立的自动化系统联结为一个有机的整体,实现信息互通、资源共享、高效联动[3],也验证云平台的经济效益、方案、架构、兼容性、可靠性等。郑州地铁于2019 年5 月20 日开通运营了城轨AFC 系统云平台,将线网清分中心系统和AFC 系统的线路中心进行深度融合[4],集中部署在该云平台上。
(2)线路云模式。以呼和浩特地铁1 号线、2号线和昆明轨道交通4 号线为代表,构建单线路多业务系统的融合云平台。呼和浩特地铁在1、2 号线构建了城轨云平台,为城轨AFC、乘客信息系统(PIS,Passenger Information System)、ISCS、列车自动监控(ATS,Automatic Train Supervision)系统等多业务系统提供基础设施即服务(IaaS,Infrastructure as a Service),满足1、2 号线的建设要求,并预留将来3、4、5 号线的进驻能力[5];昆明轨道交通4号线云平台深度集成了20 余个城轨业务系统,实现了信息网络平台互联[6]。
(3)线网云模式。以天津地铁、广州地铁线网管理或企业管理私有云逐步扩充其它业务。天津地铁在中心城区华苑控制中心二期工程中,规划构建城轨线网级云平台,拟将线网级应急指挥、运维管理、数据中心、乘客服务等各业务系统迁移至该云平台,并预留将来线路云对接条件;广州地铁采用了VMware 技术构建企业管理云,探索采用企业管理云去扩充其他业务。
(4)融合云模式。构建多线路多系统的融合云平台,以深圳地铁正在建设的网络运营控制中心二期和武汉轨道交通网络信息化建设示范工程项目为代表。深圳地铁在网络运营控制中心二期工程中,规划构建城轨云平台,计划将城轨管理、生产、对外服务等业务系统均部署其中[7];武汉轨道交通网络信息化建设示范工程项目采用基于云平台、大数据的新信息系统架构,构建异地双活的数据中心,实施新建线路和既有线的信息系统全部纳入和迁移到云平台的技术方案。
以上是城轨云呈现的4 种建设模式,其中,第4 种多线路多系统的融合云平台符合《发展纲要》关于城轨云的建设要求,具有重要推广意义。但该种模式对于云平台承载能力、各业务系统并发能力提出了极大的挑战。这需要从整体上对云平台进行规划,同时需合理部署整个云平台的资源,实现均衡配置。
1.2 城轨系统云迁移背景
国内较多的城轨业务系统仍主要是以业务为中心独立构建烟囱式架构系统,再通过多系统之间的对接实现业务系统之间的协调管理和数据管理。这种非云平台架构中,存在业务系统分散、网络架构复杂、基础设施分散,多个系统对接消耗存储及计算资源、无法实现数据共享、无法实现存储共享等诸多问题;数据库系统基于小型机、SAN 存储以及多个节点的Oracle 集群对外提供服务[8],会导致系统整体运行速度慢、单点故障导致数据库不稳定,进而导致业务系统无法提供有效服务的严重问题[9]。
应对以上现状,文章提出将上述城轨业务系统统一逐步迁移至城轨云的渐进式方案,使城轨云能够承载ISCS、AFC、PIS、门禁系统、闭路电视监视系统等多业务,完成业务与数据的平滑过度,实现资源共享,按需调配,弹性扩展,为业务紧密联动和大数据分析打下基础。
2 城轨系统云迁移原则及评估流程
云计算技术的不断发展及普及,从网络建设、架构设计、业务运营和系统运维等多个角度对烟囱式传统架构信息系统建设产生了深远影响[10]。传统架构注重硬件的高可用性及纵向扩展能力,而云平台通过分布式架构实现横向扩展能力及高可用性,集成了备份、监控、高可用性、审计等基础运维服务。
2.1 系统云迁移原则
从传统烟囱式信息系统IOE 架构(指传统计算机系统中类似基于IBM 公司小型机、Oracle 公司数据库以及EMC 公司存储的系统架构)向云平台架构转移的过程中需要考虑以下几点问题:
(1)可用性。脱离小型机及高端存储的高冗余机制,采用基于PC 服务器的分布式架构云计算平台能否做到高可用[11]。
(2)一致性。Oracle 基于实时应用集群及共享存储可实现物理级别一致性[12],云数据库可否达到同类效果。
(3)高性能。高端存储的I/O 能力很强,基于PC 服务器的云数据库可否提供同样、甚至更高的并发能力[13]。
除此之外,针对业务系统是否适合迁移至云平台,需要根据业务特性、特点、方位等多方面进行评估,具体评估内容,如表1 所示。
表1 业务系统评估
2.2 系统云迁移评估流程
从现有业务系统向云平台迁移时需要根据系统类型及重要性选择合适的迁移方式,城轨业务系统的云迁移过程应根据实际情况及严格的评估流程进行评估。评估流程,如图1 所示。
3 城轨系统云迁移策略分析
目前,城轨业务系统的普遍现状是业务逻辑与数据库之前具有强耦合性,大量采用Oracle 的特有语法PL/SQL 实现,若全部对其改造,造成开发成本过高、周期过长,短期内无法实现云迁移等诸多问题,因此为确保整个系统的平滑过渡,采用渐进式云迁移策略来解决城轨业务系统的云平台部署问题。具体的策略如下:
(1)结构化数据云迁移,非结构化数据、图片等数据暂不迁移。
(2)部分统计分析业务云迁移,诸如安检、票务等业务,将这类业务中的统计分析功能优先实现云迁移。
(3)周边非核心业务访问业务云迁移,依赖系统数据(如线网监控、指挥调度、生产管理)周边业务系统访问全部迁移至云平台上实现数据库访问。
图1 系统云迁移评估流程
4 城轨系统云迁移方案及架构实施
以天津中心城区华苑控制中心二期工程为例,结合线网中心系统各系统的现状,采用部分云迁移的方案,以下分为3 步对系统进行渐进云迁移。
4.1 结构化数据云迁移
将结构化数据在云平台上存储3 份,分别存储在关系型数据库、分析型数据库及大数据计算服务。
(1)关系型数据库存储在线业务库结构增量数据,对外提供高并发量、简单查询服务。
(2)分析型数据库通过实时同步服务从关系型数据库接收实时增量数据,对外提供并发量较小的实时统计分析查询。
(3)大数据计算服务主要对外提供离散数据分析处理,大数据计算服务中的数据增量可通过定期抽取或实时同步的方式从关系型数据中完成数据同步。具体实施的架构,如图2 所示,图2 中所指核心业务及周边业务是根据具体、符合此种业务与逻辑关系的情况而定的,云上业务系统和云下业务系统在线业务库没有任何数据或接口间的调用关系,云上业务的访问均由关系型数据库支撑。
图2 结构化数据云迁移方案示意
4.2 异构数据库改造云迁移
异构数据库改造云迁移主要包含2 部分。
(1)依赖于原有系统提供数据支持的周边业务改造云迁移。
(2)原有的系统部分统计分析功能改造业务云迁移。
异构数据云迁移的前提条件是充分调研平台系统各个业务模块之间的调用关系,优先迁移没有业务调用关系或业务调用关系较少的业务模块,并且需要根据业务访问的特点合理选择关系型数据库、分析型数据库、大数据计算服务,依照从简单到复杂的原则逐步完成整个在线业务系统的异构改造云迁移。实现云迁移的业务处理逻辑和数据访问功能全部在云平台完成。具体实施的策略,如图3 所示。
图3 异构数据库云迁移方案示意
4.3 数据同步云迁移
完成前两步的云迁移改造后,利用分布式数据库服务继续对业务系统进行优化。主要涉及2 个方面的内容。
(1)使用分布式关系数据库实现关系型数据库节点的动态可扩展性。
(2)基于企业级分布式应用服务进行微服务化改造。
最终实现业务系统在云端的部署状态。云上的最终实施架构以及迁移后城轨云平台最终架构如图4、图5 所示。
图4 云迁移后业务逻辑
图5 云平台迁移前后架构对比
天津中心城区华苑控制中心二期工程项目正处在实施阶段,从云平台迁移前后架构对比来看,项目拟通过城轨业务系统及数据的云平台迁移。
(1)提高资源利用率,降低建设运营成本。
(2)实现对各条线路的统筹协调、统一运维,并借助云平台的高可靠、可扩展性、资源复用、数据共享等优势,不断提升天津城市轨道交通的运营信息化管理水平,提高运能、降低成本。
5 结束语
城轨云平台是信息化时代城轨运营管理的重要手段,建设城轨云平台可以显著提高资源的利用率及控制中心的运营效率。但云迁移并非易事,除了本文所提出的方面之外,还需要考虑的因素很多,比如成本优化、额外的安全隐患以及迁移后的业务资源消耗等,这些都需要具体问题具体探讨[14]。切忌为了迁移而迁移,应遵循与其他复杂项目一样的原则,要有系统的规划和适当的准备。本文提出的城轨业务系统统一逐步迁移至城轨云渐进式方案,不仅可以降低云迁移过程的风险,还可以帮助问题追踪,为目前国内广大城轨业务系统迁移云需求提供具体的借鉴与参考。