📚 课程目录第3章支付业务消息模型设计

3. 支付业务消息模型设计：订单、支付、对账、风控等 Topic 的合理划分

在支付系统中，Topic 的划分直接决定了消息的隔离性、扩展性以及运维复杂度。一个合理的 Topic 模型应当遵循“业务边界清晰、数据生命周期一致、消费者组独立”的原则。本节将围绕订单、支付、对账、风控四大核心领域，给出经过生产验证的 Topic 划分方案。

3.1 支付业务核心 Topic 划分矩阵

下表列出了支付系统中常见的 Topic 及其关键属性。每个 Topic 对应一个独立的业务域，拥有独立的存储策略和消费语义。

Topic 名称	业务域	分区数建议	保留策略	消息格式	关键消费者
`order-lifecycle`	订单	12~24	7 天	OrderEvent	订单服务、履约服务
`payment-txn`	支付	24~48	3 天	PaymentTransaction	支付网关、账务服务
`reconciliation-raw`	对账	6~12	30 天	ReconciliationRecord	对账引擎、差错处理
`risk-decision`	风控	12~24	1 天	RiskEvent	风控引擎、规则计算
`notification-dispatch`	通知	6~12	2 天	NotificationMessage	短信、邮件、推送服务
`audit-log`	审计	3~6	90 天	AuditEntry	审计系统、合规检查

设计要点：支付类 Topic 的保留期不宜过长（通常 3~7 天），因为支付数据对实时性敏感，且下游消费后通常会持久化到数据库。对账和审计 Topic 需要更长的保留期，以支持跨日核对和合规追溯。

3.2 订单与支付 Topic 的分离策略

很多团队初期将订单和支付事件合并到一个 Topic，导致消费端逻辑耦合、分区扩展困难。正确的做法是将订单生命周期事件和支付交易事件拆分为两个独立的 Topic。

订单 Topic（order-lifecycle）：承载订单创建、取消、完成等状态变更事件。分区键使用 order_id，保证同一订单的事件顺序。
支付 Topic（payment-txn）：承载支付发起、成功、失败、退款等交易事件。分区键使用 payment_id 或 transaction_id，保证同一笔支付的状态顺序。

分离带来的好处：

独立扩展：支付 Topic 的吞吐量通常远高于订单 Topic，分离后可以单独增加支付 Topic 的分区数。
消费隔离：订单服务和支付服务可以独立调整消费者组，互不影响。
语义清晰：下游对账系统只需要订阅支付 Topic，无需过滤订单事件。

生产案例：某支付平台在合并 Topic 阶段，支付峰值时订单事件占用了 60% 的 Topic 带宽，导致支付事件延迟上升。拆分为独立 Topic 后，支付延迟从 800ms 降至 120ms。

3.3 对账 Topic 的“原始数据”设计原则

对账系统需要消费来自多个渠道的原始交易记录，包括支付网关、银行、第三方支付机构等。对账 Topic 的设计应遵循“原始数据不加工”原则。

Topic 名称：reconciliation-raw
消息内容：直接存储渠道返回的原始报文（JSON 或 CSV 格式），不做任何清洗或转换。
分区策略：按渠道 ID 或日期进行分区，便于对账引擎按渠道并行消费。
幂等性：对账消息可能重复投递，消费者端必须基于交易流水号做幂等去重。

// 对账原始消息示例（JSON）
{
  "channel": "alipay",
  "batch_date": "2025-03-21",
  "records": [
    {
      "txn_id": "2025032100012345",
      "amount": 1999,
      "status": "SUCCESS",
      "raw": "<xml>...</xml>"
    }
  ]
}

避坑提醒：不要在生产者端对原始报文做字段裁剪或格式转换，否则一旦对账发现差异，将无法回溯原始数据。对账 Topic 的消费者应保留原始报文至少 30 天。

3.4 风控 Topic 的实时性与优先级

风控系统对消息的实时性要求极高，通常需要在毫秒级内完成规则判定。风控 Topic 的设计需要兼顾低延迟和高吞吐。

Topic 名称：risk-decision
分区数：建议与风控引擎的并行度一致（通常 12~24 个分区）。
消息大小：控制在 1KB 以内，仅包含风控判定所需的关键字段（用户 ID、设备指纹、交易金额、IP 等）。
ACK 策略：使用 acks=1 或 acks=0 降低延迟，但需配合生产者重试机制。

风控 Topic 的消费者通常采用“同步+异步”混合模式：同步调用风控规则引擎，异步将判定结果写入下游 Topic。

3.5 Topic 划分架构总览

下图展示了支付系统中各 Topic 之间的上下游关系。箭头方向表示消息流向，每个 Topic 对应一个独立的业务域。

3.6 分区键与消息顺序保证

在支付场景中，同一笔交易的状态变更必须严格有序。分区键的选择直接影响消息顺序的保证能力。

Topic	推荐分区键	顺序保证范围	说明
`order-lifecycle`	`order_id`	同一订单内严格有序	订单状态机依赖顺序消费
`payment-txn`	`payment_id`	同一支付单内严格有序	支付状态变更不可乱序
`reconciliation-raw`	`channel_id + date`	同一渠道同一天内有序	对账按渠道和日期批量处理
`risk-decision`	`user_id`	同一用户内有序	风控规则依赖用户历史行为

关键原则：分区键的基数应远大于分区数，避免数据倾斜。例如 payment_txn 有 24 个分区，但支付 ID 的基数可达百万级，每个分区负载均匀。

3.7 避免 Topic 数量膨胀的治理策略

随着业务发展，Topic 数量容易失控。建议采用以下治理策略：

按业务域聚合：同一业务域内的多个子事件（如支付成功、支付失败、支付退款）合并到同一个 Topic，通过消息类型字段区分。
按数据生命周期分层：实时 Topic（保留 1~3 天）、近线 Topic（保留 7~30 天）、离线 Topic（保留 90 天以上），分别对应不同的存储介质。
使用 Topic 命名规范：{业务域}-{数据类型}-{环境}，例如 payment-txn-prod、reconciliation-raw-prod。
定期清理废弃 Topic：通过元数据管理平台标记无消费者订阅的 Topic，超过 30 天自动归档。

常见误区：不要为每个微服务创建独立的 Topic。例如订单服务和库存服务如果都消费订单事件，应该共享同一个 order-lifecycle Topic，通过不同的消费者组进行隔离。

3.8 消息模型设计检查清单

在完成 Topic 划分后，建议对照以下清单进行复核：

每个 Topic 是否只承载一个业务域的数据？
分区键是否能够保证关键业务的有序性？
保留策略是否与数据消费窗口匹配？
是否存在多个消费者组订阅同一个 Topic 但消费逻辑重复？
对账 Topic 是否保留了原始报文？
风控 Topic 的消息大小是否控制在 1KB 以内？
Topic 命名是否遵循了统一的规范？
是否有自动化工具监控 Topic 的积压和分区倾斜？

通过以上设计，支付系统的消息模型能够同时满足高吞吐、低延迟、易扩展的生产要求，为后续的并发瓶颈诊断和消息堆积治理打下坚实基础。