在一次线上服务升级中，由于下游接口超时，导致服务启动阻塞，进而引发大量实例 OOM。通过排查，发现 goroutine 数暴涨，接口 QPS 增加。第二天，利用 pprof 工具发现一个多重嵌套循环内的打点是罪魁祸首，大量打点引起的锁冲突和 goroutine 堆积造成 OOM。修复打点问题后，服务恢复正常。本次事故提醒我们，每一行代码都可能成为未来事故的源头，要重视代码质量和事故排查能力的提升。
你好，我是小X。
曹大最近开 Go 课程了，小X 正在和曹大学 Go。
这个系列会讲一些从课程中学到的让人醍醐灌顶的东西，拨云见日，带你重新认识 Go。
最近线上事故频发，搞得焦头烂额，但是能用上跟曹大学的知识并定位出了问题，还是值得高兴一把的。毕竟“打破砂锅问到底”，“定位出根因”一直是技术人的优良品质。
虽然我们总是逃不过事故驱动开发的魔咒，但吃一堑长一智，看别人的事故，学到的是自己的能力。
现象
一个平凡的午高峰，服务在全量上线的过程中，碰到一个非常重要的下游接口超时（后来发现该下游也在上线，可用实例数变少，正常实例负载变高，超时了一丢丢），拿不到该拿的数据，阻塞了启动。这样，打到线上正常实例上的流量就增加了。
不大会儿，线上大量实例 OOM，报警满天飞。不得已，回滚（遇到事故，第一件事就是回滚）。没想到，回滚无效，OOM 的实例数还是一直在增加，给跪了。
中间查到服务在启动过程中，一直在尝试调那个超时的下游，就临时把超
最低0.47元/天 解锁文章
1225
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
