题记:
我是一个读书时学习java,工作中使用C#的轨道交通行业的程序员,因此也会发一些关于本行业的东西,可能会有很难理解或者很LOW的文章,呵呵,爱看不看,本来也只是作为自己的笔记本存在的地方......嚣张了吧,不服来刺激战场刚一波......▄︻┻═┳一
因为重庆环线项目的独特特点,对之前AFC票务系统的架构提出了必须更改以适配的需求,因此,设计了几种方案,以供项目组选择。
前提说明:
1、重庆环线LC建设方为其它集成商
2、票务系统暂时考虑架设在某一车站中,其它车站通过环网访问票务系统
3、我方暂不具备在LC机房架设服务器的可能
4、AFC+票务系统的模式仍然需要实现
5、票务系统与LC无法直接通信
票务系统处理的票务相关数据至少包括以下:
1、审核数据,包括TVM审核数据、BOM审核数据、长款数据、短款数据等
2、调票数据,包括车票下发、车票上交、车票调拨等数据
3、库存数据,包括现金库存和车票库存等实时数据和调整数据等,以及可能涉及到的库存盘点数据
4、类型数据,包括车票库存类型、车票类型(二者可能会等同)等
5、权限数据,包括通用权限数据和票务专属权限数据
6、其它业务数据,包括非及时退款退卡数据、银行解行数据
方案一
方案一系统架构图
说明:
1、所有票务相关数据均需要和LC系统进行交互
2、SC服务器直接与LC系统进行交互,SC实现与LC之间所有票务数据的接口
3、票务系统划分为业务服务器TC和通信服务器DC
4、业务服务器TC负责处理业务,通信服务器负责实现数据接收、数据转发、与SC服务器通信、数据审计等
5、SC服务器需要改造,具备支持所有票务数据转发至DC的能力
6、TC与DC之间通过WebService实现通信,TC需要实现若干接口来满足业务需求,具体接口等待方案确定后详细设计
方案二
方案二系统架构图
说明:
1、票务系统不进行拆分,所有与SC通信能力全部依靠TC实现
2、SC服务器直接与LC系统进行交互,SC实现与LC之间所有票务数据的接口
3、所有SC具备能够主动调用TC提供的WebService接口来实现票务业务的能力
4、票务系统DB与所有SC DB做DB-Link
5、票务系统TC需要实现若干接口来满足业务需求,具体接口等待方案确定后详细设计
方案三
方案三系统架构图
说明:
1、增加方正LC,所有SC与LC通信的同时,与方正LC同时进行数据交互
2、票务系统不与LC进行任何交互,SC与LC不进行任何票务数据交互
3、我方所有设备、系统登录权限不归LC掌控
分析:
1、以上三个方案的建设模式和系统改造量相比,方案三最为简单,方案一(DC服务器)和方案二(TC服务器和数据库及报表)改造量均较大。
2、从重庆环线整体角度考虑,方案一和方案二最切合地铁运营公司的需求,方案三与地铁组织架构不太切合,不容易被接受。
3、从对硬件需求的角度考虑,方案一和方案三均需要收集所有交易数据到票务系统中,因此对硬件的要求、对数据审计能力的要求较高,最优硬件方案是2台小机+2台PC Server+磁盘阵列,方案二由于通过DB Link实现了一种伪分布式架构,减少了对硬件和数据审计能力的要求,一台PCServer基本可以满足需求。
4、从可移植性和未来扩展角度来看,方案一解耦了SC数据库与票务系统数据库之间的耦合度,解耦了票务系统TC和AFC系统之间的关系,更容易上升至MLC层级,更容易产品化,也与部门目前的工作方向更契合。
5、从开发时间成本上考虑,方案三时间成本
结论:
综上考虑,个人更推荐重庆环线票务系统采用方案二,但是需要明确与LC之间所有的票务接口,在地标文件中这些数据交互接口并不完善!
领取专属 10元无门槛券
私享最新 技术干货