Go服务器性能调优：9年实战破选型陷阱，QPS翻倍

　　我原以为是 WAF 规则又抽风了——去年五月那个凌晨三点，防火墙日志一直在刷，红底白字滚得比心跳还密，可后端指标全平得像睡着了。运维老张甩过来一张图：CPU 用不满 30%，内存剩一半，GC 次数稳得反常，就 QPS 从三千六掉到八百，断续地、一阵一阵地掉，跟有人蹲在负载均衡后面掐网线似的。

　　手机一直在震，业务方王姐连打五个未接，第七个我回过去，她第一句是：“是不是你们把限流阈值调错了？”我说没动过，她秒回：“那为什么用户投诉说点个提交要等二十秒？上个月还好好的。”我挂了电话盯着 pprof 的火焰图发呆，中间那条 main.func1 的宽幅突然窄了半截——不是 CPU 时间少了，是它根本没跑完就被 context.cancel 了。我盯着看了四分钟，泡面凉了，汤面浮着一层油花，我没动。

　　其实早该警觉。前一周测试环境压测，QPS 上四千五时 goroutine 数就飙到两万三，我们当时还开玩笑说“Go 轻量级协程真不骗人”，结果上线后一跑真实流量，goroutine 不涨反跌，跌得悄无声息。我查过 trace，也抓过 net/http.Server 的 ServeHTTP 入口，甚至翻出 runtime/pprof 的 block profile —— 没锁争用，没 channel 阻塞，连 sync.Pool 的 HitRate 都高得离谱。我就卡在这儿，熬了一整夜，窗外天亮了，灰白光从机房窗缝斜切进来，照在监控大屏右下角的时间上：5:42。

　　跟业务方吵了一架是在第三天下午。王姐推门进来，手里捏着用户反馈截图，边走边说“你们 Go 服务是不是用了什么不兼容的中间件？”我指着 Grafana 里那条持续三个月没变过的 http_server_requests_total_by_status{status="504"} 曲线，说：“不是超时，是没发出请求。”她愣住。我补了句：“连 dial 都没开始。”她笑了，说“你这话说得跟没说一样”。我没反驳。那天我改了三版部署配置，来回折腾三趟，最后发现——不是参数问题，是选型本身长歪了。

　　Go 官方 net/http 默认的 server 参数看着挺干净：ReadTimeout、WriteTimeout、IdleTimeout。但没人告诉你，当你在阿里云 SLB 后面再套一层自建 Nginx 做 TLS 终结时，“IdleTimeout” 实际上被双重挤压：SLB 空闲切断 + Nginx keepalive_timeout + Go Server IdleTimeout —— 三者之间没协商，只有最短的那个说了算。我们设的是 60 秒，Nginx 是 75，SLB 默认是 60……表面看严丝合缝，实则任何一次客户端网络抖动（比如弱信号切换），都可能让连接在 Nginx 层就滞留，等到 Go server 发起读操作时，socket 已经半关闭。net/http 处理这种状态的方式？它不报错，不记录，就 quietly discard 这个连接，连 access log 都不落一行。我查了三天日志才确认：所有“消失”的请求，request_id 都不在 access log 里出现，但在 client-side 的埋点 SDK 里清清楚楚写着 “start→fail”。

文章配图，仅供参考

　　同事小陈提醒我去看 HTTP/1.1 的 connection: keep-alive 处理逻辑。我翻到 src/net/http/server.go 里 handlerOnce 之后那段代码，才明白：Go 把半关闭连接当成“已处理完毕”，而真正的请求 payload 根本没抵达 ReadBody 的入口。我原以为是 GC 或 goroutine 泄漏，结果是协议栈在悄悄吞请求。不是性能差，是它压根没认出那是有效请求。

　　这事防不住。你加固 WAF，它不关你事；你升级 TLS 版本，它还在那里等你重连；你加 metrics，它不产生指标。后来我们改成直接透传 TLS 到 Go server，把 idle control 全收回来，QPS 回到了四千二，比原来翻了一倍。可现在新问题来了：SSL handshake 耗时上去了，运维老张天天在群里甩 openssl s_time 的截图骂娘，说“你们写 Go 的是不是以为密码学不用耗 CPU”。

　　上周五晚上我又梦见那条平直的 CPU 曲线。醒来打开终端，习惯性敲 go tool trace，文件名打到一半停住了——其实 trace 里早有蛛丝马迹，只是我当时盯着 GC pause 看，没往 conn state 里钻。工单系统弹出新通知，是财务系统的支付回调失败告警，我看了一眼，没点开，把终端关了。冰箱里还有半盒隔夜豆浆，我懒得热，直接灌下去，微酸的，带着豆渣感。

　　去年这时候我还在用 Python 写调度服务，被 async/await 和 event loop 绕晕过三次。现在换 Go，照样栽在 connection lifecycle 上。优胜劣汰不是说谁语法好谁活下来，是看谁能先看见那些不报错的失效。可下次呢？下次是不是又有个新组合在等我，表面风平浪静，底下 socket 已经腐烂成渣。

　　明天得补个 patch，把 net/http.Server 的 log 输出开关重新打开，不打 access log，至少让它把 conn state change 打进 debug 日志。不过我也说不准，也许开了更糟——到时候满屏都是“connection closed before headers sent”，大家又得问我：“这是攻击还是bug？”

　　反正我先把泡面盒子扔了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!