Распространение системы чата Erlang

Question

Я только что закончил Erlang in Practice screencasts (код here) и у вас есть вопросы о распространении.

Вот это общая архитектура:

Вот как дерево контроля выглядит следующим образом:

Чтение Distributed Applications приводит меня к мысли, что одна из главных мотиваций для перехода на другой ресурс.

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

Или должно быть 3 разных приложения OTP?

Кроме того, как можно сделать эту систему горизонтально? Например, если я понимаю, что моя система может обрабатывать 100 пользователей, и что я определил Message Router в качестве основного узкого места, как я могу просто добавить другой узел, где теперь он может обрабатывать 200 пользователей?

Answer 1

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

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

Это, как говорится, не упрощает создание приложения, которое может масштабироваться. Правило большого пальца гласит, что если вы хотите, чтобы приложение работало в 10 раз больше узлов, вам нужно переписать его, поскольку в противном случае служебные данные для обмена сообщениями были бы слишком большими. И, очевидно, когда вы начинаете с 1 до 2, вам также нужно это учитывать.

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

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

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

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

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