@ZHSV

Здравствуйте. Пишу игру (стратегию (пошаговая/глобальная/RTS)) под Android, которая должна работать в онлайн режиме. Делаю я ее пока-что как хобби (и для дипломного проекта).
Так вот уже кое-что сделано на стороне сервера, но у меня возникают сомнения, насколько это правильные решения:
1. Есть один главный сервер, к которому подключаются все клиенты по tcp-протоколу, его основная задача - "оградить" внутреннюю структуру сервера (остальные сервисы и сервера) от игроков, как он работает: получает соединение, сохраняет его, и при получении данных от клиента отправляет их на один из сервисов обработки сообщений (отдельный "внутренний сервер"), на какой именно: он выбирает в зависимости от загруженности, то есть получается некий прокси-сервер.
2. Сервер обработки сообщений получает данные и бросает их в один из потоков (в каждом из которых имеется очередь для обработки), когда очередь дошла доходит до пакета данных, данные обрабатываются и отправляются на главный сервер, который их переправляет нужному клиенту.
3. Каждое подключение (сокет) в главном сервере также состоит в похожем потоке (как в пункте №2).
3. Для взаимодействия между сервисами используются обычные сокеты (протокол: tcp). WCF (или RPC) использовать не хочу ибо они медленнее работают (ну или я так думаю). То есть, при необходимости передать данные с одного сервиса (сервера) на другой используется "socket.Send", сервисы принимают данные асинхронно.
4. Всё (в теории) должно работать в облаке Azure, где каждый сервис/сервер является отдельной VM или Worker-ролью.

В общем, если кто-то подскажет где в такой системе "узкие места" или как лучше всё изменить для более "продвинутой" архитектуры и главное масштабируемости буду очень благодарен.

0

@LeniumSoft

Блин! Описано вроде круто!
Такую штуку называют Load Balancer

1