KiwiCloud 面向的是「一家公司几百上千台 Android 商用终端分散在全国门店」的场景：连锁餐饮、零售、仓储、末端配送、医疗、教育、企业办公都有。
这类客户的痛点是 IT 根本无法逐台操作：新店开业要装机装应用，门店设备要被锁定成只能跑收银或展示应用，设备丢了要能远程锁死和擦除，策略变更要能一次性推到所有设备。
传统做法是「派人到店 + 一台台点」，门店越多成本越高，出问题还查不到执行记录。所以平台的核心不是"连上设备"，而是把设备的注册、配置、策略、内容、指令做成可批量、可追溯、可回滚的远程管理能力。
平台定位是 UEM（统一端点管理），核心模块：
1）设备注册：批量注册、组织与门店归属、在线状态与设备画像；
2）应用管理：企业应用批量安装/卸载/版本锁定，按设备组灰度分发；
3）设备管理：远程指令下发（重启、锁屏、清数据、截屏），设备分组与批量操作；
4）策略管理：合规策略下发（密码强度、网络、应用白名单），违规设备检测与整改提醒；
5）内容管理：门店素材与播放列表推送到指定设备组，支持定时生效；
6）报表：设备在线率、策略合规率、指令执行结果，按组织与设备维度统计；
7）Kiosk 模式：把设备锁定为单一应用或指定网页，适配门店收银、展示、自助场景；
8）多租户与权限：租户隔离、子账号权限、套餐与席位计费。
我负责设备管理与指令链路两块，从方案设计到上线。
技术栈：Java / Spring Cloud 微服务，MySQL 存指令表与设备影子表，Redis 存在线状态与去重令牌，设备侧走阿里云 IoT（MQTT），已通过 Google EMM 认证。
关键实现：
① 幂等下发：以 tenantId + requestId 作幂等键并建唯一索引。批量指令重发是常态（网络超时、页面重试），没有幂等键，同一台设备可能被执行两次远程擦除——这类误操作不可逆。
② 状态机收口：指令走 PENDING / SENT / ACKED / FAILED 四态，终态不可逆；重复 ACK 判 duplicate-ack，迟到 ACK 只记录不翻状态，避免"已失败但实际成功"的对账口径混乱。
③ 指数退避：第 n 次重试间隔 base×2^(n-1) 并封顶。门店设备经常晚上断电、白天才上线，定长重试会让失败指令在早高峰同一秒集体重发，把网关打满。
④ 设备影子对账：desired（策略应生效的值）与 reported（设备实际值）分开存，定时比对，发现漂移自动补发。设备刷机回滚、店员手动改设置，都靠这一层拉回来。
这套链路支撑了 100 万台在册设备、5 万常驻连接、六大区域，Google EMM 认证覆盖策略下发与合规检测。
评论