为了实现高可用性和可扩展性，在分布式环境中部署无状态 Java EE 6 应用程序的最佳方法是什么？我的应用程序是无状态的。因此，我不需要复制任何会话状态（HTTP会话，EJB有状态Bean等）。
具体来说，我想知道以下内容：
我计划使用 Amazon AWS （RDS 与多可用区部署、弹性负载均衡、EC2）。
我处于类似的情况，我目前正在发现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;博士
我对你们各自观点的看法：
1）会话复制是集群管理的一部分，它不是创建集群服务器环境的目标。从群集中获得的好处是：
2）您可以将Apache ActiveMQ与玻璃鱼服务器一起使用，以使JMS在集群环境中工作。
3）我认为共享数据库应该足够了
