Команда Spring АйО подготовила статью про Rate Limit в Maven Central — один из тех инфраструктурных проектов, без которых современная JVM-экосистема уже немыслима. Здесь живёт подавляющее большинство библиотек и инструментов для Java, Kotlin, Scala и Android. После закрытия JCenter в 2021 году он окончательно стал де-факто центральным публичным репозиторием, куда в итоге попадает практически каждая новая библиотека.
В 2024 году объём скачиваний из Maven Central вырос на десятки процентов, достигнув астрономических масштабов. При этом финансирование и поддержку инфраструктуры обеспечивает компания Sonatype, которая отвечает за проверку и публикацию артефактов, стабильность, безопасность и доступность сервиса для всего мира.
Проблема: «трагедия общин» в действии
По данным Sonatype, 83 % трафика формирует всего 1 % IP-адресов, и чаще всего это крупнейшие компании и их CI/CD-системы. Во многих случаях они не используют кеширование или делают слишком много уникальных запросов — например, при сборках в контейнерах, которые скачивают зависимости заново каждый раз.
Эта ситуация наглядно иллюстрирует «трагедию общин»: небольшой процент участников чрезмерно использует общий ресурс, что создаёт нагрузку на инфраструктуру и в перспективе способно снизить качество сервиса для всех.
Решение: rate limits и троттлинг
Чтобы сохранить устойчивость работы Maven Central, Sonatype внедрила ограничения пропускной способности для самых ресурсоёмких пользователей.
Это включает:
Замедление отдачи (throttling) при большом числе запросов.
HTTP 429 Too Many Requests при явном превышении порогов.
Организационные лимиты — поведенческий анализ трафика позволяет применять ограничения к целой организации, даже если запросы распределены по множеству IP.
Важно: обычные разработчики, которые работают с локальным кешем, практически никогда не сталкиваются с этими ограничениями. Основной риск — у CI/CD без кеширования.
Как избежать проблем
Sonatype и сообщество рекомендуют несколько простых шагов:
Используйте кеширующие прокси-репозитории (Nexus Repository, Artifactory, JFrog, Gradle Enterprise).
<mirrors>
<mirror>
<id>internal-nexus</id>
<mirrorOf>*</mirrorOf>
<url>https://nexus.company.com/repository/maven-all/</url>
</mirror>
</mirrors>Это снизит обращения в Maven Central в десятки раз.
Кэшируйте зависимости в CI/CD: в GitHub Actions — через actions/cache для .m2/repository, в других системах — аналогичные механизмы.
GitHub Actions (Maven):
- name: Cache Maven packages
uses: actions/cache@v4
with:
path: ~/.m2/repository
key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
restore-keys: |
${{ runner.os }}-maven-GitHub Actions (Gradle):
- name: Cache Gradle packages
uses: actions/cache@v4
with:
path: |
~/.gradle/caches
~/.gradle/wrapper
key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
restore-keys: |
${{ runner.os }}-gradle-Минимизируйте запросы к SNAPSHOT-ам и не скачивайте лишние версии.
<repositories>
<repository>
<id>snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<snapshots>
<updatePolicy>daily</updatePolicy>
</snapshots>
</repository>
</repositories>Вместо always используйте daily или interval:X.
Не удаляйте локальный кеш без необходимости.
Даже в CI не всегда нужно «чистое окружение» — для безопасности сборок лучше использовать проверку зависимостей (OWASP Dependency-Check, Maven Enforcer), а не удаление кеша.
Эти меры не только уберегут от замедлений, но и значительно ускорят сборки.
Если вы уже попали под ограничения
Признаки — резкое падение скорости скачивания и ошибки HTTP 429 Too Many Requests в логах сборки.
В таком случае Sonatype советует:
Проверить настройки кеша и оптимизировать запросы.
Связаться с ними через mavencentral@sonatype.com — в некоторых случаях они предлагают выделенные каналы или зеркала для крупных организаций.
Итог: ограничения в Maven Central — это не попытка «закрутить гайки», а способ сохранить ресурс, который обслуживает миллионы разработчиков по всему миру. Если вы используете кеширование и best practices, эти меры останутся для вас незаметными. А вот тем, кто без нужды гоняет сотни гигабайт зависимостей через CI, стоит срочно пересмотреть подход.
Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано
