高校一网通办的坑与解:流程引擎、认证、数据交换

9170 字
46 分钟
高校一网通办的坑与解:流程引擎、认证、数据交换

概述#

一网通办是高校信息化建设的”一号工程”。它的目标说起来很简单:让师生办事只跑一次、只进一扇门。但背后的技术架构远比看起来复杂。

拆开来看,一网通办平台的核心由三个子系统构成:

一网通办门户(师生访问入口)
├── 流程引擎(办事流程的驱动核心)
├── 统一身份认证(一次登录、全网通行)
└── 数据交换平台(打通各部门的业务系统)

本文从技术实现角度逐个拆解,末尾用三所重庆高校的实际案例说明这些技术是怎么落地的。


一、流程引擎#

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 超时与催办#

流程引擎需要处理超时:

// 定时任务扫描超时待办
@Component
public 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 个账号。

统一身份认证要解决的问题:

  1. 单点登录(SSO):登录一次,访问所有系统
  2. 统一账号管理:一个账号对应一个人,入职自动创建、离职自动禁用
  3. 安全策略统一:密码强度、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 服务端核心实现(简化)

@RestController
public 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 对接
@Configuration
public 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 数据标准的定义#

数据交换平台最核心的工作是统一数据标准。同一个”学生”,在不同系统中叫法不同:

含义教务系统财务系统一卡通标准字段
学号XHstudent_idaccountstudent_id
姓名XMnameuser_namename
学院YXMCcollegedeptcollege_name
入学年份RXNYenroll_yearcreate_dateenroll_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 字段映射与协议转换#

数据交换平台的适配器负责字段映射:

@Component
public 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 数据脱敏与权限#

数据交换平台必须做权限控制和脱敏:

@Component
public 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 容器平台 │
└────────────────────────────────────────────┘

北邮的低代码表单引擎(出自学报论文):

北邮自研了一套轻量级表单引擎,让业务部门管理员可以直接拖拽配置表单,无需开发人员介入。

// 低代码表单引擎核心:动态表单渲染
@Component
public 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 p
LEFT 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 网关注册 │
└────────────────────────────────────────────┘

页面搭建的后端核心实现:

// 页面搭建平台的渲染服务
@Service
public 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 网关 + 自研 ESBESB + CDC + 主数据管理API First + 数据中台
前端React + qiankunVue 3 + Element PlusReact + Umi + 微前端 + 低代码搭建
部署K8s + 华为云私有云(VMware)+ 物理机OpenStack + 自研 K8s
上线事项80+(一期)120+(二期)200+
核心特色低代码表单引擎数据治理同步推进API First + 低代码页面搭建
适合谁参考中等规模、有开发团队规模大、重视数据治理顶尖规模、有强开发能力

三个案例代表了高校一网通办建设的三种典型路径——技术选型没有标准答案,取决于学校的规模、团队能力、现有系统基础和投入预算。但贯穿所有案例的共同经验是:一网通办的成功 70% 靠协调、20% 靠设计、10% 靠编码。技术架构只是基础,真正难的是让各部门把流程拿出来、把数据接进来。

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

高校一网通办的坑与解:流程引擎、认证、数据交换
https://selfstack.xiaoxiaotan.online/posts/一网通办坑与解/
作者
zicai
发布于
2026-06-07
许可协议
CC BY-NC-SA 4.0
zicai
Hello, I'm zicai.
公告
欢迎来到我的博客!这是一则示例公告。
音乐
封面

音乐

暂未播放

0:00 0:00
暂无歌词
分类
标签
站点统计
文章
11
分类
4
标签
56
总字数
29,238
运行时长
0
最后活动
0 天前

文章目录