铁路客票电子票库系统服务化改造设计与应用

2024-05-07戴琳琳阎志远李晓楠

铁路计算机应用 2024年4期

李杨，戴琳琳，阎志远，江琳,，李晓楠,

（1.中铁程科技有限责任公司，北京 100081；2.中国铁道科学研究院集团有限公司电子计算技术研究所，北京 100081）

经过20余年的发展，中国铁路客票发售与预订系统（简称：客票系统）形成了覆盖线上（即12306互联网售票系统，包括12306网站及移动终端App）和线下全国3 000多个客运车站的超大型票务系统[1]。铁路客票电子票库系统（简称：电子票库）作为客票系统的核心业务系统之一，承担着旅客从购票、支付、退改签、乘车、进出站和换乘等全流程信息化服务中的交易事务环节。电子票库通过数据库存储过程、分布式扩展等技术，良好地承担了近年来客票系统的巨大业务压力，随着客票系统交易量的日益增长及复杂度的日益增加，为进一步提高电子票库的扩展能力，实现业务的快速迭代，减少研发、部署和维护的复杂性，基于服务架构，对当前电子票库进行了改造[2]。本文阐述了改造后的电子票库架构、关键技术和试运行效果。

1 电子票库服务化改造方案

1.1 电子票库架构概述

当前，电子票库支撑线上互联网售票、线下终端（包括窗口、代售点、自动售票机等）售票，是铁路电子客票的底层核心系统，是线上、线下服务一体化的重要环节。当前电子票库架构如图1所示。

图1 当前电子票库架构

1.1.1 客服内/外网

客服内/外网是支撑12306互联网售票系统的独立网络分区。旅客的线上购票请求通过客服内/外网中的12306网站和移动终端App服务、排队、风控等环节进入客票网，经过客票网中间件控制层后在电子票库进行交易处理。

1.1.2 客票网

旅客的线下购票请求通过客票网里的铁路局集团公司、车站线下终端接入中国国家铁路集团有限公司（简称：国铁集团）中间件控制层后，到达电子票库进行交易处理。

电子票库分为售票节点和退改签节点。售票节点主要承担售票、支付、候补等业务处理和数据存储，并将数据实时同步到退改签节点；退改签节点主要承担改签、退票和检票等业务处理和数据存储，并将数据实时同步到缓存集群，提供大并发高速查询服务。

目前，电子票库采用商业数据库Sybase[3]，并通过分库、分表支持横向扩展，可以将业务请求均衡地分散到很多个数据库节点上进行处理，提高了电子票库的处理能力。由于电子票库仍然采用数据库存储过程实现业务逻辑，这种数据与业务紧耦合的方式[4]，一定程度上制约了电子票库的扩展灵活性和业务治理水平。

1.2 基于服务架构的改造设计

为了实现业务与数据库的彻底解耦，将原本在Sybase数据库存储过程中的业务逻辑抽离出来，可提升业务功能的快速迭代能力，提高业务复用能力和业务治理水平[5]。本文基于业界主流的业务治理模式——服务架构，对电子票库进行了架构改造设计，如图2所示。

图2 新电子票库架构

将现有Sybase+存储过程的数据库集群，逐渐改造为电子客票业务服务集群。新电子票库架构主要分为接入层、应用层、数据层和总体支撑。

（1）接入层：负责电子票库集群内各应用服务的导航、路由和管理。

（2）应用层：基于领域驱动设计对电子票库业务流程进行重构，提炼并标准化基础业务逻辑，形成可复用的核心组件，进而构建了公共基础服务和业务服务。

（3）数据层：进行服务改造后，数据存储更加灵活，可继续采用商业数据库，也可以根据实际需求采用开源或者国产数据库。

（4）总体支撑：主要包括监控统计和服务治理[6]。为整个电子票库集群提供了服务注册、注册中心、配置中心、动态扩缩容、熔断限流、持续交付与部署等支撑。

2 服务化改造关键技术

服务架构相对于存储过程模式更为复杂，电子票库作为客票系统核心关键系统，在改造过程中须保持业务的稳定和连续，以下针对改造中的若干关键技术进行阐述。

2.1 适配技术

电子票库作为客票系统的核心业务系统，通过与众多上下级系统及同级子系统进行交互和协同共同承担客票业务。因此电子票库在进行服务化改造后，需要进行适配，继续保持与外部系统的交互，达到电子票库在客票系统中的业务无缝衔接。适配技术主要分为3个方面，如图3所示。

图3 新电子票库系统适配示意

2.1.1 API适配

应用程序编程接口（API，Application Programming Interface）适配。如图3左上方所示，API接口分超文本传输协议（HTTP，Hypertext Transfer Protocol）和传输控制协议（TCP，Transmission Control Protocol）2类接口，是用于支撑电子票库的上级系统接入。通过约定报文规范，进行报文格式化、序列化完成适配，适配后，线上票务交易系统、线下票务交易系统可通过中间件基于多种网络协议进行业务请求，管理控制也可通过TCP进行业务管理。

2.1.2 数据存储适配

如图3左下方所示，数据存储主要为数据库、缓存、文件系统等数据资源，通过服务的内置持久化框架或者数据接口进行研发适配。实现对Sybase数据库、其他类型数据库、Redis缓存、其他缓存、文件系统的访问。

2.1.3 同级关联系统适配

如图3右半部分所示，同级关联系统主要包括客票系统的智能运营维护、定时任务、监控系统、业务审计、服务治理、安全扫描等系统。通过对Web适配、运营维护管理适配、报警通知适配、日志适配和技术支撑适配等技术进行研发，实现电子票库服务化改造在客票系统中的无缝迁移。

2.2 数据库迁移技术

在新电子票库部署完毕之后，须进行数据迁移[7]，整个数据迁移过程包括数据迁移评估、结构迁移、数据迁移和数据校验等过程[8]，如图4所示。

图4 数据库迁移流程

2.2.1 数据迁移评估

如果目标数据库与源端数据库为同构数据库，则主要对迁移数据量、存储空间、迁移时间和工作量进行评估；如果目标数据库与源端数据库为异构数据库，则在上述评估内容的基础上增加对数据库的函数、索引、序列，以及数据类型、字段长度等对象的兼容性评估，并评估是否存在显性或隐性的迁移风险。

2.2.2 数据库对象迁移

将包括表结构、索引、序列等在内的数据库对象进行迁移，支持根据迁移目标数据库类型进行数据库对象的定义转换。

2.2.3 数据迁移

全量数据迁移及后续的增量数据迁移，是为保障迁移过程中源端数据库的数据变动能够及时同步到目标数据库中，确保两端数据库的数据一致性[9]。由于全量数据迁移过程持续时间较久，期间源端数据库仍有新业务数据写入，为保证数据迁移的一致性，在全量数据迁移之前，将启动对增量数据监听，将增量变动数据存储在本地存储中。当全量数据迁移完成后，对增量数据回放，将增量数据同步到新系统数据库中。

2.2.4 迁移校验

分别对源端数据库和目标数据库进行全量数据和增量数据抽取，按行生成哈希值，对哈希值进行比较。如果哈希值一致，则两端数据库数据一致；如果哈希值检测数据不一致，则根据不一致的哈希值位置，找到相应数据记录进行修复和数据补偿。

2.3 业务流量迁移技术

为实现业务流量迁移，以及当前电子票库向新电子票库平滑过渡，将2种架构的电子票库作为同等实例节点并行在生产系统中，通过中间件将业务请求逐步转发到新电子票库上，实现业务流量的迁移。具体业务迁移如图5所示。

图5 电子票库服务化改造流量迁移

业务流量迁移技术实现多种迁移规则配置，支持按用户迁移、按车次迁移等，可支持新老系统的灰度迁移与并行运行。同时，数据实时同步备份到当前电子票库，在服务集群试运行验证期遇到故障时，可及时切回当前电子票库，降低风险。

3 实施效果

改造后的电子票库充分利用了服务架构的优势，实现业务灵活扩展，并有效地提高处理能力，试运行的具体效果体现如下。

3.1 扩展性方面

本文以AKF立方体扩展模型作为对电子票库服务化改造后的扩展性评估，AKF立方体也叫做Scala Cube，它在《The Art of Scalability》一书中被首次提出[10]，AKF 把系统扩展分为3个扩展维度：X轴、Y轴和Z轴。X轴表示无状态实例的水平扩展，Y轴表示功能或者服务的扩展，Z轴表示散列块或者数据分片扩展。

在服务改造前，电子票库由于采用存储过程实现业务逻辑，业务逻辑紧耦合在有状态的数据库里，如图6（a）所示。

图6 电子票库AKF立方体扩展评估对比

（1）在X轴方向不具备扩展能力；

（2）在Y轴具备2层的业务划分（售票层和退改签层），具备一定的扩展能力；

（3）在Z轴上基于客票系统强大的动态分区系统具备较强的扩展能力。

进行服务化改造后，新电子票库对业务逻辑和数据存储进行了解耦。如图6（b）所示。

（1）在X轴上新增了无状态业务实例的横向扩展能力，实现了一定范围内处理能力的线性增长，提高了系统容量。此外，此种扩展方式无额外开发成本，实施简单，使得新电子票库扩展高效便捷；

（2）在Y轴上，增加了多层业务职责划分，将新电子票库拆分为更细粒度的多个服务。每个服务都负责特定的业务领域，如购票、退票、改签等，降低了复杂性，提高了可维护性和可扩展性；

（3）在Z轴上，保持不变，仍然保持客票系统强大的数据分区扩展能力。

综上所述，服务化后的新电子票库具备了丰富而强大的扩展能力。

3.2 处理能力方面

对电子票库当前架构和服务化架构的单数据节点上进行提交订单业务、支付业务压测。性能对比如图7所示。

图7 电子票库服务化改造前后性能对比

从图7中可以看出，服务化架构在请求并发较小时，响应时间高于当前架构下存储过程模式，这是由服务在模块之间及与数据库之间网络交互多于存储过程导致的，是服务化改造需要认知到的一个事情。但是随着并发量增加，当并发超过50 TPS的时候，服务响应比较稳定，而存储过程响应时间迅速增长。从而可以判断出，服务化的电子票库在大并发和高负载的场景下处理能力优于存储过程模式。