Хорошо, я относительно новичок в сервисной шине. Работаем над проектом, в котором мы используем Azure servicebus для очередей сообщений. Наша архитектура примерно выглядит следующим образом:
Таким образом, идея заключается в том, что в нашей SourceSystem происходят все виды вещей, что приводит к тому, что сообщения помещаются на сервисбустопик. Теперь мы несем ответственность за синхронизацию этих событий с внешним клиентом, чтобы они знали о том, что мы делаем.
Теперь проблема в том, что в настоящее время мы не используем сеансы служебной шины, поэтому порядок сообщений не гарантируется. Также рассмотрим следующий сценарий:
OrderCreated OrderUpdate 1 OrderUpdate 2 OrderClosed
Что происходит сейчас, если API externalclients не работает, скажем, для OrderUpdate 1 и OrderUpdate 2, мы могли бы потенциально отправлять сообщения в порядке : OrderCreated, OrderClosed, OrderUpdate 1, OrderUpdate 2.
В настоящее время мы просто повторяем сообщение несколько раз, а затем оно перемещается в очередь deadletter для ручной обработки.
Какие шаги следует предпринять для лучше гарантийный порядок сообщений? Я чувствую, что в объеме заказа порядок сообщений должен быть гарантирован.
Должны ли мы заставить исходную систему помещать все сообщения для заказа в сеанс служебной шины? Но как мы можем справиться с этим с несколькими темами? И что нам делать, если сообщение 1 из сеанса попадает в тупик?
Здесь много соображений, следует ли нам использовать одну топи c, чтобы было проще управлять сеансами? Но это открывает другие проблемы с различными структурами сообщений, находящимися в одной топи c?
Мне бы очень хотелось услышать ваше мнение по этому поводу