Terracotta делает JMS ненужным слоем?

Question

В настоящее время мы пишем приложение, для которого ИТ-отдел уже приобрел оборудование. Их подход состоял в том, чтобы купить большое оборудование, на котором мы будем развертывать. Чтобы добавить больше обработки, они планируют добавить дополнительные серверы с идентичным программным обеспечением. Чтобы приспособить этот дизайн, мы используем Terracotta, чтобы обеспечить возможность запуска нескольких JVM, как если бы это была одна большая. Независимо от того, является ли это мудрым путем (в котором я до сих пор не убежден), с этой ситуацией я сталкиваюсь.

В любом случае, у нас есть часть приложения, которая использует стандартную очередь типа производитель / потребитель. С помощью Terracotta мы можем создать одну очередь, которая работает с несколькими JVM. Это довольно гладко и хорошо работает.

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

Есть предложения или мысли? Должны ли мы просто продолжать строить очереди как параллельные структуры или рассматривать их как отдельные, потенциально удаленные объекты?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

Мой коллега использовал Mule , что позволяет вам определять очереди, которые могут быть внутри- или между JVM-очередями.

Я согласен с krosenwald : неясно, что JMS добавит в вашем случае, если нет общего плана либо отойти от Терракоты (или, по крайней мере, иметь возможность).