Архитектура лазурных функций

Question

У меня есть функция Azure с триггером очереди хранения Azure.Работает нормально без проблем.Внутри очереди будет сохранен JSON, а затем функция сделает свою работу.Но теперь нам нужно больше функциональности.Мне нравится расширять JSON функциональной клавишей.Теперь лучше расширить также функцию. Если функциональность = A, перейти в класс A, иначе перейти в класс B

. Или лучше создать новую функцию с тем же триггером?Привет

Answer 1

Функции похожи на традиционные приложения.Нет проблем при обращении к библиотеке классов, которая обрабатывает эту десериализацию.

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

Одна из возможностей - рассматривать каждое сообщение как Команду (см. CQRS).Вы можете предварительно проанализировать номер версии в сообщении и иметь CommandHandler для каждой версии.

Это не относится к функциям.Вот совет, связанный с функциями.Держите одну функцию.В процессе управления версиями будет проще отлаживать и находить, какие функции все еще работают или нет.

Answer 2

Можно использовать разные классы в функции.

Чтобы функция отвечала только за определенный процесс, вы можете разделить ее на две функции и иметь Подписки на разделы служебной шины вместо очередей хранения.Это обеспечит надежность реализации, так как Service Bus обладает широким набором функций по сравнению с очередями хранения.

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