在 Amazon AWS 上使用 Glassfish 将无状态 Java EE 应用程序群集

我处于类似的情况，我目前正在发现GF聚类可以为我做什么/不能做什么。

Re 1） 我是否需要 Glassfish 3.1 的集群功能

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

GF 集群将确保配置自动应用于所有实例。JNDI 是自动复制的。应用程序是自动部署的。只需一个命令即可横向扩展并添加其他实例 - 不久之后，您的集群将得到扩展，新实例将配置、部署、启动并准备就绪。对我来说，这是管理天堂，也是每当我拥有超过1个实例时使用GF集群的理由！

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

Re 2） ...如何设置 JMS 以使其在集群环境中工作？

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

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

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

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

如果您需要计时器在（应用程序服务器）实例组中仅自动触发一次，我相信您确实需要 GF 集群（当然还有共享数据库）。否则，我不明白，每个实例应该如何知道它是否应该触发。但是，这很容易测试...

tl;博士

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

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

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

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

2）您可以将Apache ActiveMQ与玻璃鱼服务器一起使用，以使JMS在集群环境中工作。

3）我认为共享数据库应该足够了