800万协程压垮支付系统：Go团队用40倍吞吐反杀黑五流量

去年黑五，某支付服务在流量峰值时内存飙到12GB，协程数突破80万——这不是攻击，是自家代码的"并发优化"在搞自杀。

作者团队最初也信那条金科玉律：Go的协程（goroutine）只有2KB栈空间，随便造，10万个并发不在话下。结果生产环境给了响亮耳光：协程1:1对应请求的"标准做法"，在5万并发处直接性能断崖。

2KB谎言：被低估的内存黑洞

每个协程确实从2KB起步，但生产环境的活跃协程平均膨胀到4-8KB。更隐蔽的杀手是调度开销——超过1万个活跃协程后，Go调度器切换上下文的时间开始超过实际执行时间。

垃圾回收（GC）压力随之指数级上升。更多协程意味着更多对象，更频繁的GC停顿。作者团队的监控数据画出一道清晰的死亡曲线：50,000并发操作是 naive 并发模式的性能悬崖。

这段代码曾让他们引以为傲：

// naive 做法——无限制生成协程 func handleRequests(requests <-chan Request) { for r := range requests { go processRequest(r) // 每个请求一个协程 } }

演示环境丝般顺滑，真实负载下却是资源炸弹。问题不在于协程本身，而在于把"轻量"误解为"免费"。

工人池模式：以少胜多的反直觉战术

解决方案是工人池（worker pool）——限制活跃协程数量，让固定数量的工人消化任务队列。这引入了关键的背压（backpressure）机制：系统不再无差别接纳请求，而是主动控制并发度。

基准测试结果让团队怀疑仪器坏了：

5万并发请求，naive 模式：2.1GB内存
同场景工人池模式：247MB内存（减少85%）
吞吐提升：40倍

内存降幅和吞吐增幅的反差，恰恰暴露了原始设计的资源浪费程度。不是机器不够强，是并发策略在疯狂内耗。

从"更多并发"到"受控并发"的思维迁移

这个案例戳中了Go生态的集体盲区。教程反复渲染协程的廉价，却很少讨论调度器瓶颈和GC放大效应。开发者带着"协程即正义"的信仰进生产环境，往往在流量洪峰时付出学费。

工人池不是新概念，但作者团队的测量数据让它从"可选优化"变成"生存必需"。关键认知转变：并发性能不由协程数量决定，而由调度效率和资源密度决定。

他们的支付网关重构后，黑五流量被消化得悄无声息。没有告警，没有扩容，没有凌晨三点的事故复盘。

作者最后留了一个未解的悬念：工人池的 optimal size 如何随硬件和负载动态调整？他们的下一篇文章将讨论自适应池大小算法——如果你也在用Go扛高并发，这个数字值得盯紧。