使用Glassfish在亚马逊AWS上集群无状态Java EE应用程序

Question

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

具体来说，我想了解以下内容：

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

我打算使用Amazon AWS（具有多可用区部署，弹性负载平衡，EC2的RDS）。

Answer 1

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

回复1）我需要Glassfish的3.1的集群功能

由于您的EJB是无状态的，你不需要对会话/状态复制的GF集群（像你说的你自己）。您可以设置多个独立实例并分别将它们部署到它们。但是，即使在无国籍的应用程序中，从行政角度来看，我发现GF集群的好处非常值得。

GF集群将确保配置自动应用于所有实例。 JNDI被自动复制。应用程序自动部署。这是一个扩展并添加额外实例的单个命令 - 稍后，您的群集将进行扩展，并且新实例将被配置，部署，启动并准备就绪。对我来说，只要我有超过1个实例，那就是行政天堂和足够使用GF集群的理由！

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

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

不知道我理解你的问题...如果你想在GF之外有一个高可用的消息代理，你需要相应地设置它并自己管理它。例如，ActiveMQ有几种设置集群/ HA /扩展的方法。如果您使用GF提供的OpenMQ，则设置GF群集还会提供群集消息代理。盒子外面。

但是，经纪人集群本身就是一个话题，不容低估。您可能需要考虑持久性和共享消息存储等，而不管使用外部还是GF提供的集群代理。

如果JMS是您的应用程序的一个组成部分，我建议适当注意经纪人。我可能不会使用GF经纪人，而是有一个独立的经纪人集群（关注点分离;例如，您可以相互独立地升级GF /经纪人）。

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

如果您需要计时器到组的自动闪光一次（appserver-）的情况下，我相信你做需要GF集群（加场的共享DB）。否则，我不明白，每个实例应该知道它是否应该触发。但是，这很容易测试...

TL;博士

• 使用GF集群对管理工作
• 使用一个外部的，易于理解的高可用消息代理
• 使用共享的数据库保存您的EJB计时器

Answer 2

我在你的各点的角度：

1）会话复制的集群管理功能，它不是建立集群服务器环境的目标的一部分。你走出集群的好处是：

• 提高了可扩展
• 更高的可用性
• 更大的灵活性集群 副作用是加大对基础设施的复杂性，额外的设计和规范要求等，所以，如果你是考虑集群，那么你的决定应该由诸如你希望应用程序的可扩展性，可用性和灵活性等因素驱动。

2）您可以使用Apache ActiveMQ与您glassfish服务器，使您的JMS的东西在集群环境中工作。

3）我想共享DB应该足够

Answer 3

你可能会需要一个工业级EJB框架，如果你真的想你的应用程序流畅运行....但是，你肯定不会仅仅局限于GlassFish的。重要的是要记住的是，EJB是一个规范，不一定局限于任何一种实现！

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

不，你没有定义。如果你的应用程序是无状态的，Glassfish将不是必需的。

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

JBoss是这里的一个选项。我的JBOSS集群服务只需重新选择新的主节点即可在发生故障时管理消息传递，因此可用性得到了保证。

3）我也在使用EJB计时器服务。这在集群环境中如何工作？除了使用 共享数据库来存储计时器（而不是嵌入式Derby数据库）之外，还有什么需要做的吗？

如果您使用weblogic或Jboss ejb实现，时间安排可以透明聚类。在这种情况下，我不认为你需要嵌入式数据库：框架可以直接处理：。