我对 Java EE 比较陌生，并且已经开始听说可以集群的许多不同类型的系统：
维基百科将“聚类”定义为：
计算机集群由一组松散连接的计算机组成，它们一起工作，因此在许多方面它们可以被视为一个单一的系统。
我想知道对于这些“集群类型/方法”（如上所述）中的每一个，集群是如何工作的，以及它们如何相互关联。
例如，如果一个人可以从集群应用程序中受益，他/她可能会将它们放在集群应用程序服务器上，然后将集群管理器投入其中（再次，如 Terracotta）。
但是因为“聚类”这个短语似乎以模糊/模棱两可的方式使用，我没有看到这些中的每一个是如何与其他的联系在一起的，或者如果他们甚至这样做。在此先感谢任何勇敢的 StackOverflowers，他们可以帮助我理解这个相互交织的术语！
对我来说，集群意味着系统的许多品质，但归结为容错能力——服务器、网络和数据持久性。有松散耦合和紧密耦合的系统，以及介于两者之间的所有类型。紧耦合系统在接近硬件的级别上执行集群。许多旧的集群系统与应用程序更紧密地耦合在一起，通常无法识别它们是集群的。
如今，松散耦合系统已成为常态，完全在软件级别实现了很大程度的容错。集群中的系统仅共享网络连接以实现容错。通常有一些专门的负载平衡器使用专门的硬件（有时只是软件）将请求路由到各种集群服务器来完成此任务。
您提到的所有示例都有某种“聚类”。描述每个架构如何实现这一点的细节需要很长的答案。对我来说，不同之处在于当您使用该架构时“免费”提供什么，以及您需要做多少工作才能使其以最佳方式工作。
您如何混合和匹配您提到的解决方案取决于您的架构是什么样的以及您的要求。您可以拥有一个 Terracotta 存储用于本地高速持久性，而云存储用于其余的。您可以使用 Glassfish 作为您的应用程序服务器，并使用 Terracotta 作为您的持久层。
以下是我对您列出的技术的看法：
云应用程序显然是最容易使用的。从架构的角度来看，您唯一的工作就是选择一个好的集群提供商。当然，亚马逊和谷歌在容错和数据完整性方面会做得“正确”。还有许多其他玩家可能做得“足够好”并且更便宜。您对他们的 API 进行编程，这些 API 带有自己的一组限制和费用。云应用程序的一个问题是，很可能很难切换到新的应用程序。同样，您的应用程序的某些 [大部分] 可能在云服务器上运行，并且有一些本地系统来满足您更高的延迟要求。趋势是将大多数生产功能放在云中，或者至少以这种方式开始，直到您变得太大或需要一些他们无法提供的服务。
这 3 个系统提供了自己的集群功能。他们可能需要您进行大量机器和服务层配置，以使系统在生产环境中运行良好。我听说 Terracotta 是一个分布式持久层的好消息。我已经使用了很多 Jboss 下的 Jgroups，要正确运行可能会很棘手，但 Jboss 也可能有一些很好的默认配置/文档。Oracle 很可能是最难正确集群的。DBA 通过调整 Oracle 配置赚了很多钱。
这些是在聚类方面定义的最无定形的。一些虚拟机被认为是“集群的”，因为它们共享网络硬件和电源背板，但与云计算相比确实不是集群。如前所述，有一些非常定制的集群硬件解决方案，需要大量特定领域的知识才能正常运行。
我对 Tomcat 和 Glassfish 等应用服务器的经验很少。我们在 Jgroups 之上拥有自己的集群软件并完全运行 Jetty。应用程序服务器本身不是“集群”的，但 Jboss 和 Terracotta 等软件包在它们之上运行以提供集群，并且它们具有为它们编写的集群软件的内部项目。
希望有些帮助。
这是一个快速的打击。你如何集群取决于你的目标是什么。以下是与 GlassFish 相关的一些想法。