context 浅析

news2025/1/21 18:49:31

在缺少直接调用关系的两个函数之间传递数据，一般都会考虑使用 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 {
	Context

	mu       sync.Mutex            // protects following fields
	done     atomic.Value          // of chan struct{}, created lazily, closed by first cancel call
	children map[canceler]struct{} // set to nil by the first cancel call
	err      error                 // set to non-nil by the first cancel call
}

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

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

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

WithValue 参考扩展

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

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