校园-智慧门禁(卡码脸)解决方案

前言

入职新公司也已经一年有余，入职后主要从事的是门禁项目，公司设计的项目是偏saas化的智慧门禁系统，目前已经在多所大学上线，以下是对该项目的个人总结复盘。

一、系统主要功能和扩展功能

可实现学校统一门禁设备管理
可实现人员管理，人员可通行场所管理(宿舍楼，食堂，图书馆)
记录下学生的通行信息，可供大数据分析，例如宿管系统，可提供学生归宿情况。
第三方平台支持功能，例如学生预约几点到几点图书馆，图书馆门禁设备自动开启

二、实现方案

1.开门方式

扫脸开门。（我们是用的本地鉴权，名单是写进设备本地人脸库的，线上门禁系统down机也不影响客户使用）

面板机选品注意事项。

识别成功率，这也是我们关心的最重要的。建议还是测试一下在阳光下、下雨环境、阴天、晚上等多情境。
设备的兼容性，设备控制可闸机的闸机类型有哪些。
支持和第三方系统对接，而不是单纯的使用厂家提供的一个面板机管理界面，类似写死在机器中的一个路由器界面。
功能方面。
- 设备可支持策略模式，例如哪些人每周一可进、周二不可进等个性化功能，部分学校有这个需求。
- 设备支持测温功能、增加广告等等，具体看客户需求。
技术方面。
- 如果提供类似服务包的，要咨询服务包的并发量。
- 设备是否支持覆盖去新增人员，没有的话我们对接起来如果想去修改照片，只能先删除在新增，但是我们和设备异步通信，你编码难度会提高很多，等待删除成功的通知，再去下发人员。
面板机品牌1:巨龙创视

对接协议：http协议。厂家提供一个服务包，服务包和现场面板机进行通信，门禁系统可以直接和厂家提供的服务包进行通信。(猜测可能觉得让客户对接mqtt协议比较困难，提供了一个较为简单版本的http协议包对接)

API接口列表(部分)：

对接缺点：

1. 由于所有的设备共享一个服务包，开学高峰期下发人员并发高，服务包并发非常严重，导致门禁系统和服务包交互大量超时，由于服务包厂家提供，其中此服务包对门禁系统提供http协议接口，对设备通信猜测使用的是UDP通信，我们这边也不好对服务包做集群处理，后续改为单线程下发人员，导致下发人员速度非常慢。

2. 对接是base64流传递给服务包，服务包传递给设备下发人员，可想而知，设备是不支持批量下发的，流批量汇聚太大了，我们的门禁系统也会内存溢出。

面板机品牌2:海清面板机

对接协议：mqtt协议。

API接口列表(部分)：

对接优点：

该设备支持传递URL下发，意味着可支持批量下发。

对接缺点：mqtt协议对接设备有一个很大的缺点，下发名单的时候不支持并发操作，可能你下发人员过程中会给你反馈设备繁忙中，厂家文档中对此表示，建议下发人员之前查询下当前指令是否执行完成，或者当前设备状态，建议批量下发人员。我们下发人员过程要的就是一个最终一致性，所以我们在编码方面就十分苛刻。

方案1：下发人员名单首先都会进入到一个队列中去，每次进行完一个命令，根据名单数量预估下发时间进行阻塞，在执行下一条指令。

方案2：下发人员名单首先都会进入到一个队列中去，每次进行完一个命令，等待上一条执行执行完成设备通知你，在进行下一条指令执行，注意等待的超时时长。

扫码开门

公司自有嵌入式开发工程师，其原理也非常简单，网购一台二维码门禁读头，和嵌入式开发工程师沟通，我们在最开始会往设备中写入一个序列号在第几位，当用户打开自己的二维码时，我们会往二维码中写入是否可以开启闸机。例如序列号是2,0代表不可以开门，1代表可以，用户二维码内容是01，可以开闸机，10不可以，当然我们为了安全考虑，其中还加了二维码加密等内容。

这是我们目前使用过程中最方面的一种开门方式，对云端的依赖程度非常高，二维码需要实时去生成，