2025年12月29日
本周工作计划与执行完成进度
中心服务平台 - 轻量化跨境分布式第二阶段改造
- 目标: 控制变更范围，降低引入风险，实现面向客户可用的初步功能体验。
- 进度: 已完成 35% | 计划完成 35%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
- ✅ 跨境通用 App MQTT 临时帐号创建
- ✅ 跨境通用 App MQTT 帐号实现
- 统一帐号密码管理 通过 Nacos 服务实现所有服务器共用的 App MQTT 帐号与密码池的集中管理。每周向池中新增一组帐号和密码（池容量上限为 6 组，每月最多新增一组）。当池中已满 6 组时，停止新增；此时将第 6 组旧帐号移至首位，并更新其密码。应尽量避免修改已有帐号的密码，以防正在运行的 App 因认证失败而无法连接到 EMQX。
- 配置同步机制 各节点服务器从 Nacos 获取最新的帐号/密码池信息，并将其同步写入 EMQX 所依赖的 Redis 服务中，包含帐号、密码及相应权限配置。一旦发生新增或变更，必须确保各节点及时、准确地完成更新，保障服务一致性。
- 安全凭证分发 原 App 在调用手机或邮箱登录后的
/logind接口时，将返回通用 MQTT 帐号密码池中的第一组有效凭证。该方式避免了将固定帐号密码硬编码在客户端程序中，提升了系统的安全性与后期维护的灵活性。
- ✅ 计划本周完成: 对于为客户独立部署的版本（如印度客户），应默认连接本地服务器上部署的 Nacos 服务，相关配置需在集成的安装包或升级包中预先设定。为此，安装程序、升级程序及项目工程配置需协同调整，确保各环节一致。若需在公司非主节点运行并连接主节点的 Nacos 服务，可通过修改
.env文件中的 NACOS 参数实现切换。该方式可有效区分不同运行环境，避免配置混淆，提升部署灵活性与后期维护效率。同时，安装与升级程序需具备自动安装和升级 Nacos 服务的能力。
中心服务平台 - 安全加固及优化（性能、稳定性、用户体验）
- 目标: 安全加固及优化（性能、稳定性、用户体验）
- 进度: 已完成 45% | 计划完成 45%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
- ✅ 针对备与手机端在省电省流方面的具体解决方案，梳理并完成 Web 前端所需的修改。前端已部署至
zxs、zxs-hs、zxs-cs、zxs-ca四台服务器，相关功能测试均已通过。 - ✅ 重点关注 Web 端 ping 机制，与孙工讨论后，优化了冗余的判断逻辑，并调整了 ping 的发送频率，提升稳定性和响应效率。前端已部署至
zxs、zxs-hs、zxs-cs、zxs-ca四台服务器，相关功能测试均已通过。 - ✅ 优化 SFU 模式下通知设备快速推送关键帧的代码逻辑，提升小幅画面的出图速度。
- ✅ 手机 App 设备绑定接口安全加固：
- 引入设备生成的授权码机制，用户需通过手机 App 采集设备上的授权码并提交至服务端进行验证。
- 服务端基于内部加密逻辑校验授权码的有效性。若验证失败，返回相应错误信息；验证成功后，执行以下绑定逻辑：
- 无历史绑定记录 服务器未查询到该设备的已有授权码，直接完成绑定，并返回绑定成功响应。
- 存在相同授权码
服务器查到该设备已有相同授权码，表明已绑定：
- 若用户名一致，返回“重复绑定”提示；
- 若用户名不一致，返回“设备已绑定至用户：xxx”提示。
- 存在不同授权码
服务器查到的历史授权码与当前提交的不同：
- 若用户名一致，更新授权码并返回成功；
- 若用户名不一致，执行授权切换：更新授权码，解绑原用户，绑定新用户，并返回成功响应。
- ✅ 对手机 App 调用服务端 API 的关键接口进行日志记录，确保重要操作可追溯、责任可追究。
- ✅ 在调用 Janus 的 Admin API 时，需要传入
admin_secret参数。目前该参数被硬编码在代码中，存在较大的安全风险。为提升系统安全性，将该参数的注入方式改为由服务器在转发请求时动态添加，再将请求发送至对应的 Janus 分布式服务器节点。这样可有效避免敏感信息泄露至客户端代码中。当前 Web 前端和设备端在查询房间人数功能中，有调用该 Admin API。 - ✅ 为服务器中 EMQX 服务的 8883 端口配置证书绑定。需研究如何绑定证书，优先考虑使用 Let’s Encrypt 提供的免费证书方案。
- ✅ 在新增、修改或通过 Excel 导入设备、采集服务器及采集盒时，禁止添加已在其他租户中存在的重复设备、采集服务器或采集盒。
- ✅ 在解绑或强制绑定设备时，应通知所有与该设备相关的用户，及时刷新设备列表界面，以便将已解绑的设备从列表中移除。消息需按照 App 自定义的协议进行发送，确保通知准确送达。
- ✅ 计划本周完成: 在
device-service服务因升级、宕机或重启而重新启动时，可能存在未能及时收到设备下线通知的问题，这是由于记录设备在线状态的服务曾一度停用，导致无法准确感知设备的真实连接状态。为解决该问题，可在服务启动时执行一项初始化任务，主动检测所有设备的在线情况。目前主要有两种方案：其一是通过 MQTT 协议向所有已知设备发送 ping 消息，依据设备是否响应来判断其在线状态，该方式利用现有通信通道，无需额外配置认证信息，兼容性强且部署维护成本低，是当前优先采用的方案；其二是调用 EMQX 提供的 REST API 接口查询设备连接状态，但此方法需在 EMQX 后台预先配置 API 权限并生成密钥，同时将密钥安全同步至中心服务器完成认证，增加了部署与运维的复杂性。本方案主要适用于单服务器下单个device-service的部署模式，在后续扩展为多服务器分布式架构时，可通过部署多个device-service实例协同工作，并避免同时升级或重启，从而显著降低此类问题的发生概率。- ✅ 深入研读 EMQX 官方文档，探索通过自研安装程序与升级程序自动创建 EMQX API Key 的可行配置方案。
- ✅ 改造安装或升级程序，需生成随机的 EMQX API Key 账号与密码，写入
.env文件，并自动生成对应的 EMQX API KEY 配置文件。 - ✅
device-service服务从.env文件中读取认证凭据，用于调用 EMQX 接口查询当前在线的客户端设备信息。 - ✅ 通过 EMQX 提供的 API 获取实时在线客户端列表，写入 Redis，在得到查询结果并写入前，先清空原有的 MQTT 在线状态缓存，以降低 Redis 的存储压力。
- ✅ 该任务需为每日凌晨 2 点定时执行，以清理多余的 Redis 缓存；同时在服务启动时也触发一次，确保设备在线状态数据始终保持及时和准确。
- ✅ 计划本周完成: 手机 App 接口：在解绑或强制绑定设备时，需通知所有与该设备相关的用户。接口中当前使用的用户名应优化为手机号或邮箱，不再使用用户名作为标识。手机号或邮箱信息可通过用户与邮箱或手机号之间的绑定关系进行查询获取，确保信息准确且便于用户识别。
- ✅ 针对备与手机端在省电省流方面的具体解决方案，梳理并完成 Web 前端所需的修改。前端已部署至
嵌入式 web 前端 - 巴西客户定制需求
- 目标: 对 802.1X 功能进行重构，龚工交接的代码可读性较差，存在大量不符合 React 规范的写法，导致维护成本较高。此次重写提升了代码的结构清晰度与可维护性，便于后续开发与问题排查。
- 进度: 优先度较低，在完成其他任务后再行处理。（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
- 🟢 深入理解需求。
- 🟢 改复 BUG 时，重构代码，提升可读性与可维护性
其它
- 目标: 记录日常耗时的杂项工作、协作事项，以及必要的沟通、讨论等隐性事务。
- 进度: 属非计划内事务（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
- 29 日
- ✅ 用户协议及隐私协议的 Markdown 的排版格式改进
- ✅ 制作最新的安装及升级程序，部署到
zxs-cs及zxs-ca服务器，验证 EMQX 配置 API KEY 的正确性
- 30 日
- ✅ 优化设备在线状态同步逻辑, 减少性能消耗
- ✅ 制作最新的安装与升级程序，并将其部署至
zxs-cs和zxs-ca服务器。针对“假在线”问题，进行多轮测试：通过手动停止device-service服务后再断开设备连接；随后重新启动服务，验证此前因服务中断而离线的设备能否准确自动维护为离线状态，确保设备上下线状态同步准确无误。 - ✅ 手机 App 接口: 帐号注销接口需清理的数据包括(数据在账号注销时均需按流程逐一清除，确保信息彻底解绑并删除)
- 自身绑定的设备
- 已分享给其他用户的设备
- 其他用户分享给该用户的设备
- 手机号与用户之间的绑定关系
- 邮箱与用户之间的绑定关系
- 用户与租户之间的绑定关系
- 用户专属租户
- 用户账户本身
- ✅ 制作最新的安装与升级程序，并将其部署至
zxs服务器上，提供给 App 联调使用
- 31 日
- ✅ 验证从家中带到公司的花生棒是否可用：这是十年前购买的设备，若已损坏则需重新购置。由于需要开发对接苹果回调的接口，必须通过公网实现访问穿透，以连通内网中的开发电脑。
- ✅ 使用 zxs-cs 和 zxs-ca 服务器对集成了 Nacos 的安装程序及升级程序进行了测试。
- 01 日
- ✅ 使用 zxs 和 zxs-hs 服务器更新为最新版本
- 29 日
总结
Last updated on