Azure windows service для пакетной обработки

Question

Я хотел бы построить Azure PaaS-эквивалент «Службы Windows». Я мог бы, конечно, создать виртуальную машину и развернуть службу Windows, но я ищу способ масштабируемого/PaaS для этого. По сути мое приложение - это служба заднего плана, которая контролирует очередь (например, служебную шину Azure), и когда сообщение приходит в очередь, оно будет выполнять кучу логики обработки (логика обработки, доступ к базе данных, вызов других веб-сервисов, очередь другие процессы и т. д.). Некоторым службам, возможно, потребуется выполнить дополнительные операции, такие как создание дочернего домена приложения, запись временных файлов на диск и т. Д.

Какое решение Azure нужно искать для удовлетворения этой потребности?

Похоже, что Azure сильно изменилась за последние пару лет, и я смущен, пытаясь найти лучший сервис для удовлетворения моих потребностей. Некоторые типы проектов выглядят устаревшими, но есть еще много старой документации/блогов. Я вижу ссылки на WebJobs, рабочие роли, логические приложения и функции. Может ли кто-нибудь более опытный в создании услуг Azure сказать мне, какие технологии я должен искать для удовлетворения моих потребностей?

Я чувствую, что это должно быть очевидной и общей потребностью, но, возможно, я просто использую неправильные условия поиска, и я не нахожу много информации, которая, похоже, соответствует моей точной потребности, или info Я нахожу это с 2011 года, и я волнуюсь, пейзаж изменился с тех пор.

Answer 1

У вас есть выбор, как вы говорите - WebJobs, Logic apps, Service Fabric или Functions, и это зависит от того, какой объем управления вам нужен или требуется для кода, который вы развертываете. Роли рабочих - это термин «Облачные услуги», хотя они по-прежнему поддерживаются, как правило, не рекомендуется, поскольку развертывание, масштабируемость и управление другими перечисленными службами намного лучше.

Веб-задания и функции используют один и тот же SDK WebJobs, чтобы обеспечить загрузку поддержки для запуска из очередей, капли или выполнения расписания. Они оба работают в пределах (и масштабируются) с планом обслуживания приложений, но функции «безсерверны» в том, что вам не нужно видеть или управлять экземпляром службы веб-приложения, а также просто развертывать исходный код - он будет скомпилирован на развертывание.

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

Логические приложения имеют другую модель исполнения/зарядки и будут масштабироваться по требованию, но это больше подходит для организации рабочего процесса и объединения компонентов, а не выполнения вашей операции. То есть. для обработки данных из вашей очереди может быть компонент, который нужно запускать где-то - возможно, в приложении API или в функции Azure, которую вы также размещаете.

Answer 2

Logic Apps предназначен для точного сценария, который вы описали.

Вы должны иметь возможность создавать приложение Logic, которое запускает новое сообщение в очереди служебной шины.

Затем приложения Logic поддерживают взаимодействие с SQL/Queue/REST, даже локальную файловую систему, проверку XML, X12/AS2/EDI, а также встроенные функции, такие как синтаксический анализ JSON/XML, условия, цикл и т. д. Для более продвинутых действий, которые в настоящее время не поддерживаются в приложениях Logic, вы можете расширить Logic Apps с помощью функций Azure.