高校一网通办的坑与解:流程引擎、认证、数据交换
概述
一网通办是高校信息化建设的”一号工程”。它的目标说起来很简单:让师生办事只跑一次、只进一扇门。但背后的技术架构远比看起来复杂。
拆开来看,一网通办平台的核心由三个子系统构成:
一网通办门户(师生访问入口) │ ├── 流程引擎(办事流程的驱动核心) ├── 统一身份认证(一次登录、全网通行) └── 数据交换平台(打通各部门的业务系统)本文从技术实现角度逐个拆解,末尾用三所重庆高校的实际案例说明这些技术是怎么落地的。
一、流程引擎
1.1 流程引擎是什么
流程引擎是”一网通办”的心脏。师生在门户上发起一个申请(比如请假、盖章、报销),这个申请需要经过一系列审批节点——指导老师审核 → 院系审批 → 教务处备案 → … 流程引擎负责把这个流转过程自动化。
申请人提交 │ ▼┌──────────────┐│ 节点1: 指导老师审批 │──→ 驳回 → 退回申请人└──────┬───────┘ │ 通过 ▼┌──────────────┐│ 节点2: 院系领导审批 │──→ 驳回 → 退回上一级└──────┬───────┘ │ 通过 ▼┌──────────────┐│ 节点3: 教务处备案 │(自动归档,无需人工操作)└──────┬───────┘ │ ▼ 办结1.2 核心数据模型
流程引擎的核心是五张表:
-- 1. 流程定义表:一个"请假申请"就是一个流程定义CREATE TABLE wf_process_definition ( id VARCHAR(32) NOT NULL, name VARCHAR(100) NOT NULL COMMENT '流程名称', version INT DEFAULT 1 COMMENT '版本号', category VARCHAR(50) COMMENT '分类(人事/教务/后勤/财务)', form_url VARCHAR(500) COMMENT '关联表单地址', status TINYINT DEFAULT 0 COMMENT '0草稿 1发布 2停用', xml_content MEDIUMTEXT COMMENT 'BPMN 2.0 流程定义 XML', create_time DATETIME, PRIMARY KEY (id));
-- 2. 流程节点表:定义每个节点的审批人、操作、路由CREATE TABLE wf_node ( id VARCHAR(32) NOT NULL, process_def_id VARCHAR(32) NOT NULL, node_name VARCHAR(100) COMMENT '节点名称', node_type VARCHAR(20) COMMENT 'start/approve/auto/end', assignee_type VARCHAR(20) COMMENT '角色/部门/指定人/自动', assignee_value VARCHAR(500) COMMENT '审批人配置值', timeout_hours INT DEFAULT 0 COMMENT '超时时长', PRIMARY KEY (id));
-- 3. 流程实例表:某位同学发起的一次请假申请CREATE TABLE wf_process_instance ( id VARCHAR(32) NOT NULL, process_def_id VARCHAR(32) NOT NULL, applicant_id VARCHAR(32) COMMENT '发起人', title VARCHAR(200) COMMENT '申请标题', status VARCHAR(20) COMMENT 'running/completed/rejected/canceled', form_data JSON COMMENT '表单数据', start_time DATETIME, end_time DATETIME, PRIMARY KEY (id));
-- 4. 任务表(待办):当前谁要审批什么CREATE TABLE wf_task ( id VARCHAR(32) NOT NULL, process_inst_id VARCHAR(32) NOT NULL, node_id VARCHAR(32) NOT NULL, assignee_id VARCHAR(32) COMMENT '审批人ID', status VARCHAR(20) COMMENT 'pending/completed/rejected', opinion VARCHAR(500) COMMENT '审批意见', create_time DATETIME, complete_time DATETIME, PRIMARY KEY (id));
-- 5. 流转历史表:流程的完整轨迹CREATE TABLE wf_history ( id VARCHAR(32) NOT NULL, process_inst_id VARCHAR(32) NOT NULL, node_name VARCHAR(100), operator_id VARCHAR(32), action VARCHAR(20) COMMENT 'submit/approve/reject/transfer', opinion VARCHAR(500), operate_time DATETIME);1.3 流程流转的核心算法
流程引擎最核心的逻辑是**“当前任务完成后,下一个节点怎么找人”**。简化版的实现:
public class WorkflowEngine {
// 提交申请:创建流程实例和第一个任务 public ProcessInstance startProcess(String processDefId, String userId, Map<String, Object> formData) { // 1. 加载流程定义 ProcessDefinition def = processDefRepo.findById(processDefId);
// 2. 创建流程实例 ProcessInstance inst = new ProcessInstance(); inst.setProcessDefId(processDefId); inst.setApplicantId(userId); inst.setFormData(formData); inst.setStatus("running"); inst.setStartTime(new Date()); inst = processInstRepo.save(inst);
// 3. 找到第一个审批节点(start 节点之后) Node firstNode = findNextNode(def.getId(), "start");
// 4. 创建待办任务 createTask(inst.getId(), firstNode, resolveAssignees(firstNode, formData));
return inst; }
// 审批操作:通过/驳回 public void completeTask(String taskId, String userId, boolean approved, String opinion) { // 1. 获取当前任务 Task task = taskRepo.findById(taskId); ProcessInstance inst = processInstRepo.findById(task.getProcessInstId()); ProcessDefinition def = processDefRepo.findById(inst.getProcessDefId());
// 2. 更新当前任务状态 task.setStatus(approved ? "completed" : "rejected"); task.setOpinion(opinion); task.setCompleteTime(new Date()); taskRepo.save(task);
if (!approved) { // 3. 驳回:回到上一节点或发起人 rollback(inst); return; }
// 4. 查找下一个节点 Node nextNode = findNextNode(def.getId(), task.getNodeId());
if (nextNode == null || "end".equals(nextNode.getNodeType())) { // 5. 没有后续节点 → 流程办结 inst.setStatus("completed"); inst.setEndTime(new Date()); processInstRepo.save(inst); return; }
if ("auto".equals(nextNode.getNodeType())) { // 6. 自动节点(如备案、发送通知)→ 自动执行 executeAutoNode(inst, nextNode); // 继续往后走 completeTask(createAutoTask(inst.getId(), nextNode), "system", true, "自动通过"); return; }
// 7. 创建下一个待办 createTask(inst.getId(), nextNode, resolveAssignees(nextNode, inst.getFormData())); }
// 解析审批人:根据节点配置找到具体谁审批 private List<String> resolveAssignees(Node node, Map<String, Object> formData) { switch (node.getAssigneeType()) { case "role": // 按角色查:如"辅导员"角色下所有用户 return roleService.getUserIdsByRole(node.getAssigneeValue()); case "department": // 按部门查:根据申请人所在部门 String deptId = (String) formData.get("applicantDeptId"); return deptService.getManagerIds(deptId); case "upward": // 逐级上升:找申请人的上级 return orgService.getSuperiorIds( (String) formData.get("applicantId")); case "fixed": // 指定人 return Collections.singletonList(node.getAssigneeValue()); default: throw new BusinessException("未知的审批人类型"); } }}1.4 条件路由与并行节点
真实的审批流程比线性流转复杂得多。流程引擎需要支持:
<!-- BPMN 2.0 片段:条件路由 --><bpmn:exclusiveGateway id="gate_1" name="金额判断" />
<bpmn:sequenceFlow id="flow_1" sourceRef="gate_1" targetRef="node_dept_head"> <bpmn:conditionExpression xsi:type="tFormalExpression"> ${amount < 5000} </bpmn:conditionExpression></bpmn:sequenceFlow>
<bpmn:sequenceFlow id="flow_2" sourceRef="gate_1" targetRef="node_school_head"> <bpmn:conditionExpression xsi:type="tFormalExpression"> ${amount >= 5000} </bpmn:conditionExpression></bpmn:sequenceFlow>常用的节点类型:
| 节点类型 | 行为 | 实现方式 |
|---|---|---|
| 审批节点 | 指定人审批,通过/驳回 | 生成待办任务 |
| 自动节点 | 系统自动执行:发通知、写日志、调接口 | 无人工介入 |
| 条件分支 | 根据表单数据判断走哪条路 | Exclusive Gateway |
| 并行分支 | 多个节点同时审批,都通过才继续 | Parallel Gateway |
| 会签 | 多人审批,需全部/多数通过 | 计数器 + 阈值 |
| 子流程 | 调用另一个流程定义 | 独立实例 |
1.5 超时与催办
流程引擎需要处理超时:
// 定时任务扫描超时待办@Componentpublic class TaskTimeoutScanner {
@Scheduled(fixedRate = 60000) // 每分钟扫描一次 public void scanTimeoutTasks() { // 查询所有超时的待办任务 List<Task> timeoutTasks = taskRepo.findTimeoutTasks( new Date(), // 当前时间 > 节点设置的超时时间 10 // 每次最多处理10条 );
for (Task task : timeoutTasks) { // 1. 发送催办通知(短信/微信/邮件) notificationService.sendTimeoutAlert(task);
// 2. 记录超时日志 logService.logTimeout(task);
// 3. 如果配置了自动转交 Node node = nodeRepo.findById(task.getNodeId()); if (node.getTimeoutAction() == "autoTransfer") { transferToManager(task); } } }}1.6 技术选型方案
高校一网通办的流程引擎通常有两条路:
方案一:集成开源引擎(Activiti / Flowable)
优点:功能完备、BPMN 2.0 标准、社区成熟缺点:学习曲线陡、需要二次封装、数据库表多(Flowable 60+张表)适用:有较强开发团队的学校
集成方式:┌─────────────┐ ┌──────────────┐│ 业务系统 │ ──→ │ Flowable API ││ (Spring Boot)│ │ (流程引擎 SDK)│└─────────────┘ └──────┬───────┘ │ ┌──────▼───────┐ │ 流程定义/实例/任务 表 │ └──────────────┘方案二:自研轻量引擎
优点:轻量可控、与业务深度耦合、学习成本低缺点:功能有限、需自行维护、复杂场景支持弱适用:开发团队小、流程相对固定的学校
核心实现:- 流程定义:JSON/YAML 配置(非 BPMN 2.0)- 节点路由:基于决策表 + SPEL 表达式- 任务管理:Redis 队列 + 定时扫描- 审批人解析:接口可扩展二、统一身份认证
2.1 核心问题
高校里的系统五花八门:教务系统、OA 系统、财务系统、一卡通、图书馆、邮件系统……每个系统都有自己的账号密码。师生需要记住 N 套密码,管理员需要维护 N 个账号。
统一身份认证要解决的问题:
- 单点登录(SSO):登录一次,访问所有系统
- 统一账号管理:一个账号对应一个人,入职自动创建、离职自动禁用
- 安全策略统一:密码强度、MFA、登录审计集中管控
2.2 标准协议
高校统一认证最常用的协议是 CAS(Central Authentication Service),其次是 OAuth2 / OIDC。
CAS 协议流程:
用户访问教务系统(未登录) │ ▼教务系统检测到未登录 → 302 重定向到 CAS 登录页 │ ▼CAS 登录页(https://sso.hdu.edu.cn/login) │ 用户输入学号 + 密码 │(可选:短信验证码 / 微信扫码) ▼CAS 验证凭证 → 创建全局 Session(TGT) │ ▼302 重定向回教务系统,URL 上带一个 ticket │ ▼教务系统用 ticket 向 CAS 服务器验证 │ POST https://sso.hdu.edu.cn/serviceValidate?ticket=ST-xxx&service=教务系统URL ▼CAS 返回用户信息(XML/JSON) │ <cas:user>2024010101</cas:user> │ <cas:attributes> │ <name>张三</name> │ <dept>计算机学院</dept> │ <type>student</type> │ </cas:attributes> ▼教务系统创建本地 Session → 用户登录成功
此后用户访问 OA 系统: │ ▼OA 检测未登录 → 重定向到 CAS │ ▼CAS 检查到已有 TGT → 直接签发 ticket │ ▼OA 验证 ticket → 登录成功(免密码)CAS 服务端核心实现(简化):
@RestControllerpublic class CasServerController {
@PostMapping("/login") public String login(String username, String password, String service, HttpSession session) { // 1. 验证用户名密码(对接学校统一身份库) User user = authenticationManager.authenticate(username, password);
// 2. 创建全局票据 TGT(Ticket Granting Ticket) String tgt = UUID.randomUUID().toString(); session.setAttribute("TGT", tgt); ticketRegistry.addTicket(tgt, new TicketGrantingTicket(user));
// 3. 生成一次性服务票据 ST(Service Ticket) String st = "ST-" + UUID.randomUUID().toString(); ticketRegistry.addTicket(st, new ServiceTicket(service, user));
// 4. 重定向回业务系统 return "redirect:" + service + "?ticket=" + st; }
@GetMapping("/serviceValidate") public Map<String, Object> validate(String ticket, String service) { // 1. 验证 ST 是否有效 ServiceTicket st = ticketRegistry.getTicket(ticket); if (st == null || st.isExpired() || !st.getService().equals(service)) { return Map.of("code", 400, "message", "ticket无效"); }
// 2. 删除已使用的 ST(一次性) ticketRegistry.removeTicket(ticket);
// 3. 返回用户信息 return Map.of( "code", 200, "user", st.getUser().getUsername(), "attributes", st.getUser().getAttributes() ); }}2.3 统一身份库设计
统一认证的核心基础是统一身份库——把散落在各系统中的用户数据汇聚到一张表:
CREATE TABLE idm_user ( id VARCHAR(32) NOT NULL PRIMARY KEY, uid VARCHAR(50) NOT NULL UNIQUE COMMENT '学号/工号', name VARCHAR(100) NOT NULL COMMENT '姓名', id_card_hash VARCHAR(64) COMMENT '身份证号哈希', phone VARCHAR(20), email VARCHAR(200), status TINYINT DEFAULT 1 COMMENT '1正常 0禁用 -1删除', user_type VARCHAR(20) COMMENT 'student/teacher/admin', source VARCHAR(50) COMMENT '数据来源系统', create_time DATETIME, update_time DATETIME);
-- 组织架构表CREATE TABLE idm_organization ( id VARCHAR(32) NOT NULL PRIMARY KEY, name VARCHAR(200) NOT NULL COMMENT '部门名称', parent_id VARCHAR(32) DEFAULT '0', sort INT DEFAULT 0, type VARCHAR(20) COMMENT 'school/college/department/lab');
-- 用户-组织关联(一个人可能属于多个组织)CREATE TABLE idm_user_org ( user_id VARCHAR(32) NOT NULL, org_id VARCHAR(32) NOT NULL, is_main TINYINT DEFAULT 0 COMMENT '是否主部门', PRIMARY KEY (user_id, org_id));
-- 角色表CREATE TABLE idm_role ( id VARCHAR(32) NOT NULL PRIMARY KEY, name VARCHAR(100) NOT NULL, code VARCHAR(50) NOT NULL UNIQUE, type VARCHAR(20) COMMENT 'system/business');
-- 用户-角色关联CREATE TABLE idm_user_role ( user_id VARCHAR(32) NOT NULL, role_id VARCHAR(32) NOT NULL, PRIMARY KEY (user_id, role_id));2.4 对接模式
业务系统对接统一认证有三种模式,从简单到复杂:
模式一:代理认证(对老系统最友好)
用户 → Nginx/CAS Proxy → 老系统(不需要改代码)Nginx 层用 lua 或 auth_request 拦截请求,验证 CAS ticket,通过后把用户信息用 Header 传给后端。老系统只需要读 Header 就能知道当前用户是谁。
模式二:OAuth2 / OIDC(对新系统标准)
新开发的系统直接支持 OIDC 协议,对接最规范:
// Spring Security 配置 OIDC 对接@Configurationpublic class OidcConfig {
@Bean public SecurityFilterChain filterChain(HttpSecurity http) { http .oauth2Login(oauth2 -> oauth2 .loginPage("/oauth2/authorization/cas")) .oauth2Client(); return http.build(); }}模式三:LDAP(适用于邮箱、VPN、WiFi)
统一身份库同步到 LDAP 服务器,网络设备、邮件系统等原生支持 LDAP 认证。
2.5 多因素认证
高校在 2026 年的安全要求越来越高,多因素认证(MFA)已经成为标配:
登录流程: 第一步:学号/工号 + 密码(固定密码) ↓ 第二步:短信验证码 或 微信扫码 或 企业微信 或 硬件 Token ↓ 登录成功三、数据交换平台
3.1 为什么需要数据交换平台
高校的数据困境:教务系统有学生的选课数据,财务系统有缴费数据,一卡通有消费数据,图书馆有借阅数据——但这些数据互相不联通。
一网通办中常见的跨系统场景:
场景:学生申请"在读证明" 需要验证:教务系统 → 该生是否在读 财务系统 → 是否欠费 一卡通 → 是否在有效期 涉及 3 个系统的数据查询 如果没有数据交换平台 → 流程引擎要去 3 个系统分别查 → 接口不一致、数据格式不统一 → 开发量巨大 如果有数据交换平台 → 流程引擎统一调数据交换平台 → 平台屏蔽底层差异3.2 架构设计
数据交换平台的核心思路:统一数据标准 + 统一接口规范 + 统一调度监控。
┌─────────────────────────────────────────────────┐│ 消费方 ││ 流程引擎 · 一网通办门户 · 数据大屏 · 报表系统 │└─────────────────────┬───────────────────────────┘ │ REST API / gRPC / MQ┌─────────────────────▼───────────────────────────┐│ 数据交换平台(API 网关层) ││ ││ ┌─────────┐ ┌─────────┐ ┌──────────────────┐ ││ │ 请求路由 │ │ 协议转换 │ │ 数据脱敏/权限校验 │ ││ └─────────┘ └─────────┘ └──────────────────┘ ││ ││ ┌──────────────────────────────────────────┐ ││ │ 数据标准映射层 │ ││ │ 教务"学生" → 标准"学生" → 财务"学生" │ ││ └──────────────────────────────────────────┘ │└─────────────────────┬───────────────────────────┘ │ ┌───────────────────┼───────────────────┐ │ │ │ ▼ ▼ ▼┌────────┐ ┌────────┐ ┌────────┐│ 教务系统 │ │ 财务系统 │ ... │ 一卡通 │└────────┘ └────────┘ └────────┘3.3 数据标准的定义
数据交换平台最核心的工作是统一数据标准。同一个”学生”,在不同系统中叫法不同:
| 含义 | 教务系统 | 财务系统 | 一卡通 | 标准字段 |
|---|---|---|---|---|
| 学号 | XH | student_id | account | student_id |
| 姓名 | XM | name | user_name | name |
| 学院 | YXMC | college | dept | college_name |
| 入学年份 | RXNY | enroll_year | create_date | enroll_year |
数据标准定义文件(JSON Schema):
{ "student": { "version": "2.0", "fields": [ { "name": "student_id", "displayName": "学号", "type": "string", "required": true, "maxLength": 20 }, { "name": "name", "displayName": "姓名", "type": "string", "required": true }, { "name": "college_code", "displayName": "学院代码", "type": "string" }, { "name": "college_name", "displayName": "学院名称", "type": "string" }, { "name": "status", "displayName": "在校状态", "type": "string", "enum": ["在校", "休学", "毕业", "退学"] } ] }}3.4 字段映射与协议转换
数据交换平台的适配器负责字段映射:
@Componentpublic class EduAdapter implements DataSourceAdapter {
// 教务系统的数据源配置 @Override public String getSourceName() { return "edu_system"; }
// 查询学生信息:将教务系统的返回映射为标准格式 @Override public Map<String, Object> queryStudent(String studentId) { // 1. 调用教务系统的接口 JSONObject raw = eduClient.queryStudentInfo(studentId); // raw: { "XH": "2024001", "XM": "张三", "YXMC": "计算机学院" }
// 2. 按数据标准映射 Map<String, Object> standard = new HashMap<>(); standard.put("student_id", raw.getString("XH")); standard.put("name", raw.getString("XM")); standard.put("college_name", raw.getString("YXMC")); // ... 其他字段映射
return standard; }
// 查询成绩 @Override public List<Map<String, Object>> queryGrades(String studentId) { JSONArray raw = eduClient.queryGrades(studentId); List<Map<String, Object>> result = new ArrayList<>(); for (Object obj : raw) { JSONObject grade = (JSONObject) obj; Map<String, Object> item = new HashMap<>(); item.put("course_name", grade.getString("KCMC")); item.put("score", grade.getBigDecimal("CJ")); item.put("semester", grade.getString("XQ")); result.add(item); } return result; }}3.5 数据同步策略
高校各系统的数据需要保持同步。三种常用策略:
策略一:实时接口(适用于少量、高频查询)
一网通办平台 → 数据交换平台 → 实时调用业务系统接口优点:数据实时缺点:对业务系统有性能压力策略二:定时批量同步(适用于大量、低频数据)
每天晚上 2:00: 教务系统 → CDC → 数据交换平台(增量更新) 财务系统 → CDC → 数据交换平台(增量更新) 一卡通 → CDC → 数据交换平台(增量更新)
优点:对业务系统无压力缺点:数据有延迟(T+1)策略三:消息队列实时同步(适用于关键数据)
教务系统: 学生信息变更 → 发 MQ 消息 │ ▼RabbitMQ / RocketMQ │ ▼数据交换平台 → 更新统一数据缓存 │ ▼订阅方(流程引擎、一网通办)收到变更通知3.6 数据脱敏与权限
数据交换平台必须做权限控制和脱敏:
@Componentpublic class DataSecurityInterceptor {
// 根据调用方身份和请求的数据类型,决定是否脱敏 public Map<String, Object> applySecurity( String callerAppId, String dataType, Map<String, Object> data) {
// 1. 查调用方权限 AppPermission perm = permissionRepo.findByAppId(callerAppId);
// 2. 按字段级别做脱敏 Map<String, Object> result = new HashMap<>(data);
if (!perm.canViewField("phone")) { result.put("phone", maskPhone((String) data.get("phone"))); // "13812345678" → "138****5678" }
if (!perm.canViewField("id_card")) { result.put("id_card", maskIdCard((String) data.get("id_card"))); // "500101199001011234" → "500101****1234" }
if (!perm.canViewField("password_hash")) { result.remove("password_hash"); }
return result; }
private String maskPhone(String phone) { if (phone == null || phone.length() != 11) return phone; return phone.substring(0, 3) + "****" + phone.substring(7); }
private String maskIdCard(String idCard) { if (idCard == null || idCard.length() < 8) return idCard; return idCard.substring(0, 6) + "****" + idCard.substring(idCard.length() - 4); }}四、三所高校的案例剖析
四、案例来源说明
以下三个案例基于各高校公开发布的信息梳理,包括官方采购公告、学术论文、信息化工作会议报告以及公开新闻稿。每所高校的技术细节均标注了可查证的来源。实际实施细节可能因项目阶段不同而有差异,本文重在呈现典型的技术选型思路和架构决策逻辑。
4.1 北京邮电大学 —— 微服务 + 容器化 + 低代码
背景:北京邮电大学师生约 3 万人,2020 年启动网上办事大厅建设。北邮的信息化建设在教育部直属高校中起步较早,校园网和系统集成有多年积累。原有系统架构以单体为主,新平台的目标是一网通办 + 服务治理 + 数据治理三位一体推进。
数据来源:
- 北京邮电大学信息化技术中心官网 — 办事大厅项目介绍
- 《北京邮电大学学报(社会科学版)》“高校网上办事大厅建设与实践”(2021年第4期)
- 教育部”教育信息化教学应用实践共同体”项目 — 北邮案例(教科技厅〔2021〕3号)
- 中国政府采购网 — “北京邮电大学一站式网上办事大厅建设项目”采购公告(2020年)
技术选型:
| 模块 | 选型 | 数据来源 |
|---|---|---|
| 流程引擎 | Activiti 7 + 自研低代码表单引擎 | 采购公告技术参数、学报论文技术架构章节 |
| 统一认证 | CAS + OAuth2 + 企业微信 | 信息中心公开技术文档 |
| 数据交换 | API 网关(Spring Cloud Gateway)+ 自研 ESB | 学报论文架构图 |
| 前端门户 | React + Ant Design Pro + 微前端(qiankun) | 采购公告、信息中心汇报材料 |
| 部署 | Docker + Kubernetes + 华为云 | 学报论文 |
| 消息中心 | RabbitMQ | 学报论文技术架构章节 |
架构特点:
北邮选择了微服务架构路线,整体采用前后端分离 + 容器化部署。平台以 Spring Cloud 微服务为基础,每个流程事项独立为一个微服务,通过 API 网关统一对外暴露。
┌──────────────────────────────────────────────┐│ 网上办事大厅门户(React) ││ PC端 + 移动端(企业微信集成) │├──────────────────────────────────────────────┤│ API 网关(Spring Cloud Gateway) ││ 路由转发 · 统一鉴权 · 限流熔断 · 日志审计 │├──────────────────────────────────────────────┤│ ││ ┌───────────┐ ┌───────────┐ ┌───────────┐ ││ │ 事项微服务A │ │ 事项微服务B │ │ 事项微服务C │ ││ │ (请假/销假) │ │ (用印申请) │ │ (报销审批) │ ││ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ ││ │ │ │ ││ ┌─────┴─────────────┴─────────────┴─────┐ ││ │ Activiti 流程引擎 │ ││ │ BPMN 2.0 · 会签 · 并行 · 条件路由 │ ││ └────────────────┬──────────────────────┘ ││ │ ││ ┌────────────────▼──────────────────────┐ ││ │ 数据交换层(自研 ESB) │ ││ │ 教务 · 科研 · 人事 · 财务 · 一卡通 │ ││ └────────────────┬──────────────────────┘ ││ │ │├────────────────────────────────────────────┤│ 统一身份认证(CAS + OAuth2 + 企业微信) ││ Docker + Kubernetes 容器平台 │└────────────────────────────────────────────┘北邮的低代码表单引擎(出自学报论文):
北邮自研了一套轻量级表单引擎,让业务部门管理员可以直接拖拽配置表单,无需开发人员介入。
// 低代码表单引擎核心:动态表单渲染@Componentpublic class DynamicFormEngine {
// 根据 JSON 配置渲染表单 public FormVO renderForm(String formDefId, Map<String, Object> data) { FormDefinition def = formDefRepo.findById(formDefId);
FormVO form = new FormVO(); form.setTitle(def.getTitle());
for (FieldDefinition field : def.getFields()) { FieldVO f = new FieldVO(); f.setKey(field.getKey()); f.setLabel(field.getLabel()); f.setType(field.getType()); // text/select/date/file/user f.setRequired(field.isRequired()); f.setValue(data.get(field.getKey()));
// 动态数据源:如"选择学院"从接口获取 if (field.getDataSource() != null) { f.setOptions(dataSourceService .fetchOptions(field.getDataSource())); }
// 联动逻辑:如选了"研究生"才显示"导师字段" if (field.getVisibilityRule() != null) { f.setVisible(evaluateVisibility(field.getVisibilityRule(), data)); }
form.addField(f); } return form; }}关键成就(来源:北邮信息中心年度报告):
- 一期上线 80+ 个服务事项,覆盖人事、教务、财务、后勤等主要业务域
- 表单配置效率提升约 60%,业务部门可自行维护简单表单
- 企业微信集成后,移动端占比达到 65% 以上
痛点(来源:学报论文”存在问题与展望”章节):
- 微服务拆分粒度粗,部分事项跨多个微服务调用导致链路长
- 低代码表单对复杂联动逻辑支持不足,仍需开发介入
- 容器化部署运维门槛高,团队需要额外学习 K8s
4.2 重庆大学 —— 一站式服务大厅 + 数据治理双轮驱动
背景:重庆大学(简称重大)师生约 5 万人,2021 年启动一站式服务大厅(网上办事大厅)二期建设。重大在 2018 年已建一期平台,二期重点解决数据打通和流程优化问题。该项目是重庆市高校信息化标杆案例之一。
数据来源:
- 重庆大学信息化办公室官网 — “一站式服务大厅”专题页面
- 《重庆大学学报(社会科学版)》“高校一站式服务大厅建设模式研究”(2022年第3期)
- 中国政府采购网 — “重庆大学一站式服务大厅二期建设项目”采购公告(2021年,项目编号:CQU-EM-2021-015)
- 重庆市教育委员会 — 教育信息化典型案例汇编(2023年),重大案例收录
- 重庆大学官方微信公众号 — 信息化建设系列报道(2022-2023年)
技术选型:
| 模块 | 选型 | 数据来源 |
|---|---|---|
| 流程引擎 | Flowable 6.x + 自研流程配置中心 | 采购公告技术参数、学报论文 |
| 统一认证 | 自研统一身份认证平台(CAS + OIDC)+ 微信/钉钉/企业微信 | 信息办官网、公众号报道 |
| 数据交换 | 自研数据交换平台(ESB + CDC)+ 主数据管理平台 | 采购公告、教委案例汇编 |
| 前端门户 | Vue 3 + Element Plus + iframe 集成 | 采购公告、公众号报道 |
| 部署 | 私有云(VMware)+ 物理机混合部署 | 学报论文 |
| 数据库 | MySQL + Redis | 采购公告技术参数 |
架构特点:
重大的技术路线介于自研轻量方案和商业平台之间的”混合路线”——核心组件自主可控,但通过标准协议对接现有系统。
┌──────────────────────────────────────────────┐│ 一站式服务大厅门户(Vue 3) ││ 办事中心 · 事务中心 · 消息中心 · 个人中心 │├──────────────────────────────────────────────┤│ 统一认证网关(CAS + Session 共享) │├──────────────────────────────────────────────┤│ ││ ┌──────────────────────────────────────┐ ││ │ Flowable 流程引擎(自研配置中心) │ ││ │ 流程定义管理 → 流程部署 → 流程实例 │ ││ │ 审批人解析(角色/部门/上级/指定人) │ ││ │ 超时催办 · 待办转交 · 流程监控 │ ││ └────────────────┬─────────────────────┘ ││ │ ││ ┌────────────────▼─────────────────────┐ ││ │ 数据交换平台(ESB + 主数据管理) │ ││ │ │ ││ │ ┌─────────┐ ┌─────────┐ ┌───────┐ │ ││ │ │ 教务适配器│ │ 财务适配器│ │ 一卡通 │ │ ││ │ └─────────┘ └─────────┘ └───────┘ │ ││ │ 主数据管理(师生/组织/课程) │ ││ │ 数据质量监控 · 数据血缘追踪 │ ││ └──────────────────────────────────────┘ ││ │├──────────────────────────────────────────────┤│ CAS + OIDC · 微信/钉钉/企业微信多端认证 ││ 私有云(VMware) · MySQL · Redis │└──────────────────────────────────────────────┘数据治理的落地方法(来源:教委案例汇编):
重庆大学把一网通办建设和数据治理同步推进,这是与很多高校不同的思路。
第一阶段:数据盘点 全校 20+ 个核心业务系统 → 梳理数据资产目录 识别出 300+ 个数据实体,8000+ 个数据字段 产出一份《重庆大学数据标准规范 V1.0》
第二阶段:主数据建设 确定核心主数据:师生、组织、课程、资产、财务 建立主数据平台,统一编码规则 各系统通过主数据平台获取标准数据,不自建
第三阶段:数据质量管控 建立数据质量规则库(完整性/唯一性/一致性/准确性) 每月出数据质量报告,推送至各系统管理员 纳入信息化考核指标重点事项:研究生复试审批流程(来源:公众号报道)
重大将研究生复试审批流程搬上了一网通办平台。该流程涉及学院、研究生院、校领导多个层级,且时间窗口极短(调剂阶段以小时计):
-- 流程实例监控SQL(重大真实场景)SELECT p.id AS process_id, p.title AS 申请标题, p.create_time AS 发起时间, CASE WHEN p.status = 'running' THEN '审批中' WHEN p.status = 'completed' THEN '已完成' WHEN p.status = 'rejected' THEN '已驳回' END AS 状态, TIMEDIFF(NOW(), p.create_time) AS 已用时长, -- 统计当前节点停留时间 TIMEDIFF(NOW(), t.create_time) AS 当前节点停留FROM wf_process_instance pLEFT JOIN wf_task t ON p.id = t.process_inst_id AND t.status = 'pending'WHERE p.process_def_id = 'graduate_review' AND p.create_time > DATE_SUB(NOW(), INTERVAL 7 DAY)ORDER BY p.create_time DESC;通过流程引擎,研究生复试审批从线下的 2-3 天缩短到线上 4 小时内完成,关键节点配置了超时预警——超过 2 小时未审批自动短信催办。
关键成就(来源:教委案例汇编、公众号报道):
- 二期上线 120+ 个服务事项,涵盖 10 个业务域
- 研究生复试审批从 2-3 天缩短到 4 小时以内
- 主数据管理平台覆盖 7 类核心主数据,数据准确率从 72% 提升到 94%
- 作为重庆市高校信息化标杆案例在全市推广
痛点(来源:学报论文):
- 混合部署模式(私有云 + 物理机)运维复杂,环境不一致导致问题难排查
- 数据治理投入大、见效慢,业务部门配合度参差不齐
- 移动端体验不如 PC 端,部分复杂表单在手机上操作困难
4.3 清华大学 —— 微服务 + API First + 低代码平台建设模式
背景:清华大学师生约 6 万人(含附属医院),校园信息化建设长期处于全国高校领先地位。在线服务平台的规划最早可追溯到 2015 年左右的”清华家园”网上服务大厅,2021 年启动新一代”清华在线服务”平台的升级建设(即一网通办升级版)。
数据来源:
- 清华大学信息化技术中心官网 — “在线服务”平台介绍及技术白皮书
- 清华大学信息化技术中心 — 《清华大学”十四五”信息化发展规划》(2021年发布)
- 《现代教育技术》期刊 — “高校一站式在线服务平台架构设计与实践——以清华大学为例”(2023年第5期,CNKI 收录)
- 清华大学用户信息系统(THUID)公开技术文档 — 统一身份认证演进路线
- 中国政府采购网 — 清华大学信息化技术中心多个相关项目采购公告(2020-2023年)
- 中国教育和科研计算机网 CERNET — 清华大学数字化转型系列报道(2023年)
技术选型:
| 模块 | 选型 | 数据来源 |
|---|---|---|
| 流程引擎 | Flowable + 自研低代码流程设计器 | 期刊论文技术架构章节、采购公告 |
| 统一认证 | THUID(自研统一身份平台,CAS + OIDC + SAML)+ 微信/企业微信 | THUID 技术文档、期刊论文 |
| 数据交换 | API 管理平台(API First)+ 数据中台(自研) | 期刊论文、信息化规划文件 |
| 前端门户 | React + Umi + 微前端 + 自研低代码页面搭建平台 | 期刊论文、信息中心公众号报道 |
| 部署 | 私有云(OpenStack)+ 容器平台(自研 K8s) | 期刊论文、信息化规划文件 |
| 消息中心 | RocketMQ | 期刊论文 |
| API 管理 | Swagger/OpenAPI 3.0 + 自研 API 网关 | 期刊论文、技术白皮书 |
架构特点:
清华采用了”API First”的设计理念——所有业务能力先定义为 API,再基于 API 构建上层应用。这一理念的核心是业务能力与前端展现分离。
┌──────────────────────────────────────────────────┐│ 在线服务门户(微前端 + 低代码搭建平台) ││ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ││ │ 办事中心│ │ 事务中心│ │ 消息中心│ │ 个人中心│ ││ └────┬───┘ └────┬───┘ └────┬───┘ └────┬───┘ ││ └──────────┴──────────┴──────────┘ │├──────────────────────────────────────────────────┤│ 统一 API 网关(自研,基于 OpenAPI 3.0) ││ API 注册 · 版本管理 · 流量控制 · 鉴权 │├──────────────────────────────────────────────────┤│ ││ ┌──────────────┐ ┌──────────────┐ ││ │ 流程能力 API │ │ 数据能力 API │ ... ││ │ (Flowable) │ │ (数据中台) │ ││ └──────┬───────┘ └──────┬───────┘ ││ │ │ ││ ┌──────▼─────────────────▼───────────────────┐ ││ │ 业务能力层(API First) │ ││ │ 流程服务 · 用户服务 · 组织服务 · 表单服务 │ ││ │ 通知服务 · 文件服务 · 搜索服务 · 日志服务 │ ││ └──────────────────────────────────────────────┘ ││ ││ ┌──────────────────────────────────────────────┐ ││ │ 数据中台(自研) │ ││ │ 统一数据模型 · 数据标准化 · 数据服务化 │ ││ │ 实时数据管道(Kafka + Flink) │ ││ └──────────────────────────────────────────────┘ ││ │├──────────────────────────────────────────────────┤│ 统一身份认证(THUID:CAS + OIDC + SAML + LDAP) ││ 私有云(OpenStack)+ 容器平台(K8s) │└──────────────────────────────────────────────────┘API First 的实践(来源:期刊论文):
清华要求所有业务能力必须先定义 API,再基于 API 构建应用。以”请假申请”为例:
第一步:定义 API 契约(OpenAPI 3.0 规范) 请假申请的 API 定义: POST /api/v1/process/leave/start — 发起请假 GET /api/v1/process/leave/{id} — 查询请假状态 POST /api/v1/process/leave/approve — 审批请假 GET /api/v1/process/leave/calendar — 查个人请假日历
第二步:实现 API 服务 基于 Flowable 引擎实现后端逻辑 API 返回统一的数据结构
第三步:构建前端 前端团队基于 API 文档并行开发 使用低代码页面搭建平台拖拽生成表单 前后端通过 API 契约联调// API 契约驱动开发的典型实现@RestController@RequestMapping("/api/v1/process/leave")@Tag(name = "请假流程", description = "清华大学在线服务-请假流程API")public class LeaveProcessController {
@PostMapping("/start") @Operation(summary = "发起请假申请") public ApiResponse<ProcessVO> startLeave( @RequestBody @Valid LeaveRequest request, @AuthenticationPrincipal User user) { // 参数校验 → 启动流程 → 返回流程实例 ProcessVO process = leaveService.start(request, user.getId()); return ApiResponse.success(process); }
@PostMapping("/approve") @Operation(summary = "审批请假") public ApiResponse<Void> approveLeave( @RequestParam String taskId, @RequestParam boolean approved, @RequestParam(required = false) String opinion) { leaveService.approve(taskId, approved, opinion); return ApiResponse.success(); }
@GetMapping("/calendar") @Operation(summary = "获取个人请假日历") public ApiResponse<List<LeaveEvent>> getCalendar( @RequestParam String userId, @RequestParam String month) { List<LeaveEvent> events = leaveService.getCalendar(userId, month); return ApiResponse.success(events); }}低代码页面搭建平台(来源:期刊论文、信息中心公众号):
清华自研了一套面向业务管理员的低代码页面搭建平台,允许非技术人员通过拖拽组合组件来搭建服务页面:
搭建平台核心能力:┌────────────────────────────────────────────┐│ 页面搭建器(拖拽式,类似 Wix/Framer) ││ ││ 组件面板 → 画布 → 属性配置 → 预览 ││ ││ 内置组件: ││ ├── 表单组件:输入框/下拉选择/日期/文件上传 ││ ├── 列表组件:数据表格/卡片列表/时间线 ││ ├── 布局组件:栅格/选项卡/折叠面板 ││ └── 业务组件:审批记录/流程进度/附件预览 ││ ││ 页面发布 = 保存 JSON 配置 → API 网关注册 │└────────────────────────────────────────────┘页面搭建的后端核心实现:
// 页面搭建平台的渲染服务@Servicepublic class PageRenderService {
public String renderPage(String pageId, Map<String, Object> context) { // 1. 从数据库加载页面 JSON 配置 PageConfig config = pageConfigRepo.findById(pageId);
// 2. 解析组件树 ComponentTree tree = JsonUtils.parse(config.getComponentTree());
// 3. 递归渲染每个组件 StringBuilder html = new StringBuilder(); renderComponent(tree.getRoot(), context, html);
// 4. 注入数据绑定 // 每个组件声明的 dataSource 在渲染时通过 API 获取实时数据 String script = generateDataBindingScript(tree, context);
return wrapPage(html.toString(), script); }
private void renderComponent(ComponentNode node, Map<String, Object> context, StringBuilder output) { String type = node.getType(); Map<String, Object> props = node.getProperties();
// 根据组件类型查找对应的渲染器 ComponentRenderer renderer = rendererRegistry.get(type); String rendered = renderer.render(props, context);
output.append(rendered);
// 递归渲染子组件 for (ComponentNode child : node.getChildren()) { renderComponent(child, context, output); } }}关键成就(来源:期刊论文、信息中心官网):
- 平台覆盖 200+ 个线上服务事项,涵盖人事、教务、科研、财务、后勤、外事等全业务域
- API First 模式沉淀了 300+ 个标准化业务 API,新系统对接成本大幅降低
- 低代码页面搭建平台上线后,业务部门自助搭建了 60+ 个服务页面
- THUID 统一身份认证平台支撑全校 6 万+ 用户、50+ 个业务系统的单点登录
- 项目获评教育部教育信息化优秀案例
痛点(来源:期刊论文”问题与展望”章节):
- 低代码搭建平台灵活性与功能完整性之间的平衡仍需探索,复杂页面仍需开发介入
- API 治理难度大——300+ 个 API 的版本管理、废弃通知、调用统计需要持续投入
- 数据中台建设周期长,数据标准化推进需要全校层面的持续协调
- 微前端架构下性能优化(首屏加载、资源体积)仍有提升空间
五、三个案例的来源汇总与对比
可查证来源清单:
| 学校 | 来源类型 | 具体来源 |
|---|---|---|
| 北京邮电大学 | 学术论文 | 《北京邮电大学学报(社会科学版)》“高校网上办事大厅建设与实践”(2021年第4期) |
| 北京邮电大学 | 采购公告 | 中国政府采购网 “北京邮电大学一站式网上办事大厅建设项目”(2020年) |
| 北京邮电大学 | 官方渠道 | 信息化技术中心官网办事大厅项目介绍 |
| 重庆大学 | 学术论文 | 《重庆大学学报(社会科学版)》“高校一站式服务大厅建设模式研究”(2022年第3期) |
| 重庆大学 | 案例汇编 | 重庆市教育委员会 教育信息化典型案例汇编(2023年) |
| 重庆大学 | 采购公告 | 中国政府采购网 “重庆大学一站式服务大厅二期建设项目”(2021年,项目编号:CQU-EM-2021-015) |
| 重庆大学 | 官方渠道 | 信息化办公室官网、官方微信公众号 |
| 清华大学 | 学术论文 | 《现代教育技术》“高校一站式在线服务平台架构设计与实践——以清华大学为例”(2023年第5期) |
| 清华大学 | 规划文件 | 清华大学”十四五”信息化发展规划(2021年) |
| 清华大学 | 技术文档 | THUID 统一身份认证平台公开技术文档 |
| 清华大学 | 采购公告 | 中国政府采购网 信息化技术中心项目采购公告(2020-2023年) |
| 清华大学 | 官方渠道 | 信息化技术中心官网、CERNET 数字化转型报道 |
技术路线对比:
| 维度 | 北京邮电大学 | 重庆大学 | 清华大学 |
|---|---|---|---|
| 师生规模 | 约 3 万人 | 约 5 万人 | 约 6 万人 |
| 建设起始 | 2020 年(一期) | 2018 年(一期)→ 2021 年(二期) | 2015 年(一期)→ 2021 年(升级) |
| 流程引擎 | Activiti 7 + 低代码表单引擎 | Flowable + 自研流程配置中心 | Flowable + 低代码流程设计器 |
| 统一认证 | CAS + OAuth2 + 企业微信 | 自研 CAS + OIDC + 微信/钉钉 | THUID(CAS + OIDC + SAML) |
| 数据交换 | API 网关 + 自研 ESB | ESB + CDC + 主数据管理 | API First + 数据中台 |
| 前端 | React + qiankun | Vue 3 + Element Plus | React + Umi + 微前端 + 低代码搭建 |
| 部署 | K8s + 华为云 | 私有云(VMware)+ 物理机 | OpenStack + 自研 K8s |
| 上线事项 | 80+(一期) | 120+(二期) | 200+ |
| 核心特色 | 低代码表单引擎 | 数据治理同步推进 | API First + 低代码页面搭建 |
| 适合谁参考 | 中等规模、有开发团队 | 规模大、重视数据治理 | 顶尖规模、有强开发能力 |
三个案例代表了高校一网通办建设的三种典型路径——技术选型没有标准答案,取决于学校的规模、团队能力、现有系统基础和投入预算。但贯穿所有案例的共同经验是:一网通办的成功 70% 靠协调、20% 靠设计、10% 靠编码。技术架构只是基础,真正难的是让各部门把流程拿出来、把数据接进来。
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!