Использование Azure Service Fabri c для ручного управления и запуска агентов обработки заданий

Question

В настоящее время я изучаю возможность использования Azure сервиса Fabri c и его надежных сервисов для реализации моей архитектуры проблемного домена.

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

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

Итак, основы c Высокоуровневый дизайн выглядит примерно так:

Идея: Центральный движок системы веб-сканирования (далее - CWCE) работает в бесконечном l oop, пока программа не будет прервана и получает сообщение очереди служебной шины, которое содержит URL-адрес просматриваемой страницы. Затем компонент CWCE проверяет имя хоста этого URL-адреса и обращается к базе данных регистратора агентов SQL, если живой агент уже существует для данного имени хоста. Если нет, то CWCE выполняет одну из следующих процедур:

1. Если количество живых агентов (A_alive) равно значению Max (верхний предел агентов, предоставленный администратором приложения) CWCE ожидает, пока A_alive <Макс. значение </p>

2. Если A_alive <Макс., CWCE пытается создать нового агента и присвоить ему имя хоста. (затем агент регистрируется в SQL базе данных регистратора). </p>

Каждый агент работает в своем собственном разделе (имя хоста URL, например: example.com) и рекурсивно сканирует только страницы этого имя хоста при обнаружении URL-адресов внешних имен хостов и добавлении их в очередь служебной шины для других обработок агентов.

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

Однако я очень новичок в Azure Service Fabri c и поэтому хотел бы спросить, способен ли этот уровень PaaS решить эту проблему? Основные вопросы:

1. Можно ли вручную создавать новые экземпляры агентов веб-сканирования с помощью программируемого кода и передавать им параметр имени хоста, используя Azure Service Fabri c? (Может быть, используя класс FabricClient для управления кластером и создания экземпляров службы?)

2. Какая модель программирования ASF лучше всего подходит для этого параллельного сценария долгосрочных агентов? Службы без сохранения состояния , Службы с сохранением состояния или Модель актера ? Каждый агент может выполняться как долго выполняемая задача, поскольку он рекурсивно сканирует указанные c URL-адреса имени хоста и прослушивает очередь.

3. Можно ли контролировать и изменять этот верхний предел ограничения Max живых агентов во время выполнения приложения?

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

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

Answer 1

Сервис Fabri c позволит вам реализовать архитектуру, которую вы хотите.

1. Можно ли вручную создавать новые экземпляры агентов веб-сканирования с помощью программируемого кода и передавать им параметр имени хоста, используя Azure Service Fabri c? (Может быть, используя класс FabricClient для управления кластером и создания экземпляров службы?)

Да. Служба, которую вы будете разрабатывать и развертывать в Service Fabri c, будет иметь значение ServiceType. Типы сервисов на самом деле не запускаются, вместо этого из ServiceType вы можете создать настоящие сервисы с именами. Одна служба (например, ServiceA) будет иметь несколько экземпляров, чтобы обеспечить масштабирование и доступность. Вы можете программно создавать и удалять сервисы определенного типа и передавать им параметры, чтобы каждый сервис знал, какой URL сканировать. Посмотрите пример здесь .

Какая модель программирования ASF лучше всего подходит для этого параллельного сценария с долгосрочными агентами? Службы без сохранения состояния, службы с отслеживанием состояния или модель актера? Каждый агент может запускаться как долго выполняемая задача, поскольку он рекурсивно сканирует указанные c URL-адреса имени хоста и прослушивает очередь.

Я бы выбрал службы без сохранения состояния, поскольку они будут наиболее эффективный с точки зрения использования ресурсов и самый простой в управлении (нет необходимости хранить состояние и управлять состоянием, разбиением и репликами). Единственное, что вам нужно учитывать, - это то, что каждый сервис в конечном итоге обработает sh и перезапустится, поэтому вам нужно сохранить текущее место сканирования в постоянном хранилище, а не в памяти.

Можно ли контролировать и изменять этот верхний предел максимального числа активных агентов во время выполнения приложения?

Да. Служба Службы Fabri c работают в узлах (виртуальных машинах), а в Azure они управляются наборами масштабов виртуальных машин. Вы можете легко добавлять и удалять узлы из VMSS, что позволит вам настроить необходимую вам общую вычислительную мощность и объем памяти, а фактическое количество сервисов уже контролируется вами, как указано в пункте 1.

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

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