当你拒绝接受“数据源已宕机”这一理由时，会发生什么。
问题所在
GitHub 的热榜页面是数百万开发者每天发现新项目的地方。但 GitHub 从未为此提供过官方应用程序接口（API）——如果你想以编程方式获取这些数据，就必须抓取超文本标记语言（HTML）页面。
我发现的每一个现有抓取工具都有相同的设计缺陷：单一数据源，单点故障。GitHub 的超文本标记语言（HTML）结构发生微小变化 → 你的服务就会在一周内返回 503 错误。被 Cloudflare 限制访问频率 → 结果同样糟糕。
我想要一个即使在 GitHub 页面宕机时也能保持运行的热榜应用程序接口（API）。因此，我构建了 Hydra，并将其部署在 hydra9.dev 上。
架构（一图概览）
┌───────────────┐
请求 ───▶ │ 路由器 │
└───────┬───────┘
│ 按顺序尝试，受熔断器保护
┌───────────────┼────────────────┬─────────────────┐
▼ ▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌──────────────┐ ┌──────────────┐
│通道 A │ │ 通道 B │ │ 通道 C │ │ 通道 D │
│超文本标记语言 │ │社区 │ │搜索应用程序接口 │ │gitstar- │
│抓取 │ │镜像 │ │(创建时间:>7天) │ │ranking.com │
└────────┘ └──────────┘ └──────────────┘ └──────────────┘
任一通道失效？熔断器打开，下一个请求将绕过它。
所有通道均失效？提供最近的 PostgreSQL 数据库快照 + 触发 Prometheus 警报。
四个独立的数据源。在滚动时间窗口内失败 3 次的通道，其熔断器将打开 60 秒——路由器会跳转到下一个通道，而不会增加用户请求的延迟。
为什么选择 4 个数据源而不是 2 个
两个数据源听起来似乎足够，直到它们共享相同的故障模式为止。我选择的这四个数据源在架构上是相互独立的：
通道 A（github.com/trending 超文本标记语言 HTML）：数据最新，但格式可能会毫无预警地发生变化
通道 B（ghapi.huchen.dev 社区镜像）：由一位热心人士维护，但它可能会静默数小时
通道 C（GitHub 搜索应用程序接口 API，条件为 created:>7d sort:stars）：最稳定，但它是重构的热榜数据——并非实际页面上显示的内容
通道 D（gitstar-ranking.com）：完全不同的数据模型（历史总星数），仅作为最后的交叉验证手段有用
如果因为 GitHub 超文本标记语言（HTML）变更导致通道 A 失效，通道 B 不会受影响（它有自己独立的解析器）。如果因为维护者的服务器宕机导致通道 B 失效，通道 C 位于 GitHub 完全不同的基础设施上。如果通道 C 限制了你的访问频率，通道 D 则是一个完全独立的网站。
历史数据——GitHub 不愿提供的东西
官方热榜页面只是某一时刻的快照。如果你刷新页面，昨天的列表就永远消失了。
Hydra 每 15 分钟运行一次 Celery Beat 任务，将新的快照存储到 PostgreSQL 数据库中。这解锁了官方页面无法提供的四个分析端点：
今日出现但昨日不在榜单上的仓库
curl https://hydra9.dev/api/v1/trending/new-stars
刚刚跌出榜单的仓库
curl https://hydra9.dev/api/v1/trending/dropped
按每小时星数排名，而非累计知名度
curl https://hydra9.dev/api/v1/trending/velocity
查看任意时间点的数据
curl https://hydra9.dev/api/v1/trending/history?at=2026-07-14T00:00:00Z
特别是增速指标一直是我的最爱——它能挖掘出那些正在迅速爆发
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
