Work for YILI

Appearance

2026-06-11 工作日志 ​

项目周会 ​

本次会议为项目周会，对齐了各模块进展，讨论了数据、性能及遗留问题，并明确了后续的优化方向和待办事项。

小结 ​

1. 活动中心与核心物码

  • 经销商签收时间：讨论了"未签收则不允许出货"的规则，但此规则与现有"不校验货权也可出货"的逻辑存在冲突，需重新确认。
  • 电子围栏：解决方案依赖主数据，预计 7 月底上线；团队内部有 6 月上线的备选方案，将与供应商再次开会讨论。
  • 前端体验优化：6.11 版本正在进行灰度测试，已包含登录、首页等多方面的优化，且 iOS 与安卓版本已对齐。

2. 数据治理与迁移

  • 数据迁移：TTS 的数据迁移因上线暂停时间过长而中断，将重新制定方案后再推行。
  • 智慧门店：完成了 102 客户的数据初始化，正在进行非 102OU 客户的历史数据标记处理。
  • 门店数据清洗：需处理约 500 万条门店数据，将纳入整体数据治理流程。

3. 性能与监控

  • 接口性能：将基于 APM 工具对全量接口进行扫描，并输出本周的扫描计划。
  • 前端性能：6.11 版本上线将增加前端埋点监控，需在上线前进行压测，以评估其对前端性能的影响。

4. 遗留问题与风险

  • 必传字段缺失：监控发现多个接口存在必传字段为空的问题，根源在于前端未严格遵守接口规范，需专项跟进。
  • 数据重复：已发现部分数据重复，部分由防抖机制导致，已通过灰度发布的方法上线解决。
  • 线上 Bug：5 月底发布的"小智"版本出现线上 Bug，需补充相应场景的测试用例；"Siv"版本灰度发布后也出现了 Bug，需复盘原因。

待办 ​

1. 活动中心与核心物码

  • 刘晓娜 重新确认"未签收则不允许出货"与现有出货规则的冲突问题。
  • 李亚洲 组织与供应商的会议，讨论电子围栏取值逻辑的解决方案及排期。
  • 彭婷婷 推动 TTS 数据迁移工作，重新制定迁移方案和应急方案。
  • 邢健、李亚洲 推进智慧门店与主数据系统间的数据比对与清洗工作。
  • 邢健 推动"小智"系统门店数据初始化同步方案的确认。
  • 任铭 组织一次跨系统（智慧门店、Saf）的工作同步会。

2. 数据治理与迁移

  • 李亚洲、李赵丹 将 500 万门店数据清洗任务纳入整体数据治理流程。

3. 性能与监控

  • 李赵丹 跟进 6.11 版本上线前的前端性能压测工作。
  • 邱毅、李亚洲 梳理并输出仍在报错的 APM 问题清单，明确各接口及负责方。

4. 遗留问题与风险

  • 刘晓娜 梳理监控中发现的必传字段为空问题，形成清单并推动各端技术负责人跟进。
  • 吴菊 复盘"小智"版本发布的线上 Bug，并补充相应场景的测试用例。
  • 吴菊 复盘"Siv"版本灰度发布的 3 个线上 Bug，分析原因并评估上线评审机制的优化。
  • 吴菊 跟进 Saf 与 618 版本的发版进度。

扫码加锁与活动升级模块性能压测评审 ​

本次会议评审了扫码加锁接口的压测结果与优化策略，明确了活动升级模块的压测指标与执行计划，并制定了针对低频接口的差异化测试策略以保障上线质量。

小结 ​

1. 扫码加锁与释放接口性能评估

  • 接口压测现状与瓶颈识别：扫码加锁接口在 5 分钟阶梯加压（最高并发 100 用户）下，TPS 达到 6256，累计请求 110 万次，95% 响应时间 21ms，99% 响应时间 29ms，服务器资源消耗正常。当前接口需传输大量码明细数据（JSON 报文），导致压测脚本文件过大（49M/120 万条），无法上传至压测平台，限制了更高并发的验证。解锁提交环节涉及锁表删除、业务表插入及更新操作的完整事务，是系统的核心瓶颈点。
  • 业务逻辑优化与技术重构：决定取消前端向后端重复传递码明细数据的冗余流程，后端改为仅接收单号，通过查询数据库（MongoDB）获取明细，以减少网络带宽占用和报文解析开销。为确保新旧版本过渡期数据一致性，后端代码将增加容错逻辑：若前端传码明细则以明细为准，若不传则自动查询云端数据。明确前后端职责分离，后端去除对部分字段的强校验，由前端保证必填项的有效性，实现"背靠背"信任机制。
  • 后续压测执行计划：张喜负责修改后端接口逻辑，支持无明细提交模式。完成后，吕杰基于新逻辑调整压测脚本，重点验证无明细传输下的接口极限性能。采用"前 10 分钟加锁灌数 + 后阶段批量释放"的联动测试方式，模拟真实业务场景下的并发压力。

2. 签收链路优化与低频接口测试策略

  • 签收与查询接口策略：鉴于 SFA 代签收、整单退货、查询扫码记录等接口调用频率极低（如退货日均几百单），且多为辅助功能，决定不进行线上高并发压测。上述接口转为上线后观察，但必须在功能测试阶段严格验证页面响应时间（如 5000 毫秒内完成）、大数据量查询效率以及业务流程的正确性。
  • 一键转移专项测试："一键转移"功能本质为"原单退货 + 新单出货"的组合原子操作，涉及大事务回滚风险，是本版本最复杂的核心功能。该功能虽并发不高，但极易产生错误数据，要求开发侧确保全链路日志（Log）完备，支持按单号追溯所有操作记录，保留时长至少半年以上。测试团队需重点覆盖特殊场景（如已退货单据再次转移、异常中断恢复等），确保数据一致性与事务完整性，而非单纯追求 TPS 指标。

3. 活动升级模块压测方案评审

  • 压测目标与基准确认：参考去年 12 月老系统重构后的压测数据，确定本次活动的 TPS 目标值为 480，并发用户数目标为 300。压测环境配置必须与生产环境保持一致，确保测试结果的可靠性。
  • 测试场景设计修正：方案中原定的 90%（抽奖）+7%+3% 的混合比例被质疑无法满足实际峰值需求，要求调整为更贴近真实业务的流量模型，或直接以 TPS 达标为首要标准。郑然然指出方案中的"并发 300 即停止"存在逻辑漏洞，要求压测过程应持续增压直至系统出现瓶颈（如 CPU 超 70%、内存超 80% 或响应时间超标），以找到真正的性能拐点，而不仅仅是满足预设数值。

待办 ​

1. 扫码加锁接口优化

  • 张喜 修改后端接口，移除码明细必传限制，实现根据单号查询明细的逻辑。
  • 吕杰 准备不含码明细的压测参数文件，执行新版本的扫码加锁与释放接口压测。

2. 接口清单与压测计划

  • 马奇、邱毅 输出详细的接口清单表格，明确各接口的压测时机（上线前/上线后）及原因。

3. 活动升级模块压测方案

  • 陈晨 完善活动升级模块压测方案，修正混合场景配比与增压策略，补充测试计划时间表。