约束驱动设计：为何选择内存追踪

追踪的本质

分布式系统中，一个请求会流经多个服务、多个函数、多个外部API。当某个环节失败时，你需要知道请求在哪里断掉，为什么断掉，之前经历了什么。

追踪系统就是为请求打上标记，记录它的完整生命周期。从前端发起，到网关接收，到处理器调用AI厂商API，再到回调返回——每一步都有痕迹可循。

这不是可选功能。没有追踪，你在黑暗中调试。

两种路径

实现追踪有两种基本路径：

持久化追踪：将追踪信息写入数据库。每个请求的每个环节都持久化存储，可以事后查询、分析、统计。这是完整的、可审计的、长期可用的。

内存追踪：将追踪信息保存在内存中。请求结束后，追踪信息随之释放。只能用于实时调试，无法事后查询。

第一种看起来更强大。第二种看起来像妥协。

但在 Cloudflare Workers 环境中，第一种路径有问题。

约束的现实

Cloudflare Workers 是边缘计算环境。它的优势是全球分布、启动极快、响应迅速。它的约束是执行时间有限、资源受限、成本按请求计算。

在这个环境中，频繁的数据库写入是昂贵的：

每次写入都是网络往返。延迟累加。一个请求如果追踪三个环节，就是三次数据库写入，每次 10-50ms，累计 30-150ms 的额外延迟。

数据库连接是有限的。在高流量场景下，Workers 同时处理大量请求，每个都要写数据库，连接池会成为瓶颈。

计费按请求和执行时间。数据库操作增加执行时间，直接增加成本。

更重要的是，追踪信息的生命周期通常和请求一致。一个请求从开始到结束，通常只需要几秒。追踪信息在这几秒内最有价值。

对于处于快速迭代期的系统，实时调试能力是核心需求。保存所有历史追踪数据不是第一优先级。

内存追踪的选择

内存追踪在 Workers 环境中更合适：

零延迟写入：Map.set() 操作在内存中完成，延迟小于 1ms。不阻塞请求处理。

零数据库负载：不占用数据库连接，不增加数据库写入压力。系统可以专注于业务逻辑。

自动回收：追踪上下文的生命周期和请求绑定。请求结束，内存释放，无需手动清理。

足够的功能覆盖：支持追踪ID生成、跨度管理、链路追踪、日志关联、性能监控——实时调试所需的一切。

这不是功能缺失，这是约束驱动的设计选择。

export class TraceManager {
  constructor() {
    this.contexts = new Map();
  }

  generateTraceId() {
    const timestamp = Date.now().toString(36);
    const random = Math.random().toString(36).substring(2, 8);
    return `trace_${timestamp}_${random}`;
  }

  createTrace(operationType, userId, metadata = {}) {
    const traceId = this.generateTraceId();
    const context = {
      traceId,
      operationType,
      userId,
      startTime: Date.now(),
      spans: [],
      metadata
    };
    this.contexts.set(traceId, context);
    return context;
  }
}

代价与局限

内存追踪有明确的局限：

无历史查询：请求结束后，追踪信息消失。无法事后查看上周某个失败请求的完整链路。

无趋势分析：无法统计过去一个月的平均响应时间、错误率分布、性能瓶颈趋势。

无跨请求关联：如果一个用户连续发起多个请求，无法将它们串联起来分析用户行为模式。

这些不是技术缺陷，这是取舍的结果。

在快速迭代阶段，实时调试能力更紧迫。大部分问题需要立即发现、立即定位、立即修复。追踪的价值在当下，不在过去。

这个选择有明确的前提：你的系统处于早期或成长期，不是成熟的关键业务系统。金融交易、医疗记录、审计日志等场景，从一开始就需要完整的历史追踪。

当系统成熟，当流量增大，当需要长期优化和趋势分析时，再引入持久化。

何时重新评估

有几个信号提示你应该考虑持久化追踪：

复杂问题需要历史数据：有些 bug 只在特定条件下出现，需要回溯历史请求才能复现。

性能优化需要趋势：要找到系统的性能瓶颈，需要分析数周的追踪数据，识别模式。

合规要求审计日志：某些行业要求保存完整的请求追踪历史，用于审计和合规检查。

团队规模扩大：多个团队协作时，需要标准化的追踪存储，方便跨团队调试。

到那时，可以采用混合方案：

采样持久化：只将错误请求或随机抽样的请求持久化，减少数据库负载。

异步写入：请求完成后，将追踪信息异步写入队列，不阻塞响应。

分层存储：实时追踪用内存，历史分析用数据库，两者并存。

async function persistTrace(traceContext) {
  // 只持久化错误或采样的追踪
  if (traceContext.status === 'error' || shouldSample()) {
    await env.TRACE_QUEUE.send({
      traceId: traceContext.traceId,
      serializedData: serializeTrace(traceContext)
    });
  }
}

function shouldSample() {
  // 1% 采样率
  return Math.random() < 0.01;
}

追踪的目的

追踪系统不是为了记录一切。追踪的目的是让你在需要时，能快速定位问题。

在约束环境中，完美的解决方案不存在。你要在功能完整性、性能效率、实现复杂度之间权衡。

内存追踪是当前阶段的正确选择。它足够简单，足够快，足够用。

当约束改变，当需求升级，重新评估。设计不是一次性的决定，设计是持续的权衡。

系统的架构设计中，如何平衡短期需求和长期扩展，可以参考 purikura-workers-architecture 中的分层思考。

追踪只是手段。目的是让系统可观测，可调试，可信赖。