Go 语言如果没有 ctx 传递，如何让 Trace ID 连贯传递呢？

[RedisMasterNode]

RT 对于 Go （这类）没有 ThreadLocal 的语言，如果在服务方法调用之间缺漏了 ctx context.Context 的传递，Trace 的信息就无法传递下去。

通常来说对于平台、工具方来说（例如做 Trace 平台的人），想推动所有业务都去改造是相当困难的，请教一下了解的 V 友有什么办法能 “改善” 这种情况？

[mrgeneral]

无它，规范耳。

另外一个就是放在 mesh 层做，对业务透明。

[RedisMasterNode]

@mrgeneral mesh 层如何将 in & out 的流量进行关联呢？
例如我是服务 B ，收到了一个服务 A 的请求，处理，然后向服务 C 发一个请求，mesh 的基础设施如何保证发给 C 的请求携带的 TraceID 与 A 发给我的 TraceID 一样呢？

[ensonmj]

直接告诉他们你们 latency 很高，需要优化。自己去分析哪儿是瓶颈，他们就想到用了

[bli22ard]

要有 tid ，老老实实显式传递。不单是 tid 的问题，还有 log 的问题。 最佳实战就是 ctx ，携带 log 和 tid

[paceewang1]

之前也遇到过这个问题，用魔法取 gid 不可取，只能通过传递变量的方式进行，其实这里也有两种实现：
1 、到底是传递 context ，很多框架用这种，但是实际的 Log 方法参数的时候要带上 ctx ，并且如果需要携带的 trace 多的话感觉效率不高
2 、传递 log 变量呢，有一些框架用这种，第一眼看到也觉得很新奇，个人感觉用 log 变量传递的话能更高效的携带各种 trace ，并且 Log 方法参数和普通日志库都一致

[RedisMasterNode]

@paceewang1 我们之前在业务团队的时候倾向于用 ctx 传递，因为第三方库的方法签名不可控不可改，但是基本都保留了 ctx 。如果用 log 传递，或者说把 log 变量放在结构体内传递，它是对 ctx 的隐式使用，而且是 hardcode 的使用，无法分离出来给第三方方法用（或者说成本不如方法 1 ）

而这个帖子，其实不是想讨论如何改成传递 ctx ，而是说不发生任何业务修改的情况下如何拦截采集这种信息。因为想改动的人不是业务团队，也就是不是写这个代码的人，而是平台提供方，如何在极低成本（例如，只修改 cmd/main.go 方法里面的一两行）的目标下完成改造，（尽可能）让所有调用、日志都携带 trace 信息。

另外我们之前选用方法 1 做业务层面的改造时，log.Info(string) 改成了 log.Info(context.Context, string)，这个没啥好办法，都是全局的字符串替换修改调用方的，修改成了 context.TODO() 传入，然后等未来慢慢补全，实际落地下来感觉效果还可以的，而且有利于整体习惯养成。用 log 传递那是不是又不用设计 ctx 在方法签名里了？实际上这在 go 里是个不好的实践，相当于用 log 传递的方式，节约了 log.Info 调用的改造成本，但是继续保留了不传 ctx 的坏习惯，个人认为不可取。

[kingofzihua]

@RedisMasterNode #26 你看下 https://skywalking.apache.org/docs/skywalking-go/next/en/concepts-and-designs/key-principles/ 能否满足你的要求，看文档 skywalking go 使用起来貌似没有需要业务方做大量的改动，你你参考下他的实现

[RedisMasterNode]

@kingofzihua 很高兴在这里看到有人提及 skywalking go ，我也是其中的一位 contributor ，我觉得混合编译及代码生成是个很有创意的 idea ，因为项目比较新，短期内也没办法直接推广到公司用，未来看看其他使用方的反馈