Amazon EC2 受到 JEE 和 Groovy 开发者的青睐

尽管软件即服务（Software as a Service——SaaS）的思想逐渐为人接受，而硬件即服务（HaaS）仍是一个新概念。这种服务的一个例子是 Amazon 的弹性计算云（Elastic Computer Cloud——EC2），它是于2006 年夏天宣布的。EC2 是一个基于 Xen 管理程序结构的计算服务。它允许开发者创建基于 Linux 的虚机，这种创建过程既可以从零开始也可以使用预先构建好的映像文件。然后，使用 Web 服务 API 或该 API 的脚本封装器，你可以快速部署到任何数目的虚机。

虚机结构允许 Amazon 提供不同大小的 VM，最大可到硬件的物理限制。因此除了默认的小实例（1.7 GB 内存，单 1.0-1.2 GHz 2007 Opteron/Xeon 处理器，160 GB 实例存储（instance storage），32 位平台），Amazon 现在可提供大的（7.5 GB 内存，4 个如前规格处理器，850 GB 实例存储，64 位平台）和特大的（15 GB 内存，8 个如前规格处理器，1690 GB 实例存储，64 位平台）实例。如果（打个比方）你需要一个用于数据库处理的重量级 VM 以及两个提供应用服务器服务的轻量级 VM 话，搭配方法是非常有用的。此外，VM 映像，Amazon 称之为 Amazon Machine Images（AMIs），可以类似 VMware 的虚拟应用一样被存档和传递。这给客户提供了一种发布或共享 AMI 的机制，要么由一个特定产品开始，要么作为一种收入来源（为公司和个人提供付费映像文件）。有不少 AMI 文件已经可供下载使用了，包括两个 GigaSpaces 环境和一个基于 Tomcat 的 JEE 环境。

EC2 环境通常表现很好， RightScale 提供的一些初始测试表明 EC2 和 Amazon 的 Simple Storage Service（S3）的网络吞吐量都很高。然而 EC2 有一些重要的伸缩性限制。首先是垂直伸缩性限制，即 Amazon 提供的最大 VM 尺寸的限制。第二个是水平伸缩性限制，你必须依赖于软件负载均衡技术。这些限制通常比对等硬件的限制更大，因为像 TCP 缓冲（它负责将来自 Web 服务器负载均衡器缓冲器的响应发送给速度较慢的客户端，因而使得 Web 服务器有能力处理其他任务）或 SSL 卸载这样的高级技术不能被实现。此外，因为 EC2 环境是基于虚机的，你不能使用如内核修改或其他 OS 级优化等等在重任务 Linux 环境中很普遍的底层性能技术。一个大的基于虚机的环境也引出了另一个挑战，因为它们难以安装和维护。

值得注意的是，当把大 VM 实例用于 7X24 小时服务时费用会激增——一个特大 VM 每年将花费 7000 美元。然而，如果用于低容量 Web 服务器或用于特定其他情形（比如批处理，这种服务不需要 24 小时不间断服务），或者进行耗时不长的测试，同样的定价模型使 EC2 非常物有所值。例如 Oracle 的 Coherence 数据网格团队，将 EC2 用于测试用途。开发副总裁 Cameron Purdy 这样告诉 InfoQ：

“Amazon 的 EC2 是用信用卡就能购买一个数据中心的唯一简便方法。

对短期、高耗资源（也就是众多服务器）任务，它非常有用且很划算。让所有事情去有效地利用 EC2 是一种投资，但是如果这项任务要重复许多次，那么这种投资是值得的。因为有些我们的工程师在他们开发产品特性时要执行大规模数据网格（Data Grid）测试，我们不可能承受为每个工程师运行五十个专用服务器，因此，EC2 通常是测试我们软件最简便且最划算的方法。

EC2 允许你立即启动一组 VM 实例，我们就是这样启动数据网格的。在 EC2 上运行数据网格最简便的方法是让每个应用程序使用自己的 S3-bucket。启动 EC2 时，用户需要提供应用集群的名字，它对应于 S3-bucket 的名字。接着，S3-bucket 自身被用于调整引导过程，由节点决定是否由它们创建一个新的簇（cluster）（引导数据网格），或者只是加入一个已在运行的簇。为了避免使用多播发现，节点负责确定一个公共地址（Well-Known Addresses，WKA）列表，而应用程序（一个可执行的.JAR 文件）则通过由命令行传递的 WKA 信息而被调用。因为 Coherence 很容易被嵌入，Coherence 数据网格库（一个.JAR）位于映像文件本身之中。

我们在 EC2 上测试的应用之一是代号为 C0 的项目的一部分。无需深入细节，C0 数据网格运行在 EC2 之上，扮演一个单一的、巨大的资源池，可以给数据网格托管的不同应用动态分配资源。我们通过如下方式进行测试：构建一个安装了 Coherence Provisioning Agent 的 VM 映像，并在引导时将其启动为一个服务，有一个看门狗（watchdog）保持其处于运行状态。该 Agent 接着加入到 C0 簇中，使得那个特殊的 VM 成为数据网格的可管理资源。因为 EC2 只是一个 Web 服务，有许多 Java 库可以调用它，你可以通过 EC2 编程来分配服务器。在一个按需分配容量（Capacity-On-Demand）的环境中，比如一个自动供应系统（auto-provisioning system），有可能在需求增长时扩大 VM 数量，在需求减少时关闭增加的 VM。在我们的例子中，我们驱动系统使用一个规则引擎（其本身就是一个数据网格），这样就能够根据需要扩张和缩减 VM 的数量了——这是数据网格自身在自动的膨胀和收缩。

最终，一个大规模虚拟环境必须具备的是每个 VM 能自我配置，因为手工去配置和管理大量的 VM 映像几乎不可能。例如，EC2 提供了 VM 实例描述数据，我们可以使用这些数据去配置像 Provisioning Agent Server 的 HTTP 主机及端口，并且将 S3 当作包（bundle）和代码库去访问。照此，唯一的引导任务就是扩容 VM 数量，因为 VM 是自我配置的，不需要为每个 VM 指定参数。这种方法的一个问题是，VM 需要能访问帐户的 Amazon AWS 证书，以便它可以访问 S3 来引导自身；当前，这意味着你可能必须将证书硬连接到 EC2 引导映像本身。

总结一下，EC2 为那鲜有要求大量服务器的系统、或者那些需要以不可预知的方式动态增加或减少服务器数量的系统打开了大门。现在，我们使用它去测试像数据网格这样的大规模系统，但是将来我们的一些客户可能使用它作为自己的产品部署平台。业内通常将 EC2 联系到软件即服务上（SaaS），但它不止这些——它是数据中心即服务。你也能用信用卡购买数据中心了。”

另一个可以证明 EC2 很划算的领域是创业公司。InfoQ 的 Java 编辑 Ryan Slobojan 最近从事于一个创业的项目，叫做 Jamloop ，用来收集并定位新旧音乐器械。在一篇博文中他罗列了几点理由，说明为什么 EC2 是一个诱人的选择：

• “JamLoop 不需要购买昂贵的主机空间或雇用任何 IT 人员、或者承担低价主机站点的风险——Amazon 是个足够大的名头，我觉得我们能够信任他们
• JamLoop 能适应变化的流量模式——如果网站突然流行起来或者出现了流量障碍，他们可以按照需要实例化新的 EC2 实例，并且仍然只需支付 $0.10/ 小时 / 服务器
• 如果 JamLoop 的正常流量负载用 20 个服务器即可处理，而峰值需要 100 个服务器，他们不需要总是使用 100 个服务器——他们可以在需要的时候扩大或减小规模
• 因为该站点作为一个汇集器来运转，它需要引入外部数据——JamLoop 可以产生一些用于捕获数据的实例，只要有需要它们就一直运行，当任务完成时关闭它们。
• 花费确实很低——每服务器每天 $2.40，每服务器每月是 $72，这看来是个好价码，尤其是这些并不需要合同，这是一种随用随付费的模式（ pay-as-you-go model）
• JamLoop 可以运行任何想要的操作系统或软件，因为这些是他们的东西——他们不必受限于服务提供商给他们建立的系统，比方说 Apache 和 PHP”

使用 EC2 API 很简单，但是为了让其使用起来更简单 Chris Richardson 开发了一个Groovy 框架，可以在Amazon 的EC2 上启动MySQL、Apache HTTP Server、一组Tomcat 实例和JMeter，以及部署Web 应用。该框架还在早期开发阶段，还没有开源（尽管这是最终目标），但是它提供了一个有用的方法，使Java 开发者可以非常快速的了解并使用该技术。

查看英文原文： Amazon EC2 Gains Favor with JEE and Groovy Developers