融合虚拟机和容器的地铁MLC系统

方晖 蒋坚迪 姜富强

（1.宁波市轨道交通集团有限公司 浙江省宁波市 315040 2.浙江浙大网新众合轨道交通工程有限公司 浙江省杭州市 310051）

近年来，基于虚拟化的云计算技术风起云涌，大有横扫一切传统后台系统的态势。最早，公有云一枝独秀，公有云提供商希望后台系统都运行在公有云。但是实际上，出于安全、可控等因素，大量企业新建的应用系统部署的是私有云，或者混合云。然而，当基于虚拟化的云技术被企业逐渐接受后，容器和容器云技术又席卷而来。容器类似虚拟化技术，也实现了资源隔离，但更加轻量级，结合K8S 等编排技术，容器云能轻松实现秒级部署和伸缩。但是，容器本身无法替代虚拟机，公有云、私有云、混合云、容器云等技术，必然长期共存。技术需要以正确的方式服务社会，在设计地铁MLC系统时，必须考虑各种云化技术的技术特点，根据项目场景进行合理规划。

1 地铁MLC系统

对整个地铁MLC系统进行分析，可以得知地铁MLC系统即可以完成运营多条线路的共同管理，是线路中心，同时更是线路的组成核心部分。在MLC系统中，该运营主体所管辖的线路通过同一个MLC 与ACC 接口，确保能够真正实现轨道交通网络运营化的需求以及运输服务。在目前的MLC系统中，以北京市为例，北京市已然构成MLC系统，包含两个在建MLC系统，一个运输MLC系统。这三个MLC 运输系统隶属两家运营公司，为地铁的运行提供良好的建议以及改良措施。

MLC系统在建立过程中，蕴含丰富的逻辑架构，其包含备份子系统、报表子系统、历史数据子系统、系统管理子系统、融合数据库。随后，在交易数据处理子系统中，对设备运行状态进行监控，返回至业务处理子系统，以便完成整个数据的传输。在MLC 的系统软件架构中，结合虚拟机，其可以完成系统功能，包含但不限于访问控制系统、监督数据备份、网络管理、时钟同步、防病毒管理、参数管理。而在业务应用层中，其包含了报表应用、数据运营、管理监控。而在数据储存层中，其包含了生产数据库以及历史数据库。在业务处理层中，其包含了业务处理、交易处理以及设备状态、客流监视。而在外部通讯层中，其包含了SC 接口以及ACC 接口。

MLC系统包含了全方面的运营体系，其不仅可以对地铁线路进行统一监控，同时更可以就以往的监控模式完成点、线、面的立体监控。就整个设备的图标进行表达，分析设备出现异常声音完成报警提示，并就设备的属性敏感度进行突出显示。

2 地铁MLC系统现状

分析地铁MLC系统现状，可以得知目前其城市交通轨道大多数在建设过程中均按照“一线一中心”的传统设计方法进行构建。此方案在运行时，根据整个系统构建五层体系：

其一层，为清算系统；

其二层，则是整个项目中心；

其四层，是车站终端设备；

而第五层，就是车票。

按照五层架构，形成全新的建设方案，以确保整个地铁运行能够精准、合理。但在后续发展中，此种方法仅适用于初级线路或少数线路，若整个城市发展步伐加快，以一线城市北京、深圳、上海、广州为例，城市规划建设均设置MLC系统，这将会导致投资以及其资源出现极大浪费。针对于整个计算系统层面，有可能会导致清算层面收集到的必要信息数据较少，无法确保在数据清算层面能够实现线路共享，无形中增加了运行管理、票务管理、维修管理的压力，使整个管理的效率严重降低。在对MLC系统进行建设过程中，有必要建设合理的系统模式，以便对整个MLC系统展开分析研究。

3 地铁MLC云化设计

地铁MLC 的云化设施层运行于硬件资源之上，并服务于上层软件，因此云化方案的设计，必须考虑整个系统的软硬件情况。地铁MLC系统的硬件包括网络设备、通用服务器、SAN 存储设备等。其中，单台服务器的性能通常都比较强大，云化设施层必须能够充分利用其硬件性能。软件方面，现在的地铁MLC系统，通常包含大量基础中间件，且业务系统采用微服务设计，每个微服务实例需要的资源不多，但是数量庞大。

基于以上软硬件特点，宁波MLC系统的总体云化方案如图1。

图1：宁波MLC系统的总体云化方案

图1 中，核心数据库直接部署在物理机上。MLC系统中的核心数据库承载了大量的IO 压力和部分计算，在裸金属上直接部署，有利于发挥其最大性能。同时，Oracle、DB2 等数据库，均自带高可用方案，不需要云平台支持。然后，在剩余物理机上划分虚拟机。其中一部分虚拟机运行中间件，这些中间件采用集群或者主备部署，不与具体业务绑定，只向业务软件提供通用服务。另一部分虚拟机部署容器云。容器云基于Rancher 和K8S，包含若干管理节点、镜像仓库节点，以及最重要的K8S 工作节点。其中，在地铁MLC 场景下，管理节点的数量基本固定，对资源的需求也不高，一般2 核CPU、4G 内存即可满足要求。K8S 工作节点分配的资源可以尽量放大，比如一台物理机平均划分两个虚机，因此，K8S 工作节点的虚机数量也不多，大约是物理机数量的1-2 倍。最后，K8S 工作节点中运行多个K8S Pod，每个Pod 执行一个MLC 业务进程。

可以看到，以上方案不是纯粹的裸金属方案、虚拟机方案、容器方案，甚至也不是在虚拟机上统一运行容器的方案，而是各个方案的融合。该方案是综合考虑MLC 项目的实际因素的结果，下面逐条分析。

采用三种测量工具收集研究数据；(1)The Quick Placement Test(QPT),(2)The Vocabulary Levels Test(Nation,1990),and (3)The Productive Vocabulary Levels Test(PVLT)(Laufer&Nation,1999)。

（1）本方案降低了虚拟机的数量，提高了资源利用率。由于采用微服务设计，MLC 业务系统需要几百个服务实例，如果采用纯虚机方案，则需要划分几百个虚机，而每个虚机都需要运行一整套操作系统，会造成大量的资源浪费。

（2）本方案利用K8S 编排功能，简化了软件的部署，而镜像仓库中则包含了MLC 各服务的所有历史版本，可通过命令实现快速的版本升级和回退。

（3）本方案把IO 密集的、基础性的中间件部署在虚机上，而不是部署在容器中，保证了中间件的性能。这类软件部署好之后，不会轻易修改配置、更新版本，不存在升级麻烦的问题。

（4）本方案利用Keepalived 的VRRP技术和nginx，以高可用的方式向对接MLC 的外部系统，发布访问接口。通常，K8S 通过Ingress 将容器云中的服务暴露到外部，但是K8S 本身不提供虚IP，Ingress 的访问地址只能是单点的。在公有云环境中，通常由公有云服务商的负载均衡器来保证Ingress 高可用，而本方案通过Keepalived 和nginx 完成相同的功能。

需要说明的是，以上方案最大可能的压缩了虚机需求，但是无法完全规避，原因如下。

首先，各类中间件一般都是多服务节点组成集群，为了隔离故障域，要求每个服务节点运行在不同的物理机上，而且最好是不同机架的物理机上。比如Kafka 集群，通常需要5 或者7 个节点，每个服务节点占用不同的物理机。但是，根据MLC 的数据压力，每个Kafka 服务节点需要的资源，大约是6 核心、32G 内存，但是单个物理机一般是几十核心、几百G 内存。如果每台物理机只跑Kafka 服务，则极度浪费资源。但是，如果在一台物理机上部署多类服务，比如同时跑Kafka 和Redis 缓存，两类服务之间难免会争夺CPU、内存、磁盘、网络等资源，无法保证各自的服务质量。在运维过程中，修改一个服务的配置，也容易导致对另一个服务的误操作。因此最佳的方式仍然是，在物理机上划分若干虚机，在虚机中各自运行中间件服务。

其次，虽然K8S 工作节点直接运行在裸金属上也可以，但考虑到资源划分的灵活性，一般还是建议划分虚机。比如一台物理机，可以把30%的资源划分为三台虚机运行中间件，剩余70%的资源划分为一台虚机运行K8S 工作节点。

但是，总体而言本方案中的虚拟机的数量较少，因此企业可根据自身技术能力选择合适的虚拟化方案，既可以选择商业产品，也可以选择采用开源技术，比如KVM。

4 非性能指标分析

运行在虚拟机内的中间件，均采用集群或者主备模式工作，即使单节点失败，系统仍然能够正常运行，此时可以通过把虚拟机迁移到新的物理机来修复。系统扩容需要人工介入，新增虚拟机，调整中间件参数，一般需要若干小时。但考虑到维护期间业务正常执行，且地铁MLC 中，一般是在引入新业务或者开通新线路时才进行中间件扩容，此维护时间可以接受。

对于运行在容器的业务软件，K8S 会自动监测各个Pod 的执行情况。如果K8S 发现失败的Pod，会自动在可用的工作节点上重启该Pod，通常秒级完成，保证业务可用。各个服务的扩容和缩容，既可以采用手工修改K8S 的编排文件、增加Pod 的副本的方式，也可以采用让K8S 根据各个Pod 的负载情况，自动调整Pod 的数量的方式。

5 MLC系统运行优势

分析整个MLC系统的运行优势，其具备以下四点：

（1）完全适应系列化标准需求。随着整个地铁MLC系统的运营，在全新的监管体系下，可以确保地铁相关部门能够共同参与制定全新的规范措施，以保障整个MLC系统能够实行标准化运行，为后续中心建设提供全新的基础。充分实现建设标准化成果，具有非常重要的现实意义；

（2）满足网络化运营需求。针对于实现MLC系统的城市，均历经了单条线路的转换过程。因此，在后续建设中，为了避免其弊端，更好的满足运营化需求，MLC 建立完毕后可实现一卡通管理方案，使乘客在各线路之间可以达成无障碍换乘，确保能够及时的完成地铁线路的管理，以便实现互联互通。就整个线网建设以及运营角度，考虑进行MLC系统项目建设具有极佳的重要性；

（3）节省项目建设投资。采用MLC系统后，整个项目的总投资量将会显著减少，以便于后续完成地铁的运维建设；

（4）提高整个系统经济效益。通过建立MLC系统，其可以最大限度地实现资源共享，降低运营成本。在现有的采购上，可以按照我国供货商的特长选择商品自行组成系统，降低其建设投资，做到投资利益最大化。

6 总结

随着技术的成熟，虚拟化、容器最终会变成和通用服务器一样，成为大部分企业应用系统依赖的基础设施。本文结合地铁MLC系统，提出了企业应用系统云化的一个可用方案，可为类似系统提供参考。