云是否准备好用于企业Java Web应用程序？寻求Java EE托管建议 [英] Is the Cloud ready for an Enterprise Java web application? Seeking a Java EE hosting advice

问题描述

向这里所有聪明的人致以问候！

Greetings to all the smart people around here!

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

I'd like to ask whether it is feasible or a good idea at all to deploy a Java enterprise web application to a Cloud such as Amazon EC2. More exactly, I'm looking for infrastructure options for an application that shall handle few hundred users with long but neither CPU nor memory intensive sessions. I'm considering dedicated servers, virtual private servers (VPSs) and EC2. I've noticed that there is a project called JBoss Cloud so people are working on enabling such a deployment, on the other hand it doesn't seem to be mature yet and I'm not sure that the cloud is ready for this kind of applications, which differs from the typical cloud-based applications like Twitter. Would you recommend to deploy it to the cloud? What are the pros and cons?

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

The application is a Java EE 5 web application whose main function is to enable users to compose their own customized Product by combining the available Parts. It uses stateless and stateful session beans and JPA for persistence of entities to a RDBMS and fetches information about Parts from the company's inventory system via a web service. Aside of external users it's used also by few internal ones, who are authenticated against the company's LDAP. The application should handle around 300-400 concurrent users building their product and should be reasonably scalable and available though these qualities are only of a medium importance at this stage.

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

I've proposed an architecture consisting of a firewall (FW) and load balancer supporting sticky sessions and https (in the Cloud this would be replaced with EC2's Elastic Load Balancing service and FW on the app. servers, in a physical architecture the load-balancer would be a HW), then two physical clustered application servers combined with web servers (so that if one fails, a user doesn't loose his/her long built product) and finally a database server. The DB server would need a slave backup instance that can replace the master instance if it fails. This should provide reasonable availability and fault tolerance and provide good scalability as long as a single RDBMS can keep with the load, which should be OK for quite a while because most of the operations are done in the memory using a stateful bean and only occasionally stored or retrieved from the DB and the amount of data is low too. A problematic part could be the dependency on the remote inventory system webservice but with good caching of its outputs in the application it should be OK too.

不幸的是，我只有模糊对几百个用户需要这样的平均Java EE应用程序的系统资源（内存大小，CPU /核心的数量和速度）的想法。我基于实际的亚马逊提供的粗略和毫无根据的估计是1.7GB和单核，2核现代CPU，速度大约2.5GHz（高CPU中实例）应该足够用于任何两个应用服务器因为我们可以通过提供更多的负载来处理更高的负载）。或者，我会考虑使用大实例（64b，7.5GB RAM，1GHz的2核）

Unfortunately I've only vague idea of the system resources (memory size, number and speed of CPUs/cores) that such an "average Java EE application" for few hundred users needs. My rough and mostly unfounded estimate based on actual Amazon offerings is that 1.7GB and a single, 2-core "modern CPU" with speed around 2.5GHz (the High-CPU Medium Instance) should be sufficient for any of the two application servers (since we can handle higher load by provisioning more of them). Alternatively I would consider using the Large instance (64b, 7.5GB RAM, 2 cores at 1GHz)

所以我的问题是这样的部署到云是技术和财务可行或是专用/ VPS服务器是否是更好的选择，以及是否有类似的现实世界体验。

So my question is whether such a deployment to the cloud is technically and financially feasible or whether dedicated/VPS servers would be a better option and whether there are some real-world experiences with something similar.

非常感谢！ / Jakub Holy

Thank you very much! /Jakub Holy

PS：我找到了 JBoss EAP在云案例研究中显示，可以将真实世界的Java EE应用程序部署到EC2云，但遗憾的是没有关于拓扑，实例类型或任何东西： - （

PS: I've found the JBoss EAP in a Cloud Case Study that shows that it is possible to deploy a real-world Java EE application to the EC2 cloud but unfortunately there're no details regarding topology, instance types, or anything :-(

推荐答案

我从单个EC2高CPU中此外，我使用一些服务：

I'm serving a "few hundred users" from a single EC2 High-CPU Medium instance. No load balancing, no dedicated DB servers, nothing fancy at all. Simply a single box. Additionally I'm using some services:

• Elastic Block Store for MySQL data, MySQL binlogs and Lucene indexes
• S3 for resource and backup storage, obviously different baskets for each
• SimpleDB Metadata for resources
• CloudFront for resources - mainly because we can :)
• Simple Queue Service for messaging (used to queue some background tasks)

正如我所说，没有什么想法 - 至少在亚马逊的云环境中。和一切少于200 $ /月。关于定价，你应该注意。亚马逊做了很好的工作，混淆主要成本。例如，查看CloudFront定价，您可能会看到每GB0.15 $，但忽略0,01 $每10,000 - 这是一个可笑的很小的价格为很多请求，不是吗？大惊喜：我们的CloudFront成本的2/3是针对请求（每个请求大约3 KB）。 I / O请求EBS是一个类似的故事。

As I said, nothing fancy - at least in Amazon's cloud environment. And everything for less than 200$/month. Regarding pricing, you should take care though. Amazon did a good job at obfuscating main costs. For example, looking at CloudFront Pricing, you might look at 0,15$ per GB but ignore 0,01$ per 10,000 - it's a ridiculously small price for a lot of requests, isn't it? Big surprise: 2/3 of our CloudFront cost is for requests (about 3 KB per request). I/O requests for EBS is a similar story.

由于这将是非常容易规模（使用一个更大的实例，移动数据库关系数据库服务）我建议你开始使用相同的设置。正如你所说，抛出更多的盒子是很简单的（假设你的设置支持添加/删除节点上的）。这使得通过尝试和错误选择适当的设置容易可行 - 一些完整的负载测试应该做的工作。选择适合您预期负荷（加上一些额外的力量）的东西，并在有生产数据后立即增长/收缩。

As it would be extremely easy to scale (use a bigger instance, move DB on Relational Database Service) I'd suggest you start with the same setup. As you said, throwing more boxes in is pretty simple (assuming your setup supports adding/removing nodes on the fly). This makes choosing the appropriate setup by trial and error easily feasible - some thorough load testing should do the job. Choose something that works for your expected load (plus some extra power) and grow/shrink as soon as you have production data.

结论：是的，在EC2上托管Java EE应用程序：

As a conclusion: yes, it's certainly possible to host Java EE apps on EC2 :)

编辑：作为注释：比较EC2的价格与传统托管比较苹果和橘子 - 至少只要你没有为您的网络获得SLA，几乎无限的可扩展性，没有硬件问题，几乎无限的冗余存储，不同的可用区域和一堆额外的服务。如果有人告诉你传统托管是便宜的，他可能是一个系统管理员焦虑他的工作;）不要误会我的错，它是更便宜 - 但你少得多少少钱。

as a side note: comparing pricing of EC2 with traditional hosting is comparing apples and oranges - at least as long as you don't get an SLA for your network, nearly unlimited scalability, no hardware issues, nearly unlimited and redundant storage, different availability zones and a bunch of extra services with it. If somebody tells you that traditional hosting is cheaper, he might be a sysadmin anxious about his job ;) Don't get me wrong, it is cheaper - but you get much less for a little less money.

顺便说一下，我没有附属亚马逊...但我觉得我应该被奖励作为一个好的发言人，我不应该？ ：D

And by the way, I'm in no way affiliated with Amazon ... but I feel that I should be rewarded for being a good spokesman, shouldn't I? :D

这篇关于云是否准备好用于企业Java Web应用程序？寻求Java EE托管建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！