Актер Azure Service Fabric для длительных задач

Я новичок в Azure Service Fabric. Из моего исследования я очень заинтересован в использовании его для конкретного сценария проблемы оптимизации. Однако я не нахожу подробной информации в MSDN, подтверждающей мои выводы.

Мое требование состоит в том, что у меня есть веб-API, который получает входные данные и сбрасывает их в базу данных. Этот вход используется для запуска алгоритма оптимизации, который обычно занимает около 3-5 минут. Пользователи могут подавать несколько запросов, которые в конечном итоге необходимо будет обработать.

В настоящее время я думаю, что создание новых надежных актеров ASF для каждого ввода оптимизации является хорошим выбором. Однако я не совсем понимаю, как работает ASF для таких задач, которые выполняются долго, а не мгновенно.

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

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


azure .net azure-service-fabric
person Praneeth    schedule 22.12.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Я думаю, что здесь важно выполнять вычисления в фоновом режиме. Вызывающие объекты Service/Actor не должны ждать, пока работает алгоритм оптимизации.

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

Для этого в Actor требуется:

  • Использование StateManager для хранения очереди, содержащей задания
  • Регистрация таймера для обработки работы.
  • Необязательно вызов другого (дополнительного) Актера для отчета о прогрессе

Для этого в службе без сохранения состояния требуется:

  • Внешняя очередь (которая является внешней зависимостью, влияющей на доступность)
  • Необязательно внешнее хранилище прогресса

Для этого в службе Stateful (дополнительный выбор) требуется:

  • используя StateManager, чтобы удерживать ReliableQueue.
  • периодически проверяя эту очередь на работу от RunAsync.
  • Необязательно периодически сохранять прогресс в файле StateManager.

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

person LoekD    schedule 22.12.2016
comment
Спасибо за ответ. Предположим, я использую службу с сохранением состояния, которая сохраняет команду в надежной очереди. Затем я периодически проверяю очередь, чтобы проверить ожидающие выполнения команды. Удалите первый из очереди и создайте апатрида или актера (не уверен, что лучше) и инициируйте алгоритм. Не могли бы вы предложить, как я обычно отслеживаю, завершена ли моя служба алгоритма или нет. Должно ли это быть задачей службы алгоритмов или главной службы с отслеживанием состояния. Я до сих пор не понимаю, как этого достичь. - person Praneeth; 28.12.2016

arrow_upward
0
arrow_downward

Я думаю, что сочетание stateful и stateless будет хорошим решением для вашего сценария. Используйте stateful для постановки запросов в очередь и используйте stateless для обработки (алгоритмов) запросов. Кластер SF создаст новые экземпляры службы без отслеживания состояния для других узлов в кластере, если это необходимо, в зависимости от нагрузки. Служба с отслеживанием состояния будет вашим надежным хранилищем для хранения запросов (через надежную очередь) и прогресса (надежные словари). Служба с отслеживанием состояния поддерживает одну первичную реплику и две вторичные реплики в кластере.

person alltej    schedule 24.12.2016
comment
Спасибо за ответ. Не могли бы вы сообщить мне, почему в этом случае вы рекомендуете SF Stareless Service вместо актеров? Также предположим, что у меня есть кластер из 5 узлов, и я порождаю 5 экземпляров алгоритма, который на 100% загружает ЦП, как будет вести себя порождение другого экземпляра в контексте SF? - person Praneeth; 28.12.2016