搞不懂跟踪追击是什么意思？快速理解这个复杂概念
这玩意儿说白了，就是想知道一个东西从头到尾都干了点都去了哪儿，跑哪儿去了。
我刚开始接触这个概念的时候，也是一头雾水，感觉特别玄乎。什么叫“跟踪”，什么叫“追击”？听起来就感觉像在搞什么特工活动。
咱们捋一捋这个事儿，就从我第一次遇到这个需求开始说起。
那会儿我在做一个电商平台的后台系统，用户下单后，我们得搞清楚这笔订单到底经历了哪些环节。下单成功了，然后？支付成功了？系统扣库存了？物流开始派送了？这些步骤可不是一步到位的，中间环节特别多。
我图省事儿，就在订单表里加了个状态字段，然后用几个if/else语句在那儿判断：订单状态是“已支付”还是“已发货”。结果没两天，产品经理就跑过来问我：“老板，这个订单显示已发货了，可我查物流信息，发现它还没到仓库，这到底是怎么回事？”
我当时就懵了，只能赶紧去查日志，东翻西找，才发现，原来系统在支付成功后，先给自己内部记录了一个“待发货”的状态，然后才去调用物流接口，物流接口返回个成功，我们才更新成“已发货”。中间那个环节的记录，我们压根儿就没存下来。
这就是个典型的“跟踪”没做好的例子。你只看到了开头和结尾，中间那些弯弯绕绕的过程，全被忽略了。
拆解“跟踪追击”
后来我琢磨了一下，这个“跟踪追击”可以拆成两部分来理解：
- 跟踪 (Tracking)：这部分主要是记录“发生了什么事”，也就是事件的发生点。比如，“用户点击了A按钮”，“系统生成了订单ID 123”，“支付接口返回了成功码”。这些都是孤立的事件。
- 追击 (Tracing)：这部分就是要把这些孤立的事件串起来，搞清楚它们之间的因果关系。比如，用户点击A按钮，导致系统生成订单ID 123，然后订单ID 123去调用了支付接口，支付接口成功了，这些连起来才叫“追击”。
我记得有一次，我们系统搞了个复杂的促销活动，好几层优惠叠加，结账价格跟预想的不一样。产品经理急得团团转，非要我说明白这20块钱的差价是怎么来的。
如果我只存了个最终价格，那真是无从说起。我得从用户点击“结算”按钮开始，一步步往下看：
第一步：系统抓取了商品原价。
第二步：检查是否有会员折扣，打了9折。
第三步：检查是否有满减券，减了10块。
第四步：检查是否有限时折扣，又打了95折。
第五步：合计出最终价格。
把这五步按时间顺序串起来，那个差价自然就清晰了。这就是“追击”的作用，它让你能回溯整个流程。
我怎么做的？
为了解决这种混乱，我决定把这套系统做起来。我开始用一个统一的ID来标识整个操作流程，我管它叫“请求ID”或者“Trace ID”。
每当一个外部请求进来，我先生成一个独一无二的Trace ID，然后把这个ID带到系统的每一个角落。
- 在用户操作日志里，我把这个Trace ID存下来。
- 在数据库操作里，我也把这个Trace ID打上去，标记是哪个请求导致的修改。
- 调用第三方服务（比如物流、短信）的时候，我得确保把这个Trace ID也带过去。
这样一来，当出问题的时候，我只需要拿着那个Trace ID去数据库一查，就能把所有跟这个请求相关的记录都揪出来。虽然过程稍微费点事，数据库表也多了几个字段，但至少我能搞清楚整个“追击”路线了。
一开始确实麻烦，每次新增功能，都要记得带上这个ID，稍不留神就忘了，然后系统里就出现一堆“无主”的日志。但坚持了一段时间，系统跑稳定了，我再回头看这些记录，简直是一目了然。那个曾经让我头疼不已的“发生了什么”的问题，现在只要动动手指头就能解决了。
所以说，搞懂“跟踪追击”，就是搞懂怎么给你的业务流程画一张清晰的地图，哪个路口拐弯了，哪个地方堵车了，你都能找得到源头。
