context 浅析

在缺少直接调用关系的两个函数之间传递数据，一般都会考虑使用 context，而 context 也被用来存储整个请求链路的公参信息，用户 uid、链路 traceID、特定的业务参数等。函数第一个参数类型设置为 context.Context 也是 Go 的默认写法，如果你对是否指定 ctx 作为函数的第一个入参，感觉到模棱两可，那就指定它吧。

树状链路结构

context 的惯用模式是覆写，比如下面的 Printable 函数，参数 ctx 在函数内部被覆写了。而这个操作在当前的 context 链路上又追加上了一个节点，其实也是将 context 切换到一个新的 context 上。通过这种模式，每个方法都有了自己独立的 context 变量，并且可以查找到到上级的 context，整个调用链路都可以通过 context 来还原。

func Printable(ctx context.Context) {ctx = context.WithValue(ctx, "key", "value")// ......
}

下面这个绿色的 ctx，通过它可以获取到红色的父 ctx 和蓝色的子 ctx。创建子 ctx 的方式就是官方提供的 ctx 覆写的方式。树结构的每一条链路都是链表结构，每个 context 内部记录了指向父节点的指针。函数 WithValue 的注释有这样一段描述：WithValue returns a copy of parent in which the value associated with key is val. 但 WithValue 传递的参数类型实际是指针，这里应该只是想强调指针引用的拷贝。

除了通过当前节点找到父节点，还需要能查找到当前节点的所有子节点。但通过 WithValue 创建的节点并没有保存子节点的信息，也就无法查找到子节点列表，WithValue 被设计用来存储当前链路的值，查找某个具体的 key 值时，需要逐层向父节点查找，当前节点此时此刻也不包含任何子节点。

下图最左边的蓝色 ctx 查找某个 key 值时，会逐步向上查找。假如红色和绿色的 ctx 设置了相同的 key 值，会返回绿色 ctx 的 value，因为这种链路的层次关系，红色的 key 值会被覆盖掉。通过这样的设计，ctx 中的变量具有了作用域范围，红色 ctx 不能访问绿色 ctx 中的值，绿色 ctx 可以“覆盖”红色 ctx 的值。

孩子节点

WithValue 创建的 ctx 中没有维护孩子节点的信息，所以，接下来我们使用 WithCancel 对树形链路做分析。 cancelCtx 结构体的 children 存储了孩子节点的信息。children 是 map 类型，对应的 value 是空的结构体类型，而空的结构体不占用任何内存空间，所以 key 是关键，key 是 canceler 接口类型。

children 不支持并发读写，err 也需要并发保护，cancelCtx 通过 sync.Mutex 来控制并发。atomic.Value 本身就只原子类型，理论上是不需要加锁保护的。

// A cancelCtx can be canceled. When canceled, it also cancels any children
// that implement canceler.
type cancelCtx struct {Contextmu       sync.Mutex            // protects following fieldsdone     atomic.Value          // of chan struct{}, created lazily, closed by first cancel callchildren map[canceler]struct{} // set to nil by the first cancel callerr      error                 // set to non-nil by the first cancel call
}

WithCancel 在新建节点的时候，首先要查找到对应的父节点，然后注册到父节点的 children 中，这样就建立了父子节点的对应关系。关键是查找到对应的父节点，因为父节点可能不是 WithCancel 函数传入的 ctx，而是“血型”匹配的父节点，下图蓝色的 cancelCtx 就找不到对应的父节点。

再比如下图的右子树，两个浅黄色的 cancelCtx 并不存在父子关系，因为中间被 valueCtx 给隔开了。所以，关键点是判断 WithCancel 调用时的 parent 的参数类型。两个 cancelCtx 节点能否建立父子关系，首先需要类型匹配，其次需要父节点是有效的。

我们可以理解为 cancelCtx 其实是局部树，它在整个 context 树状结构中是独立的一颗颗小子树。这样的设计方式，应该和 cancelCtx 的要处理的场景有关系，毕竟 cancelCtx 是被用来处理小范围内的调用取消控制的。

WithValue 参考扩展

前文已经介绍过，WithValue 创建的节点并不会保存子节点的信息。但我们可以做扩展，让 WithValue 支持保存父子节点的关系。有了这层关系，我们可以将整个服务的调用链通过 ctx 关联起来，可视化地将树形结构显示出来。竖向表示串联逻辑，横向表示包含逻辑，下图中的“历史记录”和“同地域”表示并行逻辑。

微服务通过在入口生成统一的 traceID 来关联所有的服务，通过 traceID 来排查链路调用的问题。但通过 traceID 查询到的一条条日志缺少业务逻辑聚合关系，表面上是按服务维度进行划分的，但粒度太大了。

我们可以利用 context 实现业务逻辑层面的粒度划分，比如将整个业务域划分成召回、过滤、排序三个大逻辑，每个逻辑内部再继续划分成多个小逻辑，整个链路共用同一个 traceID，但每个业务域内生成特有的 ID 来标志对应的业务域。最终，通过业务逻辑的调用图将日志信息可视化展示出来。

我们参考 WithValue 的实现，当进入到召回逻辑时，我们启用一个业务域，在 ctx 中设置当前的业务域为“召回”，当进入到“过滤逻辑时”，我们将当前的业务域设置为“过滤”，以此类推，我们将整个链路通过树的结构连接起来。这样，一个可视化的日志排查链路就设计好了。

树形结构的表示

在 api 的交互中，要表示一个树形结构，数据结构该如何组织呢？

业务执行流程都是串行向下的，但可能存在某一阶段多路并行的情况。比如下图中黄色的圈，表示异步执行多路逻辑。按照 context 的组织思路，context 是一个树状的组织结构，子节点仅能唯一确认一个父节点，不能对应多个父节点。所以，图中红色的节点就比较尴尬，但又实际存在。

我们先确认最终的数据结构，基于这个数据结构，就可以简单连线构造出上面的图形。而且，根据现在的结果去推导实现的过程，思路就会开阔起来。让我想到一个Question：如何提出一个好的问题。

type node struct {*Mchildren []*T
}

上面是伪代码的描述，node 表示图中的一个节点，*M表示节点的属性，其中 children 用来表示节点有哪些子节点。最后，我们将所有的节点和子节点连接起来，就可以构成上面的图形。

回到图示，context 结构中，蓝色的子节点包含黄色，以及红色（右图），只是我们用上图的形式做了展示（左图）。黄色的连线逻辑就变成：有父节点，没有子节点，且父节点还指向了下一个流程的红色节点。