Skip to content

Tracking ​

解决什么问题:业务事件跨多个系统后无法追溯——"订单从下单到送达到底发生了什么"。Tracking = 业务事件维度的可观测性,区别于技术 trace。

它是什么 ​

Tracking(业务追踪) 是对业务事件在跨系统流动中的端到端追踪——它不只是技术 trace,还包括业务语义:

  • 一个订单的下单、支付、发货、收货事件链
  • 一个用户的注册、激活、首次购买旅程
  • 一个资金流的入账、扣款、结算全路径

EDM Ch 11:"Business event tracking gives you business observability—not just system observability."

V2 视角(V2.7 B5 反馈):Tracking = 业务维度的反馈通道——和系统 trace 不同,business tracking 关心"业务发生了什么" 而非"系统做了什么"。

关键属性 ​

属性值/含义
追踪对象业务事件(订单、用户、资金流)
关联键correlationId / orderId / userId
载体事件流(Event Stream)+ 业务事件存储
可视化时间线 / 桑基图 / 状态机图
反模式只 trace 技术不 trace 业务 / 没有 correlationId
核心约束跨 BC 传递 correlationId——是 Tracking 的前提
判错标准客户问"我的订单到哪了"客服答不出来 = Tracking 失效

怎么用 ​

场景 1:订单全链路 Tracking ​

java
// 下单 BC 发出事件,带 correlationId
eventBus.publish(new OrderPlaced(
    orderId,
    customerId,
    correlationId  // 整个生命周期传递
));

// 支付 BC 消费,传播
eventBus.publish(new OrderPaid(
    orderId,
    paymentId,
    correlationId  // 同一 ID
));

// 物流 BC 消费,传播
eventBus.publish(new OrderShipped(
    orderId,
    trackingNumber,
    correlationId
));

查询:用户查订单状态 → 查 Event Store / 业务事件表 → 按 correlationId 拉出全链路。

场景 2:用户旅程 Tracking ​

注册 → 激活 → 首次购买 → 复购——每一步都是事件:

UserSignedUp → UserActivated → FirstPurchase → RepeatPurchase

应用:漏斗分析、转化率、A/B test 结果归因。

场景 3:资金流 Tracking ​

金融系统必备——每笔钱从入账到结算的完整流向:

DepositReceived → FundsAllocated → Withdrawn → Settled

要求:不可篡改(审计)、可追溯(合规)、可对账(业务)。

常见误区 ​

  1. "Tracking = 分布式 Trace"——错。Trace 是技术维度(HTTP 调用),Tracking 是业务维度(订单生命周期)
  2. "Tracking = 加日志"——错。日志是技术记录,Tracking 是业务事件的因果链——必须有事件 store
  3. "不需要跨 BC 传 ID"——错。不传 correlationId = 没 tracking——这是头号反模式
  4. "全量存储事件"——对但要权衡——事件存储比 log 贵——要分层(热/温/冷)
  5. "Tracking = BI"——半错。BI 是聚合分析,Tracking 是单事件因果——两者互补

关键洞察 ​

Tracking 是控制论反馈通道的"业务版本"——业务事件的因果链 = 业务系统的传递函数。

控制论 Ch 7 §7.4 视角:状态反馈 = 通过可观测变量重构内部状态。Tracking = 用业务事件重构业务状态。 IDDD Ch 8 视角:领域事件是 Tracking 的天然载体——发事件 = 记录业务发生 = 提供 tracking 数据。 SE@G Ch 22 视角:技术 trace 不能替代业务 tracking——两者维度不同,必须配合。 EDM Ch 11 视角:事件溯源(Event Sourcing)系统天然有完美 tracking——事件流就是业务历史。

相关链接 ​

从名家方法论与工程化思路中蒸馏出自己的工程体系。