Amazon EC2

        尽管软件即服务（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开发者可以非常快速的了解并使用该技术。