跳到主要内容

门禁业务最佳实践

本文档基于 DejaOS 标品门禁应用的设计经验，详细阐述构建高效、稳定的门禁系统所需的关键数据模型、业务流程及架构模式。

1. 核心数据模型​

一个典型的门禁系统围绕以下四个核心实体构建：

1.1 凭证 (Credentials)​

用于验证身份的物理或数字媒介。DejaOS 支持多种凭证类型，每种类型在数据库中存储的格式不同：

凭证类型存储内容数据量级 (预估)备注
人脸特征值 (Feature Vector)~1024 Bytes不存储原始照片，仅存储提取后的数学特征
指纹特征值 (Feature Template)~1024 Bytes同样仅存储特征模板
二维码字符串内容~32 - 64 Bytes动态或静态二维码的内容
PIN 码哈希值或明文~6 Bytes通常为 4-6 位数字密码
NFC 卡卡号 (UID)~4 - 32 BytesIC/ID 卡的序列号
蓝牙蓝牙数据包~32 Bytes通常用于手机蓝牙开门

注意：并非所有硬件设备都支持上述所有凭证，需根据具体选型确定。

1.2 人员 (Personnel/Subject)​

门禁通行的主体。

  • 核心字段：PersonID (唯一标识)。
  • 扩展字段：姓名、部门、工号、有效期等。

1.3 权限 (Permission)​

定义“谁”在“什么时间”可以进入“哪里”的规则。常见的权限策略包括：

  • 常开模式 (Always)：无时间限制，永久有效。
  • 时段模式 (Time Slot)：仅在特定起始日期和结束日期之间有效。
  • 每日/周循环模式 (Daily/Weekly)：例如仅工作日（周一至周五）的 9:00 - 18:00 有效。

1.4 通行记录 (Access Log)​

每次尝试通行的完整审计记录。无论通行成功与否，都应记录：

  • 时间戳
  • 凭证类型
  • 凭证值
  • 通行结果 (成功/失败及原因)
  • 人员 ID (仅成功时)
  • 现场抓拍 (人脸通行时通常附带现场截图)

2. 注册流程 (Enrollment)​

注册是将“人员”、“凭证”和“权限”三者关联并写入设备数据库的过程。主要有三种实现模式：

2.1 离线注册 (Device Side)​

直接在设备端完成，无需网络。

  • 适用场景：单机使用、临时访客、无网络环境。
  • 操作方式：
    • UI 录入：通过设备屏幕直接输入人员 ID。
    • 硬件采集：设备作为采集器读取 NFC 卡号、录入指纹或抓拍人脸。
    • 权限限制：通常仅支持默认权限（如“永久有效”）。

2.2 局域网 Web 管理 (Local Web)​

利用设备内置的 Web Server 进行管理。

  • 适用场景：小规模部署、局域网环境。
  • 操作方式：设备连接网络后，管理员通过 PC 浏览器访问设备 IP，在 Web 界面上进行可视化的人员和权限管理。

2.3 云端下发 (Cloud/MQTT) - 推荐​

设备作为客户端连接后台管理系统。

  • 适用场景：规模化部署、集中管理。
  • 实现建议：
    • 协议：推荐使用 MQTT 长连接，相比 HTTP 轮询更实时、更高效。
    • 流程：管理员在后台系统中录入数据，后台通过 MQTT 将 update 指令推送到指定设备，设备接收并写入本地数据库。
+------------+                  +------------+                  +----------+
|  后台管理  |                  | MQTT Broker|                  | 设备应用 |
+------------+                  +------------+                  +----------+
      |                              |                               |
      | 1. 管理员录入人员/权限       |                               |
      |----------------------------->|                               |
      |                              |                               |
      | 2. Publish Update 指令       |                               |
      |----------------------------->|                               |
      |                              | 3. Push 消息                  |
      |                              |------------------------------>|
      |                              |                               |
      |                              |                   4. 解析消息并写入 DB |
      |                              |                               |
      |                              |                   5. 返回操作结果 (Ack)|
      |<-----------------------------+-------------------------------|
      |                              |                               |
数据一致性警告

强烈建议不要混合使用“离线注册”和“云端下发”模式。 离线注册的数据直接产生于设备，而云端模式的数据源头在服务器。混合使用极易导致数据冲突（如 ID 重复）和同步困难。一旦选择了云端集中管理，应禁用设备的本地注册功能。

3. 通行校验流程 (Verification)​

设备通过 Worker 线程并发监听多种输入源（摄像头、指纹仪、读卡器），一旦捕获凭证，即触发校验流程。

3.1 离线校验 (Local Match) - 最常用​

  • 机制：人员、凭证、权限数据全量同步至设备本地。校验过程完全在边缘端完成：凭证 -> 查找人员 -> 匹配权限 -> 开门。
  • 优点：响应速度极快（毫秒级），不受网络波动影响，断网仍可工作。
  • 缺点：设备存储和算力有限，通常支持的底库数量在 2,000 - 50,000 人之间。
  • 适用：绝大多数固定人员场景（公司考勤、小区门禁）。

3.2 在线校验 (Server Match)​

  • 机制：设备仅作为“采集器”。获取凭证后，实时通过 MQTT/HTTP 上报给服务器，由服务器判断后返回“开门”指令。
  • 优点：无底库数量限制，便于统一管控。
  • 缺点：极度依赖网络稳定性，网络延迟会导致开门卡顿，断网则完全瘫痪。
  • 适用：极大规模人员库、或安全性要求极高需实时鉴权的场景。

3.3 混合校验 (Hybrid)​

  • 机制：优先进行本地离线校验；如果本地未匹配到（例如新入职员工数据尚未同步，或访客），再发起在线校验。
    • 适用：兼顾体验与灵活性的场景。
+----------+        +----------+                    +------------+
|   用户   |        |  设备端  |                    | 后台服务器 |
+----------+        +----------+                    +------------+
     |                   |                                |
     | 1. 刷卡/刷脸      |                                |
     |------------------>|                                |
     |                   |                                |
     |                   | 2. [本地] 查找凭证与权限       |
     |                   |                                |
     |                   |           (匹配成功?)          |
     |                   |           /        \           |
     |                   |         Yes         No         |
     |                   |          |          |          |
     |                   |          |          v          |
     |                   |          |   3. [在线] 上报请求|
     |                   |          |-------------------->|
     |                   |          |                     |
     |                   |          |     (鉴权判断)      |
     |                   |          |                     |
     |                   |          |   4. 返回开门指令   |
     |                   |          |<--------------------|
     |                   |          |                     |
     |                   |          v                     |
     | 5. 开门 (继电器)  |<---------+                     |
     |<------------------|                                |
     |                   |                                |
     |                   | 6. 记录通行日志 (异步上报)     |
     |                   |------------------------------->|
     |                   |                                |

3.4 记录上报策略​

所有通行记录应优先缓存于本地数据库（建议设置上限，如 2000 条，循环覆盖）。当设备在线时，app 自动将缓存记录批量上报给服务器。

4. 人脸识别专题​

人脸凭证具有特殊性，其核心是特征值 (Feature Vector) 的提取与比对。

4.1 照片 vs 特征值​

设备底层比对的是特征值，而非原始照片。注册过程本质上是将“照片”转换为“特征值”的过程。

4.2 两种下发模式​

  1. 下发照片 (Photo Dispatch)：

    • 服务器发送原始照片给设备。
    • 设备利用 CPU 算力提取特征值并存储，随后删除原始照片。
    • 优点：后台系统开发简单。
    • 缺点：照片大小通常都是几十 K，大量下发需要长时间。

  2. 下发特征值 (Feature Dispatch) - 推荐：

    • 搭建独立的“特征提取服务”（运行在独立的服务器上）。
    • 入库照片先在服务器端转为特征值。
    • 服务器直接将 1KB 的特征值数据下发给设备。
    • 优点：极大减轻端侧压力，注册速度极快。
    • 前提：服务器端使用的算法模型必须与设备端完全一致，否则特征值无法通用。

更多关于人脸技术的细节，请参考 人脸识别概览。