У меня вопрос по архитектуре. В кластерной среде веб-приложений я могу придумать три способа справиться с фоновыми заданиями:
Какой предпочтительный подход?
У каждого варианта есть свои плюсы и минусы, и для выбора предпочтительного способа в любом случае требуется (имхо) немного больше информации. Например, какие фоновые задания? Это важный вопрос, потому что если, например, есть бизнес-процесс, может быть интересно воспользоваться уже существующим кластером.
Если это, например, процессы обслуживания, не связанные напрямую с бизнесом (или потребностями пользователей), возможно, имеет смысл иметь отдельное оборудование (или виртуальное).
По моему опыту, иногда все мы немного неохотно используем кластер в полном объеме, но кластеры готовы их использовать!
IANAExpert, но я полагаю, что вариант 1 будет предпочтительнее. Причина этого - простое разделение проблем. Если у рабочих мест есть собственная выделенная машина, вы сможете лучше управлять ростом. Если вы воспользуетесь вариантом 2, у вас будет потенциал обработки задания, не соответствующий его требованиям. Хотя используемые ресурсы должны быть одинаковыми, независимо от того, на одной машине или на нескольких выполняются задания, я предполагаю, что какая бы система очередей ни использовала, есть некоторые накладные расходы. Кроме того, если что-то пойдет не так с очередью или веб-сервером, вы не остановите другой. Вы изолировали каждую часть вашего приложения, поэтому вы можете расти по мере необходимости, а не в соответствии с требованиями вашей архитектуры.
Если у вас есть ресурсы, и для фоновых задач не имеет значения, откуда они запускаются, я бы выбрал вариант 1.
Для этого нет никаких причин, кроме того, зачем нагружать ваши веб-серверы, если вам это не нужно.
Это зависит от вашего бюджета, но наиболее желательным подходом является выполнение заданий на отдельных машинах, отличных от тех, которые обслуживают веб-контент. Это дает хорошее разделение проблем, и вам не нужно беспокоиться о том, что на работу в Интернете повлияет тяжелая работа.
Пелди, рассмотрите возможность использования подхода, который позволил бы иметь одну очередь заданий (желательно в базе данных) и одного или нескольких исполнителей заданий. Таким образом, вы можете запускать одного или нескольких рабочих заданий на одной или разных машинах - и это сделает вашу конфигурацию гибкой.
Я не знаю, какие задачи вы собираетесь выполнять и какие технологии будете использовать, но в мире Ruby / Rails такую задачу можно решить с помощью delayed_job
Другая информация о фоновой обработке доступна по адресу http://en.wikipedia.org/wiki/Job_scheduler
Лично в своем проекте я запускаю фоновые задания на том же компьютере, где находится база данных, но я могу добавить больше рабочих / машин позже, если в этом возникнет необходимость.
Надеюсь это поможет :)
Столкнувшись с той же ситуацией, в которой вы оказались:
Я бы не стал выбирать вариант 1, поскольку у вас есть единственная точка отказа. или дополнительные работы по архитектуре, чтобы снизить риск этого отказа
Я бы не стал выбирать вариант 3, так как вы получите неидентичные веб-узлы, и это будет препятствовать любой автоматизации в будущем.
Я бы использовал вариант 2 и имел центральную службу очереди, предпочтительно облачную, поскольку она уже будет кластеризована, что избавит вас от бремени переключения при отказе, масштабирования и т. Д.
Я предполагаю, что вы уже имели дело с отработкой отказа и загрузкой, используя кластер со своими веб-узлами, поэтому я бы просто добавил к рабочей нагрузке этих лошадей, но выполняемых в отдельном процессе.
надеюсь, это поможет