Go HTTP 调用超时后吞吐下降:从取消传播到连接复用的治理实践
适用场景 本文适用于 Go 服务通过 net/http 调用内部 API、第三方接口或对象存储的场景。典型现象是:下游偶发变慢后,请求大量超时;下游恢复后,调用方吞吐仍然偏低;连接数、TIME_WAIT 或新建 TLS 连接数明显上升;日志只看到 context deadline exceeded,却无法判断超时发生在
Tag
包含这个标签的文章。
适用场景 本文适用于 Go 服务通过 net/http 调用内部 API、第三方接口或对象存储的场景。典型现象是:下游偶发变慢后,请求大量超时;下游恢复后,调用方吞吐仍然偏低;连接数、TIME_WAIT 或新建 TLS 连接数明显上升;日志只看到 context deadline exceeded,却无法判断超时发生在
适用场景 支付、订单、代码托管或消息平台通过 Webhook 主动回调业务系统。接口已经校验 HMAC 签名,但偶尔仍出现同一事件被重复执行,甚至攻击者截获一条合法请求后,可以在数小时后原样重放。 本文以 Python 3.11、FastAPI 和 Redis 为例,实现一套可直接落地的接收端:对原始请求体进行 HMA
适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时,小文件正常,大文件刚提交便收到 413 Request Entity Too Large。应用日志没有请求记录,客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例,说明怎样确认拦截层、放开正
适用场景 业务服务部署在负载均衡、CDN、Kubernetes Ingress 或四层代理之后。应用日志中的 remote_addr 全是代理的内网地址,限流、风控和审计都无法识别真实访问者;更危险的是,直接信任请求携带的 X-Forwarded-For,会让攻击者伪造来源 IP 绕过白名单。 本文以“公网负载均衡 →
适用场景 线上服务切换负载均衡、迁移 API 网关或故障切流后,权威 DNS 已显示新 IP,但仍有一部分客户端持续访问旧地址。常见表现包括:请求间歇超时、少量用户仍命中已下线机房、发布后错误率在一个较长窗口内缓慢回落。 本文以 api.example.com 从 203.0.113.10 切换到 203.0.113.
适用场景 Java、Django、Node.js 等服务在 Kubernetes 中滚动发布后,新 Pod 长时间处于 CrashLoopBackOff,Deployment 一直无法完成;而在开发或低负载环境中启动正常。日志常只来得及打印数据库连接、缓存预热或迁移检查的前几行。 本文以“应用冷启动约 90 秒,但存活
适用场景 Python 服务或批处理脚本通过 httpx 调用第三方 HTTP API。流量上来后,应用日志开始出现 httpx.PoolTimeout,但目标接口的监控显示延迟正常;重启服务后短暂恢复,随后问题又出现。常见于 FastAPI/Django 的异步任务、数据同步程序和并发爬取工具。 本文以 httpx.
Nginx 偶发 502 且上游日志正常:upstream keepalive 陈旧连接的排查与治理 适用场景 服务部署在 Nginx 反向代理之后,流量高峰或发布后偶发 502 Bad Gateway。Nginx 错误日志出现 upstream prematurely closed connection、recv()
适用场景 本文适用于 Nginx 作为反向代理或网关时,用户访问接口偶发或持续返回 504 Gateway Time-out,错误日志中出现 upstream timed out、while reading response header from upstream 等信息的场景。 典型架构如下: Client ->
适用场景 本文适用于 Prometheus 已经配置了 scrape_configs,但在 Targets 页面看到目标实例显示 DOWN,或者 PromQL 查询 up{job="xxx"} == 0 的场景。常见对象包括 node_exporter、应用自暴露的 /metrics、Kubernetes Servic