论文部分内容阅读
摘 要：本文根据交通运输部关于建设联网售票系统的要求，充分考虑现有建设条件，提出相关设计原则及设计思路，提出了当前较先进的建设联网售票系统及数据中心的设计框架、设计技术路线。
关键词：交换管理；数据中心；联网售票
一、数据中心设计思路及原则
1. 设计思路
根据交通运输部《省域道路客运联网售票系统工程建设指南》要求，针对道路客运联网售票与电子客票系统试点工程存在的问题和原因，充分考虑现有建设条件，以增强道路客运行业管理部门综合监管和决策分析能力、提高公路客运服务质量和信息服务水平为宗旨，结合新时期道路客运行业发展特点和实际需求，以行业管理部门、客运场站和运输企业以及社会公众的需求为导向，统一标准和技术要求，建设联网售票系统，开发统一的清分结算系统，规范业务管理流程和各方经营行为；完善售票服务方式和手段，提供更加统一、全面、完善的网上购票、电话订票等服务；依托全面的道路客运信息资源整合与汇总挖掘分析，提升对行业主管部门的决策支持能力，促进公路客运行业的稳定快速发展。
2. 设计原则
系统主要坚持以下原则：
（1）坚持先进性与实用性统筹
在不脱离实际的前提下，要使系统具备应用新技术成果的能力，采用具有先进水平的信息技术，使系统在设计上具备不断容纳新技术的能力，在较长时期内保持一定的先进性。同时紧密结合联网售票工作实际，针对联网售票工作特点，确保系统使用简便、功能完备。
（2）合理利旧、资源节约
充分利用已有的各类资源。升级完善已有系统功能完善，根据新的需求进行功能模块的扩展和升级，正确评估现有硬件资源，形成相对完整的体系架构，最大限度的保护已有投资，并保障升级工程的有实施和业务流畅过度。
（3）服务为本、监管并重
充分体现“服务公众”的理念，以方便公众购票、出行为宗旨，应用系统功能的设计以及软硬件设备的选型应充分考虑如何方便公众购票、乘车，着重提高道路客运的公众服务能力。落实这一理念需要贯彻和执行信息化服务的“监管并重”原则，“监”要求所采集的数据是充分和有效的，“管”要求对所采集数据的利用是科学和充分的。
（4）坚持开放性与可扩展性并重
系统的建设要走开放性的道路，无论是应用系统的体系架构设计，还是服务器、网络设备、操作系统、数据库管理系统等软硬件的选型，都需要考虑所遵循的工业标准是否具有开放性，减轻系统维护负担、增强系统的扩展能力，并为后续工程奠定良好基础。
（5）安全可靠、长效运行
联网售票系统是否能切实发挥功效，关键在于能否应对黄金周、春节等大型节假日高峰客流冲击的风险。系统设计、软硬件选型和网络性能、安全防范等应充分考虑系统运行和业务开展的稳定性、可靠性和突发事件下的灵活性。同时在不脱离实际的前提下，使系统设计上具有先进性和前瞻性，具备不断容纳新技术的能力，在较长时期内保持一定的先进性，并对运行管理模式、系统功能进行合理设计，保障系统安全有效、长效运行。
（6）科学合理、有效改进
联网售票系统需要具有丰富开发和运维经验的专业团队进行设计和开发，因此开发团队应以此设计为基础，对系统架构、技术框架、系统功能和性能充分理解和论证后，可以进行合理科学的改进。
二、数据中心设计架构
1. 总体架构
根据建设现状和特点，系统采用两级架构、分布式存储和三级管理，具体如下图所示：
系统分为省联网售票数据中心系统、客运站站务系统两级架构，交易数据分布式存储。由于本系统是典型的联机交易系统，数据的集中式或分布式存储主要是指实时交易数据的存储方式，本系统采用分布式存储方式，即实时交易数据分布存储在车站数据库中，联网中心采集和存储各车站交易完成后的非实时数据。
2. 业务架构
系统包括客运站务管理、联网售票数据交换管理、业务管理、售票服务、清分结算、客运综合监管等系统。客运站务管理系统服务于客运站企业，实现车站基础信息管理、车站售票、车站检票、车辆调度等功能；联网售票数据交换管理服务于行业管理部门和客运站企业，实现联网售票数据整合与交换，达到数据整合共享的目标；业务管理系统服务于行业管理部门和联网售票运营机构，实现票源管理、渠道管理、规则管理等功能，为售票服务系统提供支撑；售票服务系统服务于出行公众，提供多元化的售票服务；清分结算系统服务于客运车站、运输企业和第三方代售机构等联网售票参与单位，提供结算账户管理、清分规则管理、自动对账和结算管理等功能；客运综合监管服务于客运企业与行业管理部门，提供行业管理、综合分析和辅助决策支持等功能。工程业务架构如下图所示：
结合上述联网售票业务架构示意图看，系统主要着力于解决省级联网售票相关问题，其目标是实现全省票务资源与客运资源整合，从而服务社会公众和企业，提升行业管理效能。
3. 数据架构
数据是该系统的核心和业务基础。严格遵循信息资源规划思想，一方面坚持“一数一源”的原则，避免重复采集，另一方面应真正实现现有静态信息与动态信息的融合。在系统建设过程中，行业管理部门涉及数据主要包括道路客运基础数据、联网售票业务数据、清分结算数据及统计分析数据等，客运企业涉及数据主要包括联网售票业务数据、清分结算数据及统计分析数据等，公众涉及数据主要包括道路客运基础数据、联网售票业务数据等。
省联网售票中心建立统一的数据汇聚、交换与共享平台，实现全省道路客运数据和票务数据的大集中，对下采集客运站的基础客运数据，向上传输业务数据、统计分析数据、清分数据、基础数据至省运输管理局与省交通运输厅，对外与其他部门如民航、铁路、银行、保险等按照实现约定的协议交换相关数据。 4. 网站技术架构
根据12306网站和其他省份道路客运联网售票系统的网上售票系统经验来看，2年左右互联网的日均售票量即达到总售票量的50%，春运高峰期约为总售票量的70%，但并发量是平时的10倍以上。考虑到道路客运系统的流水班次较多，这部分的售票压力依然在车站，因此网站的日均售票量按照总售票的30%即19万张/日、并发交易量100笔/秒计算，春运高峰期按照总售票量的50%即32万张/日、并发交易量为平日的10倍即1000笔/秒计算。因此，网站系统的技术架构应满足1000笔/秒的并发交易量，以及10倍于并发交易量的查询访问，即10000笔/秒的并发查询访问量。
互联网门户系统技术实现框架层次结构如下图所示，从左向右各层次依次为客户端、应用层、数据存储层，其中应用层又可细分为UI表现层、业务逻辑层、数据访问层。这种架构设计的主要好处是可以通过分层实现并行设计与开发，每一层都基于成熟的框架技术来设计，层与层之间松散耦合，从而可以并行的进行设计、开发，将每层的处理逻辑分别封装成框架里组件或对象，最终借助框架集成到一起。
框架结构从左向右依次包含客户端、应用层和数据存储层，每个层次采用的具体技术如下所述：
？誗 客户端
基于Browser浏览器/手机APP的客户端，使用Html、Css、JavaScript等Web前端技术，通过Http请求方式访问后台服务。
框架应用层进一步细分为UI表现层、业务逻辑层、数据访问层。
？誗 UI表现层
采用基于Struts2的MVC框架技术实现，负责接受用户通过浏览器提交的Web页面请求，调用业务逻辑层应用组件服务接口进行业务处理，并将最终的处理结果展示给用户，为了更好优化表现层页面的组织方式，引入了SiteMesh网站混搭框架，抽取共性页面，采用装饰模式优化页面组织结构。
？誗 业务逻辑层
采用Spring或EJB3作为的业务Bean管理容器，由容器负责管理依赖注入、安全、事物、日志、异常等非功能性逻辑，业务Bean可以方便的实现对象的接口封装，然后通过注解方式，灵活发布应用服务的本地和远程服务接口。会话Bean负责提供可由表示层调用的接口，处理由表示层传入的业务请求。该层里包括了所有业务管理对象的接口和实现，因此，我们可以把票务系统的管理功能，都设计成若干个业务管理对象，并定义好各自的外部交互接口，然后就可以专注于各个模块自身进行设计了。
？誗 数据访问层
选用iBatis作为数据访问层框架，封装对数据库的访问操作，负责提供可由业务层调用的接口，为业务层里的对象访问数据库提供了面向对象的处理方式，该层主要包括操纵iBatis管理数据库的API、由iBatis映射工具负责抽取存储的实体与映射文件。
？誗 数据存储层
选用MySQL数据库作为数据持久软件，支持数据库的主从热备。通过Redis内存数据库做数据缓存管理。
三、数据中心设计技术路线
系统总体技术路线需采用松耦合的组件化设计和成熟稳定的软硬件开发平台，以满足系统通用接口设计要求、跨平台部署要求和系统未来扩展要求。
系统采用主流的技术路线，选用基于Java EE技术体系及其应用中间件开发，采用面向服务的SOA架构和B/S框架的组件化总体设计，通用服务接口符合JAX-RS2.0规范要求。
1. SOA体系架构
面向服务的体系结构（Service-Oriented Architecture，SOA）方法是在面向对象设计（Object-Oriented Design，OOD）方法的基础上扩展的构建系统的思想和方法。面向服务的方法关注的是企业业务，从系统顶层目标开始将联网售票业务进行逐层分解，直到分解为获取车次、获取票价、生成电子客票信息等原子服务或简单的组合服务，以这些业务服务为核心元素来封装业务流程和已有的应用系统。服务的颗粒度设计能力越高，越能匹配企业级的业务，可以实现更高级别的重用和通用接口的实现；耦合度越低，未来独立扩展和升级的可能性越高，但需要控制对性能的影响程度。通过SOA构建IT系统可以提高业务效率和用户满意度，有利于整合IT资源，提高IT系统的对外协作能力。
2. 软硬件开发平台
（1） 无单点故障
系统、网络、数据库和应用软件均需要有备份，不能有“单点”。数据库天然是有状态的，状态就是其中的数据，新增一个数据节点一般伴随着大量的数据复制和迁移。昂贵的商用存储解决方案是“IBM+Oracle+EMC”，互联网企业则一般采用较为廉价的开源方案，同样可以在MySQL主库宕机时实现备机接管，接管时间可以控制在30秒内。
（2） 可靠性
除了特别小型的系统，没有100%可靠的系统。一般需要根据系统的情况制定合适的目标，该目标最通用的衡量维度是系统可用率。系统可用率是可以提供服务的时间与总时间的比率，常用的系统可用率如下表所示。
系统容灾的基本策略是，
预防：容量估算和接入方限流是常用的手段，以应对宕机或者突发流量对系统的影响；
发现：主要依赖监控和各种系统性能工具及时发现系统可能的资源变化趋势，以应对可能的系统灾难。
解决：应对灾难的应急预案，例如针对外部的调用，系统有降级开关，可以随时关闭；针对系统内部某个接口导致整个系统失去响应的场景，可以限制接口的并发量等等。
此外，系统容量的冗余和可水平扩展也是容灾的必备要求，无状态的系统对于系统扩容更友好。
（3） 开发平台
系统可部署在主流的操作系统、应用服务器和数据库上，基本要求如下： ——操作系统：Unix、Linux、Windows
——开发环境：jdk1.6/java EE
——数据库：ORACLE 11g、MySQL、SQLserver
前端开发工具：以浏览器为主的B/S开发工具，也可以采用成熟的C/S前台售票软件，但必须具备自动更新能力。
3. 通用服务接口
联网售票系统主要有三类接口：子系统之间的接口、设备接口、与外部服务提供商的接口，应用接口主要采用Web Service接口和Socket接口，Web Service接口需符合JAX-RS2.0规范要求。
（1） 子系统之间的接口
联网售票系统基于模块化的设计思想，按业务功能及特点可分为若干个子系统，为保证各系统之间调用关系清晰、一致性，以及提供给外围系统调用的接口统一性，可采用ESB服务总线中间件，对各子系统内部接口和提供对外的接口统一管理，通过ESB能清晰梳理系统之间的接口关系，以及不同类型接口协议之间的转换、适配、路由、服务整合等工作。
（2） 设备接口
包括自动售票机、闸机、二代证读卡器、银行卡读卡器和打印设备等标准接口，可以采用Socket或Web Service接口方式。
（3） 服务提供商的接口
外部服务提供商接口主要有网站、电超市、银行、运政系统和公安系统等等，由于接口较多，且标准不统一，为降低各子系统之间对服务提供商接口的依赖性、偶合性、复杂性，设置应用交易接口与数据接口。应用交易接口主要用于处理联机交易应用，采用符合JAX-RS2.0规范的WebService网关技术，实现统一管理服务提供商的接口，负责屏蔽各接口之间差异和协议转换、安全控制等工作。数据接口用于系统之间批量数据交换，设置接口数据库，通过ETL实现系统之间批量数据传输、转换等处理。
四、结束语
当前，联网售票数据中心及联网售票系统的建设需求正日趋迫切，设计思路也产生多元化。本文建议系统总体技术路线需采用松耦合的组件化设计和成熟稳定的软硬件开发平台，以满足系统通用接口设计要求、跨平台部署要求和系统未来扩展要求。选用应用中间件开发，采用面向服务的SOA架构和B/S框架的组件化总体设计。系统建设应采取当前先进的技术同时满足未来发展的需求。
参考文献
[1] 公路水路交通信息化“十二五”发展规划（交规划发〔2011〕192号）.
[2] 交通运输部.省域道路客运联网售票系统工程建设指南.
[3] http：//www.moc.gov.cn/，交通运输部网站.
[4] 袁玉宇。云计算时代的数据中心[M].北京：电子工业出版社，2012.
关键词：交换管理；数据中心；联网售票
一、数据中心设计思路及原则
1. 设计思路
根据交通运输部《省域道路客运联网售票系统工程建设指南》要求，针对道路客运联网售票与电子客票系统试点工程存在的问题和原因，充分考虑现有建设条件，以增强道路客运行业管理部门综合监管和决策分析能力、提高公路客运服务质量和信息服务水平为宗旨，结合新时期道路客运行业发展特点和实际需求，以行业管理部门、客运场站和运输企业以及社会公众的需求为导向，统一标准和技术要求，建设联网售票系统，开发统一的清分结算系统，规范业务管理流程和各方经营行为；完善售票服务方式和手段，提供更加统一、全面、完善的网上购票、电话订票等服务；依托全面的道路客运信息资源整合与汇总挖掘分析，提升对行业主管部门的决策支持能力，促进公路客运行业的稳定快速发展。
2. 设计原则
系统主要坚持以下原则：
（1）坚持先进性与实用性统筹
在不脱离实际的前提下，要使系统具备应用新技术成果的能力，采用具有先进水平的信息技术，使系统在设计上具备不断容纳新技术的能力，在较长时期内保持一定的先进性。同时紧密结合联网售票工作实际，针对联网售票工作特点，确保系统使用简便、功能完备。
（2）合理利旧、资源节约
充分利用已有的各类资源。升级完善已有系统功能完善，根据新的需求进行功能模块的扩展和升级，正确评估现有硬件资源，形成相对完整的体系架构，最大限度的保护已有投资，并保障升级工程的有实施和业务流畅过度。
（3）服务为本、监管并重
充分体现“服务公众”的理念，以方便公众购票、出行为宗旨，应用系统功能的设计以及软硬件设备的选型应充分考虑如何方便公众购票、乘车，着重提高道路客运的公众服务能力。落实这一理念需要贯彻和执行信息化服务的“监管并重”原则，“监”要求所采集的数据是充分和有效的，“管”要求对所采集数据的利用是科学和充分的。
（4）坚持开放性与可扩展性并重
系统的建设要走开放性的道路，无论是应用系统的体系架构设计，还是服务器、网络设备、操作系统、数据库管理系统等软硬件的选型，都需要考虑所遵循的工业标准是否具有开放性，减轻系统维护负担、增强系统的扩展能力，并为后续工程奠定良好基础。
（5）安全可靠、长效运行
联网售票系统是否能切实发挥功效，关键在于能否应对黄金周、春节等大型节假日高峰客流冲击的风险。系统设计、软硬件选型和网络性能、安全防范等应充分考虑系统运行和业务开展的稳定性、可靠性和突发事件下的灵活性。同时在不脱离实际的前提下，使系统设计上具有先进性和前瞻性，具备不断容纳新技术的能力，在较长时期内保持一定的先进性，并对运行管理模式、系统功能进行合理设计，保障系统安全有效、长效运行。
（6）科学合理、有效改进
联网售票系统需要具有丰富开发和运维经验的专业团队进行设计和开发，因此开发团队应以此设计为基础，对系统架构、技术框架、系统功能和性能充分理解和论证后，可以进行合理科学的改进。
二、数据中心设计架构
1. 总体架构
根据建设现状和特点，系统采用两级架构、分布式存储和三级管理，具体如下图所示：
系统分为省联网售票数据中心系统、客运站站务系统两级架构，交易数据分布式存储。由于本系统是典型的联机交易系统，数据的集中式或分布式存储主要是指实时交易数据的存储方式，本系统采用分布式存储方式，即实时交易数据分布存储在车站数据库中，联网中心采集和存储各车站交易完成后的非实时数据。
2. 业务架构
系统包括客运站务管理、联网售票数据交换管理、业务管理、售票服务、清分结算、客运综合监管等系统。客运站务管理系统服务于客运站企业，实现车站基础信息管理、车站售票、车站检票、车辆调度等功能；联网售票数据交换管理服务于行业管理部门和客运站企业，实现联网售票数据整合与交换，达到数据整合共享的目标；业务管理系统服务于行业管理部门和联网售票运营机构，实现票源管理、渠道管理、规则管理等功能，为售票服务系统提供支撑；售票服务系统服务于出行公众，提供多元化的售票服务；清分结算系统服务于客运车站、运输企业和第三方代售机构等联网售票参与单位，提供结算账户管理、清分规则管理、自动对账和结算管理等功能；客运综合监管服务于客运企业与行业管理部门，提供行业管理、综合分析和辅助决策支持等功能。工程业务架构如下图所示：
结合上述联网售票业务架构示意图看，系统主要着力于解决省级联网售票相关问题，其目标是实现全省票务资源与客运资源整合，从而服务社会公众和企业，提升行业管理效能。
3. 数据架构
数据是该系统的核心和业务基础。严格遵循信息资源规划思想，一方面坚持“一数一源”的原则，避免重复采集，另一方面应真正实现现有静态信息与动态信息的融合。在系统建设过程中，行业管理部门涉及数据主要包括道路客运基础数据、联网售票业务数据、清分结算数据及统计分析数据等，客运企业涉及数据主要包括联网售票业务数据、清分结算数据及统计分析数据等，公众涉及数据主要包括道路客运基础数据、联网售票业务数据等。
省联网售票中心建立统一的数据汇聚、交换与共享平台，实现全省道路客运数据和票务数据的大集中，对下采集客运站的基础客运数据，向上传输业务数据、统计分析数据、清分数据、基础数据至省运输管理局与省交通运输厅，对外与其他部门如民航、铁路、银行、保险等按照实现约定的协议交换相关数据。 4. 网站技术架构
根据12306网站和其他省份道路客运联网售票系统的网上售票系统经验来看，2年左右互联网的日均售票量即达到总售票量的50%，春运高峰期约为总售票量的70%，但并发量是平时的10倍以上。考虑到道路客运系统的流水班次较多，这部分的售票压力依然在车站，因此网站的日均售票量按照总售票的30%即19万张/日、并发交易量100笔/秒计算，春运高峰期按照总售票量的50%即32万张/日、并发交易量为平日的10倍即1000笔/秒计算。因此，网站系统的技术架构应满足1000笔/秒的并发交易量，以及10倍于并发交易量的查询访问，即10000笔/秒的并发查询访问量。
互联网门户系统技术实现框架层次结构如下图所示，从左向右各层次依次为客户端、应用层、数据存储层，其中应用层又可细分为UI表现层、业务逻辑层、数据访问层。这种架构设计的主要好处是可以通过分层实现并行设计与开发，每一层都基于成熟的框架技术来设计，层与层之间松散耦合，从而可以并行的进行设计、开发，将每层的处理逻辑分别封装成框架里组件或对象，最终借助框架集成到一起。
框架结构从左向右依次包含客户端、应用层和数据存储层，每个层次采用的具体技术如下所述：
？誗 客户端
基于Browser浏览器/手机APP的客户端，使用Html、Css、JavaScript等Web前端技术，通过Http请求方式访问后台服务。
框架应用层进一步细分为UI表现层、业务逻辑层、数据访问层。
？誗 UI表现层
采用基于Struts2的MVC框架技术实现，负责接受用户通过浏览器提交的Web页面请求，调用业务逻辑层应用组件服务接口进行业务处理，并将最终的处理结果展示给用户，为了更好优化表现层页面的组织方式，引入了SiteMesh网站混搭框架，抽取共性页面，采用装饰模式优化页面组织结构。
？誗 业务逻辑层
采用Spring或EJB3作为的业务Bean管理容器，由容器负责管理依赖注入、安全、事物、日志、异常等非功能性逻辑，业务Bean可以方便的实现对象的接口封装，然后通过注解方式，灵活发布应用服务的本地和远程服务接口。会话Bean负责提供可由表示层调用的接口，处理由表示层传入的业务请求。该层里包括了所有业务管理对象的接口和实现，因此，我们可以把票务系统的管理功能，都设计成若干个业务管理对象，并定义好各自的外部交互接口，然后就可以专注于各个模块自身进行设计了。
？誗 数据访问层
选用iBatis作为数据访问层框架，封装对数据库的访问操作，负责提供可由业务层调用的接口，为业务层里的对象访问数据库提供了面向对象的处理方式，该层主要包括操纵iBatis管理数据库的API、由iBatis映射工具负责抽取存储的实体与映射文件。
？誗 数据存储层
选用MySQL数据库作为数据持久软件，支持数据库的主从热备。通过Redis内存数据库做数据缓存管理。
三、数据中心设计技术路线
系统总体技术路线需采用松耦合的组件化设计和成熟稳定的软硬件开发平台，以满足系统通用接口设计要求、跨平台部署要求和系统未来扩展要求。
系统采用主流的技术路线，选用基于Java EE技术体系及其应用中间件开发，采用面向服务的SOA架构和B/S框架的组件化总体设计，通用服务接口符合JAX-RS2.0规范要求。
1. SOA体系架构
面向服务的体系结构（Service-Oriented Architecture，SOA）方法是在面向对象设计（Object-Oriented Design，OOD）方法的基础上扩展的构建系统的思想和方法。面向服务的方法关注的是企业业务，从系统顶层目标开始将联网售票业务进行逐层分解，直到分解为获取车次、获取票价、生成电子客票信息等原子服务或简单的组合服务，以这些业务服务为核心元素来封装业务流程和已有的应用系统。服务的颗粒度设计能力越高，越能匹配企业级的业务，可以实现更高级别的重用和通用接口的实现；耦合度越低，未来独立扩展和升级的可能性越高，但需要控制对性能的影响程度。通过SOA构建IT系统可以提高业务效率和用户满意度，有利于整合IT资源，提高IT系统的对外协作能力。
2. 软硬件开发平台
（1） 无单点故障
系统、网络、数据库和应用软件均需要有备份，不能有“单点”。数据库天然是有状态的，状态就是其中的数据，新增一个数据节点一般伴随着大量的数据复制和迁移。昂贵的商用存储解决方案是“IBM+Oracle+EMC”，互联网企业则一般采用较为廉价的开源方案，同样可以在MySQL主库宕机时实现备机接管，接管时间可以控制在30秒内。
（2） 可靠性
除了特别小型的系统，没有100%可靠的系统。一般需要根据系统的情况制定合适的目标，该目标最通用的衡量维度是系统可用率。系统可用率是可以提供服务的时间与总时间的比率，常用的系统可用率如下表所示。
系统容灾的基本策略是，
预防：容量估算和接入方限流是常用的手段，以应对宕机或者突发流量对系统的影响；
发现：主要依赖监控和各种系统性能工具及时发现系统可能的资源变化趋势，以应对可能的系统灾难。
解决：应对灾难的应急预案，例如针对外部的调用，系统有降级开关，可以随时关闭；针对系统内部某个接口导致整个系统失去响应的场景，可以限制接口的并发量等等。
此外，系统容量的冗余和可水平扩展也是容灾的必备要求，无状态的系统对于系统扩容更友好。
（3） 开发平台
系统可部署在主流的操作系统、应用服务器和数据库上，基本要求如下： ——操作系统：Unix、Linux、Windows
——开发环境：jdk1.6/java EE
——数据库：ORACLE 11g、MySQL、SQLserver
前端开发工具：以浏览器为主的B/S开发工具，也可以采用成熟的C/S前台售票软件，但必须具备自动更新能力。
3. 通用服务接口
联网售票系统主要有三类接口：子系统之间的接口、设备接口、与外部服务提供商的接口，应用接口主要采用Web Service接口和Socket接口，Web Service接口需符合JAX-RS2.0规范要求。
（1） 子系统之间的接口
联网售票系统基于模块化的设计思想，按业务功能及特点可分为若干个子系统，为保证各系统之间调用关系清晰、一致性，以及提供给外围系统调用的接口统一性，可采用ESB服务总线中间件，对各子系统内部接口和提供对外的接口统一管理，通过ESB能清晰梳理系统之间的接口关系，以及不同类型接口协议之间的转换、适配、路由、服务整合等工作。
（2） 设备接口
包括自动售票机、闸机、二代证读卡器、银行卡读卡器和打印设备等标准接口，可以采用Socket或Web Service接口方式。
（3） 服务提供商的接口
外部服务提供商接口主要有网站、电超市、银行、运政系统和公安系统等等，由于接口较多，且标准不统一，为降低各子系统之间对服务提供商接口的依赖性、偶合性、复杂性，设置应用交易接口与数据接口。应用交易接口主要用于处理联机交易应用，采用符合JAX-RS2.0规范的WebService网关技术，实现统一管理服务提供商的接口，负责屏蔽各接口之间差异和协议转换、安全控制等工作。数据接口用于系统之间批量数据交换，设置接口数据库，通过ETL实现系统之间批量数据传输、转换等处理。
四、结束语
当前，联网售票数据中心及联网售票系统的建设需求正日趋迫切，设计思路也产生多元化。本文建议系统总体技术路线需采用松耦合的组件化设计和成熟稳定的软硬件开发平台，以满足系统通用接口设计要求、跨平台部署要求和系统未来扩展要求。选用应用中间件开发，采用面向服务的SOA架构和B/S框架的组件化总体设计。系统建设应采取当前先进的技术同时满足未来发展的需求。
参考文献
[1] 公路水路交通信息化“十二五”发展规划（交规划发〔2011〕192号）.
[2] 交通运输部.省域道路客运联网售票系统工程建设指南.
[3] http：//www.moc.gov.cn/，交通运输部网站.
[4] 袁玉宇。云计算时代的数据中心[M].北京：电子工业出版社，2012.