邯黄铁路微服务架构应用中的关键技术问题研究

金树桥

摘要 文章介绍了邯黄铁路智慧化建设的主要内涵，阐述微服务架构在邯黄铁路智慧化建设中的意义和作用，通过对邯黄铁路微服务的系统基本架构和基于Redis的数据中台方案中的关键技术的研究、国产数据库适配的比选、对数据库部署方案的推演及实施，成功解决了邯黄铁路的信息系统架构升级，推动邯黄的智能化升级和数字化转型。

关键词 微服务架构；云原生应用；数据中台；信息化创新

中图分类号 U29-39文献标识码 A文章编号 2096-8949（2024）06-0010-03

0 引言

邯黄铁路是以货运为主的区域性合资铁路，邯黄铁路全线长468 km，共计31个车站，其中8个车站办理货运业务，主要作业集中在东部的渤海三站，即渤海东站、渤海新区站、渤海西站，约占装车总量的85%。

2020年，邯黄铁路有限责任公司印发了《“十四五”发展规划》和《邯黄铁路智慧化建设规划纲要》，提出了建设智能货运、智能运输等一系列战略目标，并开始筹建一系列信息化改造及新建项目。“邯黄铁路智能货运一体化应用”（以下简称“货运一体化”）是其中的关键项目之一，承担了整合既有应用系统、推动应用架构全面升级的基础性工作。

按照两个规划要求，结合邯黄公司的投资计划，货运一体化拟基于微服务架构规范，以公司运输调度、资源规划、货运作业、安全管控为核心，重构一系列依托PaaS平台运行的云原生应用，形成完整的云原生应用体系，并逐步扩大云原生应用范围，最终实现企业应用的整体升级。同时，按照国家信创要求，选购国产CPU、服务器、操作系统和数据库，按照“边建设、边改造”的原则，结合应用系统架构设计，利用3年左右时间完成国产化替代。该文就项目设计中关于微服务架构和安可替代的几个关键技术问题进行研究，提出相关的设计思路和实现解决方案。

1 系统基本架构

基于微服务架构的云原生应用是目前信息系统的主流架构，《邯黄铁路智慧化建设规划纲要》中已经明确将微服务作为信息系统的主流架构，所有新建应用系统均应优先考虑使用微服务架构。

微服务（Micro Service）是一种软件架构方式，将传统上的单体应用分解为一系列可独立运行的、多实例的服务，每个服务均提供良好定义的接口[1]。云原生（Cloud Native）应用是基于微服务架构、充分利用云计算特征重新开发的应用系统。与传统面向服务架构（SOA）相比，微服务架构强调“重构”，是一种彻底放弃原有代码，重新构建全新代码的思路，这也是云原生中“原生”的基本含义[2]。“多实例”是微服务架构的一个基本特征，传统的应用通常只有1个或有限几个实例，微服务应用将传统的单体应用分解为多个微服务。每个微服务又同时运行多个实例，因此，基于微服务架构的云原生应用需要更多的运行环境支持，传统的基于物理机或虚机的基础设施环境，都无法满足微服务应用的运行要求，需要基于容器的支撑平台，即PaaS平台之上。由于传统IT系统本身的复杂性，PaaS平台往往涉及跨平台的多云、混合云管理[3]。

结合项目预算及基于微服务的云原生应用、高可用性、多云混合云管理等要求，货运一体化应用系统的基本架构，如图1所示：

主用系统采取新购的信创设备，建成完整的基于PssS的云原生应用体系。备用系统采用利旧设备，在新系统投产后利用替换下来的既有x86服务器作为备用设备，将微服务直接部署在物理机操作系统上，不安装云平台，不提供多实例支持，以节省资源需求和建设投资。

主用系统中间件选用青云虚拟化软件（IaaS）+鲁班（原Kubesphere）PaaS平台。其中青云虚拟化软件实现新购信创设备的虚拟化。由于邯黄铁路信息系统发展的歷史原因，邯黄铁路信息系统繁多、架构各异、整合困难，因此，先期必须提供多种基础设施环境。应用系统、中间件尽量以容器方式运行，由PaaS平台提供高可用保证，同时减少对硬件资源的占用。同时，为满足“边改造、边升级”的策略要求，某些遗留系统及其依赖的中间件，还需以虚机方式运行。该架构通过青云虚拟化软件来提供虚机，遗留系统和其所依赖的无法纳入容器的中间件，由青云虚拟化软件提供的虚拟服务器支撑运行。

鲁班PaaS平台除提供高可用性保障之外，还集成了大量第三方工具，提供了交互式运维管理界面、开发运维一体化、图形化性能及监控、日志聚合、数据链路追踪等服务。其底层基于Kubernetes构建，具有开放式架构，可提供安全、可靠、高可用的基础设施管理和计算存储资源调配、水平伸缩、服务迁移能力，为云原生应用提供可信基础设施服务。

数据库系统独立部署，主、备系统共享使用。数据库选用人大金仓的KingbaseES V8系统，采取主备方式，直接部署在物理机上。

2 基于Redis的数据中台方案

数据中台是全领域数据的共享能力中心，提供数据采集、数据模型、数据计算、数据治理、数据资产、数据服务等全链路的一站式产品、技术、方法论服务。通过数据中台，企业将原来分散在各应用系统中的数据整合成为完整、一致、统一的企业数据，使数据能够反映企业决策、设计、生产、销售的全链条全场景。数据中台是企业数智化的前提，也是一切智能算法的基础，是邯黄建设智慧货运、智慧运输体系的基础。

数据中台建设是企业架构升级的核心内容，涉及内容包括：建立数字化模型，全面实现业务数据数字化建模；统筹企业应用系统数据，形成全景全链条的企业级数据架构；制定数据质量标准，设计企业级元数据模型；构建数据采集能力，建立稳定可靠的数据来源；整合企业应用系统，形成围绕数据中台的应用体系等一系列问题。

在应用建设期间，需要先解决数据中台建设的技术问题，即探讨基于Redis的微服务架构中无状态Stateless服务的解决方案。这是云原生应用重构的核心，也是数据中台建设的最基础技术前提和要求。

微服务的多实例特征，要求服务实例不能保存私有数据，否则就破坏了无状态原则。如果每次都从数据库读写数据，不但影响运行速度，也会给数据库造成很大压力。因此，需要类似Redis的内存数据库中间件来管理共享的内存数据，以及一组操作Redis的数据中台服务。Redis和数据库是两个完全独立的中间件，两者之间不直接交换数据。如图2所示。

数据中台的本质，就是提供一组Redis操作方法，使业务组件可以便捷地读写Redis，简化系统设计。Redis代理由应用框架提供，具体通过应用框架的Redis Agent工具类实现，服务接口如下。

基本读写服务API，可不导入Jedis包直接操作Redis：

（1）getInstacne（ ） 获取Redis Agent实例。

（2）get、set方法，提供object-object的键值对存取，服务自动记录对象类型，自动决定使用哪种串行化方式。

（3）getString、setString方法，对String-String型键值对的快捷方法。

高级读写服务API，返回Jedis引用，直接操作Jedis：

（1）selectDb（index） 切换数据库。数据库用数字索引标识。

（2）getJedis（ ） 返回Jedis引用，由使用者自行操控Redis。

在应用层面，数据读写通常被归到数据读写服务（通常是数据中台服务的API），业务逻辑开发人员不需要花费精力去关注实现细节，但需要保持足够的控制。一种推荐做法是对业务逻辑提供一致的读写方法，并通过参数控制数据读/写的源/目标对象。

（1）在读方法中设置布尔参数refresh，refresh为true表示需要从数据库中读取数据，否则从Redis中读取数据即可。该参数主要用于读取来自外部源的数据，需要定期读取数据库来刷新Redis数据中台。

（2）在写方法中设置布尔参数commit，commit为true表示写中台的同时也写数据库，否则只写中台。该参数主要基于效率因素考虑，在数据IO较大时，可以更精细地控制写操作频度。

战术数据中台是应用框架的一部分。除数据中台方案外，应用框架还需提供消息队列代理、可靠守护进程框架、统一登录和用户身份认证、访问授权等一系列服务。

3 国产数据库适配及部署方案

经比较适配，邯黄智能货运一体化应用采用人大金仓KingbaseES v8作为数据库。数据库服务器采取读写分离的主备方式，提供需要的高可用性保证。邯黄现有应用运行于Oracle数据库，该数据库系统及其服务器（非信创）仍保持使用，支撑该次尚未迁移的遗留应用系统运行，同时，也作为货运一体化应用的备用数据库，使资源能力得到充分使用。待新设备采购到位再逐步进行升级替换。上述架构如图3所示：

图3中主用数据库集群为新购金仓KingbaseES v8系统，采取读写分离的主备方式，其中主用数据库为写数据库，承担所有写数据库操作，备用数据库为只读数据库，承担读数据库操作。读写分离由金仓数据库通过JDBC组件自行进行负载均衡（Kingbase数据库在JDBC链接串中指定多个数据库URL，可自行定位读写服务器，不需要用户在程序中予以考虑）。读写数据库服务器间通过内置同步软件实现实时数据同步，当检测到一方出现问题后，会自动将负载全部转移到另一台服务器，不需要用户干涉。问题修复后，可自行同步数据并恢复双机运行，整个过程均不需要人工干预。主用集群和备用数据库系统（邯黄目前为单机系统）间采用Kingbase FlySync（简称KFS）进行异步数据同步。KFS是一个非常强大的数据同步软件，支持“多对一”“一对多”的异构高效数据同步。其中，“多对一”表示多个数据源同步到一个目标数据库，“一对多”表示一个数据源同步到多个目标数据库，异构表示可以在Kingbase、Oracle、MySQL、PostgreSQL等数据库产品，以及RabbitMQ、Kafka等传输中间件间传递数据，高效表示基于数据库log实现高效增量写入。在该系统中，使用了KFS一对一的异构数据库同步能力。

数据库是信创适配中的重点工作。从小型机到服务器、从实时应用集群（RAC）到主备集群，从Oracle到国产数据库，都会造成一定的性能损失，叠加起来，可能会对应用性能造成较大影响，因此，必须在设计方案上考虑比较充分的性能冗余。衡量数据库访问量，主要是通过QPS和TPS两个参数判断，简言之，QPS是每秒执行SQL语句的数量，TPS是每秒提交事务的数量。由于该系统投资有限，而邯黄系统数据智能化要求较高，数据访问量大，因此，在应用中进行了一定优化，采用了自行编写数据库访问代码的方式，未使用MyBatis等框架进行O-R Mapping，以期在性能上达到更优。

邯黄铁路智能货运系统的另一个特点，是主备系统分别使用了不同数据库厂商的异构数据库，要求应用系统具备自动识别数据库类型、主动适应不同数据库连接的能力。在这方面，金仓数据库实现了与Oracle的完美兼容，除加载数据库驱动的方式略有不同外，所有数据库操作均可复用同样代码。因此，只需配置两套数据库参数，并完成在线识别、链接操作即可。具体步骤如下：

（1）在配置参数中为两套数据库分别配置连接参数，程序自动根据URL中的关键字识别数据库，并选用相关配置参数。

（2）每次获取数据库连接时，首先获取主数据库连接，在获取失败时改为获取备用数据库连接。

（3）应用具体的数据库操作方法，均与使用哪种连接无关。换言之，使用哪种数据库对开发者是透明的。

邯黄数据库架构是根据邯黄设备实际情况设计的个性化备用方案，希望在主数据库服务器设备失效时，备数据库服务器可以实现自动接管。主—备集群失效时，备用数据库集群可以通过人工干预进行接管。人大金仓本身可以通过仲裁节点实现备用集群自动接管，但考虑主备集群同时故障的概率较小，兼之网络、设备等各种复杂性因素，自动接管可能会带来更多的不稳定风险，因此，选择了人工干预切换的方式。由于通过KFS实现了准实时同步，接管操作非常简单，可在两分钟之内完成，可以满足邯黄信息系统故障切换时间的要求。

上述方案是邯黄铁路智能货运一体化应用初期的数据库方案，仅考虑了联机应用系统（OLTP）。随着邯黄铁路智能货运建设的不断深入，还需增加集成数据中台和离线数据分析系统（OLAP），增加分析数据库软件。由于投资和设备能力限制，该次数据库方案中未纳入这部分内容。后期工作中需增加独立的分析数据库服务器集群，借助于KingbaseFlySync，也可以轻松地搭建邯黄的集成数据中台和大数据分析体系，实现企业级运输分析和决策支持系统。

4 结束语

邯黄铁路智能货运一体化应用，是一个典型的地方铁路运输生产领域的现代化应用信息系统。项目虽然规模不大，但汇集了信创、云原生、集中部署等现代信息化应用的全部特点，具有很强的示范作用。通过邯黄货运一体化应用的建设，不但可以解决邯黄铁路的信息系统架构升级，推动邯黄的智能化升级和数字化转型，还可以为其他地方铁路的信息化转型升级提供很好的经验积累。该文从邯黄铁路智能货运建设实践出发，从面到点阐述了一些实际设计和建设中的具体方案和经验，涉及范围较广，疏漏之处在所难免。不当之处，请同行不吝指正。

参考文献

[1]刘子扬， 王兴中， 王青. 面向微服务的国家能源集团铁路综合调度信息系统架构设计与实现[J]. 铁道运输与经济， 2022（S1）： 7-13.

[2]李贝贝， 阎志远， 戴琳琳. 铁路运输应用云原生技术优化路线研究[J]. 铁路计算机应用， 2021（1）： 15-18+23.

[3]刘志勇. 基于微服务架构的铁路多云管理应用实践探索[J]. 铁路通信信号工程技術， 2021（2）： 62-66.