Goroutine id 的获取方式
之前做的项目中，会使用 goroutine-id（以下简称 goid） 作为日志中的一个标识参数。而 goroutine 的相关信息是不对外暴露的。想要获取 goid，除了直接修改 Golang 源码的骚操作，通常会使用两种方式：
- 一种是通过堆栈获取。
func Goid() int {
var buf [64]byte
n := runtime.Stack(buf[:], false)
goroutineId := strings.Fields(strings.TrimPrefix(string(buf[:n]), "goroutine "))[0]
id, err := strconv.Atoi(goroutineId)
if err != nil {
panic(fmt.Sprintf("cannot get goroutine id: %v", err))
}
return id
}
这种获取方式会牺牲一部分性能，好处是不用修改 Golang 的源码，不用关心 Go 语言版本，省去后期维护的麻烦。
- 另一种获取
goid的方式是建立goroutine的本地存储。相关库参考：
github.com/v2pro/plz。这种方式同样不入侵源码，更为高效，但是需要随Go语言的版本进行维护。
以上获取 goid 的方法在搜索引擎中可以很容易地获取到。但是，这是不是反而引发了 goid 的滥用呢？换句话说，goid 是否是一个伪需求呢？
为什么不应该使用goroutine id？
根据 Go 语言的官方设计，我们是无法对一个运行中的 goroutine 进行操作的。coder 对协程不具有管理权限，一旦使用 go 关键字开启了一个协程，只能任其运行。不像在其他语言中管理线程，Go 不需要一个线程的标识来记录对于线程的管理。
在大多数业务场景里，服务端启用一个协程处理一个任务（多数情况下是一个请求）。这种场景下，我们使用 goid 的目的，更多地在于标识一个任务。然而 goroutine 是一种可复用资源。一个 goid 为 10 的协程，可以在处理完一个任务后，重置状态，再处理另一个任务。使用一个有限复用的资源去标识一个唯一性资源从语义上来说，是不符合逻辑的。使用 goid 作为标识会引发混乱，并且仍然需要其他标识作为参考。
而在一个任务对应多个协程的场景中，goid 更是徒劳无益。
标识与渠道相关，而不是与处理相关
正确的做法是使用编程的方式标识一个任务。这不仅契合 标识 本身的含义，也更加具有扩展性。
微服务架构越来越流行。比起设计一个庞大臃肿的系统，人们更倾向于把它拆分为多个小巧的系统，各司其职。这也符合 devOps 的发展方向。这种情况下，一个从系统入口就生成并透传的唯一标识是必须的。这是链路追踪的基础。
此外，对于分布式事务来说，一个事务也需要一个唯一标识。