когда обмен сообщениями (брокеры / очереди на основе JMS) является излишним?

Question

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

Answer 1

Это все вопрос масштаба.

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

Если у вас есть несколько служб, работающих на нескольких серверах (и, возможно, на нескольких центрах обработки данных), которым необходимо взаимодействовать друг с другом (а не только с базой данных), обмен сообщениями становится необходимым.

Другой случай, когда ваши сервисы имеют разные графики выпуска, особенно когда их много, и они разрабатываются разными командами. Наступает момент, когда синхронизация выпусков для обеспечения совместимости и минимизации простоев становится настоящим бременем. Асинхронный обмен сообщениями является частью решения.

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