云是不是为企业 Java Web 应用程序做好了准备？寻求 Java EE 托管建议 [关闭]

Posted 2023-03-04

【中文标题】云是不是为企业 Java Web 应用程序做好了准备？寻求 Java EE 托管建议 [关闭]

【英文标题】：Is the Cloud ready for an Enterprise Java web application? Seeking a Java EE hosting advice [closed]云是否为企业 Java Web 应用程序做好了准备？寻求 Java EE 托管建议 [关闭]

【发布时间】：2011-02-07 22:43:00

【问题描述】：

向这里所有的聪明人问好！

我想问一下，将 Java 企业 Web 应用程序部署到 Amazon EC2 等云中是否可行或是否是个好主意。更准确地说，我正在寻找一个应用程序的基础设施选项，该应用程序应处理数百个用户，但既不是 CPU 也不是内存密集型会话。我正在考虑专用服务器、虚拟专用服务器 (VPS) 和 EC2。我注意到有一个名为 JBoss Cloud 的项目，所以人们正在努力实现这样的部署，另一方面，它似乎还不成熟，我不确定云是否已经为这种部署做好了准备应用程序，这与 Twitter 等典型的基于云的应用程序不同。您会建议将其部署到云端吗？有什么好处和坏处？

该应用程序是一个 Java EE 5 Web 应用程序，其主要功能是使用户能够通过组合可用的部件来组成自己的定制产品。它使用无状态和有状态会话 bean 和 JPA 将实体持久化到 RDBMS，并通过 Web 服务从公司的库存系统中获取有关零件的信息。除了外部用户之外，它还被少数内部用户使用，他们通过公司的 LDAP 进行身份验证。该应用程序应该处理大约 300-400 个并发用户来构建他们的产品，并且应该具有合理的可扩展性和可用性，尽管这些品质在现阶段仅具有中等重要性。

我提出了一个由防火墙 (FW) 和支持粘性会话和 https 的负载均衡器组成的架构（在云中，这将被 EC2 的 Elastic Load Balancing 服务和应用程序服务器上的 FW 取代，在物理架构中）负载平衡器将是一个硬件），然后是两个物理集群应用程序服务器与 Web 服务器相结合（这样如果一个失败，用户不会丢失他/她长期构建的产品），最后是一个数据库服务器。数据库服务器需要一个从属备份实例，如果主实例发生故障，它可以替换它。这应该提供合理的可用性和容错性，并提供良好的可伸缩性，只要单个 RDBMS 可以保持负载，这应该可以持续一段时间，因为大多数操作都是使用有状态 bean 在内存中完成的，并且只是偶尔存储或从数据库中检索，数据量也很低。一个有问题的部分可能是对远程库存系统 web 服务的依赖，但如果在应用程序中对其输出进行了良好的缓存，它也应该没问题。

不幸的是，对于数百个用户所需的这种“普通 Java EE 应用程序”所需的系统资源（内存大小、CPU/内核的数量和速度），我只有模糊的概念。根据亚马逊的实际产品，我粗略且几乎没有根据的估计是，1.7GB 和一个速度约为 2.5GHz（高 CPU 中型实例）的单个 2 核“现代 CPU”对于两个应用程序服务器中的任何一个都应该足够了（因为我们可以通过配置更多负载来处理更高的负载）。或者，我会考虑使用大型实例（64b，7.5GB RAM，2 个 1GHz 核心）

所以我的问题是，这样的云部署在技术上和财务上是否可行，或者专用/VPS 服务器是否是更好的选择，以及是否有一些类似的实际经验。

非常感谢！ /Jakub 圣洁

PS：我发现 JBoss EAP in a Cloud Case Study 表明可以将真实世界的 Java EE 应用程序部署到 EC2 云，但遗憾的是没有关于拓扑、实例类型或任何内容的详细信息 :-(

【问题讨论】：

这将更适合 Serverfault.com

谢谢，Michael，我不知道这个服务器。我已将问题转发到 Serverfault.com - serverfault.com/questions/132325/…

【参考方案1】：

我正在通过一个 EC2 高 CPU 中型实例为“几百个用户”提供服务。没有负载平衡，没有专用的数据库服务器，没有什么花哨的。只是一个盒子。此外，我正在使用一些服务：

Elastic Block Store 用于 mysql 数据、MySQL 二进制日志和 Lucene 索引 S3 用于资源和备份存储，显然每个篮子不同 SimpleDB 资源元数据 CloudFront 资源 - 主要是因为我们可以:) Simple Queue Service 用于消息传递（用于排队一些后台任务）

正如我所说，没什么特别的 - 至少在亚马逊的云环境中。一切都低于 200 美元/月。关于定价，你应该小心。亚马逊在混淆主要成本方面做得很好。例如，查看 CloudFront 定价，您可能会看到每 GB 0.15 美元，但忽略每 10,000 美元 0.01 美元 - 对于很多请求来说，这是一个非常低的价格，不是吗？大惊喜：我们的 CloudFront 成本的 2/3 用于请求（每个请求大约 3 KB）。 EBS 的 I/O 请求是一个类似的故事。

因为它非常容易扩展（使用更大的实例，在Relational Database Service 上移动数据库）我建议您从相同的设置开始。正如您所说，投入更多的盒子非常简单（假设您的设置支持动态添加/删除节点）。这使得通过反复试验选择适当的设置变得很容易 - 一些彻底的负载测试应该可以完成这项工作。选择适合您预期负载的东西（加上一些额外的功率），并在获得生产数据后立即增长/缩小。

作为结论：是的，当然可以在 EC2 上托管 Java EE 应用程序 :)

编辑：附带说明：比较 EC2 与传统托管的定价是比较苹果和橘子 - 至少只要您没有为您的网络获得 SLA，几乎无限的可扩展性，没有硬件问题，几乎无限和冗余存储、不同的可用区和一堆额外的服务。如果有人告诉您传统托管更便宜，那么他可能是一名系统管理员，担心自己的工作；）不要误会我的意思，它更便宜 - 但您花更少的钱得到的东西要少得多。

顺便说一句，我与亚马逊没有任何关系......但我觉得我应该因为成为一名优秀的代言人而受到奖励，不是吗？ :D

【讨论】：

非常感谢您的宝贵见解以及关于定价的附注！你帮了我很多。

@Jakub 我很高兴能帮上忙。另一件事是：一旦您开始使用 Amazon 的云服务，在许多情况下就非常想投入 EC2、S3 等——仅仅因为您可以。所以另一个很可能会开始增加成本的风险;)

还有一件事：如果您的服务不需要 100% 正常运行时间，您可能会从现场实例中受益。您通常支付与预留实例类似的小时费用，但无需支付首期费用 - 您应该能够处理（主要是理论上的）停机风险。它非常适合将任务提交到 SQS 队列的后台处理（例如数字运算）。我们将结果发布到 S3 并使用 XMPP PubSub 通知订阅者（不过我们正在考虑迁移到 SNS）。真的很酷的东西:)

关于使用更多服务的诱惑，我希望 - 这正是亚马逊想要的 :-) 正如你所指出的，他们擅长隐藏成本，因此必须小心。

@shadesco 是的，你可以安装任何东西