2025年12月15日

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

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

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

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

• 目标: 安全加固及优化（性能、稳定性、用户体验）
• 进度: 已完成 20% | 计划完成 20%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
  • ✅ 针对备与手机端在省电省流方面的具体解决方案，梳理并完成 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 提供的免费证书方案。
  • 🟢 需要实现一个定时任务，由服务器定期通过 MQTT 向所有设备发送 ping 消息，用于检测设备的在线状态。此功能主要用于修复在记录设备在线状态的服务停用期间，因服务器升级、服务器宕机或服务器重启等原因导致 missed 设备下线通知的问题。作为替代方案，也可定时调用 EMQX 的 API 接口进行在线状态核对，但该方式需先在 EMQX 后台手动配置 API 访问权限和密钥，并将对应密钥配置到中心服务器中以完成认证。目前优先考虑 MQTT ping 方案，避免依赖 EMQX API 权限配置的复杂性。
  • 🟢 在企业租户中新增 或 excel 导入设备时，不允许添加已在其他租户中存在的重复设备。

其它

• 目标: 记录日常耗时的杂项工作、协作事项，以及必要的沟通、讨论等隐性事务。
• 进度: 属非计划内事务（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
  • 15 日
    • ✅ 新员工入职培训：提供技术资料及介绍大概情况
    • ✅ 新员工开发任务安排与需求说明
    • ✅ 对曹溯川遗留代码问题的修正。
    • ✅ 针对 zxs-hs 测试环境中发现的问题进行了系统性排查，完成缺陷修复与验证。修复完成后，已制作新版本的安装程序，并重新部署至 zxs-hs 服务器。
    • ✅ 30% 定位服务及地理位置反查服务向深圳内网服务器的迁移工作。
  • 16 日
    • ✅ 新员工开发任务的需求沟通讨论。
    • ✅ 定位服务及地理位置反查服务向深圳内网服务器的迁移工作。
    • ✅ zxs-cs 与 zxs 服务器升级至修复 Bug 的新版本，zxs-hs 已于昨日完成升级。
  • 17 日
    • ✅ 对已迁移至深圳内网服务器的定位服务和地理位置反查服务进行测试验证，确保各项功能运行正常。同时优化 frp 的线程数配置，提升了并发处理能力，以更好应对高负载请求。
    • ✅ 对 zxs-ca 服务器进行了服务优化，移除了一些不必要的后台服务，以降低内存占用并提升运行效率。重新部署最新版本。
    • ✅ 长沙办公室内腾出了一台小型服务器（原用于地理位置反查服务，现已迁移），重新安装 Ubuntu Server 24.04.3 LTS 系统，将作为局域网内的开发测试环境使用，有助于减少程序联调时部署上云的时间开销。
    • ✅ 安装程序、升级程序及初始环境配置修改（已迁移至深圳内网服务器）：原代理至 https://nominatim-1.netbodycamera.com 的地理位置反查服务，现已更改为 http://47.96.110.98:8092/reverse。
    • ✅ Webrtc 直播客户端在建立连接时，偶尔会出现重连两次的情况（发生概率较低）。目前该问题较难复现，需进一步排查相关代码逻辑，以提升连接过程的稳定性和可靠性。
  • 18 日
    • ✅ zxs、zxs-hs、zxs-cs、zxs-ca 部署新版本: 解决了 App 共用 MQTT 账号的问题，并修复了 WebRTC 直播客户端的重连问题。
    • ✅ 参与会议，讨论设备与手机端在省电省流方面的具体解决方案。
    • ✅ 梳理后续需开发的功能任务，并完善相应的实现方案。
    • ✅ 排查出一个 Janus 相关的消息发送问题, 已修复：本应将消息发送给 Janus，却误发给了设备。
  • 19 日
    • ✅ zxs、zxs-hs、zxs-cs、zxs-ca 部署新版本:
      • 手机 App 设备绑定接口安全加固;
      • 对手机 App 调用服务端 API 的关键接口进行日志记录，确保重要操作可追溯、责任可追究。
      • 在调用 Janus 的 Admin API 时，需要传入 admin_secret 参数。目前该参数被硬编码在代码中，存在较大的安全风险。为提升系统安全性，将该参数的注入方式改为由服务器在转发请求时动态添加，再将请求发送至对应的 Janus 分布式服务器节点。这样可有效避免敏感信息泄露至客户端代码中。当前 Web 前端和设备端在查询房间人数功能中，有调用该 Admin API。
      • 排查出一个 Janus 相关的消息发送问题, 已修复：本应将消息发送给 Janus，却误发给了设备。
    • ✅ KH3980 印度客户的技术支持：
      • 完成最新 2.0.0 版本更新日志的编写与维护，并已部署至 https://zxs-dev.netbodycamera.com/guide/center-server/change-log/2.0.0.html
      • 完成最新 2.0.0 版本安装手册的更新与发布，并已上线至 https://zxs-dev.netbodycamera.com/guide/center-server/install-manual/2.0.0.html
      • 完成 2.0.0 国际版新分支的代码调整、安装包制作、测试与发布，最终通过测试的版本可从以下地址下载：https://zxs-dev.netbodycamera.com/download/es-center-server-install-app-2.0.0-ge-1-202512192012.tar.gz
  • 20 日
    • ✅ 手机 App 接口绑定设备功能优化：在设备绑定成功后，接口将直接返回所绑定设备的相关信息。这样，App 可提前获取配置数据，用于初始化 MQTT 连接等操作，无需再等待调用设备列表接口来获取设备信息，提升了流程的效率与响应速度。
    • ✅ 制作新的更新包，部署新的改动到 zxs 服务器上， 让手机 app 能够使用到新改动。
    • ✅ 修复自测中发现的问题：在 App 与设备联调过程中，新增了关于开启/关闭设备端编码器的控制信令，该改动影响到 Web 端 SFU 模式下直播流的正常播放。已定位并修复相关问题，恢复播放功能。
    • ✅ 顺便优化以前曹工改动过的代码：Web 端 SFU 模式下请求关键帧写法太繁琐，优化后代码更加简洁易读。
    • ✅ 制作新版本更新包，并将修改内容部署至 zxs 服务器，确保 Web 端在 SFU 模式下的直播流播放稳定正常。

总结

• 定位服务及地理位置反查服务迁移至深圳内网服务器, 本次迁移工作中，遇到的主要挑战并非技术难题，而是数据传输过程中的实际限制。
  • 定位服务的数据库从公网服务器导出后，体积超过 5GB。通过长沙的设备中转，先将数据导出至长沙本地电脑，再导入至深圳内网，受限于长沙到深圳的蒲公英异地组网带宽，整个导入过程预计耗时超过二十小时。为解决此问题，联系了深圳的王工协助，直接使用深圳本地的笔记本电脑导出数据库，并通过深圳内网局域网快速导入目标服务器，大幅缩短了传输时间。
  • 位置反查服务所需的地理数据超过 1 GB，尝试了多种传输方式均进展缓慢。最终联系深圳的王工协助，通过微信分包发送，由他将数据接收并上传至深圳内网服务器的指定位置。
  • 此外，部署所需多个 Docker 镜像无法直接在内网环境中拉取。起初尝试在国外服务器下载并导出为离线包，再由深圳内网服务器下载，但传输速度依然缓慢，耗时长达十余小时。最终采用折中方案：在长沙本地电脑通过代理获取所需镜像，导出为离线文件后上传至国内公网服务器，再由深圳内网服务器从中下载。该方式有效规避了跨境下载限制，同时提升了整体效率。
• zxs-ca 服务器在上周升级后出现登录无响应的问题，目前已完成排查并处理完毕，具体原因如下：
  • 上周在服务器上新增了 Nacos 服务，占用了部分 CPU 和内存资源，已将该服务移除以释放系统资源。
  • 服务器可用磁盘空间不足 1GB，影响系统正常运行。已清理历史上传的安装包、升级包以及旧版本的 Docker 镜像，腾出存储空间，保障服务稳定。
• WebRTC 直播客户端在建立连接时，偶尔会出现重连两次的情况。经排查，问题根源是某一个 ICE（Interactive Connectivity Establishment）服务器添加失败时，触发了不必要的重连逻辑 —— 实际上客户端会配置多个 ICE 服务器地址并尝试连接，其中部分地址连接失败属于正常现象，本不应因此触发重连。

备忘