我们目前正在编写一个 IT 已经为其购买硬件的应用程序。他们的方法是购买我们将部署的大型硬件。为了增加更多的处理能力，他们计划添加具有相同软件的额外服务器。为了适应这种设计，我们使用 Terracotta 来提供运行多个 JVM 的能力，就好像它是一个大的一样。不管这是否是明智的选择（我仍然不相信），这就是我正在处理的情况。
无论如何，我们有一部分应用程序使用标准的生产者/消费者类型队列。使用 Terracotta，我们能够创建与多个 JVM 一起工作的单个队列。这很漂亮，而且效果很好。
但是现在，我们正在寻找更多的机会来运行异步进程。为了使我们所有的排队逻辑更加一致，我们正在考虑使用 JMS 来抽象出通用逻辑。由于我们不打算将 JMS 用作远程队列（至少在可预见的将来），我想知道 JMS 是否只是增加了不必要的复杂性。
有什么建议或想法吗？我们应该继续将队列构建为并发结构，还是将它们视为单独的、潜在的远程对象？
消息队列本质上只是具有一些花哨选项的队列数据结构。如果您的项目与大多数其他项目一样，那么您没有使用任何使 JMS 与任何旧Queue实现不同的 JMS 功能，特别是因为 Terracotta 正在处理持久性和分发。
所以 JMS 可能只是增加了应用程序的复杂性，而这正是 JMS 非常擅长的。像所有不必要的复杂性驱动因素一样，摆脱它。如果您出于一个或多个原因决定使用 JMS，那么就去做吧。
我的一位同事一直在使用Mule，它允许您定义可能是 JVM 内或 JVM 间队列的队列。
我同意krosenwald的观点：目前尚不清楚 JMS 会在您的情况下添加什么，除非有一个总体计划来远离 Terracotta（或者至少可以选择）。
我没有使用过 Terracotta，但我们使用的是与它非常相似的分布式缓存产品。我们的架构听起来也与您的架构相似。生产者和消费者都坐在同一个缓存上并使用缓存子系统共享数据。
虽然我原则上同意现在添加 JMS 对您来说可能是不必要的复杂性，但我们发现，虽然很巧妙，但分布式缓存并不是消息传递机制的最佳实现。虽然可以创建相同的语义，但一些小细节会导致问题（例如消费者的负载平衡，这可能需要与分布式缓存进行额外的同步，但可以自然地与 JMS 一起使用。）
如果您认为您未来的用例需要更多具有持久性等的 pub-sub 语义，您可能需要开始考虑 JMS。另外，考虑关注点分离。您正在使用 Terracotta 分发数据（这是它的设计目的）。您是否还会使用它来分发控制指令（使用消息语义做得更好）？