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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

Кстати, я тоже согласен с @BradS

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