Java-сервер с высокой нагрузкой

Question

Я делаю многопользовательскую игру. Теперь я пытаюсь выбрать технологию подключения устройств Android к серверу. Клиенты работают на Android, а игра MMORPG. Я хотел бы написать сервер в java. Прямо сейчас у меня есть только 3 идеи:

1) создание многопоточной среды с простой java и сокетами. Таким образом будет проще выполнять полнодуплексное соединение между игровым клиентом и сервером. Но у меня есть следующие проблемы:

1,1) Игра MMORPG с большим количеством объектов, и я не знаю, как такие решения масштабируются, если есть, например, 5000 людей, играющие одновременно. Сколько потоков я смогу запустить на java Machine? Как я могу рассчитать это? В случае, если 1 нить считывается для каждого сокета и 1 поток записывает в сокет (так что 2 потока для 1 игрока).

1.2) Когда количество игроков растет, как я смогу масштабировать свой самонаписанный jar-архив для распространения по нескольким серверам? Может быть, есть какой-то особый трюк?

1.3). Много программирования накладных разъемов API довольно низкого уровня.

2) Создание сервлет-интерфейса для обслуживания 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) Кажется, что-то перерабатывает. Неужели это так люди? Я имею в виду, это даже правильный путь? Может ли любой здравомыслящий разработчик сделать это?

Я хотел бы, чтобы вы помогли мне с выбором, пожалуйста. У меня нет большого опыта работы с такой работой. И хотелось бы придерживаться лучших практик.

Answer 1

Я не думаю, что идея 3 была бы над инженерной, и я бы ударил по этой дороге.

Building @MessageDriven Bean «адаптер», который обрабатывает входящие соединения сокетов в методе onMessage, легко развивается, и оттуда вы находитесь в мире масштабирования EE.

Вы в вашем случае, вы даже можете рассчитывать на UDP. См. Следующий пример: http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/

Но, с моей точки зрения, существуют другие важные причины для этого. Некоторые указатели:

1.) Как вы уже упоминали. Создание собственного Socket Server для обработки потоков и запросов - это большая работа, и в конце вы можете создать свой собственный «сервер приложений».

2.) Не бойтесь использовать сервер приложений. Конечно, люди склонны называть такую ​​платформу «накладными расходами». Хотя, когда я измерял количество времени для вызова других сервисов или ebbs, использование локальных интерфейсов стоило менее 10 микросекунд за звонок. Имея свои собственные пулы потоков &, рабочие и их обработка сами могут быть быстрее, хотя и не близки к 0 микросекундам ;-)

3.) Наличие AS, вы можете легко настроить границы своих экземпляров. Еще более важно, что вы можете масштабировать приложение намного проще, чем самодельное программное обеспечение. Представьте, что кластер запускается на серверах с двумя серверами (и вы будете, если ваша MMO будет успешной). Сетевой loadbalancer работает для всех типов архитектур, хотя и имеет возможность делиться информацией о сеансе (возможно, не для подключений геймеров, хотя почему бы не для входа в сеансы пользователей), или управляющие сущностями по кластерным узлам просто «свободны» в пакете EE.

Все эти Е.Е. инструменты & модели дают вам время, чтобы развить игру вместо рамки ;-)