在 Amazon AWS 上使用 Glassfish 对无状态 Java EE 应用程序进行集群答案

【问题标题】：Clustering a stateless Java EE application with Glassfish on Amazon AWS在 Amazon AWS 上使用 Glassfish 对无状态 Java EE 应用程序进行集群
【发布时间】：2012-01-01 08:33:42
【问题描述】：

在分布式环境中部署无状态 Java EE 6 应用程序以实现高可用性和可扩展性的最佳方式是什么？我的应用程序是无状态的。因此，我不需要复制任何会话状态（HTTP 会话、EJB 有状态 bean 等）

具体来说，我想知道以下几点：

我是否需要 Glassfish 3.1 的集群功能（假设我不需要复制会话状态）？
我大量使用 JMS 队列和消息驱动 Bean。如何设置 JMS 以使其在集群环境中工作？
我也在使用 EJB 计时器服务。这在集群环境中如何工作？除了使用共享数据库来存储计时器（而不是嵌入式 Derby 数据库）之外，我还需要做些什么吗？

我计划使用 Amazon AWS（具有多可用区部署的 RDS、弹性负载均衡、EC2）。

【问题讨论】：

如果您发布 3 个单独的问题，您的运气可能会更好。

标签： java jakarta-ee glassfish amazon-web-services jms

【解决方案1】：

我处于类似情况，我目前正在研究 GF 集群可以/不能为我做什么。

Re 1) 我需要 Glassfish 3.1 的聚类功能吗

由于您的 EJB 是无状态的，因此您不需要 GF 集群来进行会话/状态复制（正如您自己所说的那样）。您可以设置多个独立实例并将您的应用程序单独部署到它们。但是，即使在无状态应用程序中，我发现 GF 集群的好处非常值得 - 从管理的角度来看。

GF 集群将确保配置自动应用于所有实例。 JNDI 会自动复制。应用程序是自动部署的。这是扩展和添加额外实例的单个命令 - 不久之后，您的集群被扩展并且新实例被配置、部署、启动并准备就绪。对我来说，这就是管理天堂，有足够的理由在我拥有超过 1 个实例时使用 GF 集群！

需要考虑的一件事（我目前正为此苦苦挣扎）可能是分布式/协调的 L2 缓存，以防您的应用程序正在与数据库通信。

关于 2) ... 如何设置 JMS 以使其在集群环境中工作？

不确定我是否理解您的问题...如果您想在 GF 之外拥有高可用性消息代理，您需要相应地进行设置并自行管理。例如，ActiveMQ 有几种设置集群/HA/横向扩展的方法。如果你使用 GF 提供的 OpenMQ，设置一个 GF-cluster 也提供了一个集群消息代理。开箱即用。

但是代理集群本身就是一个主题，不容小觑。您可能需要考虑持久性和共享消息存储等 - 无论使用外部代理还是 GF 提供和集群的代理。

如果 JMS 是您的应用程序不可或缺的一部分，我建议适当注意代理。我可能不会使用 GF-broker，而是有一个单独的 broker-cluster（关注点分离；例如，您可以独立升级 GF/broker）。

Re 3) EJB 计时器服务...除了使用共享数据库来存储计时器之外，我还需要做些什么吗？

如果您需要计时器在您的 (appserver-) 实例组中只自动触发一次，我相信您确实需要 GF 集群（当然还有共享数据库）。否则我看不到每个实例应该如何知道它是否应该触发。但是，这很容易测试...

tl;dr

使用 GF 集群来节省管理工作
使用外部的、易于理解的高可用性消息代理
为您的 EJB 计时器使用共享数据库

【讨论】：

非常感谢。完全同意集群 GF 实例的易于管理性。可能会和它一起去。我的应用程序也在与 MySQL 数据库通信，但到目前为止我们还没有考虑 L2 缓存。关于JMS broker，我会先内置OpenMQ，看看效果如何。
好汉克。但是你有没有关于 glassfish 不同实例之间的 L2 缓存同步的任何解决方案。

【解决方案2】：

我对你们各自观点的看法：

1) 会话复制是集群管理的一部分，它不是创建集群服务器环境的目标。您从集群中获得的好处是：

改进的可扩展性
更高的可用性
更大的灵活性集群的副作用是基础设施复杂性增加、额外的设计和代码要求等。因此，如果您正在考虑集群，那么您的决定应该由您希望应用程序的可扩展性、可用性和灵活性等因素驱动。李>

2) 您可以将 Apache ActiveMQ 与 glassfish 服务器一起使用，以使您的 JMS 事物在集群环境中工作。

3) 我认为共享数据库就足够了

【讨论】：

关于 1) 我了解集群为我带来了更高的可扩展性和更高的可用性。这就是我想做的原因。我的问题是我是否需要 Glassfish 集群功能或者是否足够 - 鉴于我的应用程序是无状态的 - 我只是使用共享数据库和负载平衡器设置多个无状态服务器。关于 2）它是否与 OpenMQ 一起使用，这是 Glassfish 中的标准 JMS 实现？
拥有多台机器可以解决硬件故障问题。采用水平集群的成本很高，但总是比垂直集群提供更好/可靠的性能 (publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/…)。

【解决方案3】：

如果您真的希望您的应用程序顺利运行，您可能需要一个工业级的 EJB 框架......但是，您当然不仅仅局限于 glassfish。要记住的重要一点是，EJB 是一种规范，不一定限于任何一种实现！

1) 我是否需要 Glassfish 3.1 的集群功能（假设我不需要复制会话状态）？

不，你绝对不。如果您的应用程序是无状态的，则不需要 Glassfish。

2) 我大量使用 JMS 队列和消息驱动 Bean。如何设置 JMS 以使其在集群环境中工作？

JBoss 是这里的一个选项。如果一个节点出现故障，JBOSS 集群服务只需重新选举新的主节点来管理消息传递，因此保证了可用性。

3) 我也在使用 EJB 计时器服务。这在集群环境中如何工作？除了使用用于存储计时器的共享数据库（而不是嵌入式 Derby 数据库）？

如果您使用 weblogic 或 Jboss ejb 实现，则可以透明地对时间进行集群。在这种情况下，我认为您不需要嵌入式数据库：框架可以直接处理：http://community.jboss.org/wiki/DeployingEJB3TimersInCluster。

【讨论】：