云端视觉模型卡顿？三步网络优化达毫秒响应

　　去年四月那会儿，业务方突然冲进机房——其实现在哪还有正经机房，就是工位隔断后面那排机柜——说视觉模型的API响应卡成PPT了。我原以为又是哪个开发把测试环境的缓存关了，结果一查监控，好家伙，TCP重传率飙到17%，丢包率一阵一阵的，像心电图抽风。运维小哥叼着冰棍过来看了一眼，说“这网络质量，跟我家小区WiFi似的”。

　　第一反应是查CC攻击——毕竟上个月刚被扫过弱口令，WAF日志里还躺着三百多条/api/model的请求。可翻遍防火墙规则，没见异常流量；再瞅CDN回源记录，请求量也没暴涨。正盯着Nginx的error.log发呆，手机突然震了，是业务方老大：“用户说模型卡得连人脸识别都超时，你们到底修不修？”我回了句“在查”，转头看见运维小哥把泡面放在交换机上，汤都洒到RJ45接口上了。

　　其实这时候已经排除了攻击——要是CC，WAF早该报警了。可卡顿还在持续，模型推理时间从平时的80ms涨到300ms，偶尔还蹦出5000ms的尖峰。我盯着抓包工具里的TCP序列号，突然发现个反常识的细节：重传的包全是往西南方向去的，而我们的云服务器在华北。打电话给云厂商技术支持，对方查了半天，说“可能是跨区域骨干网拥塞”。我差点把键盘摔了——拥塞你早说啊！非得让我查半天日志？

　　但问题没这么简单。就算骨干网拥塞，也不该只卡视觉模型——其他API都正常。这时候业务方又来催，说“用户要退单了”。我让运维小哥把模型服务的日志导出来，自己蹲在工位上筛。筛到凌晨三点，发现个关键线索：每次卡顿前，都有大量“DNS查询超时”的错误。我原以为DNS服务器挂了，结果一查，是模型服务自己配置了多个DNS解析节点，其中有个节点在华南，而我们的用户主要在华北——每次解析失败就重试，重试就超时，超时就重传，重传就卡顿，卡顿就挨骂。

　　第二天一早，我直接把模型服务的DNS配置改了，只留华北的节点。业务方老大又冲进来：“你改什么了？现在模型响应倒是快了，可其他服务偶尔报DNS错误！”我盯着他：“要不您选一个？要么模型卡，要么其他服务偶尔报错？”他沉默了两秒，说“那还是模型快吧”。这时候运维小哥凑过来：“其实我昨天就想说，DNS配置里那个华南节点，IP地址跟上次被挂马的服务器一样。”我愣了下：“你怎么不早说？”他挠挠头：“我以为你早知道。”

　　改完DNS，卡顿确实缓解了，但TCP重传率还是比平时高。我盯着抓包工具里的RTT（往返时间），发现华北到云服务器的延迟从20ms涨到了60ms。这时候云厂商的技术支持终于回电话了，说“我们检测到骨干网有阵发性的丢包，建议把模型服务部署到华北的另一个可用区”。我差点笑出声——早干嘛去了？但业务方等不及，当天下午就让我迁移可用区。迁移完一测，模型响应时间直接掉到50ms，TCP重传率归零，连WAF日志都干净得像新买的硬盘。

　　后来复盘，我发现三个关键点：第一，别把DNS配置当摆设，尤其是多节点解析，一个节点出问题就能拖垮整个服务；第二，骨干网拥塞不是借口，云厂商的SLA里写了“跨区域延迟不超过100ms”，超过就得追责；第三，业务方永远只关心“卡不卡”，不会管你查了多少日志、熬了多少夜——所以下次再出问题，直接说“我们在迁移可用区”，比解释“可能是DNS问题”管用多了。

文章配图，仅供参考

　　现在业务方又提新需求了，说要把模型部署到全球多个区域，说“用户在哪，服务就要跟到哪”。我盯着他们递过来的全球节点列表，突然想起上个月被挂马的服务器——那台机的IP，好像也在华南。我叹了口气，把列表推回去：“先把华北的可用区跑稳了，再谈全球吧。”他们点点头，说“也行”。窗外天亮了，运维小哥的泡面凉了，我的咖啡也见底了——但至少，模型不卡了。

　　下一步该补什么？可能是监控全球节点的DNS解析状态，也可能是跟云厂商签更严格的SLA。但说真的，我挺怕他们又提“多活架构”——上次搭多活，我熬了三个通宵，结果发现业务方的数据库根本没做同步。这事儿防不住，只能见招拆招了。

（编辑：站长网）

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