这几年在老旧小区改造项目上折腾了不少给我最深的感触是很多小区装门禁越装越像“数字围城”。楼下的单元门从最早的刷卡、按密码慢慢变成了必须刷脸才能进。刷脸确实快但问题也跟着来老人指纹浅刷不出来、小孩身高不够够不着摄像头、外卖员被挡在门外一遍遍按对讲还有一部分业主直接拒绝采集人脸信息——你说强制吧人家物业也委屈说系统就只支持这一种方式。后来我接触到ZUU中优这套4G云门禁的端云协同架构才觉得这事儿有解。它的核心思路不是“把刷脸做得更强”而是“把选择权还给住户”。在设备端和云端做了一套协同机制让刷卡、密码、小程序远程开门、室内机开锁这些传统方式全部保留刷脸只是可选能力不强制。这个方向对于改造难度大、无管线条件、又想把成本压下来的老旧小区来说非常值得聊一聊。这篇文章我就从架构角度把这类4G云门禁到底是怎么设计的、端和云各自干什么、部署落地时坑在哪里一条条拆开讲清楚。适合工程商、集成商、物业信息化负责人以及对门禁产品架构感兴趣的朋友参考。1. 老旧小区门禁改造真正的拦路虎是什么很多人以为老旧小区门禁改造的难点是“选哪款设备”其实不是。等你拿着图纸到现场转一圈就会发现真正卡脖子的是两件事管线和供电。1.1 没有弱电井、没有网线传统门禁方案寸步难行老小区的单元门基本没有预留弱电管线。早期那套“电控锁 室内分机”的老设备靠的是楼内穿好的两芯线如果年头久了线路老化换新设备往往意味着重新砸墙布线。这成本不是按“一台设备”算的是按“一整栋楼”算的。小区又往往不止一栋楼几十个单元门全部重新布线报价单拉出来物业和业委会基本都是倒吸一口凉气。更麻烦的是很多老楼没有专门的弱电井网线、光纤想从楼道拉到单元门口需要协调的事情一大堆。这时候4G云门禁的价值就出来了设备端直接插一张物联网SIM卡通过4G网络完成所有通信不需要拉网线不需要穿墙打洞。本质上它把“联网”这件事从物理施工变成了开机即用这是它能落地老旧小区的最底层原因。1.2 强制刷脸为什么行不通住户需求、合规风险、场景兼顾再聊刷脸的事。人脸识别在门禁上的体验确实好走到跟前一停门就开了尤其手里拎着菜、抱着孩子的时候腾不出手来刷卡。但问题在于“强制”——当刷脸成了唯一开门方式所有不方便都变成了住户的麻烦。实际项目里我遇到的情况大致有这几类老人指纹浅、面部特征变化大刷脸识别率不稳定经常出现“明明站在那半天门就是不开”的尴尬。小孩身高不够摄像头角度对着成人儿童刷脸要么拍不到要么拍到了也匹配不上。外卖、快递、保洁这类临时人员不可能给每个人都录入人脸只能靠物业开门效率很低。一部分住户对生物信息采集有明确抵触不愿意把人脸数据交给物业或第三方平台。所以ZUU中优这套架构把“非人脸方式”作为优先实现项是很务实的产品策略。住户可以选刷卡、输密码、微信小程序远程开门甚至还可以通过室内分机或呼叫转移方式授权开门。人脸识别不是没有而是作为“可选增强项”不愿意用的完全可以关掉。这个思路的关键在于端云协同。端侧设备本地保存白名单和开门策略云端负责配置下发和记录管理。即使不联网、不刷脸本地也能完成身份校验和开锁动作而不是所有决策都依赖云端的“核身”结果。1.3 老旧小区门禁的需求清单综合下来老旧小区对门禁的需求其实很清楚需求维度具体表现对架构的影响免布线无弱电井、无网线可用必须支持4G/无线通信低维护物业技术水平有限远程配置、远程升级、远程诊断多方式开门刷卡、密码、小程序、室内机、刷脸可选端侧需支持多种认证模块离线可用断电断网时也要能开门本地白名单 门锁电控独立合规安全拒绝强制采集人脸默认非人脸方案人脸可关闭说白了这套系统能不能做成关键不在摄像头像素有多高而在架构是不是足够“接地气”。端云协同这个词听起来高大上落到老旧小区改造里翻译成人话就是楼下的设备够聪明云端够稳定两者配合起来让人感觉不到“系统”的存在。2. 端云协同架构整体拆解四层模型一眼看懂端云协同不是把设备“连上云”就完事而是要划分好端侧和云侧的职责边界。ZUU中优这套方案的整体架构我习惯用四层模型来理解设备感知层、通信传输层、云端平台层、用户交互层。2.1 设备感知层单元门上的边缘节点设备端就是装在单元门口的智能门禁机别看它体积不大里面塞了不少东西主控板、4G通信模组、读卡模块、按键/触摸模块、摄像头可选、扬声器、电源管理模块以及对应的门锁控制电路。在端云协同的架构里设备端不只是“执行指令的哑终端”它本身具备完整的边缘计算能力。开门这个动作必须在端侧完成不能等云端返回结果再开门——万一网络延迟个两三秒住户在门口干等着体验就是灾难。所以端侧至少要承担这几件事本地保存合法的卡号、密码、二维码、白名单数据本地执行身份验证逻辑验证通过后直接驱动电控锁记录开门事件并暂存在本地缓存网络恢复后补传云端接收云端下发的配置包括白名单增删、时段策略、设备参数本地检测SIM卡状态、信号强度、供电状态异常时上报2.2 通信传输层4G链路是唯一的“云通路”通信层在这套架构里就是一张4G物联网SIM卡。它把设备端的开门记录、在线状态、心跳包、事件告警通过运营商网络送到云端服务器。选择4G而不是Wi-Fi或蓝牙原因是门禁场景正好卡在两者都不适用的位置Wi-Fi在老小区单元门口基本没有信号覆盖蓝牙又无法实现“跨楼层远程管理”。4G的覆盖率最高设备插上卡就能用且不依赖业主家里的宽带。对于分散在几十个单元门上的设备4G几乎是综合成本最低的选择。从技术选型上看这类门禁设备一般用到的是4G Cat.1或者Cat.4模组。Cat.1的优势是成本低、功耗低满足门禁这种小流量、长连接、非高带宽场景Cat.4则带宽更高适合需要频繁上传图片或视频流的设备。如果门禁支持远程抓拍或视频对讲Cat.4会更稳妥如果只是刷卡记录、远程开门、心跳保活Cat.1足够。2.3 云端平台层统一管理所有设备和住户云端平台是整个系统的“大脑”负责所有设备的接入、管理、策略配置和数据存储。ZUU中优这套云平台我理解的是一个典型的物联网设备管理平台再加上业务管理系统。云端做的事可以分成几块设备接入管理设备注册、鉴权、状态监控、离线告警人员与凭证管理录入人员信息分配卡号、密码、人脸模板权限策略管理设置不同人员的开门时段、可进楼栋、有效期事件记录存储开门记录、报警记录、异常事件可回溯查询远程控制通道下发远程开门指令、升级固件、修改配置云平台的难点不在功能多而在“稳”。门禁系统一旦上线就是7×24小时运行云端的可用性直接决定物业的信任度。这块后面单独展开聊。2.4 用户交互层物业端、住户端、访客端用户交互层面向三种角色物业管理人员、住户和临时访客。物业用的是管理后台或小程序端可以查看设备状态、管理住户凭证、远程开门、查看进出记录住户用的是住户端小程序能远程开门、授权访客、接收开门通知访客则通过门口机的呼叫功能联系住户由住户远程确认后开门。这一层其实最容易影响使用体验。很多门禁系统“设备挺好App难用”最后住户不配合物业也嫌麻烦。所以交互层的设计逻辑是越简单越好——能扫就扫、能点就点不要让住户去理解复杂的权限概念。2.5 端和云的分工为什么不能“一头沉”端云协同的核心就是端和云各有侧重谁也不能替代谁。如果所有验证都放到云端一旦断网整栋楼都进不去这是不可接受的如果所有数据都只存在本地物业又无法远程管理改造的价值就砍掉了一大半。端侧负责“快”云侧负责“全”。端侧本地完成身份验证和开锁动作保证毫秒级响应云侧负责所有需要跨设备、跨楼栋、跨时间的全局逻辑比如人员调离后统一撤销权限、某个时段禁止进入、设备固件统一升级。二者通过4G链路同步数据形成一个闭环。维度端侧门禁机云侧平台身份验证本地白名单即时校验下发白名单、人脸模板开锁动作本地驱动电控锁远程开门指令下发数据存储事件暂存、离线缓存全量记录、统计报表故障处理断网时降级为本地模式设备离线告警、在线诊断系统升级接收OTA升级包管理批量升级任务3. 4G链路与嵌入式侧的几个硬核设计细节聊完整体架构落到底层硬件的设计有四个细节值得多说几句。这些点决定了设备在真实场景里“到底好不好用”。3.1 为什么门禁机要用低功耗设计而且必须支持备用电源门禁机一般不缺电单元门通常能就近取市电。但老旧小区存在一个很现实的问题楼道里的公共用电往往是“谁用谁头疼”线路老化导致电压不稳甚至可能被其他大功率设备拉低电压。ZUU中优这类设备在设计时都会考虑宽电压输入并且内置备用电池保证市电断电后设备仍能工作一段时间。低功耗设计在这个场景里的意义不是省电费而是延长备用电池的待机时间。如果设备满负荷运行功耗太高备用电池撑不了几小时断电就等于门禁全瘫。实际项目中门禁机在待机状态下功耗要控制在极低水平只有读卡、开门、通信时才会拉高功耗。这就必须有完善的电源管理和外设唤醒策略。3.2 通信协议选型和心跳机制决定在线率的隐形因素4G门禁的通信通常基于MQTT协议。MQTT是为物联网设计的轻量级消息协议长连接、低带宽、支持断线重连非常适合门禁这种“平时没多少数据但又要实时可控”的场景。设备端与云端建立MQTT长连接后通过心跳包维持在线状态。心跳间隔需要权衡设置太短流量消耗大、云端压力大设置太长设备异常下线后云端不能及时发现远程开门指令容易“找不到设备”。行业里常见的做法是心跳间隔设在30秒到120秒之间并配合云端超时判断逻辑。实际调试中我发现心跳机制写得好不好直接决定设备在线率。好的心跳机制不做简单的定时上报而是会根据网络状况自适应调整网络差时适当拉长间隔网络恢复后立即重连上报。这一层做扎实了物业端的“设备在线列表”才靠谱。3.3 本地白名单机制离线开门能力的基石刷脸门禁的一个通病是“摄像头识别必须联网”——人脸模板在云端设备端只是一个采集端网络一断人脸验证就失效。ZUU中优这套端云协同架构在端侧保存了所有必要的身份凭证卡号、密码、二维码、本地人脸白名单如果启用刷脸模式的话。这就意味着大多数开门场景是端侧独立完成的。即使4G网络完全断开住户刷卡、输密码依然有效。云端只是事后同步记录等网络恢复后再补传。这个设计从根本上解决了“断网就进不了门”的致命问题。3.4 OTA升级几十台设备的远程维护全靠它撑住门禁设备遍布小区各个单元如果每台设备都要派人去现场升级运维成本不可想象。OTA远程升级是这类产品的标配能力云端可以给设备批量下发固件升级任务设备下载完成后自动校验、更新、重启。OTA升级看起来简单实际要做好有几个坑升级包不能太大4G网络下下载太慢会失败要有断点续传和失败回滚机制升级失败不能把设备变成砖头升级要避开使用高峰不能住户正在开门时设备重启。我见过一些项目因为升级逻辑没写好半夜自动升级后设备没起来第二天早上整个单元门打不开物业电话被打爆。这套细节做得好不好是区分专业厂商和杂牌厂商的分水岭。4. 云平台设计多小区隔离、权限分级与非人脸优先策略端侧做得再好云平台撑不住整个系统还是会崩。门禁云平台和普通Web系统不一样它要面对的是大量低配终端、复杂的设备网络环境以及非常敏感的住户数据。4.1 多小区多租户隔离一个平台管几十个小区一个平台往往要同时服务多个小区、多个物业公司甚至多级代理商。如果所有小区的数据混在一个库里权限边界不清就是灾难。合理的做法是按“租户”维度进行逻辑隔离。每个小区是一个租户空间物业只能看到自己小区的设备和人员数据代理商可以看到其名下所有项目的数据但看不到其他代理商的平台运营方才有全局视角。同时要做好角色权限分级平台管理员、代理商、物业经理、门岗值班员、住户每类角色的权限范围完全不同。4.2 “非人脸优先”的凭证体系设计再回到“拒绝强制刷脸”这个产品理念。在凭证体系上ZUU中优的做法是默认支持多种非人脸凭证人脸仅作为可选的附加项。这样的设计有几个实际好处避免因收集人脸数据带来的合规风险照顾不愿意使用人脸识别的住户让临时访客外卖、快递、装修人员的授权变得简单——不用录人脸直接发个临时密码或小程序二维码就行这也是一种很聪明的架构策略不是拒绝技术而是让技术“退到可选位置”。当用户主动选择刷脸时人脸作为一种体验增强当用户拒绝刷脸时系统全部功能照常可用。这个逻辑在架构层面体现为“凭证类型可插拔”新增一种开门方式不需要改动核心代码只加一个认证模块即可。4.3 数据链路安全门禁不是监控别把隐私当儿戏门禁系统的数据安全很多人不重视这是要命的。门禁里存着住户的姓名、手机号、房号、开门记录如果启用了人脸还有人脸特征数据。这些信息一旦泄露比单纯的验证码泄露严重得多。从架构角度至少要覆盖这几层设备与云端通信采用TLS加密防止传输层被窃听设备本身要有唯一密钥或证书防止仿冒设备接入云端人员凭证数据加密存储人脸特征模板采用不可逆算法处理管理后台严格鉴权防止水平越权访问其他小区数据提供数据删除能力住户迁出后可以清除其全部信息做一个基本的判断标准如果这套门禁系统被安全测试公司打一次能不能扛得住扛不住的系统在老旧小区改造这种“民生工程”里很容易因为数据问题翻车。4.4 极端场景演练断网、断电、云宕机门禁能不能扛住架构设计得再好也要拿极端场景来检验。单台设备断网端侧白名单机制保证刷卡、密码、二维码开门全部可用云端标记该设备离线并告警。小区大面积断电设备备用电池启动维持基本开门功能。云平台检测到多台设备同时离线可以自动生成停电事件通知物业。云平台短时不可用所有开门操作在端侧完成不受影响。远程开门、小程序授权这类依赖云端的操作暂时不可用恢复后自动追补。设备被物理破坏设备本身带有防拆报警拆机后上报云端同时门锁状态保持安全不能因为拆机导致门禁自动敞开。这些场景都想明白系统上线后就不会有“半夜被叫起来救火”的情况。5. 落地部署与运维实录40个单元门项目的实战复盘理论讲再多还不如一次现场实施来得实在。下面把我在一个40个单元门的老旧小区项目里遇到问题和处理方法整理出来分享。5.1 现场勘察动手安装前先看这五样东西门禁设备不是装上就能用安装前的勘察决定了后续问题的80%。我一般会重点看五样第一是门体结构。老小区的单元门五花八门铁门、铝合金门、木门改铁门门体厚度、门框材料、闭门器状态都不一样。电控锁的安装方式和走线路径要提前确认门体太薄的要考虑加装加强铁板。第二是供电条件。单元门附近有没有便捷的市电取电点如果没有要从楼道声控灯或者住户电表箱取电需要提前和物业、业委会沟通确定电费由谁承担。第三是4G信号质量。用手机装同一运营商的卡在单元门口实测信号强度和上传下载速度。楼梯间通常信号较差特别是地下室或半地下室的单元门信号差的要提前规划外置天线或选择信号更好的运营商。第四是安装高度和视角。设备安装高度一般距地面1.4米到1.5米方便大多数成年人操作。如果设备带摄像头还要考虑逆光、遮挡等问题。第五是网络覆盖死角。把每个单元门的信号数据记录进台账信号弱的单元门优先使用外置天线版本设备或者变更SIM卡运营商。5.2 SIM卡选择不是随便插张卡就能用4G门禁的SIM卡优先选择物联网卡。物联网卡和普通手机SIM卡有区别资费更低、有专用的管理平台、可以统一查看流量使用情况、支持设置流量阈值告警。但物联网卡的采购渠道很关键一定要找正规运营商或大型代理商否则容易出现“卡被停用、设备失联”的坑。门禁设备的流量需求其实很小。一台设备每天上传的开锁记录、心跳包、状态信息加起来一个月通常不超过30MB到50MB。所以在流量套餐上不用买大的关键是卡的稳定性、是否有公网IP、是否支持设备接入自家云平台。还有个细节有的小区地下室信号弱单靠SIM卡信号不够需要接外置天线。天线要避开金属门框尽量朝窗外或信号较好的方向安装。天线位置差一个角度信号强度能差出一大截。5.3 项目部署时的批量操作全在云端完成40个单元门如果逐个手工配置工作量不小。云平台的价值在批量部署时体现得最明显。我在项目里是这么操作的先用电脑或手机连接设备进行基本配置设置好设备编号和所属单元门随后设备通过4G自动注册到云端在云平台上按楼栋、单元批量导入住户信息导出对应卡号批量下发最后用云平台的远程开门功能逐个单元门测试一遍确认每台设备都在线、开锁正常。这里有个小技巧批量下发白名单时不要一次下发几千人应该按单元门只下发该单元的住户。这样每台设备本地白名单数据量小检索速度快开门响应也更灵敏。5.4 常见问题快查表直接照着处理真实维护中有几个高频问题整理成表格方便查阅现象可能原因处理方法设备显示离线SIM卡欠费、停用登录物联网卡管理平台检查状态设备显示离线信号弱、天线位置不当查看设备信号强度调整外置天线方向开门延迟大依赖云端验证未走本地白名单检查本地白名单是否已下发优先用本地验证刷卡没反应卡号未配置或卡片损坏在云平台查卡号状态重新发卡远程开门失败设备心跳断开重启设备检查网络重新建立心跳备用电池很快耗尽主电源未接好一直在耗电池检查供电线路确认市电供电正常设备频繁重启供电电压不稳加装稳压电源模块检查线路老化情况5.5 运维效率技巧别等住户投诉才发现问题好的运维不是被动救火而是靠系统的预警能力提前发现风险。云平台如果配置了设备离线告警设备掉线超过一定时间就能主动推送消息到物业和工程商。这个功能一定要开启并且要配置好接收人不然后果就是设备离线了三四天直到住户打电话投诉物业才发现。我还习惯定期抽查设备的信号强度和心跳成功率。信号强度下降往往是一个渐进过程可能是运营商网络调整也可能是天线老化。早发现一个月可能就少跑一次现场少接一堆投诉电话。6. 从架构里看到的一些产品思路这套端云协同架构表面上解决的是“老旧小区门禁改造”这个具体问题但往深了看它代表了一种产品思路技术应该是提供选择的而不是剥夺选择的。强制刷脸的问题本质是把一种技术方案作为唯一方案强加到所有人身上。而ZUU中优的端云协同架构通过把多种验证方式“可插拔”地整合进同一套系统让不同的人群都能找到适合自己的开门方式同时降低了数据合规风险。我想这才是“拒绝强制刷脸”真正的底气——不是反对某项技术而是让技术回归工具本位。如果你正在做类似的项目我的建议是先想清楚边界哪些能力必须放在端侧哪些逻辑应该收到云端哪些数据必须加密存储。把这几条边界想清楚了架构的骨架就立住了剩下的都是在这个框架上添砖加瓦。另外提醒一句门禁是7×24小时在线的公共设施不是可以“上线后慢慢优化”的互联网产品。一个小的升级bug影响的是整栋楼几百人的进出。所以选型时多关注设备在断网、断电、云不可用等极端场景下的表现这比摄像头像素高不高、外观好不好看重要一百倍。