jsowell-charger-web/docs/feature-tracker-无交易记录自动结算.md

功能开发追踪：无交易记录时按实时检测数据自动结算

功能编号: TBD 版本: v0.4 日期: 2026-08-11 项目: 万车充运营管理平台 状态: ✅ 方案已确认，待开发 负责模块: jsowell-pile / jsowell-netty / jsowell-quartz

---

变更记录

版本	日期	变更内容
v0.1	2026-08-11	初稿：需求分析、风险点、实现方案、开发进度追踪框架
v0.2	2026-08-11	确认决策：金额以桩端 chargingAmount 为准；双依据判定都启用；特定站点灰度
v0.3	2026-08-11	新增8个待明确问题（第六章）；扩充测试计划至29个场景（第七章）；新增附录
v0.4	2026-08-11	✅ 完成8个问题的决策回答；更新已决策问题列表（11个决策）；状态更新为"方案已确认，待开发"

---

一、背景与目标

背景

当前自动结算唯一入口是收到交易记录帧。充电桩在线、充电已停止，但若未收到交易记录（桩端漏发、网络丢帧、交易记录帧异常等），订单将永远停留在「待结算」状态，无法自动结算，导致：

• 用户预付资金长期冻结，体验差
• 后台需要人工介入结算，运维成本高

目标

充电桩在线且停止充电超过 10 分钟仍未收到交易记录时，平台按最后一条实时检测记录中的耗电量（充电度数）自动结算，替代人工结算，缩短资金冻结周期。

非目标（本期不做）

• 桩离线场景的自动结算（离线时数据不可信，需人工确认）
• 尖峰平谷分时明细的补全（实时数据本身不含分时信息）

---

二、需求分析

2.1 当前逻辑（现状）

环节	现状	代码位置
结算触发	仅收到交易记录帧时触发 settleOrder	TransactionRecordsRequestHandler.processOrder() → jsowell-netty/.../TransactionRecordsRequestHandler.java:683
结算数据来源	交易记录 TransactionRecordsData（含尖峰平谷分时电量、单价、金额）	同上
无交易记录时	订单停在「待结算」，不自动结算	—
桩离线	订单置为异常 updateOrderStatusAsAbnormal	YKCBusinessServiceImpl.java:166
人工结算	已支持「无交易记录 → 用最后一条实时数据构造结算数据」	OrderService.manualSettlementOrder() → jsowell-admin/.../OrderService.java:1008-1027

2.2 目标逻辑

定时任务（周期可配，默认如每 10 分钟）扫描待结算订单：
  ├─ 条件 1：订单状态 = 待结算 (STAY_SETTLEMENT)
  ├─ 条件 2：充电桩在线（connector status ≠ "0" 离线）
  ├─ 条件 3：充电已停止超过 10 分钟
  │     ├─ 优先依据：chargeEndTime 非空 且 距当前 > 10 分钟（桩上报过 0x19 充电结束）
  │     └─ 兜底依据：最后一条实时检测数据 dateTime 距当前 > 10 分钟（桩未上报结束/交易记录）
  └─ 条件 4：存在实时检测数据（chargingDegree > 0）

命中后：
  1. 复用人工结算逻辑，从最后一条实时检测数据构造 TransactionRecordsData
  2. 走 orderLogic.settleOrder(data, orderBasicInfo)

2.3 关键数据来源

数据	字段	说明
累计充电度数	RealTimeMonitorData.chargingDegree	精确到 4 位小数，待机置零
已充金额	RealTimeMonitorData.chargingAmount	桩端计算（电费+服务费）*计损度数
实时数据落库	order_monitor_data 表 / redis PILE_REAL_TIME_MONITOR_DATA	充电中每 10s 上报一次，按分钟保留最后一条
桩在线状态	PileConnectorDataBaseStatusEnum	"0"=离线，1/2/3/4=在线
充电结束信号	ChargeEndHandler (0x19)	更新 chargeEndTime、endSoc

---

三、风险点与应对

#	风险	等级	说明	应对
R1	金额准确性依赖桩端上报	高	实时数据无尖峰平谷分时明细，结算走「以交易记录金额为准」分支，即完全信任桩端 chargingAmount。若桩端该值有误（充电中途拔枪、数据异常），直接导致扣费/退款不准确	已决策：以桩端 chargingAmount 为准（与人工结算一致）。降低影响：① 异常金额阈值（chargingAmount 远超 payAmount）时跳过并告警；② 特定站点灰度上线，逐步观察
R2	退款联动	中	chargingAmount < 预付款 payAmount 时走退款流程，金额不准会连带退款不准	结算金额以 chargingAmount 为准，与人工结算一致；金额异常（远超 payAmount）时跳过并告警
R3	幂等 / 并发	中	定时扫描与「交易记录恰好到达」可能并发重复结算	复用现有 settle_order_+transactionCode redis 锁（TransactionRecordsRequestHandler.java:602）；结算前校验订单状态与结算时间
R4	判「停止」时间点模糊	中	桩只拔枪不上报 0x19 时，chargeEndTime 为空，只能依赖实时数据 dateTime 判定；若桩同时离线则数据停更	已决策：双依据都启用（chargeEndTime 优先，最后实时数据 dateTime 兜底）。条件 2（在线）为安全底线，离线订单不结算
R5	影响面扩散	中	该逻辑影响所有待结算订单，改动结算主链路风险高	不修改结算核心 settleOrder，仅新增定时扫描入口，复用人工结算构造逻辑
R6	灰度与回滚	中	新逻辑上线初期存在未覆盖场景	已决策：特定站点灰度（auto-settle.grayscale-station-ids）。开关关闭即回退到现有行为

---

四、实现方案

4.1 总体思路

不修改现有结算核心链路，新增定时扫描任务，命中条件后复用人工结算的「实时数据 → TransactionRecordsData」构造逻辑，再走既有的 settleOrder。

4.2 实现步骤

#	步骤	说明	模块
1	配置开关	新增自动结算开关 + 站点灰度白名单：auto-settle.enabled、auto-settle.timeout-minutes=10、auto-settle.interval、auto-settle.grayscale-station-ids（特定站点灰度）。默认关闭或仅灰度站点开启	jsowell-pile / application.yml
2	构造结算数据方法	在 OrderService（或抽到 pile 的公共 Service）新增「从最后一条实时数据构造 TransactionRecordsData」方法，与人工结算复用同一逻辑	jsowell-admin / jsowell-pile
3	查询待结算订单	新增 mapper 查询：状态=待结算 + 桩在线 + 满足停止条件（chargeEndTime/最后实时数据时间 < 当前-10min）的订单列表	jsowell-pile
4	定时任务	新增 Quartz Job，周期执行扫描+结算，含 redis 分布式锁防并发	jsowell-quartz
5	结算执行	循环命中订单，构造数据 → orderLogic.settleOrder，异常单独捕获不影响整体	jsowell-pile
6	幂等保护	结算前校验订单状态未变更、settle_order_ 锁未占用	jsowell-pile
7	告警日志	结算异常、金额异常（chargingAmount 远大于 payAmount）时输出 ERROR 日志/告警	各模块

4.3 涉及文件清单（预估）

文件	变更
jsowell-pile/.../OrderBasicInfoService.java	新增查询待结算订单方法
jsowell-pile/.../OrderBasicInfoServiceImpl.java	实现查询逻辑
jsowell-pile/.../OrderBasicInfoMapper.xml	新增 SQL
jsowell-admin/.../OrderService.java	抽取「实时数据→结算数据」构造方法（或下沉到 pile）
jsowell-quartz/.../RyTask.java 或新增 Task	新增自动结算定时任务
jsowell-admin/src/main/resources/application*.yml	新增配置项

---

五、开发进度追踪

状态：⬜ 未开始 / 🟡 进行中 / ✅ 已完成 / 🔴 阻塞

#	任务	模块	负责人	状态	备注
1	需求评审确认（含 R1/R4 决策）	-		✅ 已完成	2026-08-11 确认：金额以桩端 chargingAmount 为准；双依据判定；特定站点灰度
1.1	8个待明确问题决策	-		✅ 已完成	2026-08-11 完成全部8个问题的决策回答
2	配置开关（11个配置项）	jsowell-pile		⬜ 未开始	application.yml 新增 auto-settle 配置块
3	实时数据→结算数据构造方法	jsowell-admin/pile		⬜ 未开始	从Redis获取实时数据，构造 TransactionRecordsData
4	待结算订单查询 SQL	jsowell-pile		⬜ 未开始	支持Redis查询桩在线状态，降级JOIN查询
5	定时任务	jsowell-quartz		⬜ 未开始	Cron表达式：0 */10 * * * ?
6	幂等保护（redis锁+乐观锁）	jsowell-pile		⬜ 未开始	settle_order_{orderId} + UPDATE WHERE条件
7	数据校验与告警日志	jsowell-pile		⬜ 未开始	度数、金额、阈值三层校验
8	单元测试 / 集成测试	jsowell-admin		⬜ 未开始	覆盖29个测试场景（P0优先）
9	灰度上线（特定站点）	-		⬜ 未开始	先对灰度站点开启，观察稳定后逐步放开
10	上线后监控与复盘	-		⬜ 未开始	监控Prometheus指标，分析自动结算效果

已决策问题

#	问题	决策	决策日期
1	金额策略	以桩端 chargingAmount 为准（与人工结算一致）	2026-08-11
2	停止判定依据	双依据都启用：chargeEndTime 优先，最后实时数据 dateTime 兜底	2026-08-11
3	灰度范围	特定站点灰度，先对指定站点开启，观察稳定后再逐步放开	2026-08-11
4	并发幂等锁key	采用方案A：基于orderId构造 "settle_order_" + orderId	2026-08-11
5	异常金额阈值	倍率阈值策略：amount-threshold-ratio: 1.5	2026-08-11
6	桩在线查询	优先Redis缓存（方案C），降级JOIN查询（方案D）	2026-08-11
7	最后实时数据	直接从Redis取（方案B），失败降级DB查询（方案A）	2026-08-11
8	状态校验原子性	UPDATE带WHERE条件（乐观锁，方案A）+ redis分布式锁双重保障	2026-08-11
9	数据新鲜度	增加判断，阈值30分钟 data-freshness-minutes: 30	2026-08-11
10	异常数据拦截	采用三层校验：度数>0、金额>0、金额<阈值	2026-08-11
11	配置项	采用完整配置项（11个配置）	2026-08-11

---

六、待明确问题

状态说明：⬜ 待回答 / ✅ 已解决 / 🔴 阻塞中

6.1 并发幂等保护的锁key构造（对应风险R3）

问题描述： 文档中提到复用 settle_order_+transactionCode redis锁，但无交易记录场景下没有transactionCode，锁key应如何构造？

影响：

• 若锁key不正确，可能导致定时任务与交易记录到达的并发冲突
• 多个定时任务实例同时扫描时可能重复结算

建议方案：

// 方案A：基于orderId构造锁key
String lockKey = "settle_order_" + orderId;

// 方案B：保持现有逻辑，构造虚拟transactionCode
String transactionCode = "AUTO_" + orderId + "_" + System.currentTimeMillis();
String lockKey = "settle_order_" + transactionCode;

回答：

状态：✅ 已解决

决策：采用方案A，基于orderId构造锁key
理由：transactionCode在创建订单的时候就已经生成了，但无交易记录场景下不会再生成新的，
     因此统一使用 "settle_order_" + orderId 作为锁key，与交易记录到达时使用同一把锁。
实现：String lockKey = "settle_order_" + orderId;

---

6.2 异常金额阈值的量化定义（对应风险R1/R2）

问题描述： 文档多次提到"chargingAmount 远超 payAmount 时告警跳过"，但**"远超"没有具体定义**。

影响：

• 无明确阈值会导致实现时判断标准不统一
• 无法准确识别异常金额并拦截

建议方案：

auto-settle:
  amount-threshold-ratio: 1.5  # chargingAmount > payAmount * 1.5 时告警跳过
  # 或者使用绝对差值
  amount-threshold-diff: 100.0  # chargingAmount - payAmount > 100元时告警

示例：

• payAmount = 50元，chargingAmount = 76元 → 1.52倍 → 告警跳过
• payAmount = 50元，chargingAmount = 72元 → 1.44倍 → 正常结算

回答：

状态：✅ 已解决

决策：采用倍率阈值策略
配置：amount-threshold-ratio: 1.5
理由：倍率阈值比绝对差值更通用，适应不同金额区间的订单。
     例如：10元订单和100元订单的异常判断标准应该成比例，而非固定差值。
实现：if (chargingAmount > payAmount * 1.5) { 告警跳过 }

---

6.3 SQL查询"桩在线"条件的实现效率

问题描述： 定时任务需要查询"桩在线"的待结算订单，但order_basic_info表可能没有直接存储connector_status字段，需要JOIN pile_connector_info表，大批量查询可能有性能问题。

影响：

• 每次扫描都需要多表JOIN，数据量大时查询慢
• 定时任务执行时间过长可能影响下一轮扫描

建议方案：

方案	优点	缺点	实施难度
A. 订单表增加冗余字段connector_status	查询快，单表索引	需要实时同步状态，数据冗余	中
B. 分批查询（先查订单，再批量查桩状态）	不改表结构	需要两次查询，逻辑复杂	低
C. 从Redis缓存判断（PILE_REAL_TIME_MONITOR_DATA）	最实时，无DB压力	Redis数据可能缺失	低
D. 直接JOIN查询（当前方案）	实现简单	性能问题	最低

回答：

状态：✅ 已解决

决策：优先使用方案C（Redis缓存），失败时降级到方案D（JOIN查询）
理由：Redis缓存最实时且无DB压力，适合高频扫描场景。
实现逻辑：
  1. 先从 Redis PILE_REAL_TIME_MONITOR_DATA:{connectorId} 获取数据
  2. 若Redis中有数据，直接判断connector在线状态
  3. 若Redis中无数据或异常，降级到JOIN pile_connector_info表查询
  4. 记录降级日志，便于监控Redis缓存命中率

---

6.4 "最后一条实时数据"的精确定义

问题描述： 条件4要求"存在实时检测数据（chargingDegree > 0）"，但如何确定"最后一条"数据？

• 按dateTime排序？如果同一分钟有多条怎么办？
• 按主键ID排序？
• Redis缓存里的是不是一定是最后一条？

影响：

• 排序规则不明确可能导致取错数据
• 影响结算金额准确性

建议方案：

-- 方案A：按时间+主键双重排序
SELECT * FROM order_monitor_data 
WHERE order_id = ? 
ORDER BY date_time DESC, id DESC 
LIMIT 1;

-- 方案B：直接从Redis取
String key = "PILE_REAL_TIME_MONITOR_DATA:" + connectorId;
RealTimeMonitorData data = redis.get(key);

-- 方案C：取settle_time前的最后一条
SELECT * FROM order_monitor_data 
WHERE order_id = ? 
  AND date_time <= NOW()
ORDER BY date_time DESC, id DESC 
LIMIT 1;

回答：

状态：✅ 已解决

决策：采用方案B（直接从Redis取）
理由：Redis中的 PILE_REAL_TIME_MONITOR_DATA 缓存已经是最新的实时数据，
     按充电桩上报机制，每次上报都会更新该缓存为最新值。
实现：
  String key = "PILE_REAL_TIME_MONITOR_DATA:" + connectorId;
  RealTimeMonitorData data = redis.get(key);
备注：若Redis获取失败，可降级查询DB，使用方案A（按date_time DESC, id DESC排序）

---

6.5 状态校验的原子性保证（对应风险R3）

问题描述： 文档中提到"结算前校验订单状态未变更"，但校验→结算之间仍有并发窗口，可能导致：

• 线程A校验通过 → 线程B同时校验通过 → 两者同时结算

影响：

• 重复结算导致资金异常
• 数据一致性问题

建议方案：

-- 方案A：UPDATE语句带WHERE条件（乐观锁）
UPDATE order_basic_info 
SET order_status = 'COMPLETED', 
    settle_time = NOW(),
    ...
WHERE order_id = ? 
  AND order_status = 'STAY_SETTLEMENT'  -- 确保状态未变
  AND settle_time IS NULL;  -- 确保未结算过

-- 检查受影响行数
if (affectedRows == 0) {
    log.warn("订单{}状态已变更，跳过结算", orderId);
    return;
}

-- 方案B：SELECT FOR UPDATE（悲观锁）
SELECT * FROM order_basic_info 
WHERE order_id = ? 
FOR UPDATE;
-- 然后再UPDATE

-- 方案C：依赖redis分布式锁
if (!redisLock.tryLock("settle_order_" + orderId)) {
    return;
}
try {
    // 结算逻辑
} finally {
    redisLock.unlock();
}

回答：

状态：✅ 已解决

决策：采用方案A（UPDATE语句带WHERE条件，乐观锁）
理由：乐观锁适合并发冲突较少的场景，性能优于悲观锁，且实现简单。
     结合redis分布式锁（6.1中的方案），形成双重保障。
实现：
  UPDATE order_basic_info 
  SET order_status = 'COMPLETED', 
      settle_time = NOW(),
      ...
  WHERE order_id = ? 
    AND order_status = 'STAY_SETTLEMENT'  -- 确保状态未变
    AND settle_time IS NULL;              -- 确保未结算过
  
  if (affectedRows == 0) {
      log.warn("订单{}状态已变更，跳过结算", orderId);
      return;
  }

---

6.6 "桩假在线"场景的判断逻辑（对应风险R4补充）

问题描述： 真实场景可能出现：

• 桩TCP连接还在（connector_status ≠ 0）
• 但实际已停止上报数据（最后实时数据很久没更新）

这种"假在线"状态下，实时数据不可信，不应该触发自动结算。

影响：

• 可能使用过时数据结算
• 金额不准确

建议方案：

条件2补充为：
  - connector_status ≠ 0（连接在线）
  AND
  - 最后一条实时数据的dateTime距当前 < 30分钟（数据新鲜度）

示例：

• 当前时间：2026-08-11 14:00:00
• 最后实时数据时间：2026-08-11 13:55:00 → 新鲜度5分钟 → 通过
• 最后实时数据时间：2026-08-11 13:20:00 → 新鲜度40分钟 → 不通过（桩假在线）

回答：

状态：✅ 已解决

决策：增加数据新鲜度判断，阈值设为30分钟
配置：data-freshness-minutes: 30
理由：30分钟是合理的阈值，既能覆盖正常充电停止后的数据延迟，
     又能有效过滤"桩假在线"场景（连接在但不上报数据）。
实现条件：
  条件2更新为：
    - connector_status ≠ 0（连接在线）
    AND
    - 最后一条实时数据的dateTime距当前 < 30分钟（数据新鲜度）
示例：NOW() - dateTime < 30分钟

---

6.7 异常数据场景的处理策略

问题描述： 实时数据可能出现异常情况：

• chargingDegree > 0 但 chargingAmount = 0（金额未计算）
• chargingDegree = 0 但 chargingAmount > 0（数据矛盾）
• chargingDegree 为负数（数据异常）

影响：

• 异常数据直接结算会导致金额错误
• 需要明确拦截规则

建议方案：

// 数据校验规则
if (chargingDegree <= 0) {
    log.warn("订单{}充电度数异常：{}", orderId, chargingDegree);
    return; // 跳过
}

if (chargingAmount <= 0) {
    log.warn("订单{}充电金额异常：{}", orderId, chargingAmount);
    return; // 跳过
}

if (chargingAmount > payAmount * amountThresholdRatio) {
    log.error("订单{}金额异常：实际{}元 > 预付{}元 * {}", 
              orderId, chargingAmount, payAmount, amountThresholdRatio);
    // 发送告警
    return; // 跳过
}

回答：

状态：✅ 已解决

决策：采用建议的数据校验规则
实现：
  // 1. 充电度数校验
  if (chargingDegree <= 0) {
      log.warn("订单{}充电度数异常：{}", orderId, chargingDegree);
      return; // 跳过
  }
  
  // 2. 充电金额校验
  if (chargingAmount <= 0) {
      log.warn("订单{}充电金额异常：{}", orderId, chargingAmount);
      return; // 跳过
  }
  
  // 3. 金额阈值校验（结合6.2的决策）
  if (chargingAmount > payAmount * amountThresholdRatio) {
      log.error("订单{}金额异常：实际{}元 > 预付{}元 * {}", 
                orderId, chargingAmount, payAmount, amountThresholdRatio);
      // 发送告警
      return; // 跳过
  }
  
补充场景：暂无其他需要拦截的异常场景，后续如发现新场景再补充。

---

6.8 配置项完整性补充

问题描述： 当前配置项不完整，缺少以下关键配置：

建议补充：

auto-settle:
  # 现有配置
  enabled: false                      # 总开关
  timeout-minutes: 10                 # 停止超时阈值
  interval: '0 */10 * * * ?'         # 扫描周期（Cron表达式）
  grayscale-station-ids: [1001,1002] # 灰度站点白名单
  
  # 🆕 建议补充
  amount-threshold-ratio: 1.5         # 金额异常阈值倍数（对应6.2）
  batch-size: 100                     # 单次扫描订单数量上限（防止一次查太多）
  data-freshness-minutes: 30          # 实时数据新鲜度阈值（对应6.6）
  alert-enabled: true                 # 告警开关
  lock-timeout-seconds: 60            # redis锁超时时间
  retry-on-failure: false             # 失败是否重试（建议false，等下一轮）

回答：

状态：✅ 已解决

决策：采用建议的所有配置项
完整配置：
auto-settle:
  # 基础配置
  enabled: false                        # 总开关，默认关闭
  timeout-minutes: 10                   # 停止超时阈值
  interval: '0 */10 * * * ?'           # 扫描周期（Cron表达式）
  grayscale-station-ids: [1001,1002]   # 灰度站点白名单
  
  # 新增配置
  amount-threshold-ratio: 1.5           # 金额异常阈值倍数（对应6.2）
  batch-size: 100                       # 单次扫描订单数量上限
  data-freshness-minutes: 30            # 实时数据新鲜度阈值（对应6.6）
  alert-enabled: true                   # 告警开关
  lock-timeout-seconds: 60              # redis锁超时时间
  retry-on-failure: false               # 失败是否重试（建议false，等下一轮）

备注：所有配置项均已明确，可直接用于开发。

---

七、测试计划

7.1 基础功能测试

#	场景	预期	优先级
1	桩在线 + 有 chargeEndTime + 停止>10min + 有实时数据	自动结算成功，金额=实时数据 chargingAmount	P0
2	桩在线 + 无 chargeEndTime + 最后实时数据>10min + 有实时数据	兜底依据触发，自动结算	P0
3	桩离线（connector_status=0）	不触发（条件 2 拦截）	P0
4	停止 < 10min	不触发	P1
5	停止 = 10min 0秒（边界值）	应触发（>= 10min）	P1
6	无实时检测数据（chargingDegree=0）	不触发	P1
7	配置开关关闭（enabled=false）	保持现有行为（不自动结算）	P0

7.2 异常数据测试

#	场景	预期	优先级
8	chargingAmount > payAmount * threshold（异常值）	跳过并告警，不结算	P0
9	chargingDegree > 0 但 chargingAmount = 0	跳过并告警（数据异常）	P1
10	chargingDegree = 0 但 chargingAmount > 0	跳过并告警（数据矛盾）	P1
11	chargingDegree 为负数	跳过并告警（数据异常）	P1
12	chargingAmount < payAmount（正常退款场景）	正常结算并退款差额	P0

7.3 并发与幂等测试

#	场景	预期	优先级
13	扫描期间交易记录帧到达（并发）	仅一方结算成功，另一方被幂等拦截	P0
14	多个定时任务实例同时扫描同一订单	仅一个实例处理成功（分布式锁生效）	P0
15	订单在校验后、结算前状态被其他线程修改	被原子性校验拦截，不重复结算	P0

7.4 灰度与配置测试

#	场景	预期	优先级
16	灰度站点内的订单	触发自动结算	P0
17	非灰度站点的订单	不触发（即使满足条件）	P0
18	混合：部分灰度、部分非灰度站点	仅灰度站点订单被处理	P1
19	batch-size限制（如设为10，实际符合20单）	仅处理前10单，下次扫描处理剩余	P1

7.5 边界与容错测试

#	场景	预期	优先级
20	桩"假在线"（连接在线但数据>30分钟未更新）	不触发（数据新鲜度检查拦截）	P0
21	数据库查询订单列表为空	正常退出，无异常	P1
22	Redis获取实时数据失败	降级查DB，或跳过并记录日志	P1
23	结算过程中DB连接超时	捕获异常，不影响其他订单处理	P1
24	单个订单结算失败（业务异常）	记录失败日志，继续处理其他订单	P0

7.6 压力测试

#	场景	预期	优先级
25	1000个待结算订单同时满足条件	batch-size分批处理，不超时	P2
26	定时任务执行时间 > 扫描周期（如>10min）	下一轮等待当前轮完成，或跳过	P2

7.7 监控与告警测试

#	场景	预期	优先级
27	金额异常告警触发	ERROR日志输出，告警系统收到通知	P1
28	自动结算成功	INFO日志记录订单号、金额、耗时	P1
29	查看Prometheus指标	统计自动结算成功数、失败数、跳过数	P2