kayceenuel/abuse-aware-api-gateway

# 防滥用 API Gateway 这是一个部署在产品 API 前面的 gateway，用于判断请求是否合法——它不仅检查请求者的身份，还会随着时间的推移学习其行为模式。 大多数 rate limiter 仅仅统计请求数量就止步于此。而这个 gateway 会观察行为模式。同一个 IP 使用不同用户名猛烈攻击一个登录 endpoint，与一个忘记密码的用户的正常行为截然不同。以非人类的速度完美连续抓取搜索 endpoint，与购物者的正常浏览也截然不同。这个 gateway 能分辨出其中的差异。 ## 工作原理 请求会经过三层处理： **Ring 1 — HTTP 代理** 每个请求都会首先到达 gateway。它会提取 API key 和 IP 地址，路由到正确的 endpoint，并转发给产品 API。任何请求都必须经过这里才能通行。 **Ring 2 — Rate limiter** 两种策略并行运行。Token bucket 控制每个 API key 的持续流量——每个 key 都有一个以固定速率补充 token 的桶，而请求会消耗 token。滑动窗口则在一个滚动时间窗口内追踪每个 IP 的请求计数。Redis 保存了所有的计数器，因此无论有多少个 gateway 实例在运行，限制策略都能得到一致的执行。 **Ring 3 — Kafka pipeline** 每个请求（无论允许还是阻止）都会作为事件记录到 Kafka 中。Consumer 读取该数据流并计算每个 IP 和 API key 的风险评分，专门寻找两种特定的模式：凭证填充（在短时间窗口内来自同一来源的大量不同用户名）和抓取（人类无法维持的请求速率）。当评分超过阈值时，更严格的限制会被推送到 Redis 中。Ring 2 会在下一次请求时自动应用这些限制。 ## 架构  ## 技术栈 - **Go** — gateway、rate limiter、Kafka producer - **Redis** — 分布式 rate limit 计数器 - **Kafka** — 请求事件流 - **Docker Compose** — 本地环境 ## 本地运行 _即将推出._ ## 设计决策 关于权衡的完整分析——为什么选择 token bucket 而不是 leaky bucket，当 Kafka 出现延迟时会发生什么，如何处理误报等——都在 [`docs/design.md`](./docs/design.md) 中。

标签：API网关, Go, Kafka, MacOS取证, Redis, Ruby工具, SonarQube插件, 反爬虫, 搜索引擎查询, 撞库防御, 日志审计, 流量控制, 版权保护