Мне нужно создать что-то в Azure, которое может обрабатывать входящие потоки сообщений для набора сущностей.У нас будет от 20 до 2000 организаций в любой момент времени;они создаются и удаляются динамически.Сообщения будут создаваться с использованием нашей локальной системы и отправляться в Azure с использованием какого-либо механизма очередей.Каждое сообщение будет связано с конкретной сущностью через свойство EntityId.Сообщения, принадлежащие одному и тому же объекту, должны обрабатываться по порядку относительно друг друга.
В то же время решение должно быть масштабируемым по отношению к сущностям.Если бы у меня были устойчивые потоки сообщений для 1000 объектов, я бы хотел иметь 1000 одновременных исполнений моей логики.Если объекту требуется много времени для обработки одного из его сообщений, он не должен блокировать обработку других сообщений от .Для обработки каждого сообщения может потребоваться от 100 мс до 10 с (подавляющее большинство менее 1 с), и каждая сущность будет получать в среднем по одному сообщению в секунду.
К сожалению, в бессерверном стеке Azure, похоже, нет никаких средств.достижения этого.Вот варианты, которые я рассмотрел, и их проблемы:
Функции Azure, запускаемые очередью служебной шины с сеансами.Функции Azure можно запускать как бессерверные в плане потребления, что делает их идеальными для гибкого масштабирования.Сеансы служебной шины обеспечивают доставку по заказу и являются наиболее близкой реализацией моих требований.Однако они не поддерживаются в функциях Azure: очереди службы поддержки и темы, использующие сеансы .
приложения логики, запускаемые очередью шины обслуживания с сеансами: этоподдерживается "из коробки" с помощью шаблона " Коррелированная доставка по заказу с использованием сеансов служебной шины ".Приложение логики затем может подключиться к функции Azure, запускаемой по протоколу HTTP, для обработки сообщений.Единственная цель приложения логики - предотвратить одновременную обработку нескольких сообщений, принадлежащих одному объекту / сеансу.Однако из комментариев к моему прежнему вопросу я обнаружил, что это также не будет масштабируемым.Приложение логики может выполнять только 300 000 действий за 5 минут, имеет предел параллелизма триггера, равный 50, и считается дорогостоящим.См. Ограничения и сведения о конфигурации для приложений логики Azure .
Концентраторы событий Azure с разделами, как описано в В обработке событий заказа с помощью функций Azure ,Это, как правило, самый популярный вариант, рекомендованный Microsoft.Однако концентраторы событий позволяют использовать до 32 разделов, причем при создании необходимо указать количество разделов: Функции и терминология в концентраторах событий Azure .Это ограничение фиксированного статического набора разделов идет вразрез с духом «без сервера»;если мы ограничиваем степень параллелизма до 32, то мы не получим лучшей масштабируемости, чем параллельное приложение, работающее на 32-ядерном компьютере.Предел раздела может быть увеличен до 32 с помощью заявки в службу поддержки Microsoft, но я не хотел бы просить о масштабируемости, которая на два порядка превышает возможности, доступные для общего пользования.В концентраторах событий также отсутствуют некоторые другие базовые свойства, такие как доставка не более одного раза.
Мы можем динамически создавать очередь служебной шины для каждой сущности и иметь для нее единственную функцию Azure.привязанный исключительно к этой конкретной очереди.Однако это повлечет за собой вызов API-интерфейсов управления ресурсами Azure как части нашего операционного кода, и у меня сложилось впечатление, что функции Azure не были разработаны для динамического создания таким образом.
Оптимистический контроль параллелизма для постоянного хранилища резервных копий, такого как Redis, с использованием свойства SequenceNumber сообщений очереди служебной шины для упорядочения.Тем не менее, модель программирования для этого достаточно сложна и ее легко ошибиться - операции должны выполняться в циклах повторов с учетом явного внимания к атомарности и идемпотентности каждый раз.Кроме того, требуется, чтобы все сообщения содержали полное состояние объекта;в противном случае информация будет потеряна, если мы отбросим устаревшие сообщения в случае гонок.Нам было бы дорого (с точки зрения вычислений и пропускной способности) отправлять полный снимок объекта с каждым добавочным изменением, поэтому мы бы предпочли найти средство, которое позволило бы нам обрабатывать добавочные сообщения по порядку.
Есть ли какой-нибудь чистый способ достижения обработки по порядку для масштабируемого числа объектов в стеке Azure без сервера?