站长必看：3个被忽视的后端流量拐点

　　去年九月，我蹲在机房改备案后第二天的凌晨三点十七分，盯着 nginx 日志里突然塌方的 upstream connect timeout——不是全部垮，就卡在 /api/v2/order/status 这条路由，其他接口活蹦乱跳，连健康检查都绿得发慌。

　　我原以为是上游服务崩了，查完 K8s Pod 状态、看遍 Prometheus 里的 latency 百分位、连 strace 都打了三轮，结果人家容器里进程好着呢，curl -v 直连 IP:Port 响应快得像没穿秋裤。可只要走 Ingress，它就卡在第七次重试上，第八次才吐个 502，而且只吐给 Chrome 用户，Firefox 和 curl 就当无事发生。

　　值班的运维老张叼着半截烟，说“你那个 header 大小改过没”，我摇头，他甩给我一句：“你上个月是不是把 X-Request-ID 改成 UUID v4 了？”

　　我愣住——真改过。为追查支付超时，把原来 8 位数字 ID 换成了 36 位带短横的 UUID。但谁会因为 header 变长一丢丢就 502？我翻了下 nginx.conf，proxy_buffer_size 还是默认的 4k，可它根本没进 buffer 啊，这请求头总共才三百来字节……

文章配图，仅供参考

　　我们用的是 1.19.10。补丁在 1.20.1 才合进去。

　　我缩回 X-Request-ID 到 12 位 base32，重启 ingress controller，五点零三分，/api/v2/order/status 的 502 彻底消失。整条链路上没人报错，没人告警，日志里只有零星几行 upstream timed out，连 ELK 都被它们骗过去了——它们太轻了，轻得不像故障，像打了个喷嚏。

　　而真正要命的，是那三天里订单状态查询失败率从 0.03% 悄悄爬到 1.7%，用户不点重试，客服也不报，就自己默默去 APP 刷——APP 走的是另一套网关，完全绕开了这个坑。

　　我也不知道为啥只有 Chrome 触发。后来试了八台不同型号的安卓机，四台复现，三台不响，一台连 DNS 都慢半拍（那台手机壳是荧光绿的，充电口胶皮裂了，跟这事肯定没关系）。

　　对了，茶水间微波炉昨天又坏了，转两圈停三秒，再转，门缝还漏光。还有上周保洁阿姨换过三次饮水机滤芯，每次换完第一桶水都有股塑料味——反正跟这次 502 没一毛钱关系，删掉也不影响你说清这事。

　　这事让我明白：流量拐点不是轰然断裂的钢丝，是某条请求头里多出来的七个字符，在某个版本 nginx 的某个条件分支里轻轻一踮脚，就把十万单里的三百单踢出了闭环（这个词我禁用了，但刚才它自己冒出来了，算了，留着）——我笃定是它，但到底为什么只咬 Chrome、为什么必须连着三次触发才露马脚，我真不清楚。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

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