一种应用于高铁领域的订餐服务系统设计

郭 楠

(通号通信信息集团有限公司，北京 100070)

铁路一直以来都是互联网应用较少涉及的领域，目前旅客乘车体验已经随着高铁技术、信号技术等的飞速发展不断提升，铁路餐饮方面的体验提升，必将使客户满意度大幅提高。随着铁路出行人群的日益庞大，除高铁目前本身提供的餐饮服务外，还需要利用互联网实现旅客有更多的餐饮服务选择，因此需要稳定而高效的系统软件架构来满足大规模并发请求的要求。同时，铁路系统中的订餐与传统的订餐网络存在一些区别，后者更多的局限在一个城市或者城市的一个区域，订单量比较分散。而前者大部分请求是发生在列车运行过程中，旅客面对的大部分是自己不熟悉的商家，因此订单的商家会更集中于有品牌效应的商家，发生订单拥塞的可能性更大，因此后台服务需要引导用户解决订单冲突，选择合适的商家及产品，而且，送餐业务的时间要求更高，需要平台对于商家完成订单有严格的时间要求。

1 总体功能架构

为提供稳定高效的服务，系统框架纵向分为4层，由下至上分别是基础层，数据层，业务组件层和应用层，其结构如图1所示。

图1 功能架构

基础层包括基础网络设施、硬件配置、网络环境、应用服务器和数据库软件等；数据层主要包括垂直划分的数据资料，分为基础数据（包括系统配置，车次信息等）、商品库（包括品牌资料，美食信息，美食分类，订购价格等）、订单数据（包括订单详细信息，配送相关信息等），用户资料（包括乘客基本信息，商家基本信息）等。各数据之间使用松散耦合方式，不做强关联，即可以拆分为多个数据源，操作数据使用读写分离模式。服务组件层使用SOA框架，提供各个模块独立的服务接口，各服务模块之间松散耦合，对不需要及时反馈的接口做异步处理。使用zookeeper管理注册服务。应用层提供手机App和web访问的数据调用接口，主要以JSON方式返回数据，使用反向代理技术和浏览器缓存优化访问速度。

2 总体技术架构

为实现整体功能，系统从技术层面实现，如图2所示。

1）CDN系统

能够实时根据网络流量、各节点的连接、负载状况以及到用户的距离和响应时间等综合信息，将用户的请求重新导向离用户最近的服务节点上。其目的是使用户就近取得所需内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。

2）负载均衡、反向代理

图2 技术架构

基于商用的硬件F5做分发（集群，前期可以不用），web服务器如nginx，在7层做负载均衡或者反向代理分发到集群中的应用节点（反向代理在集群之后建），静态资源隔离，可以暂时考虑使用独立的静态资源服务器，如以后规模扩大，可以使用MogileFS做静态资源的分布式部署+Varnish图片缓存。

3）App接入

应用层运行在Jboss或者Tomcat容器中，代表独立的系统，如前端购物、用户自主服务、后端系统等，协议接口使用HTTP、JSON格式数据，若进一步优化可以采用Servlet3.0,异步化Servlet,提高整个系统的吞吐量。Session保存使用外部的Nosql数据库（Membercache或redis），使App接入层无状态化。

4）业务服务

代表某一领域的业务提供服务，对本项目而言，领域有用户、美食、订单、支付业务等。不同的领域提供不同的服务，这些不同的领域构成一个个模块，模块划分和接口设计应参考高内聚、接口收敛的原则，为以后扩展提供便利（当然前期根据应用规模的大小，模块可以部署在一起）。业务层对外即时协议可以NIO的RPC方式暴露，采用比较成熟的NIO通讯框架，如netty、Mina。查询类的接口可以封装成Web service或REST风格的接口，对网站可以提供jsonp的回调方式。

对于分布式系统的一致性，尽量满足可用性，对于需要事务但不需要及时反馈结果的场景(比如下单)，使用异步处理方式，挪到线程中运行。

5）基础服务中间件

服务注册使用zookeeper注册服务，调用时从zookeeper中获取服务信息，为以后做分布式扩展提供基础。异步消息机制对于及时性要求不高的业务（比如下单，通知等），使用MQ异步消息队列处理；数据检索在高铁订餐系统对于搜索的需求和其他电商平台相比相对简单，前期可以直接使用数据库检索，后期可以考虑将检索部分独立出来，使用Solr/Luecne做索引。日志作为统计分析使用的重要依据，在整个交易过程中，会大量产生。分析统计日志可以使用Hadoop，通过MapReuce的分布式处理框架，用于处理大规模的数据，会写到结果表中。

6）数据存储

数据库存储大体分为关系型（事务型）的数据库，以Oracle、MySql为代表，有Key-Value非关系型数据库（NoSql），以Redis和Memcached，MongoDB为代表。高铁送餐项目的关系型数据库采用MySql，数据库使用读写分离机制，使用MysqlProxy接口统一处理，不影响开发难度。对于需要锁定操作的数据（例如库存，限制数量等），可以使用Redis在外部处理，然后统一更新到主数据库中。

数据库到一定级别可以考虑按业务垂直分库的方式，将原来一个数据库分成多个，要注意业务的变化，尤其是需要统一事务的地方，尽量保持在同一个数据源内。设计时考虑空间换时间的准则，尽量做到各个子系统之间数据依赖关系最小化。

缓存设计使用内存数据库做Cache，如Redis、Membercache，对于要求一致性较高的场景，在更新数据库的同时，更新缓存，对于一致性要求不高的，可以采用设置缓存失效时间的策略。

3 结束语

随着信息化时代的来临，铁路运输服务部门应更多地致力于解决旅客出行中遇到的各种问题。铁路在线订餐服务，将使旅客出行体验得到极大的提升，因此本文从软件架构地层面分析了铁路订餐服务系统的功能点和架构设计，着重对可能影响系统运行的问题提供了解决方案，希望利用先进技术手段对铁路旅客服务业务提供新的建设思路。目前已经取得一些有益的进展，尝试与广铁等路局合作，推动高铁订餐服务的落地。

[1]王静.互联网+时代下高铁车站客运服务研究[J].甘肃科技，2016,32（23）:32-33.

[2]郝颖.提高高速铁路服务质量的思考和对策[J].管理观察，2010（33）:25-26.

[3]黄兴建，石修路，黄其河.基于微信公众平台的高铁客运订餐服务系统设计与实现[J].铁道经济研究，2016（3）:42-47.

[4]吴崇远.部分高铁开通订餐服务[J].综合运输，2014（8）:93-94.

[5]周路，付立民，杨海超.关键路径法在高寒地区高速铁路建设供货管理中的应用[J].铁路通信信号工程技术，2017，14（2）:108-111.

[6]王桂霞.铁总推出“高铁网上订餐”服务符合市场化运营[J].中国老年，2017（17）:6.

[7]杨烁萍.告别盒饭方便面,高铁迎来网上订餐时代[J].金融科技时代，2017（8）:85.

[8]李文霞.我国高铁发展的成就及存在的问题[J].环球市场信息导报, 2017（27）:20.

[9]陈礼腾.中国高铁首度试水在线外卖铁路服务走向开放“互联网+”[J].计算机与网络，2017,43（15）:13.