监控响应时间，别等用户投诉才动手
公司最近上线了个新活动页面，结果刚推出去十分钟，客服就炸了——用户反映领券接口一直转圈。查了一圈才发现，不是后端服务挂了，而是API网关的响应时间从平时的80ms飙到了1.2s。其实在监控图表里早就有征兆，过去一小时平均延迟持续上扬，可惜没人盯着。API网关就像小区大门，再好的房子，门被堵住，住户也进不去。
合理设置限流策略，防住突发流量冲击
有次运营做了个秒杀预告，没提前通知技术侧，结果预热文案一发，瞬间涌入几万请求，直接把网关打满。正确的做法是按业务场景分级限流。比如用户中心类接口可以宽松些，而活动类接口就得设硬阈值。Nginx配置可以参考：
location /api/activity/ {
limit_req zone=activity_limit burst=20 nodelay;
proxy_pass http://backend_service;
}这样即使流量突增，也能削峰填谷，不至于全线崩溃。
证书更新别忘提前续签
去年年底我们吃过一次大亏，网关用的SSL证书到期没及时换，凌晨三点开始陆续报“连接失败”，一堆人爬起来救火。现在我们把所有证书过期时间录入统一的运维日历，提前30天自动提醒。别觉得这是小事，一旦HTTPS中断，所有接口都会被浏览器拦截，等于直接停服。
日志集中管理，排查问题不靠猜
曾经有次线上报错，前端说调不通，后端说没收到请求。最后发现是网关路由规则写错了路径前缀，但因为日志分散在各个节点，花了快两个小时才定位到。现在我们用ELK把所有网关访问日志收拢，查问题直接搜trace_id，几分钟就能理清链路。比如查某个用户请求失败，直接过滤：
method:POST AND path:/api/order/create AND status:>499谁的责任，一目了然。
灰度发布先走小流量
改网关配置就像动水电总闸，一步错步步错。有一次同事更新了鉴权规则，一口气全量推了，结果第三方合作方的token校验全失败，业务直接中断。现在我们强制要求任何配置变更必须先切5%流量，观察15分钟各项指标正常再逐步放开。哪怕只是改个header透传，也不能跳过这步。
运维API网关，不是非要懂底层源码，但得养成盯细节的习惯。它不显山露水，可真出事，第一个背锅的就是它。