AI网关深夜告警，我花了半小时救回钱包监控服务

今天主要折腾了两件事：一是给AI网关加了层安全防护，二是把钱包监控服务从崩溃边缘捞了回来。本来以为是个平稳的周五，结果下午三点刚过，告警群就开始响了。

给AI网关加了一道“限流闸门”

上午先处理了一个老问题：AI网关最近老被刷，后台日志里全是同一个来源的请求，QPS直接顶到上限，正常业务反而进不来。原因很简单——有个调用方没配鉴权，相当于门没锁，谁都能进来逛一圈。

说白了，就是给网关加了个“限流器”，每个调用方每秒最多放行固定数量的请求，超出的直接拒绝。

操作上不复杂：登录服务器A，改了下网关配置文件，加了基于API Key的速率限制规则，然后把超限请求的响应码从原来的200改成429，方便调用方识别。改完重载配置，观察了十分钟，QPS曲线明显平滑了，异常来源的请求被拦掉大半。

踩了个小坑：有个内部服务的API Key格式不标准，导致限流规则没匹配上，白白放了一波流量进来。排查了半小时才发现是Key前缀多了个空格，清掉后规则立即生效。以后写Key的时候真得注意别手滑。

钱包监控服务突然“失联”

下午三点，监控面板上钱包监控服务的指标直接归零，持续探活失败。第一反应是进程挂了，登录服务器B一看，进程还在，但日志已经停在十几分钟前，没有任何新输出——典型的死锁或卡死状态。

这种“进程活着但不干活”的情况，比直接崩溃更坑，因为常规的进程监控根本发现不了。

先看了下CPU和内存，内存占用异常高，接近上限。用命令dump了一下线程栈，发现是某个外部API调用在等响应时一直不超时，把线程池占满了，后面所有任务全堵在队列里。原因也简单：那个外部API今天升级了接口，返回格式变了，我们的解析代码没兼容，抛异常后没释放连接，导致连接池耗尽。

处理思路：先把进程重启，恢复服务；然后定位到连接池配置，把最大连接数调小，同时给外部调用加了超时时间，硬性规定最多等五秒，超时就放弃并记录告警。改完重新上线，服务恢复正常，队列积压的任务也慢慢消化完了。

反思了一下：这类第三方接口变更导致的故障，其实可以通过加一层“适配器”来隔离，但之前一直觉得没必要，现在看还是得补上。

今日小结

今天最有价值的一件事，是处理钱包监控服务卡死时，没有直接盲目重启，而是先dump线程栈定位了根因，否则重启十次也白搭。

故障不可怕，可怕的是不知道为什么挂的。今天算是又交了一次学费。

明天的计划：把AI网关的限流规则补个自动化测试，另外给钱包监控服务加一层心跳检测，避免下次再“假活”。