标签频道
网关
该标签下的文章、提问与讨论帖。
HikariCP connectionTimeout 30s 问题：网关排队 + 连接池假满的双重坑与解法清单 一、现象与背景 你遇到一个令人抓狂的性能问题： - 请求处理时间 80ms，但 2.4s 的总耗时中， - 2s 是网关 wor
【背景】 我做了 8 年安全加固，最近复盘了一起内部 DLP 绕过事件：某业务同学的导出服务在代码里硬编码了一个海外对象存储 endpoint，把脱敏不彻底的明细数据传了出去。事后排查发现，公司出口网关的「出网白名单」是业务团队自己在工单里
背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB
先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？ 背景 热榜那篇《连接
«作者：温寒山-879｜分布式系统 / 安全加固｜10 年经验 栈：Spring Boot 3.2.x、Spring Security 6.3、Nginx 1.25、Tomcat 10.1 结论先行："客户端是谁"这件事，决定权绝不能交给请
接口废弃的 90 天倒计时：我管过 47 个 API 下线的完整流程、回滚预案与踩坑记录 一、现象与背景：没人敢删接口，但没人记得它为什么还在 先给一组数字。我所在团队 2022–2024 年累计对外暴露了 213 个 REST 接口（Sp
一、现象：封禁名单越拉越长，攻击占比却「按下葫芦浮起瓢」 去年 Q4 我们给一个对外提供 API 的 B 端服务做风控加固，一周内风控引擎标记出 137 个高频恶意 IP（判定口径：同一 IP 在 24h 内触发验证码 / 下单 ≥200
背景 超时重试是分布式系统的标配，而幂等就是重试的解药。但"在哪一层做幂等"这件事，我在 5 年里至少换过三个团队，三个团队的姿势完全不同，每次迁移都要重写一遍。 常见分歧大致有四种做法： 做法 A：网关层统一兜底。 在 API Gatew
一、现象：一周 83 笔重复订单，监控却"一切正常" 上个月我们对一个日均 15 万单的 B 端订单系统做安全与稳定性加固复盘，财务同事拉出对账单，发现一周内有 83 笔订单重复落库，占当周 27,412 笔订单的 0.30%。更诡异的是：
文
标题
摘要