【原】【案例】“一卡通用”让哈工程师生在多校区无忧通行

高校信息化 2020-11-07

展开全文

随着国家对高等教育的重视，很多高校都在扩展办学规模，"一校多区"、"跨省市校区"现象应运而生。多校区办学开拓了新的教育发展空间，弥补了教育资源的不足，增加了院校的整体竞争优势。多校区高校普遍存在师生跨校工作和学习的情况，随之而来的是这些"流动"用户对学校信息化资源提出的跨校区统一应用需求，校园一卡通作为学校就餐、门禁、购物、洗浴等师生最基本的工作生活支撑，在多校区实现"一卡通用"成为了师生最迫切的需求。

下面让我们走进哈尔滨工程大学，看看这所学校是如何实现跨省两校区间校园一卡通用的。

建设背景及需求

建设背景

哈尔滨工程大学现有哈尔滨校区（以下简称老校区）和青岛校区（正在建设中，以下简称新校区），未来两校区师生规模相当，一大部分师生有往返于两个校区的用卡需求。

老校区现有校园卡系统为2008年建设，主要应用在校园金融消费、身份识别应用服务和与第三方系统对接方面，实现了餐饮、超市、洗浴、洗衣、网费、电费、图书借阅、门禁、考勤和会议签到等应用，满足了老校区的基本需求，但还存在着一些不足，具体表现在系统功能不完善，不支持虚拟卡等在线应用；网络通信线路老化，终端设备超期运行；IDC支撑环境资源不足，缺乏异地灾备等安全措施；平台扩展性不强，尚无对多校区共用校园卡的规划设计。

目前大部分高校校园卡业务仍以实体卡应用为主，离线脱机支付运用于绝大多数场景，这限制了校园卡业务的进一步扩展。随着互联网的发展以及新兴移动支付技术的普及，联机在线消费模式的校园一卡通系统逐渐发展起来，虚拟校园卡的应用越来越被用户认可，弥补了原有物理卡片的不足，使校园卡业务得以在手机APP等载体进行线上办理，给师生带来极大的便利，同时简化了业务办理流程。

哈尔滨工程大学根据学校信息化工作安排，今年进行校园一卡通系统升级改造，建设在线交易模式，实体卡、虚拟卡、NFC等各种介质并存的新一代校园卡系统。多校区"一卡通用"是本次升级建设的重要内容。

建设需求

1.构建开放的校园一卡通平台：校园卡系统将采用开放式体系结构，不仅与目前已有信息系统平滑对接，而且建设标准的对接接口，实现灵活扩展应用服务。同时，系统支持虚拟卡和实体卡。

2.实现联机在线支付：改进校园卡支付模式，构建以在线联机支付为主的校园支付环境，建设校园卡移动端应用，使二维码、NFC等新型支付介质与传统卡介质融合，满足师生在校园内各种消费场所的移动支付应用需求，提升用户使用体验。

3.实现多校区"一卡通用"：两个校区共用同一套校园卡系统，师生可在两个校区食堂、超市、浴室、体育馆等场所消费，在两校区的门禁、通道等进行身份认证；两个校区校园卡系统数据共享，采用一体化的校园卡服务模式。

系统设计原则

为保障不同校区师生的使用体验，结合实际需求，采用"系统共用、数据共享、服务一体化"原则建设多校区校园卡系统。

1.系统共用：即新校区与老校区使用同样的校园一卡通管理平台，但分别独立部署在本地，管理平台管理各自的业务系统，对于跨校区业务通过发起任务脚本程序获取异地校区的数据，处理相应的业务。确保两校区间系统功能、数据结构和数据标准一致，从而向师生提供一致的服务。

2.数据共享：即新校区与老校区使用同样版本及结构的数据库，通过租用运营商VPN专线及Oracle Golden Gate数据同步技术实现校区间数据共享和交换，同时老校区校园卡数据与新校区互为异地容灾。

3.服务一体化：各校区校园一卡通的服务与管理模式一致，服务标准相同，新校区是老校区校园一卡通的延伸，实现两校区间真正的"一卡通用"，满足师生跨校区的无感知漫游用卡需求。

总体架构设计

本校两个校区跨多个省市，考虑两校区间的物理距离可能导致广域网络的不稳定，为确保各校区绝大多数本地用户校园卡应用的及时性和并发性，在两校区本地分别部署校园一卡通管理平台、独立的数据库、独立的终端设备、独立的专网，校区间业务根据需要采取相应的数据共享及功能共用，解决跨校用卡需求。系统总体架构如图1所示。

图1 两校区校园卡系统总体架构

1.网络层：各校区在本校区内建设独立的校园一卡通物理专网，确保本校区校园卡业务运行，校区间通过租用运营商VPN专线互联，搭建逻辑上的校园一卡通专网。

2.数据层：由于考虑跨校区之间广域网络的不稳定性，数据库采用分库部署架构，两校区数据库结构相同。为保障系统的使用性能，采用两台Oracle ODA一体机部署校园一卡通数据库系统，校区间两台Oracle ODA数据库服务器之间，采用Oracle Golden Gate技术，结合校园一卡通系统的任务脚本程序进行数据同步，实现两个校区之间数据双向复制。各校区通过Oracle ADG（Active Data Guard）技术将生产数据库的数据实时备份，该库同时对外提供校园一卡通数据查询、数据分析、第三方数据发布服务。在老校区设置与生产库不在同一楼宇的容灾服务器，通过Oracle DG（Data Guard）技术实现数据容灾，从而使校园一卡通数据存储形成"两地三中心"架构。

3.系统层：校园卡系统采用联机在线+授信模式，支持实体卡和虚拟卡应用，实体卡应用系统在每个校区建立一套独立的系统，共享账户信息，异步交互授信信息，主要功能包括卡务、结算、消费、水控、自助等模块。移动端的虚拟卡应用及Web应用共用一套部署在老校区的Web/APP服务，实现两校区共用在线办理的消费、充值、卡务、查询等功能。系统后台管理模块主要完成本校区各项通用功能，同时实现与异地校区的任务处理。

4.服务层：该层面向用户提供校园一卡通服务。两校区分别部署消费POS、水控、车载及自助卡务、自助现金充值、自助多媒体等服务终端。在软件应用方面，两校区共用所有Web服务和移动端服务。同时，校区间管理办法、业务流程、服务标准等相同，为用户提供一致的服务体验。

系统关键业务实现方案设计

为了提高系统的可靠性，采用分布式部署，关键业务采用微服务构架。系统支持实体卡和二维码等多种模式应用。通过授信机制和脱机码模式解决网络异常等环境下的应急使用。关键业务实施策略如下：

1.开户：用户的开户由人员人事关系所属的校区（即本地校区）完成，开户后信息同步至异地校区。

2.充值：每个用户在办卡时需要设定所属的校区，采用Web或APP充值时，所充金额进入用户所属校区的账号中，如采用现金充值，则首先进入用户充值所在地账户中。

3.消费：联机在线校园一卡通系统支持刷卡、虚拟卡正扫码、虚拟卡反扫码消费模式，其中，刷实体卡和虚拟卡反扫码业务系统交易流程一致，以实体卡为例，交易流程如图2所示。

图2 实体卡消费流程

用户在刷卡消费时首先判断消费终端是否在线，在线时则去本地系统中查询账户信息，如查询到账户为非本地，首先启动授信消费流程，确保用户消费的及时性。随即系统发起异地账户信息同步请求，将用户的账户余额及授信额度信息同步到异地数据库，同时，扣除用户本次消费金额，进而产生准确的交易流水信息，完成整个交易过程。

虚拟卡正扫码的交易流程如图3所示：

图3 虚拟卡正扫码消费流程

用户在正扫码消费时首先查询该账户是否为本地，如为本地账户则启动在线交易流程，扣费并返回交易信息；如查询到账户为非本地，则跳转到用户所在的异地服务器，再执行在线消费流程，在异地账户扣费后返回交易信息。

在技术方面，在线消费采用阻塞流程，交易过程中授权，交易请求环节采用可靠传输，交易后消息通知采用不可靠数据推送。通过每笔交易签名保证数据的安全可靠。通过划分不同的热点交易类型，高速缓存账户信息数据等方式，提高系统并发数和缩短交易时间，避免用户使用高峰期交易时间过长。

4.结算：财务结算方面，因校区所属省市不同，各校区根据当地财务管理要求独立结算。对于用户在异地校区消费的账务，按结算周期，各校区定期按整体收入和支出情况，转账给异地账户，由异地账户结算给商户。

5.卡务：因两校区间用户数据是双向同步，用户补卡、挂失等业务两个校区均可办理。同时，可通过自助服务终端向用户提供自助服务。

数据同步及安全方案设计

数据同步

跨校区数据同步主要分为账户（授信）信息同步、流水（交易、认证等）同步、结算数据同步。异地交易异步发起同步请求校验，确保账户、流水和结算数据的一致性。

采用两台OracleODA数据库一体机部署校园卡数据库系统，两校区分别部署一台，数据库服务器之间采用Oracle Golden Gate技术实时同步，实现两个校区之间数据双向复制。

在面向校内其他应用的第三方数据同步方面，通过学校统一的数据交换平台，将两校区的信息汇总后统一发布。信息内容主要包括：用户信息（制卡和生成虚拟卡账户信息等应用），实体卡片信息（门禁、通道等），在线认证信息（二维码身份认证），交易流水数据同步（用于大数据分析）、照片信息等。第三方数据同步流程如图4所示。