一句话总结

完成 DGJ 日志精简子范围的发布验证，稳定性治理进入按优先级推进阶段，SAAS 明细 ID 需求完成可实施设计但尚未改代码。

今日成果

  • 完成 DGJ2 内部重复大对象日志的最小范围改造：保留 Robot.php 入口完整日志和关键节点，将 contact 保留为单份快照、conversation 保留完整、preConversation 收敛为 ID/状态；未修改 dgj-robot 或业务处理逻辑。
  • 完成发布后 Kibana 观察验证：onMessage 开始 单条约 156 字节，解析、联系人、会话和结束节点仍可查询，线上消费者运行正常，未发现本次发布导致的崩溃。
  • 收敛站管家稳定性周报口径：MySQL 大表使用盘点进度 30%；Robot 日志 150G → 40G 已完成，AI 报价日志 280G → 200G、目标 100G 标记为 60%；后续优先级为 P0 AI 报价日志、P0 MySQL 大表、P1 Top10 慢 SQL。
  • 完成 SAAS/DGJ 订单明细行级映射设计修正：传输字段使用 srcOrderEntryId、SAAS 列使用 src_order_entry_id，按 P1500 的 orderInfo.srcOrderEntryId → entryId 关联；需求包仍待确认后实施。

问题与风险

  • Kafka 空轮询超时和 currentIP 循环日志仍是主要噪声来源，formatMessage 商品/缓存对象、排序数据和会话重复日志也未纳入本次最小改造。
  • 业务失败与消费者成功统计并存，提示已有异常返回/提交时机语义风险；需单独建 Bug 验证，不能归因于本次日志精简。
  • SAAS 需求尚未修改代码、数据库或接口，分表 DDL、订单消息、出库匹配和旧链路回归均待确认后执行。

验证与证据

下一步

  1. 按 P0 → P0 → P1 推进 AI 报价日志精简、MySQL 大表使用盘点与精简、Top10 慢 SQL 梳理。
  2. 单独处理 Kafka 超时/循环日志及剩余大字段，先做灰度和排障能力对比，再扩大范围。
  3. 确认 SAAS design.md 后实施 16 张分表字段、订单创建/追加/更新、出库 entryId 精确匹配及旧链路回归。