Как вы представляете многопроцессные логические объекты в OTP?

Question

Представьте, что у нас есть следующая проблема:

1. У нас есть клиенты http, которые выполняют запросы к нашему программному обеспечению.Таким образом, у нас есть один процесс, который всегда доступен для них и сохраняет их запросы в очереди.
2. Нам нужно отправить эти запросы на компьютер, который находится в нашей внутренней сети (снова через HTTP).
3. Такая машина не всегда доступна.Он запускается (и останавливается, когда очередь пуста) по требованию нашего программного обеспечения (снова HTTP-запрос к машине «менеджера»).
4. У нас есть несколько (или много) из вышеперечисленного.

Итак, в принципе, у нас есть одна логическая сущность, которую мы будем называть «очередью заданий» ради аргумента.Каждая очередь заданий состоит из нескольких (разнородных) процессов.Тот, который реализует фактическую очередь и всегда доступен (не блокируется).Тот, который управляет рабочей машиной.У нас также есть несколько (порожденных по требованию) рабочих, которые удаляют записи из очереди, пытаются отправить их на рабочий компьютер, обходят ошибки;возможно, возврат (неудачные) попытки в очередь (для повторной попытки) и т. д. И, возможно, у нас также есть процесс «менеджер», который координирует работу выше.И у нас есть много «очередей заданий», которые все состоят из множества процессов.

ПРИМЕЧАНИЕ: это может быть не идеальное решение этой точной проблемы, но давайте предположим, что это так.Мой вопрос не о том, как решить проблему, а о том, как управлять такими «группами» процессов, которые представляют логические объекты.

Итак, как вы представляете это в OTP?Сколько у вас деревьев контроля, вы разделяете супервизоров между объектами "очереди заданий" или у вас есть супервизор на логическую сущность.Кроме того, как вы управляете всем этим.

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

Answer 1

Я бы использовал выделенный супервизор для каждого логического компонента (думаю, вы подразумеваете под логическим: http-worker, manager, dispatchers).У каждого из них будет руководитель над одним из этих классов.Мне это нравится, потому что я могу воспользоваться дополнительными инструментами для управления им (подсчитать количество детей, увидеть его в i () и т. Д.), И это хорошо разделяет систему.

Gproc, упомянутый @MinimeDJ и sync / asyncвещи - это совсем другое.

Я думаю, что это не лучшая архитектура, если вам нужна система, которую вы описали для использования gproc.Перепроектируйте его так, чтобы было как можно больше слоев без сохранения состояния.Например, вместо поддержки диспетчеров = модель push, попробуйте модель pull = задачи с удаленной машины.Это решение делает очереди без состояний, вы избавляетесь от диспетчеров и, если что-то идет не так, бэкэнд-слой снова ставит задачу в какую-то очередь.Более того, менеджеры просто сводятся к API к очередям и некоторым сборщикам статистики.Нагрузка на бэкэнд-работников измеряется и контролируется (локально!) В каждом из этих гетерогенных бэк-модулей.

Answer 2

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

Но перед финальным выпуском мы поняли, что поддерживать всю систему в рабочем состоянии будет реальной проблемой.

Итак, мы переработали его снова.Теперь мы представляем каждый логический блок как процесс gen_server.Каждый процесс имеет уникальное имя и живет в gproc.Поскольку gproc может работать на многих узлах, у нас очень простая в управлении отказоустойчивая система.

Итак, я бы сказал, что у нас есть управляемая объектная модель (мы называем ее MOM coz, нам это очень нравится).

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