重庆环线票务系统方案选型

题记：

我是一个读书时学习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之间所有的票务接口，在地标文件中这些数据交互接口并不完善！