2026-06-04｜多数据源冲突修复与 UAT 联调

1. UAT 订单查询失败问题排查#

今天首先处理了 UAT 环境中订单交付查询失败的问题。问题现象是调用订单交付查询接口时报错：

1
Table 'pg_gong_20231020.order_data' doesn't exist

从表面看像是 order_data 表不存在，但进一步分析发现，order_data 实际属于 productsys 库 sf_productsys20240111，而报错却显示 SQL 在 SCM 库 pg_gong_20231020 中执行。因此真正的问题不是表缺失，而是订单查询 Mapper 被绑定到了错误的数据源。

排查过程中先后验证了网络连通性、配置一致性、多数据源初始化情况和 Spring Bean 注册行为。最终定位到 ScmMybatisPlusConfig 的 @MapperScan(basePackageClasses = IvscOrderInfoMapper.class) 会从 IvscOrderInfoMapper 所在包 com.sangfor.pangugong.mapper 开始递归扫描所有子包，导致 mapper.productsys 下的 OrderDeliveryMapper 被 SCM 数据源扫描并注册。

由于 Spring Boot 默认禁止同名 Bean 覆盖，SCM 配置类先加载时抢先注册了 OrderDeliveryMapper，productsys 配置类后续再尝试注册时被拒绝。最终 OrderDeliveryMapper 被错误绑定到 scmSqlSessionFactory，订单查询 SQL 被发到 SCM 库执行，从而报出表不存在。

2. 多数据源扫描冲突修复#

针对该问题，今天新增了 @ScmMapper 自定义注解，作为 SCM 专属 Mapper 的白名单标记：

1
@Documented
2
@Retention(RetentionPolicy.RUNTIME)
3
@Target(ElementType.TYPE)
4
public @interface ScmMapper {
5
}

随后将 ScmMybatisPlusConfig 的 Mapper 扫描方式改造为：

1
@MapperScan(
2
    basePackageClasses = IvscOrderInfoMapper.class,
3
    annotationClass = ScmMapper.class,
4
    sqlSessionFactoryRef = "scmSqlSessionFactory"
5
)

改造后，即使扫描起点仍是 com.sangfor.pangugong.mapper，也只有标注了 @ScmMapper 的接口会被注册到 SCM 数据源。今天同步为 5 个 SCM 专属 Mapper 添加了该标记。

productsys、oracle、doris 包下的 Mapper 不添加 @ScmMapper，因此不会再被 SCM 数据源误扫。修复后，订单交付查询能够回到正确的 productsys 数据源执行，UAT 订单查询失败问题得到解决。

3. UAT 企微推送连通#

今天还处理了 UAT 环境中企微推送不通的问题。本地调用 qyapi.weixin.qq.com 正常，但 UAT 调度器触发后用户没有收到消息。经过排查，确认原因是 UAT K8s 集群出口防火墙拦截了 qyapi.weixin.qq.com:443。

处理方式是协调运维开通 UAT 集群到企业微信 API 的白名单。开通后第一轮测试即收到推送，说明 WecomAppPushService、企微应用配置和推送代码逻辑均正常。

4. 调度器轮询间隔优化#

订单关注模块原先的调度器轮询间隔是 2 小时。该间隔对 UAT 联调和用户体验来说过长。今天将轮询间隔调整为 10 分钟，初始延迟调整为 30 秒。

5. 状态快照从内存缓存改为数据库持久化#

原实现中，调度器使用 ConcurrentHashMap 在内存中记录上次订单状态和预计发货时间。该方式存在重启丢失的问题。今天将状态快照改为持久化到 portal_order_follow 表中的 last_order_status 和 last_est_delivery_time 字段，使状态变更检测基准在服务重启后仍然保留。

6. 用户关注后即时检测#

为了提升用户关注订单后的反馈及时性，今天在 OrderFollowService.followOnQuery() 中加入了异步即时检测逻辑。用户查询订单并自动关注成功后，系统会异步调用 scheduler.checkSingleOrder(orderNumber)，立即执行一次单订单状态检测。

同时将单订单检测逻辑抽取为公共方法 checkSingleOrder(String orderNumber)，让定时扫描和即时检测复用同一套逻辑，降低代码重复和后续维护成本。

7. UAT 双用户推送验证#

今天完成了 UAT 环境下订单关注模块的多场景验证，覆盖用户 66320 和 w47507。验证内容包括：关注后即时检测、发货时间变更推送、已发货推送、已到货推送、已到货后自动取消关注、双用户同时关注同一订单后的推送、DB 持久化快照验证。验证结果均通过。

1. UAT 订单查询 SQL 执行到了错误数据库#

• 问题：订单查询本应访问 productsys 库，却在 UAT 中访问了 SCM 库，导致 order_data 表不存在。
• 处理：分析 MyBatis-Spring 的 basePackageClasses 扫描行为，确认 SCM 的 MapperScan 递归扫描了 productsys 子包。
• 结果：通过 @ScmMapper 和 annotationClass 白名单过滤修复。

2. Mapper Bean 被 SCM 数据源抢先注册#

• 问题：SCM 配置类先加载时注册了 OrderDeliveryMapper，productsys 配置类后加载时同名 Bean 注册失败。
• 处理：限制 SCM MapperScan 注册范围，避免其扫描 productsys Mapper。
• 结果：Mapper 注册边界清晰，productsys Mapper 能绑定到正确的数据源。

3. UAT 企微推送不通#

• 问题：本地推送正常，但 UAT 用户收不到企微消息。
• 处理：排查确认 UAT K8s 集群出口被防火墙限制，协调开通 qyapi.weixin.qq.com:443 白名单。
• 结果：白名单开通后 UAT 推送成功。

4. 内存状态快照重启丢失#

• 问题：使用 ConcurrentHashMap 记录状态快照时，服务重启后缓存丢失。
• 处理：将状态快照改为写入 portal_order_follow 表。
• 结果：状态对比基准持久化，重启后不丢失。

5. 关注后等待调度时间较长#

• 问题：用户关注后需要等下一轮定时任务才会检测状态。
• 处理：在关注成功后异步触发 checkSingleOrder(orderNumber)。
• 结果：关注后可立即建立快照或触发状态变化处理。

6. Service 与 Scheduler 存在循环依赖#

• 问题：OrderFollowService 需要触发 Scheduler，Scheduler 又依赖 Service 查询关注数据。
• 处理：使用 @Lazy 注入调度器，并抽取公共单订单检测方法。
• 结果：解决循环依赖，同时提升代码复用性。