公路电子客票系统特点分析与架构选型浅析

    如果只从技术上考虑，不管是管理还在容灾备份，包括后期的运维，肯定是集中部署更好一点，但是由此也会带来一些问题，连接站点多，一旦某个站点网络至机房连接出现故障，则整个站点就瘫痪了。前不久支付宝的故障说是因为光纤被挖断就是个例子，所以容灾方案一定要做好，在网络瘫痪的情况下如何售票，是否可以使用4G网络传输等。网络设备故障，系统故障如何快速恢复。

   公路客运部门无论从资金上，还是人员技术储备上远远不如铁路和航空公司，所以在部署和后期运维上都需要优化方案。

集中部署后如中心出现故障，则全部站点都可能瘫痪，是否需要采用两地三中心等高可用方案。目前遇到机房全军覆没的基本上都是由于供电故障造成的。所以包括供电方面，双市电加UPS。核心主机采用多台小型机做双活，切分业务。主机系统可以采用VMware虚拟化，系统做成模板，把业务应用封装在docker里面，每个站点复制即可完成，大大提高部署和升级速度。数据库采用oracle 的ADG双活，存储使用HDS的远程同步。采用自动化运维监控工具，降低运维难度。

   毕竟是一项民生工程，希望能够建成高性能高可用的系统。

国外客票系统已经有很多年的积累和尝试，期间不乏使用分布式部署，后来因为数据一致性，应用复杂性的问题，不得不转回集中式，包括我们知道的中国铁路系统，现在也是趋向于集中，原来承载的业务也是各铁路局，各地年出票量最高几亿张，但是各地市系统的建设已经出现瓶颈，分布式的方法在帮助交通行业需要信息共享和实时性要求上已经显得捉襟见肘，公路客票系统未来集中，各省的出票量就会比全国铁路和公路要打，如果不实现后端核心系统的逻辑集中，数据的逻辑集中，灵活性业务的经办就会变成摆设，面对不同人群不同终端的客票服务，在全国实现实时准确的票务服务难上加难。

1、售票截止时间，开车前5分钟甚至2分钟都可以买票。

只有数据逻辑集中，紧耦合的机制，才能保持能够提供准确及时的客票服务，否则数据交换的延迟，复杂应用的跨物理站点的相互调用已经淹没了宝贵的时间。

2、大巴座位有限，运量小，多班次发车。高铁和飞机每班次承载的数量远多于大巴。

公路客运的大客运量，管理粒度小的特点要求管理要及时准确，还是那个问题，数据和系统不集中，通过不停的应用层调用，跨物理站点的网络延迟，管理起来会非常棘手。如果数据逻辑集中后，通过大数据分析，会更加有效，客票系统是标准的纵向扩展场景，数据库和应用越来越大，分布式部署，避免不了分库分表，跨物理机的数据库整合和应用调用都会变的复杂，面对越来越粒度的管理，数据的准确性和实时性都没法保证。

3、站点多，因路网密集的优势，几乎只要有客流的地方都可以到达。省市之间，甚至区县都有大巴车通达。

不打破分布式管理，没法实现高度的资源共享。

4、管理松散，因历史原因，各省市客户站的建设几乎都是各自为政，没有高铁机场全国一体化，行政集权化高，政令通达及执行效果都非常高。

国家已经发文要求省集中建设，目前各地市只是需要选型，选择业务模式和系统架构符合未来的发展需要。

5、网上预订少，几乎都是到站买票，随买随走。

网上预定每年的增幅会越来越大，这个是趋势，只是目前能够提供这种服务受限于各系统分散，不能共享数据，做不到灵活全面的票务服务。系统建设上，要保证各购票渠道的整合，纳入介入层进行统一管理，当然数据的不集中，能够提供的网上票务服务就有限。