一校多地的校园一卡通系统建设

文/周学刚 刘秀琴

随着教育体制改革的不断深入和高校招生规模的不断扩大，“一校多地”“跨省办学”成为普遍现象。同时，异地校区之间存在着相互独立和相互联系的情况，师生也会有跨校区学习和生活的需要。

校园一卡通作为承载校内金融消费和身份识别的信息化管理系统，架构在校园网之上，结合电子、单片机及数据库等技术，与其他各个管理系统模块的信息连接起来，实现先进的信息化管理。校园卡系统能够记录师生就餐、购物、图书借阅等数据，运用专网数据传输、集中化决算管理等形式，为校内人员身份识别、消费、结算提供了有力保障，促进了学校内部数据资源的交流与共享，大大提高了学校生活服务、校务管理的效率和水平。此外，校园卡系统的消费数据和身份识别数据，可关联学生消费习惯、借阅习惯、生活作息等，对学生家庭经济情况进行辅助判断，从而形成支撑学校决策的重要依据,是智慧校园建设必不可少的关键平台。

校园一卡通建设目标

在哈尔滨工程大学“一校多地”校园一卡通系统平台建设过程中，师生在不同校区生活、学习，每个人只能有一张卡和一套账务体系，同时还要考虑不同校区的个性化需求和管理方式。依照“一卡通用、数据共享、服务共用”的建设目标，师生持一张校园卡可在哈尔滨主校区、青岛校区、烟台校区无感知持卡消费和身份识别，感受相同的服务内容和服务标准。

统一的系统管理平台

各校区校园卡管理系统采用相同的密钥体系和业务逻辑架构，校园卡数据采用统一规范，可在各校区通用，每个校区拥有独立的校园卡管理平台和数据库，管理平台管理各自的业务系统，业务流程可以根据需要自行定义，校区间互不影响，也可共享。同时，各校区可根据各自的业务需要自行扩展计算资源、存储资源，拓展校园卡应用、服务流程和终端设备，在统一的管理平台下做到业务独立、账务独立和结算独立。

数据共享

主校区和分校区各自部署校园卡系统数据库，数据库架构、数据结构和数据标准完全相同，两边各自承载业务,统一管理公用数据。校区间公用数据通过运营商的专线网络实现同步，公用数据双向复制，当发生变化时，异地数据库定时同步。公用数据部分主要包括账户信息、交易数据、系统配置。公用数据在校园卡系统数据库通过双向复制保持一致性。

服务一体化

在统一的系统管理平台和数据共享的基础上，提供线上、线下一体化服务。师生的校园卡、二维码可在各校区通用，各类消费终端、水控终端、自助服务设备、身份认证设备全部采用统一的软硬件版本和应用服务模式，系统平台提供统一规范的第三方对接接口，并通过统一授权系统对第三方对接进行授权。各校区可根据业务需求的不同，分别提供个性化的服务内容和对接模式。

校园一卡通设计方案

哈尔滨工程大学校园一卡通系统平台采用“两地三中心”模式进行设计，考虑各校区间的物理距离可能导致专线网络不稳定，为确保各校区绝大多数本地用户校园卡应用的及时性和并发性，在各校区分别部署了校园一卡通管理平台、独立的数据库、独立的终端设备、独立的专网，校区间业务根据需要采取相应的数据共享及功能共用，解决跨校用卡需求。哈尔滨主校区、青岛校区、烟台校区的数据库服务器、应用服务器、计算资源和存储资源都具备独立运营能力。

数据库设计

为保证系统的可靠性，各校区都部署了数据库服务器，哈尔滨主校区和青岛校区作为校园一卡通数据中心分别部署Oracle ODA一体机，均采用Oracle RAC两结点集群，以保证应用的高可用性，同时可以自动实现并行处理及负载均衡，在系统负载时，RAC可以自动在多个节点之间平衡。

1.数据库架构。哈尔滨主校区和青岛校区的数据库服务器各自承载本校区校园一卡通业务。烟台校区的数据库服务器作为备用数据库，配置和程序与哈尔滨主校区完全相同，承担数据备份和容灾工作，数据库部署架构如图1所示。

图1 数据库架构

哈尔滨主校区和青岛校区的数据库服务器同时作为生产库，保持实时工作状态，负责本校区校园一卡通系统的卡务、交易、账务、结算等，产生的数据均保存在本地。烟台校区校园一卡通通过运营商专线直连哈尔滨。正常情况下，所有校园一卡通业务均连接主库进行办理，同时通过OGG同步软件将哈尔滨主校区数据库数据传输至本地备库。Oracle GoldenGate Extract进程从源数据库上的Oracle redo、归档日志文件或备用系统上附带的归档日志中捕获数据更改，当哈尔滨主校区主库出现问题时可快速切换至备库继续运行，从而实现数据的异地容灾保护和业务的高可用性。

2.数据的共享和交互。在师生因工作和学习的变动发生转校区的情况时，数据库可以通过安装定期数据同步程序将用户数据、卡账户数据、交易数据等公用数据进行双向复制，以保证师生在“两地”（哈尔滨主校区、青岛校区）的卡账户、交易流水、账务流水等数据的一致性和完整性。系统平台的交易参数、数据字典等系统参数也由同步程序完成。任何一方调整系统参数配置时，都不会因系统配置的不一致而导致应用服务异常。

业务逻辑设计

“两地三中心”架构模式下，哈尔滨主校区和烟台校区共同使用哈尔滨主校区数据中心的存储资源和计算资源，青岛校区使用自行部署的系统。虽然两套系统架构模式和版本完全一致，但是财务结算和对接方式不同，“两地”校园卡系统卡务、交易、结算、系统对接存在着互相联系和相对独立的情况，业务逻辑如图2所示。

图2 业务逻辑

1.卡务。师生个人基本信息主要包括学/工号、姓名、部门、校区、有效期等，以学/工号为关键字，根据学校人力资源处和学工处的师生编码要求将数据录入校园卡系统，可以确保校园卡账户信息的唯一性和一致性。个人基本信息中的校区字段用来区分师生所属校区情况，师生在所属校区开户、办卡、挂失/解挂、补办卡，当校区发生变动时，数据自动同步至异地校区。

2.交易。师生可持卡在任何校区充值、消费，交易流水包含学/工号、设备编号、交易类型、交易金额、流水号等数据项。哈尔滨主校区和青岛分校区分别建立了本校区的卡务管理中心，并各自管理本校区的消费终端、自助服务设备和水控终端。校区内不同类别的设备分别与各自的前置服务器进行业务和数据交互，前置服务器将搜集上来的交易流水暂时保存在数据文件内，然后由前置服务器向数据库服务器执行数据写入。交易记录能够标明某一刻师生在哪个设备发生了什么类型的交易，学/工号、流水号是每条交易记录的关键字，确保在写入数据库时数据行的唯一性和完整性。

3.结算。应哈尔滨主校区（含烟台校区）和青岛校区各自独立核算的要求，需分别统计出非本校区人员在本校区的消费数据，以统计报表的方式体现跨校区交易数据，并将该部分跨校区消费金额结算给对方。这部分的数据是以人员所在校区的属性区分，定期由财务结算，转给对方账户，并结算给各自的商户。

4.系统对接。校园一卡通系统与统一身份认证、校园信息门户、通道系统、网费/电费转账等信息管理平台都存在对接的需要，所以校园卡系统需提供统一的接口规范和对接整合各类信息系统。比如对于统一身份认证、校园信息门户等身份识别类的第三方对接应用需要与哈尔滨主校区数据中心对接；对于网费/电费转账、通道系统等缴费类、卡片读取类的对接就需与本地的校园卡系统前置服务器对接。灵活的对接方式可以提高对接效率，同时还可以提高系统对接的稳定运行。

效果分析

目前，学校的“两地三中心”校园卡系统平台已上线运行，为师生提供了方便、快捷的校园卡服务。师生在不同校区办卡、充值、消费和办理自助业务全部实现无差异化服务，不会因校区变动而给师生带来不便。校区内的独立结算和跨校区的财务结算也已按时完成，满足了学校的信息化建设要求和财务管理制度。经过一段时间运行后，发现仍存在一些问题，一方面是两个校区间数据同步的实时性仍需改进，师生用户数据、卡账户数据、交易数据等公用数据的数据复制周期需要优化；另一方面是哈尔滨主校区和青岛校区的数据库互为备份的体系尚未建立，存在一定安全风险。

“一校多地”的高校办学方式，为高等教育的发展带来的新的机遇，也为信息化管理带来了新的挑战。本文以哈尔滨工程大学校园卡系统的建设情况为依据，提出了一种跨省市校区建设的解决办法，关于校园一卡通系统的建设可能还有更好的建设方案，谨希望文章能够对信息化建设和校园一卡通建设提供一些思路。