01
02 / 系统架构
从使用入口到业务记录,看清整套系统的分工
五层架构说明使用入口、访问与授权、业务处理、展示与接入、数据与记录之间的关系。逻辑分层不等于必须拆分成多个服务器,学校按实际需求组合终端、设备与模块。
5 层架构 · 6 类核心业务逻辑分层,可按实际条件同机或分开部署
共同能力终端配置设备适配按需配置
总体逻辑关系 · 连线表示请求与依赖,终端和模块按学校需要组合。
版本聚焦
拖动画布移动 · Ctrl + 滚轮缩放 · 点击节点查看说明 ↗点击功能条目查看说明;切换系统架构可拖动查看整图。
一套业务基座 / 按学校与版本开通能力
点击模块查看职责、功能与交付边界
青鸽 Java 后台 · 逻辑功能边界
适配职责不等于独立进程;大华 SDK 为后台内部模块
后台按业务职责读写;以下为逻辑数据分组,不是独立数据库或已核对的物理表名
本地部署 校园网络内运行校外访问 另需公网 HTTPS 入口云端接校内设备 按学校网络配置
FUNCTIONAL MAP / 职责与功能归属
平台管服务,学校管业务
按岗位查看功能分工,点击条目了解使用方式、所需条件和可配置范围。
“功能开通”决定学校获得哪些能力;“角色与数据范围”决定当前账号能够看什么、操作什么。
学校日常人员、人脸照片、卡片和放学配置不迁入平台运营菜单;没有接入证据的本地学校不显示为可远程运维。
BUSINESS FLOWS / 数据如何形成
一套后台,四条不同的业务链路
流程中的成功、失败和待确认按实际业务结果记录;教师操作、设备事件与通知结果可分别查看。
班级放学 / 撤回操作 → 形成班级状态
指挥与刷卡共用业务处理;小程序为移动入口
班级状态成立的依据是有效业务操作及保存结果。不能据此推定每个学生已经离校,也不能用重复操作弥补通知问题。
通知支路:放学业务事件 → 通知模块 → 公众号消息 → 家长微信;不改变已经形成的班级事实。
01 / 班级业务班级已放学
来自有效操作与状态保存。不能推定该班所有学生都已出校。
02 / 现场设备人员识别 / 通行
来自设备事件。识别结果、实际通行和方向按设备能力分别记录。
03 / 消息触达家长收到 / 阅读
需要对应渠道证据。发送请求被受理不能当作收到或已读。
另一条记录链路:终端事件 → SDK 订阅连接 → 青鸽后台 → MySQL。以设备实际提供的事件语义为准;没有方向就保留未知,识别不必然等于成功通过通道。
另行确认的业务规则:由“首人出校 / 末人出校”推导班级放学状态;该规则需单独确认实现范围。
教师使用同一角色体系查询负责班级并提交操作;教师入口和家长入口不等于必须发布两个小程序。
B. 通知发送:与状态查询分开建设
需单独实现与验收
微信受理发送请求 ≠ 家长已收到或已读。不同通知渠道按学校开通范围配置;实际接收与阅读以平台可获取的信息为准。
开校开户 → 学校获得相应能力
平台职责,不进入学校日常班级放学流程
开通学校不强制依赖订单与支付。学校模块开通后,账号仍受角色、学校和负责班级范围限制;启用学校不等于续期。
平台服务公告与学校 LED 公告分离
学校后台接收服务公告
DEPLOYMENT BOUNDARIES / 运行与网络条件
同一逻辑架构,不同部署边界
分层图不要求各模块单独部署。公网访问与云端设备连接必须分别落实,不能用“设备能上网”代替网络可达性。
本图仅列已明确的 Java 后台、MySQL、私有照片存储与 SDK。不推定额外中间件或自动云端同步能力。
校园网络 / 学校侧
学校管理电脑指挥 PAD教师刷卡端LED 播放电脑
↕
本地青鸽业务运行环境后台、数据库和文件资源可以同机;也可按实际部署拆分。
Java 后台MySQL照片私有存储
后台内部:大华 SDK 模块〔设备适配〕 ↔ 校内人脸识别终端
家长校外访问条件 / 另行落实家长手机 → 互联网 → 学校对外 HTTPS 入口 → 本地青鸽后台。只有校园内网地址不能支持校外家长访问。
云端 / SaaS 部署
公众入口与校内设备连接是两件不同的事
公网 HTTPS / 业务服务侧
平台 / 学校浏览器教师 / 家长微信〔按需配置〕可达的播放 / 操作端
↕
云端青鸽业务运行环境按学校与角色提供受控业务服务,不由入口直接连接数据库。
Java 后台MySQL照片私有存储
后台内部:大华 SDK 模块;对校内设备的可达网络尚需落实
云端访问校内设备 / 设备接入方案结合学校网络评估 VPN 或校内接入节点。连接方式、SDK 运行环境与设备权限按现场条件配置,公网手机访问与校内设备连接分别确认。
SDK 版本取决于实际运行 Java 后台的环境按设备型号与现场条件联调后台运行环境Windows → Windows 版 SDK按后台真实操作系统选择厂商库。
后台运行环境Linux → Linux 版 SDK不是依据操作后台的浏览器电脑选择。
后台运行在容器中Linux 容器 → Linux 版 SDK即使宿主机是 Windows,也以容器内环境为准。
班级放学事实
班级状态由合法的放学操作形成;不直接等于全班学生已离校。
人员通行事实
以设备提供的识别 / 通行事件为准;方向未知不能按时间猜测。
家长消息事实
公众号通知按学校配置;发送受理、收到消息和阅读消息不是同一状态。
02
01 / 平台定位
不是几套彼此独立的版本,而是一套可以组合的放学业务平台
一套核心平台连接统一 App、微信小程序、现场指挥端、学校管理后台、大屏显示端、通知端和设备接入,让学校按实际场景组合终端与模块,并共享同一套权限、任务、状态和操作记录。
学校可以从小程序和管理后台起步,也可以加入现场指挥、大屏与语音、通知端、刷卡或闸机设备,以及私有化部署。无论从哪个入口操作,最终都进入同一套学校隔离、角色权限、放学任务、状态同步和操作记录链路。
01
学校开通
02
组织配置
03
任务快照
04
授权执行
05
多端同步
06
异常校验
07
历史追溯
03
02 / 使用终端
六类终端面向不同岗位,共享同一份可信业务数据
| 使用终端 | 主要形态 | 负责什么 |
|---|
| 统一移动端 | 统一 App 与微信小程序 | 家长、教师、校长和值班人员按账号授权进入各自工作台。 |
| 现场指挥端 | 手机与平板 | 面向门卫、指挥员和值班领导,聚焦当前批次和现场快速操作。 |
| 学校管理后台 | 浏览器后台 | 管理组织、账号、规则、通知、大屏、设备、日志和交付配置。 |
| 大屏显示端 | 浏览器显示端 | 展示授权范围内的班级进度,并按学校配置联动语音播报。 |
| 通知端 | 公众号、短信与扩展通知平台 | 当前支持公众号和短信通知,并可按项目接入企业微信、钉钉及学校自有平台。 |
| 设备接入 | 刷卡机、学生卡、UHF-RFID、闸机与身份设备 | 支持学生卡及 UHF-RFID 设备接入;刷卡、校牌、闸机和人脸等身份事件可进入同一任务、状态、通知和操作记录链路。 |
04
03 / 核心流程
从开校配置到日终收口,七步跑通日常放学
| 步骤 | 阶段 | 系统与学校共同完成的工作 |
|---|
| 01 | 学校与模块开通 | 平台创建学校并开通所需终端、模块和部署能力,学校管理员首次登录后完成密码修改。 |
| 02 | 组织与规则配置 | 配置年级、班级、学生、教师、家长、角色权限,以及放学时段、批次、班级范围和任务成员。 |
| 03 | 生成每日任务 | 系统按日期、时段、批次、班级和轮次生成任务,并保留生成时的成员快照,避免后续组织变更影响历史。 |
| 04 | 按授权范围执行 | 教师、校长或指挥员只查看和操作授权任务,执行开始放学、放学完成、留堂或解除留堂。 |
| 05 | 多端同步触达 | 服务端校验通过后,同步更新学校已启用的移动端、指挥端、管理后台、大屏和通知端,并按配置生成通知与语音任务。 |
| 06 | 操作记录与查询 | 记录放学、完成、留堂、解除留堂、通知和播报等操作结果,供学校后台查询与复盘。 |
| 07 | 日终收口与追溯 | 检查未完成任务、留堂和失败通知;新一天生成新任务,历史任务与操作记录持续保留并支持查询。 |
05
04 / 共同能力
所有方案共用的六项核心能力
统一任务与成员快照
按日期、时段、批次、班级和轮次生成任务,保留任务生成时的成员范围。
多角色与数据范围
学校、角色、负责年级和班级共同决定用户看得到和操作得了的范围。
四态进度同步
未放学、开始放学、放学完成和留堂在已启用终端间保持一致。
大屏与语音联动
状态变化同步到授权大屏,并按配置生成防重复语音播报。
家长独立通知
通知端按监护人分别记录发送、失败、已读和确认,不把一位家长的状态代替另一位;具体渠道以学校已开通配置为准。
过程记录与追溯
放学操作、配置变更、通知、播报和设备事件均形成记录,支持后台查询与复盘。
06
05 / 按需模块
终端和模块按学校场景组合,不把套餐名称固化成产品架构
不同学校可以选择不同终端和模块,但学校、组织、任务、权限、状态和日志始终由同一核心平台管理。当前可使用公众号和短信通知,也可按项目接入企业微信、钉钉和学校自有平台;读卡器、校牌、闸机和人脸设备通过协议适配接入。
移动放学协同放学时段、批次与多轮任务现场指挥LED 大屏与多屏站内、公众号与短信通知企业微信、钉钉与学校平台通知扩展接入家长订阅与阅读确认黑匣子与配置审计刷卡设备与设备网关班级状态与学生出校两级通知开放接口私有化与本地化部署
08
07 / 配置与交付
按学校需要开通,不把整张架构图当成固定套餐
学校选择的终端、模块和通知渠道构成具体交付范围。设备协议、接口权限、网络条件和学校账号共同决定实际可使用的能力。
新增终端和增强能力按实际开放版本与项目确认范围交付。正式使用前完成账号配置、设备适配与现场联调,不以架构关系图替代具体交付清单。
09
08 / 安全与追溯
操作可查询,数据范围与异常处理有明确边界
权限控制结合学校、角色、负责范围、日期时段、当前批次和任务状态限制用户可查看、可操作的内容。放学、完成、留堂、通知、播报和设备事件分别形成记录。
历史任务、成员和操作记录支持查询,保存策略结合学校要求配置;离线补传、冲突处理和高风险操作增强能力按具体版本开放范围确认。
10
FAQ
常见问题
小程序版、指挥版和刷卡版是不是三套独立系统?
不是。它们是青鸽放学协同平台面向不同学校场景形成的常用方案入口,共享学校组织、角色权限、放学任务、状态同步和操作记录。
统一 App 属于哪个版本?
不属于某个固定版本。统一 App 是平台的移动入口,家长、教师、校长和值班人员根据账号授权进入不同工作台;正式下载仍以签名、真机兼容和发布状态为准。
小程序、指挥端、大屏、通知端和设备能否组合使用?
可以按学校已开通模块组合。公众号和短信可按现有配置触达家长;企业微信、钉钉、学校自有平台等通知端需先确认账号、接口、网络与消息规则。所有入口经过身份、权限和任务规则校验后进入同一状态链路。
刷卡机和闸机是否默认全部兼容?
不能默认承诺。设备协议、身份字段和现场网络差异较大,需要先核验供应商接口、事件方向和异常处理方式,再确定直接接入或增加适配层。
平台会永久保存所有学生和家长数据吗?
不会用“永久保存”作为统一承诺。数据应按学校配置、业务需要、合同约定和适用规则设置留存范围,并通过权限、脱敏和审计控制使用。