Распространение сервера приложений - PullRequest
0 голосов
/ 12 апреля 2011

У меня есть сервер приложений.На высоком уровне этот сервер приложений имеет пользователей и групп .Пользователи входят в одну или несколько групп, и сервер информирует всех пользователей о состоянии своих групп и других пользователей в своих группах.Существует три основных функции:

  • Обновление и трансляция метаданных, относящихся к пользователям и их группам; например, пользователь входит в систему, а сервер обновляет статус этого пользователя и передает сообщенияэто для всех онлайн-пользователей в группах этого пользователя.
  • Действуя как прокси между двумя или более пользователями; клиент использует одноранговую передачу, но в случае, если двапользователи не могут напрямую подключаться друг к другу, сервер будет действовать как прокси между ними.
  • Хранение данных для автономных пользователей; , если клиенту необходимо отправить некоторые данные пользователю, которыйне в сети, сервер будет хранить эти данные в течение определенного периода времени, а затем отправлять их при следующем подключении пользователя.

Я пытаюсь изменить это приложение, чтобы оно могло распространятьсячерез несколько серверов, не обязательно все в одной локальной сети.Однако у меня есть требование, чтобы обратная совместимость со старыми клиентами не могла быть нарушена;по сути, дистрибутив должен быть прозрачным для клиента.

Самая большая проблема, с которой я сталкиваюсь, - это обработка случая, когда пользователь, подключенный к Серверу A , делает обновление, которое необходимо транслировать.пользователю на сервере B .

Кроме того, еще большая проблема возникает, когда пользователю на сервере A требуется, чтобы сервер действовал как прокси-сервер между ними и пользователем на сервере B .

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

Однако это только сводит к минимуму частоту взаимодействия пользователей на разных серверах.У меня все еще есть проблема с установлением связи между пользователями на разных серверах.

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

Например, если я подключен к Серверу A и мне нужен прокси с другим пользователем, подключенным к Серверу B , я бы спросил Сервер A для подключения прокси к этому пользователю. Сервер A увидит, что другой пользователь подключен к Сервер B , поэтому он установит ретрансляционное соединение с Сервер B .Это соединение будет просто пересылать мои запросы на Сервер B и ответы на меня.

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

Существуют ли хорошо известные или лучшие решения этой проблемы?Похоже, что для распределенной системы не очень распространено требование об обмене данными между пользователями на разных серверах.

1 Ответ

1 голос
/ 12 апреля 2011

Я не знаю, насколько вы гибки в изменении существующего сервера.Давным-давно я сделал так, чтобы все серверы оставляли TCP-соединение открытым друг для друга.Я использовал UDP-трансляцию, которая сообщала другим серверам друг о друге и позволяла им подключаться к новым серверам и удалять серверы, которые прекратили отправлять трансляцию.

Затем каждый раз, когда пользователь подключается к серверу, этот сервер отправляет одноадресное сообщение TCP.ко всем серверам, к которым он подключен, и на всех серверах хранится список пользователей и того, на каком сервере они находятся.

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

Вы можете запускать связь между серверами в потоке и фактически моделировать пользователя, находящегося на одном сервере.

Однако ведение списков пользователей и отправка сообщений подвержены гонкам (например, когда пользователь отключается, когда вы пересылаете сообщение с одного сервера на другой и т. Д.).

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

Если вы можете использовать язык, который поддерживает удаленные процессы и узлы, такие как Erlang.

Альтернативой может быть использование системы очереди сообщений, такой как RabbitMQ или ActiveMQ, и через нее серверы могут общаться друг с другом.Эти системы предназначены для масштабирования и обычно работают на основе механизма публикации / подписки.

...