2025年12月08日

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

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

目标: 控制变更范围，降低引入风险，实现面向客户可用的初步功能体验。
进度: 已完成 100% | 计划完成 100%（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
- ✅ 手机号注册的用户名生成策略：针对通过手机号注册的用户，系统采用格式化规则自动生成用户名，格式为 p-${手机号}。该方案利用手机号的全局唯一性，并结合用户名字符限制要求，有效避免了用户名冲突问题。相较原有的随机生成策略，在分布式部署环境下，显著降低了因多节点并发注册导致的单点登录跳转失败风险。
- ✅ 邮箱注册的用户名生成策略：对于通过邮箱注册的用户，系统采用格式化规则自动生成用户名，格式为 ${邮箱名}。该方案利用邮箱名的全局唯一性，并结合用户名字符限制要求，有效避免了用户名冲突问题。相较原有的随机生成策略，在分布式部署环境下，显著降低了因多节点并发注册导致的单点登录跳转失败风险。
- 🟢 用户注册用户名规范：为保障系统的统一性与安全性，用户注册时的用户名仅允许包含字母、数字和下划线，禁止使用特殊字符及空格。该限制旨在避免因手机号或邮箱自动生成用户名时可能引发的命名冲突问题。
  - ✅ 前端部分交由曹溯川处理：员工及租户创建或修改时，会有登录帐号（用户）的用户名验证逻辑加固，确保用户名符合规范。
  - ✅ 其它部分由我处理
- ✅ 支持在设备及采集服务器维护界面配置设备所属的节点云服务器，涵盖数据库设计、接口开发、前端及权限控制等各个方面的处理。
  - ✅ 前端部分交由曹溯川处理
  - ✅ 其它部分由我处理
- ✅ 设备及采集服务器修改，当租户为 default（个人设备库存）时，需保持同编号设备在其他租户下的配置一致；动作：以 deviceNo 为键，批量更新非 default 租户的同编号设备配置，防止多租户场景下配置漂移；字段：云服务域名、Janus 编号、STUN/TURN 服务与认证信息。
- ✅ 改造原有无状态 JWT Token 的加解密机制，集成 Nacos 同步的盐值配置。通过传递包含时效性信息的统一认证头（Super-Token），实现跨节点服务器的单点登录功能，完成 Super-Token 方案的落地。
- ~~集成 Nacos 实现全球节点服务器的配置统一管理，比如：支持设备归属节点的动态配置分发；Super-Token 业务提供可靠的配置数据支撑。~~
- ✅ 因工期紧张，暂采用简化方案，仅在主节点主机部署单实例 Nacos；后续将迭代为稳定架构。
  - ✅ 支撑研发推进：zxs-ca 服务器上部署 r-nacos 服务：https://github.com/nacos-group/r-nacos
  - ✅ 项目工程改造通过 nacos 统一管理配置
- ✅ 改造原有无状态 JWT Token 的加解密机制，集成 Nacos 同步的盐值配置。通过传递包含时效性信息的统一认证头（Super-Token），实现跨节点服务器的单点登录功能，完成 Super-Token 方案的落地。
- ~~手机注册成功，根据手机传参的定位信息，计算出以后它应该与那个服务器交互（就近原则），返回信息中增加服务器地址信息。~~
- ✅ 手机 App 调用的服务端 Http API 开发
  - ✅ 实现云服务器信息接口，支持获取全部云服务器列表及默认云服务器详情（包括域名、IP 地址、所属国家/地区等）
  - ✅ 在设备列表中新增云服务器信息字段，展示设备关联的云服务器详情（包括域名、IP 地址、所属国家/地区等）
- ✅ 设备调用的的服务端 Http API 开发
  - ✅ 返回该设备所属云服务器信息
- 🟢 可延后 手机 App 设备绑定接口安全加固：
  - 引入设备生成的授权码机制，用户需通过手机 App 采集设备上的授权码并提交至服务端进行验证。
  - 服务端基于内部加密逻辑校验授权码的有效性。若验证失败，返回相应错误信息；验证成功后，执行以下绑定逻辑：
    - 无历史绑定记录 服务器未查询到该设备的已有授权码，直接完成绑定，并返回绑定成功响应。
    - 存在相同授权码 服务器查到该设备已有相同授权码，表明已绑定：
      - 若用户名一致，返回“重复绑定”提示；
      - 若用户名不一致，返回“设备已绑定至用户：xxx”提示。
    - 存在不同授权码 服务器查到的历史授权码与当前提交的不同：
      - 若用户名一致，更新授权码并返回成功；
      - 若用户名不一致，执行授权切换：更新授权码，解绑原用户，绑定新用户，并返回成功响应。

其它

目标: 记录日常耗时的杂项工作、协作事项，以及必要的沟通、讨论等隐性事务。
进度: 属非计划内事务（🟢 未开始 | 🟡 进行中 | ⚠️ 部分完成 | ✅ 已完成 | 📌 已验证）
- 08 日
  - ✅ 完成新员工工作日志撰写培训，并配置服务器端工作日志专用读写权限账户，确保操作合规与数据安全。
  - ✅ 整理补全 BCMS 相关业务需求文档，让新员工对 BCMS 有更全面的了解。比如：内部文档网址、初代原型设计(绍工做的)
  - ✅ 对于新员工提交的代码，在代码评审通过后（经历多轮：评审 → 修改），将其代码合并至主干分支。
  - ✅ 基于后续功能模块的重大调整，创建主干分支的新版本，以确保版本演进的可追溯性与稳定性。
- 09 日
  - ✅ 参与轻量化分布式过渡阶段改造方案讨论会，明确关键技术实现细节，并规划后续演进方向。
- 10 日
  - ✅ 完成新员工后续的工作安排，及必要的需求讲解。
  - ✅ app 岗简历筛选分析
  - ✅ 制作安装程序及升级程序, 部署到 zxs-cs 进行测试
- 11 日
  - ✅ 完成系统在多台服务器的部署验证。初始部署至 zxs-ca 时出现无法登录问题，经排查，先后成功部署至 zxs-cs 与 zxs-hs 均运行正常；为进一步确认原因，于新申请的临时服务器 zxs-ls（2核8GB，今日18点到期）进行全新安装，亦无异常。综合判断问题源于 zxs-ca 服务器配置过低，导致服务无法正常访问。
  - ✅ 对于新员工提交的代码，在代码评审通过后（经历多轮：评审 → 修改），将其代码合并至主干分支。
  - ✅ 基于最新代码构建安装包与升级程序，并完成对 zxs、zxs-hs 和 zxs-cs 三台服务器的系统更新与部署。
  - ✅ 新版本更新日志文档编写，及发布到 zxs-dev 网站： https://zxs-dev.netbodycamera.com/guide/center-server/change-log/2.0.0.html
- 12 日
  - ✅ 在 zxs 服务器上部署独立的 Nacos 单机实例，原部署于 zxs-ca 的 Nacos 实例将仅保留用于开发与自测环境，以实现环境隔离。待后续服务器资源到位后，再将 Nacos 升级为分布式集群部署模式。
  - ✅ 统一项目工程配置管理，开发环境接入 zxs-ca Nacos 配置中心，生产环境对接 zxs Nacos 配置中心，实现多环境配置隔离与标准化管理。
  - ✅ 完成对 app 微信群中郭工所反馈多个技术问题的沟通与响应。
  - ✅ 解决王工在 zxs-hs 服务器创建新租户时出现的报错问题，完成故障排查与代码修复，并更新到 zxs-hs 服务器。

总结

于 2025年12月11日 上线轻量化跨境分布式过渡版本，该版本为 App 后续功能演进提供服务端接口支撑，旨在提升系统可扩展性与跨区域服务能力，并保障前后端平滑对接。主要更新如下：
- 提供 App 所需的云服务器列表（包含推荐节点），支持前端实现动态获取与区域优化选路
- 在设备列表中，为各设备信息新增 cloudServiceDomainName 字段，用于标识对应云服务域名
- 实现 Super token 机制，支持用户在任一服务器登录后生成的 Token 可在其他服务器无缝验证与使用，实现跨域会话互通