与 Rust 社区的其他部分一样，crates.io 也在快速增长，下载量和包数量每年增长 2-3 倍。这种增长并非没有问题，我们对 crates.io 的下载处理进行了一些更改，以确保我们能够长期提供 crate。

问题

这种增长带来了一些挑战。其中最显著的问题是，目前所有下载请求都通过 crates.io API 进行，偶尔会导致扩展性问题。如果 API 下线或变慢，也会影响所有下载请求。实际上，我们的 crates.io 待命团队被唤醒的首要原因是由于 API 的性能问题导致的“下载慢”。

此外，这种设置对于北美以外的用户来说也存在问题，由于距离 crates.io API 服务器较远，下载请求速度较慢。

解决方案

为了解决这些问题，在过去一年里，我们决定做一些改变

从 2024年3月12日开始，cargo 将开始直接从我们的 static.crates.io CDN 服务器下载 crate。

这一改变将通过修改包索引上的 config.json 文件来实现。换句话说：为了使这些改变生效，您的 cargo 或您自己的系统不需要做任何更改。config.json 文件被 cargo 用来确定 crate 的下载 URL，我们将更新它以直接指向 CDN 服务器，而不是 crates.io API。

在过去几个月里，我们对 crates.io 后端进行了几项更改以实现这一点

• 我们宣布弃用“非规范”下载，因为当直接从 CDN 下载时，将更难支持它们。

• 我们改变了下载的计数方式。以前，下载直接在 crates.io API 服务器上计数。现在，我们分析 CDN 服务器的日志文件来计数下载请求。

后一项改变导致大多数 crate 的下载量增加，因为之前有一些下载请求没有被计数。具体来说，crates.io 镜像站通常已经直接从 CDN 服务器下载，而这些下载之前没有被计数。对于下载量很大的 crate，这些变化几乎不会被注意到，但对于较小的 crate，自我们启用此更改以来的过去几周里，下载量有了相当大的增长。

预期结果

我们预计这些改变将显著提高下载的可靠性和速度，因为 crates.io API 服务器的性能将不再影响下载请求。在接下来的几周里，我们将监测系统的性能，以确保这些改变达到预期效果。

我们注意到一些非 cargo 构建系统没有使用索引的 config.json 文件来构建下载 URL。我们将联系这些构建系统的维护者，以确保他们了解这些变化，并帮助他们更新系统以使用新的下载 URL。旧的下载 URL 将继续可用，但这些系统将无法享受到潜在的性能提升。

我们对这些改变感到兴奋，并相信它们将极大地提高 crates.io 的可靠性。我们期待听到您的反馈！