Snap: запуск плагинов BungeeCord на Velocity

У вас есть сервер Velocity. Вы хотите мигрировать с BungeeCord, но половина плагинов еще не имеет версий для Velocity, а переписывание кажется излишним. Snap - это плагин-адаптер на Java, запускающий плагины BungeeCord напрямую на Velocity, переводя вызовы API на лету. Он не решит все проблемы совместимости, но для определенных конфигураций может спасти от мучительного замена или переписывания плагинов, на которых вы依赖те.

Что такое Snap на самом деле?

Snap - плагин Velocity, действующий как слой совместимости между двумя архитектурами прокси. Он загружает плагины BungeeCord внутрь Velocity и перехватывает их вызовы API, конвертируя их в эквиваленты Velocity в режиме реального времени. Представьте себе живого переводчика между вашими старыми плагинами и современным прокси.

История происхождения здесь важна. Этот maintainer, Phoenix616, начал с попытки задокументировать разницы между API BungeeCord и Velocity. Это переросло в построение реального адаптера, который мог бы загрузить плагины из одного прокси в другой. Результат умноват по концепции, но несет реальные компромиссы: он работает, но менее эффективен, чем родные плагины Velocity, поскольку каждый метод вызывается с переводом.

Для нишевого инструмента, решающего конкретную проблему, он достаточно активен. 134 звезд на GitHub, недавняя поддержка, и последний релиз (1.2-pre1) поддерживает Velocity 3.3.0 с совместимостью Bungee 1.20.x. Проект лицензирован под LGPL-3.0, поэтому вы можете использовать его свободно, если поделитесь любыми модификациями обратно.

Что работает (А что точно не работает)

Большинство базовых задач прокси работают нормально. Подключения игроков, переключение серверов, прослушивание событий, проверки прав - все есть. Maintainer refreshingly честен в README: "Большая часть (надеюсь)." Он не переоценивает эту штуку.

Однако несколько функций вообще не переведутся на Velocity:

• Встроенная система групп и прав BungeeCord не существует в Velocity. Проект рекомендует использовать LuckPerms вместо, что работает на обоих.
• Функциональность сервера reconnect. BungeeCord имеет это встроено; Velocity не экспонирует это.
• Поддержка Scoreboard. Velocity не имеет API для этого, и Snap не строит один.
• Некоторые настройки ProxyConfig возвращают разумные значения по умолчанию, но не являются точными отражениями поведения Bungee.
• Команды, зарегистрированные после загрузки плагина, могут не появиться в реестре команд.
• Обнаружение передачи работает только если сервер находится в онлайн режиме.

Если ваш плагин сильно зависит от любых из этих функций, Snap не спасет. Пришло время написать родной плагин для Velocity.

Здесь Snap становится практичным: вы можете настроить, что происходит, когда что-то не поддерживается. Установите `throw-unsupported-exception` в `true` (по умолчанию), и вы увидите исключения в логах, чтобы знать точно, что сломалось. Установите в `false`, и неподдерживаемые методы возвращают значения по умолчанию вместо, позволяя вашим плагинам работать с трудом.

Установка и Настройка

Установка проста, если вы работали с Velocity раньше.

Сначала возьмите файл snap.jar из системы CI проекта (ссылка на странице релизов). Он требует Java 17 или новее, поэтому убедитесь, что ваш сервер соответствует этому базовому уровню.

# Копируйте snap.jar в папку плагинов Velocity
cp snap.jar /path/to/velocity/plugins/

# Создайте каталог плагинов Snap
mkdir -p /path/to/velocity/plugins/Snap/

# Переместите ваши плагины BungeeCord туда
cp /path/to/bungee/plugins/*.jar /path/to/velocity/plugins/Snap/

Перезапустите Velocity (или перезагрузите плагин), и Snap инициализируется, загружает все плагины BungeeCord из этой папки и логгирует любые проблемы, которые встречаются. Если что-то не загружается, логи скажут вам почему.

Одна практическая рекомендация из тестирования: начните только со Snap и одним плагином BungeeCord. Подтвердите, что он загружается. Затем постепенно добавляйте больше. Вы поймаете проблемы совместимости намного быстрее, чем если бы вылить все сразу и затем задуматься, какой плагин вызывает проблему.

Когда использовать это

Snap имеет смысл в нескольких конкретных ситуациях.

У вас есть плагин BungeeCord, который больше не поддерживается и не имеет эквивалента для Velocity. Возможно, это старая утилита для персонала или кастомный модуль аналитики. Переписывание кажется расточительным. Snap позволяет продолжать использовать его без полной переписки.

Вы мигрируете сеть, но не хотите мигрировать все сразу. Использование Snap на новом сервере Velocity позволяет перенести старые плагины, пока вы постепенно пишете или находите замену для Velocity.

Вы запускаете тестовую сеть и хотите попробовать Velocity без обязательств по миграции всей экосистемы плагинов сразу.

Что не имеет смысла: использование этого в продакшене. Сам проект предупреждает об этом без обширного тестирования. И даже тогда, вы полагаетесь на экспериментальное ПО. Большинство продакшен сетей лучше полностью мигрировать.

Если большинство ваших плагинов уже имеют поддерживаемые версии для Velocity, пропустите Snap совсем. Просто мигрируйте. У вас будет меньше сюрпризов и лучше производительность.

Компромиссы производительности и ловушки

Перевод добавляет накладные расходы. Каждый вызов API перехватывается и конвертируется туда-сюда. Для плагинов, делающих тысячи вызовов в секунду, вы можете заметить влияние на CPU. Для нормальных плагинов, делающих базовую прокси-работу, вероятно, нет.

Обработка подключений - самая сложная часть. События могут срабатывать немного иначе, чем на BungeeCord. Если ваш плагин сильно манипулирует подключениями игроков или полагается на конкретное время событий, лучше переписать его для Velocity вместо попыток сделать его работать через слой перевода Snap.

Еще есть потолок масштабирования. Если вы управляете огромной сетью с тысячами одновременных игроков, неэффективность Snap будет накапливаться. На таком масштабе лучше полностью мигрировать.

Следите за CPU и памятью во время пикового трафика. Если видите спики, связанные с активностью плагинов, это может быть слой перевода, который страдает. Это ваш сигнал либо мигрировать плагин, либо найти альтернативу для Velocity.

Реальные альтернативы

Ваши варианты запуска старых плагинов BungeeCord на Velocity действительно ограничены, и именно поэтому существует Snap.

Напишите плагин для Velocity. Это правильный долгосрочный выбор и будущий путь. В зависимости от сложности, это может занять всего выходные.

Оставайтесь на BungeeCord или Waterfall. Velocity быстрее и лучше архитектурно, но не единственный вариант. Если вся ваша экосистема плагинов зависит от BungeeCord, оставаться там допустимо, пока вы не будете готовы мигрировать все вместе.

Перепроектируйте вокруг пропущенной функциональности. Вам действительно нужен этот старый плагин? Может, современная система прав, такая как LuckPerms, решит ваши проблемы без плагина. Может, вы сможете упростить инфраструктуру.

Прежде чем установить

Сначала протестируйте это в среде стейджинга. Запустите ваши плагины через каждую функцию, о которой вам важно. Затем наблюдайте за ним неделю и ищите странное поведение. Регулярно проверяйте логи. Ищите проблемы производительности.

Понимайте ограничения заранее. Snap работает для определенных плагинов и определенных случаев использования. Посмотрите, и это не будет работать для всего. Чем больше ваши плагины зависят от BungeeCord-специфичных функций (особенно системы групп и прав, манипуляций со Scoreboard или захвата подключений), тем более вероятно, что Snap вас разочарует.

Не запускайте это в продакшене без фазы тестирования в стейджинге. Проект явно предупреждает: это экспериментальное ПО. Оно решает конкретную проблему для конкретных людей. И это может не решить вашу проблему.

А если вы управляете сетью Minecraft серверов, ваши разработчики и игроки, возможно, оценят инструменты minecraft.how, такие как Поиск блоков для отслеживания конкретных материалов или Калькулятор Нитер-порталов для планирования инфраструктуры.