Извините, если это длинный и / или открытый конец ... в лазурной гамме так много вариантов, что я изо всех сил пытаюсь выбрать, какие части использовать, и я надеюсь, что кто-то может помочь указать путь.
Я пытаюсь что-то построить, как описано на изображении ниже. Я как бы «маршрутизирую» сообщения от темы мультитенантной служебной шины (верхняя часть диаграммы) к конкретным конечным точкам REST арендатора (нижняя часть диаграммы).
Самое сложное, с чем я сталкиваюсь, - это иметьсвоего рода концепция функции с динамическими триггерами очереди / события, которые меняются со временем, но я ищу совет по любым частям решения.
У меня есть 4 ограничения:
- Эти сообщения ДОЛЖНЫ в конечном итоге достигать соответствующей конечной точки отдыха
- Эти узлы конечной точки REST добавляются и удаляются динамически, но я знаю,(через сообщение сетки событий), когда это происходит.
- Эти конечные узлы REST также могут быть отключены в любое время или на длительные периоды времени (дни), и в конечном итоге все сообщения должны быть доставлены
У меня есть в основном рабочее решение для F1 , но я ищу лучшие идеи, но на самом деле это F2 , с которым я борюсь.
F1 CurrСобственно, у меня есть:
- 1 очередь на сервер клиента, созданная / удаленная на основе сообщения сетки событий
- Функция Azure, которая может возвращать имя очереди на основе содержимого сообщения служебной шины
- Логическое приложение (WIP), которое забирает сообщения из тематической подписки, использует функцию, чтобы определить имя очереди назначения, добавить URI webhook в свойства сообщения и переслать сообщение в эту очередь.
Я думаю, что F1 в конечном итоге будет работать правильно: D ... но f2 ..
F2
Это сложная часть, теперьУ меня есть N очередей, которые приходят и уходят со временем. Я не могу понять, как прослушивать все очереди с помощью 1-й функции, поэтому я подумываю попытаться снова развернуть 1-ю функцию для каждой очереди. Он будет отвечать за вытягивание сообщений из очереди и отправку на URI webhook REST.
Но тогда, когда остальная конечная точка не работает, она должна приостановить работу, а не опустошить очередь, также не уверенная в том, как это сделать эффективно. , может быть, другое приложение логики с опросом?
Я думаю, возможно, использовать сетку событий вместо очередей, потому что я думаю, что они в целом имеют больше поддержки без сервера, но я не уверен, что это также решит проблему.
Ценю любые мысли