客户端云部署与网络优化:13年实战跃迁至毫秒响应
|
凌晨三点二十,我盯着监控屏右下角那个绿色小点——它还在跳,可客户端连不上。不是 502,不是超时,是压根没 handshake 成功。我伸手把屏幕右上角那块胶布撕了,底下露出去年十一月贴的便签:“DNS TTL 改成 60 试试”,字被蹭掉半边,像块结痂。 我原以为只是 CDN 缓存没刷干净。结果 curl -v 去测边缘节点,头都没发出去;tcpdump 在 client 端抓包,SYN 都没出网卡。这时候我才想起——上周五下班前,运维小张说“主控台自动更新配置模板”,我顺手点了“确认”。他说是灰度,我说“你看着办”。他没说模板里 default route 被写死了 10.100.128.0/24,而新云环境 IP 段是 10.150.0.0/16。我点下去的时候,窗外正打雷,雨砸在机房玻璃顶上,噼啪响得像磁盘坏道在敲门。 值班室泡面桶堆在椅子边,三桶,红烧牛肉味。第二桶还浮着油花,我喝了一口汤,咸得发苦。客服小李半夜两点四十七分给我打电话,第一句是“哥,我们工单系统崩了”,我没接话,她顿了两秒又补:“不是咱这边崩,是客户那边自己改了 host 文件,硬绑了旧 IP。” 我说“挂了”,她又追一句:“您别急,我们刚拉了个群,老板在里面说话了。” 果然,群里跳出一条,老板发了个截图:微信聊天窗口里,他老婆问“今晚回家睡吗”,他回了个“等我查完 DNS 日志”。没标点,没表情,就这八个字。 我翻记录,发现真正出问题不是 DNS 解析失败,是 DNS 查询压根没发出去。本地 resolver 在云节点上被 systemd-resolved 和 dnsmasq 同时占着 53 端口,谁也没杀谁,但每次查询都会卡在 sendto() 返回 EAGAIN 上四十来分钟——不是超时,是阻塞,活活卡死。我重启 resolver 服务,第一步 systemctl stop systemd-resolved,第二步 ps aux | grep dnsmasq | awk '{print $2}' | xargs kill -9,第三步才起新的 dnsmasq -d --port=53。中间我按错了 Ctrl+C,终端卡住,光标不动,我盯着它数了七次呼吸。 上次搬家我搬了四十二箱,其中三箱全是证书链文件。不是 pem,是 .crt + .key + .ca-bundle 的组合,散装的、拼凑的、过期了三年又续签两次的。那天下午我把它们全倒进一个抽屉,抽屉太满,关不上,就斜着插着,门缝夹着一张 Comodo 的老证书副本,印着 2019 年 3 月 12 日。这次没爆证书,但我想起这个抽屉,心里发毛。优胜劣汰?对。能活过十三年的模块,早把自己编译成内核模块了;活不过三个月的,连 /etc/resolv.conf 都敢往 git 里 commit。 老王在隔壁机柜喊了一嗓子:“你那台虚机,disk usage 显示 98%,但我 df -h 看是 67%!” 我跑过去,他指着 Grafana 里的磁盘曲线,峰值冲到 98.3%,可 ssh 进去一查,/var/log/journal 用掉了 42G,而监控只采了 /dev/vda1 的 inodes 使用率,没采 actual block usage。老王叼着烟,烟灰快掉进 KVM 控制台了,说:“这图骗过三波人。” 我点点头,转身时撞到铁皮柜子,哐当一声,震得监控屏贴胶布的地方翘起一角。
文章配图,仅供参考 最吓人的是那个没告警的点。不是磁盘满,不是带宽爆,是 TCP 连接队列溢出——listen backlog 设置了 128,实际 ESTABLISHED+SYN_RECV 一度干到 327,但 netstat -s | grep overflow 根本没动过。监控脚本里写了 “if [ $(ss -lnt | wc -l) -gt 128 ]”,却没加 -o 参数,ss 默认不显示 timewait 状态,于是所有堆积连接都算进 “ESTABLISHED” 里混过去了。我查到这儿手心出汗,不是因为丢数据,是因为我上个月还夸这脚本“简洁”。简洁个屁。它就像我女儿幼儿园手工课做的纸船——胶水抹得厚,风一吹就翻。上一次被挂马是五年多前,在 IDC 自建环境,黑产用 nginx 的 autoindex 功能扫出了 /upload/ 目录,直接传了挖矿脚本。那次我还跟同事打赌,说只要关了 autoindex 就万无一失。结果他们用 phpinfo.php 的临时文件绕过了权限校验。这次没挂马,但我知道,如果哪天有人把 client 端的 fetch timeout 写成 Infinity,而 server 恰好有个未捕获异常卡在 TLS 握手环节……那等待响应的毫秒,就会在用户手机屏幕上,变成十秒、三十秒、最后直接黑屏退出。这不是故障,这是淘汰通知书。 我调出近三个月的变更日志:二十六次部署,十九次网络配置调整,七次证书轮换,三次跨云迁移。没有一次失败。但每一次,都像把刀在鞘里磨——不响,不亮,但刃在长。我说跃迁至毫秒响应,不是指 P99 降到 8ms,是指客户端发起请求那一刻,你就知道它能不能活过三次重试。这种直觉,不是算法算出来的,是被 CC 攻击打穿三层负载均衡后蹲在厕所隔间里想明白的,是看见 DNS 解析返回 NOERROR 但 A 记录为空时手指发麻记下来的。 我到现在也没想明白,为什么同一个 cloud-init 配置,在华北区实例能跑通 resolvconf 更新,到了华南就卡在 dhclient 的 hook 里死循环。但我不打算深挖了。明天先把告警阈值调了——不是 disk_usage > 90%,而是 ss -lnt | wc -l > 80,加个 -o,再加个 -t。就这么干。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


数据驱动增长:客户端工程师的传媒网站优化实践
云端视觉模型卡顿?三步网络优化达毫秒响应
网页加载快10倍?轻量化客户端的 tech 革命
