云阳一平米网站建设,wordpress运行缓慢,能免费建设网站吗,青岛城阳新闻最新消息在缺少直接调用关系的两个函数之间传递数据#xff0c;一般都会考虑使用 context#xff0c;而 context 也被用来存储整个请求链路的公参信息#xff0c;用户 uid、链路 traceID、特定的业务参数等。函数第一个参数类型设置为 context.Context 也是 Go 的默认写法#xff0…在缺少直接调用关系的两个函数之间传递数据一般都会考虑使用 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 结构中蓝色的子节点包含黄色以及红色右图只是我们用上图的形式做了展示左图。黄色的连线逻辑就变成有父节点没有子节点且父节点还指向了下一个流程的红色节点。
