Какая архитектура для "функционального рабочего процесса" с Azure?

#azure #azure-functions #azure-queues #azure-eventgrid #azure-durable-functions

#azure #azure-функции #azure-очереди #azure-eventgrid #azure-durable-функции

Вопрос:

Пример использования

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

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

Лучшим решением было бы иметь одну общедоступную функцию и несколько «частных» функций, недоступных публично (запускаемых только другими функциями Azure)

Вопрос

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

Сейчас я думаю о сетке событий. Это хороший выбор для вас? Как обрабатывать глобальный статус, который я могу получить из интерфейсной части приложения?

Заранее спасибо!

1. «нелегко вызывать функции Azure из orchestrator», Пожалуйста, уточните, поскольку основная задача orchestrator — вызывать другие функции.

2. Я предполагаю, что это возможно путем запуска HTTP-события в orchestrator, но я чувствовал, что это не лучшее решение (и я не хочу раскрывать другие мои функции Azure)

3. Существует множество способов защитить ваши функции и предотвратить прямой доступ

4. Итак, вы бы порекомендовали придерживаться надежных функций с отдельными функциями Azure, запускаемыми orchestrator?

5. Вы должны покопаться в документации и попытаться понять, что такое activity функции

Ответ №1:

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

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

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

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