一句话总结

围绕 DGJ 应收性能和日志治理完成本地真实回归及生产字符量核验:应收新链路 7/7 组结果一致、4/8 路并发可用;搜索响应日志下降约 75.7%,但整体日志治理和预发发布仍需继续。

今日成果

  • 完成本地 dgj2.0 -> dgj-center:9501 -> 预发 dgj 只读库 的应收并发链路验证,7/7 组旧逻辑与新接口的 invoiceCount、rePayment 完全一致,4 路和 8 路并发均 HTTP 200;代码未提交、未推送、未合并。
  • 核验 DGJ /offer/search/list 成功响应摘要已在生产生效:21:10–21:25 共 258 条新格式、旧完整 data 为 0,目标异常关键词均为 0;同口径字符量约 2,010,924 -> 488,296,下降约 75.7%。
  • 按 DGJ 自身日志口径重新定位剩余大头:最新窗口 DataService 约 16.49M 字符、providers/default 约 16.35M 字符,其中 AES 请求约 7.87M;下一步优先摘要 skuSaleNum 和 AES 请求。
  • 完成 DGJ、Sale、VinAudit 的请求 ID 和响应日志完整性方案核对,明确保留各系统本地 ID,以 Dgj-Request-Id 作为跨系统关联字段;方案待实施,未改下游代码。

问题与风险

  • 应收本地验证曾出现约 5.2s 中心内部数据库资源长尾,不能将单次 766ms 分段结果写成稳定生产 SLA;页面总耗时、冷缓存和并发 P95/P99待预发验证。
  • 应收改造尚未提交或发布;dgj-center 全量 PHPUnit 被仓库既有缺失依赖阻断。
  • DGJ 搜索摘要只覆盖 /offer/search/list;phone/offer/search/list、AES 请求、DataService 和下游 VinAudit /product/search 未纳入同一改造。

验证与证据

下一步

  • 按预发分支自动构建流程发布 dgj2.0 与 dgj-center,复测页面接口和返回结构。
  • 采集预发冷/热缓存、连接池、单段及完整接口 P95/P99,单独解释数据库资源长尾。
  • 先治理 DGJ DataService/skuSaleNum 与 providers/default AES 请求,保留异常原文和链路字段。
  • 评估 Dgj-Request-Id 在 Sale/VinAudit 的落日志与继续透传,并补真实搜索请求串联验证。