Проверка функциональности RabbitMQ Architecture

Question

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

Таким образом, сообщение отправляется на обмен и распадается на три очереди.

Полезные данные всегда JSON text.

Потребителями являются долгосрочные windows службы, единственной задачей которых является сидеть и слушать сообщения, предназначенные для их конкретного приложения. Когда приходит сообщение, они смотрят на заголовок, чтобы определить, как эта полезная нагрузка JSON должно быть интерпретировано и в какую конечную точку REST оно должно быть отправлено. например, «Когда я вижу заголовок 'WORK_ORDER_COMPLETE', я собираюсь проанализировать его как WorkOrderCompleteDto и отправить его как POST методу CompletedWorkOrder WebAPI на timelabor-api.mycompany.com. Если API возвращает значение, отличное от 200, я отклоняю сообщение и пусть кролик обработает его. Если я получу 200 обратно от API, я получу сообщение для кролика. "

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

Это каким-либо образом дает разумное понимание правильного способа использования Кролика?

Answer 1

Концептуально, я полагаю, что вы, возможно, полагаетесь на RabbitMQ, чтобы делать то, что нужно вашему приложению.

Предполагается, что архитектура предполагает, что каждое сообщение обрабатывается каждым из ваших приложений-потребителей полностью в вакуум. Это означает, что вам все равно, что сообщение, успешно обработанное Billing_App, в итоге завершилось неудачей с Inventory_App. Может быть, это и так, но, по моему опыту, это не так.

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

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