Как управлять/балансировать полупостоянные задания по экземплярам службы

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

Примеры таких задач

  • Прослушивание очереди сообщений для данных из источников X и Y, корреляция данных, которые поступают и хранятся в Z.
  • Храните буфер памяти в памяти, который вычисляет текущее среднее за последние 15 минут данных каждый раз, когда появляется новая запись данных.

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

График, который, мы надеемся, иллюстрирует настройку, которую мы имеем в нашей голове: services_setup

  • Служащие службы в настоящее время дезамонизированы PHP-скрипты
  • Для реестра служб мы смотрим на Zookeeper

В то время как Zookeeper (и куратор) выполняет балансировку нагрузки, я ничего не обнаружил в распределении постоянных заданий (которые можно обновлять, удалять и переназначать, когда рабочий умирает)

Предлагаемые обязанности менеджера заданий

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

Существуют ли какие-либо библиотеки/инструменты, которые могут решать такие проблемы, и могут ли они функционировать в качестве менеджера заданий? Или это все один большой анти-шаблон, и мы должны сделать это по-другому?

Ответы

Ответ 1

Вы должны посмотреть Gearman.

Он состоит из client, который назначает задания, один или несколько workers, которые будут собирать и выполнять задания, а server, которые будут поддерживать список ожидающих функций (служб) и заданий. Он будет переназначать задания, если рабочий умрет.

Ответ 2

Ваши рабочие звучат как (api-less) услуги. Таким образом, ваши требования могут быть переформулированы как:

  • Знает о развернутых сервисах
  • Знает о узлах, которые могут размещать там службы
  • Может развертывать службы для узлов
  • Может ли [отправлять обновления работы службам] = перераспределять службы/вызывать некоторый API для развернутых служб
  • Может повторно развертывать службу, если служба или node умирает

Посмотрите на Docker для развертывания, запуска и управления изолированными процессами на хосте.

Ответ 3

RabbitMq - простая очередь сообщений, с которой довольно легко перейти.