2025年12月22日

本周工作计划与执行完成进度

中心服务平台 - 轻量化跨境分布式第二阶段改造

• 目标: 控制变更范围，降低引入风险，实现面向客户可用的初步功能体验。
• 进度: 已完成 15% | 计划完成 15%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
  • ✅ 跨境通用 App MQTT 临时帐号创建
  • ✅ 计划本周完成: 跨境通用 App MQTT 帐号实现
    • 统一帐号密码管理 通过 Nacos 服务实现所有服务器共用的 App MQTT 帐号与密码池的集中管理。每周向池中新增一组帐号和密码（池容量上限为 6 组，每月最多新增一组）。当池中已满 6 组时，停止新增；此时将第 6 组旧帐号移至首位，并更新其密码。应尽量避免修改已有帐号的密码，以防正在运行的 App 因认证失败而无法连接到 EMQX。
    • 配置同步机制 各节点服务器从 Nacos 获取最新的帐号/密码池信息，并将其同步写入 EMQX 所依赖的 Redis 服务中，包含帐号、密码及相应权限配置。一旦发生新增或变更，必须确保各节点及时、准确地完成更新，保障服务一致性。
    • 安全凭证分发 原 App 在调用手机或邮箱登录后的 /logind 接口时，将返回通用 MQTT 帐号密码池中的第一组有效凭证。该方式避免了将固定帐号密码硬编码在客户端程序中，提升了系统的安全性与后期维护的灵活性。
  • 🟢 对于为客户独立部署的版本（如印度客户），应默认连接本地服务器上部署的 Nacos 服务，相关配置需在集成的安装包或升级包中预先设定。为此，安装程序、升级程序及项目工程配置需协同调整，确保各环节一致。若需在公司非主节点运行并连接主节点的 Nacos 服务，可通过修改 .env 文件中的 NACOS 参数实现切换。该方式可有效区分不同运行环境，避免配置混淆，提升部署灵活性与后期维护效率。同时，安装与升级程序需具备自动安装和升级 Nacos 服务的能力。

中心服务平台 - 安全加固及优化（性能、稳定性、用户体验）

• 目标: 安全加固及优化（性能、稳定性、用户体验）
• 进度: 已完成 30% | 计划完成 30%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
  • ✅ 针对备与手机端在省电省流方面的具体解决方案，梳理并完成 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 接口: 用户申请注销账号后，系统将保留该账号信息 7 天。在此期间，若用户重新登录，系统会自动取消注销操作，账号恢复正常使用；若超过 7 天未登录，系统将自动彻底删除该账号及其相关数据。注销操作成功后，应向用户发送短信或邮件通知，确保其知悉处理进展。同时，需做好免责提示，明确告知用户数据删除后的不可恢复性及相关责任免除事项。
  • ✅ 计划本周完成: 在解绑或强制绑定设备时，应通知所有与该设备相关的用户，及时刷新设备列表界面，以便将已解绑的设备从列表中移除。消息需按照 App 自定义的协议进行发送，确保通知准确送达。
  • 🟢 需要实现一个启动任务：在 device-service 服务启动时，通过 MQTT 向所有设备发送 ping 消息，用于检测设备的在线状态。该功能主要用于解决此前记录设备在线状态的服务停用期间，因 device-service 升级、宕机或重启等原因导致未能及时收到设备下线通知的问题。作为替代方案，也可以选择调用 EMQX 提供的 API 接口来核对设备的在线状态。但此方式需预先在 EMQX 后台手动配置 API 访问权限和密钥，并将密钥信息同步到中心服务器以完成认证，增加了部署和维护的复杂性。目前优先采用 MQTT ping 方案， 避免对外部 API 权限配置的依赖，提升系统的兼容性和部署便捷性。

嵌入式 web 前端 - 巴西客户定制需求

• 目标: 新增 802.1x 功能后，引发的原有功能的改造。
• 进度: 已完成 100% | 计划完成 100%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
  • ✅ 计划本周完成: 当在 WiFi 页面选择的网络其 SSID 的 flags 字段中包含 “EAP” 时，表示该 WiFi 需要通过 802.1x 认证才能连接。此时无需输入 WiFi 密码，但应提示用户先前往 802.1x 配置页面完成相关设置，否则无法正常接入网络。

其它

• 目标: 记录日常耗时的杂项工作、协作事项，以及必要的沟通、讨论等隐性事务。
• 进度: 属非计划内事务（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
  • 22 日
    • ✅ 龚工本周工作安排
    • ✅ 工作周报服务器上创建对应新员的新帐户，以及工作周报培训。
    • ✅ 排查手机 App 调用的绑定接口问题时，需补充处理设备被他人强制绑定的业务场景。在数据清理方面，不仅要清除分享给其他用户的设备信息以及已绑定到自身账号的设备，还需彻底清理该设备曾被其他人绑定过的相关记录。
    • ✅ 根据韦工提供的文档，补充手机 App 调用绑定接口时的授权码验证逻辑，完善校验流程。
    • ✅ 多次部署最新版本到 zxs 服务器上
  • 23 日
    • ✅ 在长沙的 192.168.1.60 服务器上部署用于编译和打包嵌入式 Web 前端(巴西客户定制版)的环境，以便后续能够重复使用，提升打包效率。
    • ✅ 针对巴西客户提出的需要安装程序问题进行了讨论，找出解决方案。以及后续规避方案。
    • ✅ 在制作安装与升级程序的过程中，恢复了任务执行完成后自动备份至 NAS 的功能。
    • ✅ 排查 zxs 服务器上 device-service 服务的 MQTT V5 连接异常问题，初步判断可能由内存不足引发。针对 JDK 21 进行了优化调整，并更新安装与升级脚本，随后将服务部署至 zxs-cs 和 zxs-ca 环境进行测试验证。
  • 24 日
    • ✅ 龚工已提交代码审核，已完成分析报告并提供给其用于后续修改完善。
    • ✅ 嵌入式 Web 前端 — 针对巴西客户定制需求中的 WiFi 界面调整，优先采用 ap_list 中的 flags 字段。
    • ✅ 通过龚工完成的任务成果，从界面角度进行审核，梳理客户频繁反馈的问题，统一设计风格，并优化排版以适配手机显示。
    • ✅ 用户协议及隐私协议已完成从 Word 格式到 Markdown 的转换，经过初步校对后，已集成至系统中。
    • ✅ 部署最新版本到 zxs-hs、zxs-cs、zxs-ca 环境，测试新增功能及稳定性。确认无误后，部署到 zxs。
  • 25 日
    • ✅ 与孙工就协议完善进行讨论，内容涵盖事件处理及策略类型，包括高频、均频和低频策略的优化。
    • ✅ 与龚工沟通界面设计的细节，进一步明确交互逻辑与展示效果。
    • ✅ 收到的苹果手机已进行检查，确认各项功能正常，仅电池续航能力较弱，已将情况告知王工。
  • 26 日
    • ✅ 与郭工沟通，明确解绑或强制绑定设备时，服务端向 App 推送通知的协议格式问题。
    • ✅ 部署新版本到 zxs 服务器，联调解绑或强制的消息通知。
    • ✅ 龚工工作交接

总结

• 本周工作计划稳步推进，整体进展顺利。
• 受多项其他任务集中叠加影响，工作负荷加重，导致加班时间较多。

备忘

关于账号注销功能，还有一些细节需要进一步明确，以便我这边能够着手开发，优先实现自用版本：

• 是否需要取消该用户已分享给好友的设备分享关系
• 是否需要解绑用户名下所有已绑定的设备
• 是否需要删除用户上传的分组配置文件
• 是否需要删除为该用户创建的 MQTT 账号
• 在启动注销流程时，是否需发送一次短信或邮件提醒用户
• 在注销倒计时的最后三天，是否每天都要发送一次提醒
• 注销完成后，是否需发送最终确认通知（短信或邮件）
• 短信与邮件的具体内容由谁来定义？法律顾问？