Является ли Async Messaging (в частности, паб / подстайл) жизнеспособным в качестве архитектуры доменного сервиса или только в среде, ориентированной на SOA?

Question

Я исследовал асинхронный обмен сообщениями, и мне нравится, как он элегантно решает некоторые проблемы в определенных доменах и как он делает концепции доменов более явными. Но является ли это жизнеспособным шаблоном для общей управляемой доменом разработки (по крайней мере, на уровне сервисов / приложений / контроллеров) или затраты на разработку таковы, что они должны быть ограничены сценариями на основе SOA, такими как удаленные сервисы и распределенная обработка?

Answer 1

Отличный вопрос :). Основная проблема с асинхронным обменом сообщениями заключается в том, что когда люди используют процедурные или объектно-ориентированные языки, работа в асинхронном режиме или на основе событий часто бывает довольно сложной и сложной, и программисту трудно ее прочитать и понять. Бизнес-логика часто намного проще, если она построена своего рода синхронным способом - вызывая методы и немедленно получая результаты и т. Д.).

Мое эмпирическое правило, как правило, состоит в том, чтобы попытаться использовать более простые модели синхронного программирования на микроуровне для бизнес-логики; затем используйте асинхронность и SEDA на макроуровне.

Например, отправка заказа на покупку может просто записать сообщение в очередь сообщений; но обработка заказа на поставку может потребовать 10 различных этапов, причем все они асинхронны и параллельны в высокопроизводительной распределенной системе со многими параллельными процессами и потоками, обрабатывающими отдельные этапы параллельно. Таким образом, проводка на макроуровне основана на подходе SEDA, но на микроуровне код для отдельных 10 шагов может быть написан в основном в стиле синхронного программирования.

Answer 2

Как и многие другие вопросы архитектуры и дизайна, ответ «все зависит».

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

• Время - запросы могут обрабатываться асинхронно, что способствует общей масштабируемости.
• Пробел. Как вы указали, распределенная обработка более надежна, чем во многих синхронных проектах.
• Технология. Сообщения и очереди являются одним из способов преодоления технологических различий.

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

Answer 3

Я тоже согласен с @BradS BTW

BTW - это способ скрыть промежуточное ПО от вашей бизнес-логики , в то же время получая преимущества слабой связи и SEDA - при возможности простого переключения между различными технологиями промежуточного ПО - из памяти SEDA из JMS в AMQP в JavaSpaces в базу данных, файлы или FTP и т. д.