Высоконагруженный Java-сервер
Я делаю многопользовательскую игру. Сейчас я пытаюсь выбрать технологию подключения устройств Android к серверу. Клиенты работают на Android, а игра MMORPG. Я хотел бы написать сервер в Java. На данный момент у меня есть только 3 идеи для этого:
1) создание многопоточной среды с простым Java и сокетами. Таким образом, будет проще установить полнодуплексное соединение между игровым клиентом и сервером. Но у меня есть следующие проблемы:
1.1) Игра представляет собой MMORPG с большим количеством объектов, и я не уверен, как масштабируются такие решения, если в нее одновременно играют, например, 5000 человек. Сколько потоков я смогу запустить на Java Machine? Как я могу приблизительно рассчитать это? В случае, если 1 поток читает для каждого сокета, а 1 поток пишет в сокет (таким образом, 2 потока для 1 игрока).
1.2) Когда число игроков будет расти, как я смогу масштабировать свой написанный мной jar-архив для распределения по нескольким серверам? Может быть, есть какой-то особенный трюк для этого?
1.3) Много программных накладных расходов - сокеты API довольно низкого уровня.
2) Создание Servlet-интерфейса для обслуживания HTTP -запросов.
2.1) Легко контролировать сеансы (и авторизацию), если у каждого игрока есть свой сеанс.
2.2) может подключаться к java EE EJB или как угодно - многие сложности с программированием на системном уровне устранены. Так что я могу сосредоточиться на написании бизнес-логики.
2.3) Может обслуживать все типы клиентов с HTTP - мобильными устройствами + браузерами.
2.4) Высокая скорость - даже один контейнер сервлета может обслуживать несколько тысяч запросов в секунду, поэтому он будет действительно быстрым.
2.4) Но этот подход не может обеспечить полнодуплексную связь. Мне придется отправлять запросы каждую 1 секунду, чтобы проверить наличие обновлений. Задержка в 1 секунду не имеет большого значения для игры, поскольку она пошаговая, но все же она генерирует много трафика. Это возможно, когда много игроков играют? Я слышал о какой-то технологии COMET, но кажется, что если серверу нужно выдвигать много сообщений подряд, мне все равно придется отправлять запросы каждый раз + эта технология еще не очень хорошо развита.
3) Создание сокетов и подключение их через JMS к серверу Java EE.
3.1) Круто, потому что обеспечивает полнодуплексную связь между клиентами и сервером + обеспечивает все интересные функции java EE. Позже может быть расширен до браузера через интерфейс сервлета.
3.2) Кажется, что-то вроде переобучения. Это действительно, как люди будут делать это? Я имею в виду, это даже правильный путь? Любой здравомыслящий разработчик сделает это так?
Я хотел бы, чтобы вы помогли мне с выбором, пожалуйста. У меня нет большого опыта в выполнении такой работы. И хотел бы придерживаться лучших практик.
1 ответ
Я не думаю, что идея 3 будет закончена, и я бы пошел по этому пути.
Создать "адаптер" @MessageDriven Bean, который обрабатывает входящие соединения сокетов в методе onMessage, легко, и вы попадаете в мир масштабирования EE.
В вашем случае вы можете даже положиться на UDP. Смотрите следующий пример: http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/
Но, с моей точки зрения, есть и другие важные причины для этого. Некоторые указатели:
1.) Как вы уже упоминали. Создание собственного Socket Server для обработки потоков и запросов - это большая работа, и в конце вы можете создать свой собственный маленький "сервер приложений".
2.) Не бойтесь использовать сервер приложений. Конечно, люди склонны называть такую платформу "накладными". Хотя, когда я измерял количество времени для вызова других сервисов или отливов, использование локальных интерфейсов стоило менее 10 микросекунд на вызов. Иметь собственные пулы потоков и рабочих и обрабатывать их самостоятельно может быть быстрее, хотя и не близко к 0 микросекундам;-)
3.) Имея AS, вы можете очень легко настроить границы вашего экземпляра. Еще важнее то, что вы можете масштабировать свое приложение намного проще, чем самодельное программное обеспечение. Представьте себе, что кластер работает на 2+ серверах (и вы это сделаете, если ваша MMO будет успешной). Сетевой балансировщик нагрузки работает для всех видов архитектур, хотя в пакете EE имеется возможность обмениваться информацией о сеансах (возможно, не для подключений геймеров, хотя и не для зарегистрированных пользователей) или менеджерами сущностей через кластеризованные узлы.
Все эти инструменты и шаблоны EE дают вам время для разработки игры вместо фреймворка;-)