Минималистская схема обработки транзакций

На схеме показано, как пользователь системы Андромеды, который хочет получить авторизацию, отправляет транзакцию авторизации поездки в систему Млечный Путь. Брокер сообщений в этом дизайне является каналом для связи между двумя платформами.

Зачем использовать брокер сообщений?

  • Для повышения стабильности. Например, если пользователь в Андромеде хотел отправить транзакцию, а Млечный Путь недоступен, Андромеда сгенерирует исключение; это вызывает конструктивную проблему, называемую сцеплением. Поначалу это кажется довольно управляемым, но чем больше систем Андромеда интегрирует, тем больше и сложнее будет становиться проблема. Например, если Млечный Путь не работает 3 часа, Андромеда будет недоступна в течение того же времени.
  • Для повышения производительности. Без брокера сообщений Андромеде приходится ждать, пока Млечный Путь выполнит каждую транзакцию. Однако система Млечного Пути иногда работает медленнее, чем обычно. Это препятствие заставляет пользователей Andromeda полагать, что их платформа работает медленно, хотя на самом деле задержку вызывает другая зависимость.

Как работает брокер сообщений в этой схеме?

Чтобы объяснить схему, давайте предположим следующую последовательность:

  1. Клиент (инопланетянин) начинает транзакцию. В этом примере пользователь пытается создать клиента. Процесс начинается через форму в исходной системе
  2. Исходная система создает сообщение запроса с полями для целевой системы для создания нового клиента.
  3. Запрос отправляется менеджеру транзакций. Он отвечает за перемещение сообщения из исходной системы в раздел служебной шины. Кроме того, он создаст идентификатор корреляции и сохранит его в системной таблице. На этом шаге сообщение настраивается для отправки подтверждения чтения в определенную очередь.
  4. Менеджер транзакций добавляет сообщение в тему. Одна из причин использования тем вместо очередей — разрешить более одного подписчика. Это обеспечивает гибкость использования нескольких считывателей и предоставляет будущим клиентам возможность получать сообщения одного и того же типа.
  5. Когда целевая система прочитает сообщение, служебная шина Azure отправит уведомление в раздел результатов транзакции. Таким образом, источник получает уведомление о том, что система назначения получила сообщение.
  6. Целевая система, использующая зеркальную реализацию диспетчера транзакций в исходной системе, примет сообщение и отправит его в сообщение обработчику транзакций. Процессор транзакций — это прослушиватель событий в целевой системе, который идентифицирует конкретную логику, подлежащую выполнению, в зависимости от типа сообщения.
  7. Как только процессор транзакций обработал запрос, он генерирует ответное сообщение. По умолчанию ответом является только подтверждение, то есть простое пустое сообщение. Однако оно может содержать дополнительные значения.
    Следуя той же логике, исходная система выберет ответное сообщение и с помощью обработчика транзакций выполнит необходимые действия.
  8. Теперь эта последовательность не всегда работает, иногда система назначения читает сообщение, но никогда не отправляет ответ. В этом случае приложение-функция отслеживает исходную и целевую темы, а затем, используя таблицу конфигурации, отправляет сообщение для темы предупреждения о транзакции.

Предоставленная схема является основой, которую может потребоваться изменить в зависимости от потребностей бизнеса. Тем не менее, он представляет собой основу для начала разговора.