云计算七问七答

缘起

最近因为工作需要，又再度开始接触 Amazon EC2/S3（早在 2006 初这个服务刚推出不久时曾用过一次，那时是 RoR 加一堆 merb，不过后来随着项目结束也就渐渐忘了这事），结果这次随便查了些资料却发现“云计算”这个单词似乎已无所不在泛滥成灾，也让我一时兴起想了解一下到底现在大家口中所谓的“云计算”是在指什么。

之所以这样好奇主要的原因是在许多地方都看到有人自称在提供云计算服务，但这些服务间彼此的性质、形态与做法差异性却很大，例如 EC2 与 GAE 两者就不太一样，GAE 与 Salesforce 又很不同，搞到最后，似乎处处是云端，人人在漫步。

根据维基百科的定义，云计算最宽松的定义是这样的：

它是一种计算方式，通过互联网将资源“以服务”的形式提供给用户，而用户不需要了解、知晓或者控制支持这些服务的技术基础架构（“云”）。（It is a style of computing in which resources are provided “as a service” over the Internet to users who need not have knowledge of, expertise in, or control over the technology infrastructure (”in the cloud”) that supports them.）

如果你对这样的定义没问题，那非常好，不用再浪费时间看下去，去喝杯咖啡吧。

很可惜这样的定义在我听来似乎宽松的有点夸张了，因为这样说来，我在家里摆几支 iPhone 跑些服务并开放 API 给人用，其实也算是云计算喽？（还是高雅的 Apple 云哩）就因为这该死的好奇心，我花了几天时间调查并整理了些相关资料，现在总算比较有个头绪了。

请注意这只是我个人的心得整理，文中对于名词的定义与诠释，尤其是“云”，只是我个人的想法，如果有错欢迎各方大德赐教。

从主机服务到 VPS，它是真正的云吗？

基本上，如果要细究到底云是什么，可能可以先吵上个三天三夜还没定论，因为根据众多前辈的说法，云这个字本来就是个流行词汇（Buzz Word），想用的人就随需取用好了，其实根本没啥定义好谈的啊。因此，我打算先跳过试图去定义这个字的破题法，从实际的部署方式来看这件事。

以往一般人要提供网络服务，大多是去租虚拟主机，有钱一点就丢机器到机房去，这是最常见也最传统的手法，这个手法最大的缺点在于：如果临时有大流量需求，例如办个活动，很难迅速扩充服务能量，不论是要搞到大量的机器，或无穷尽的带宽，都是个问题。

因此，这几年来比较流行的玩法是所谓的 VPS/VDS （Virtual Private Server），透过类似 XEN 这样的软体，将一台实体服务器虚拟化（ Virtualization ）成多台虚拟机器然后出租，这样一来当临时有大流量需求时，可以很容易地加买几台虚拟机器就撑过去了。

前面开头谈到的 EC2 就是这样一个服务，另外这一两年颇受好评的 Slicehost 也是，在 EC2 的例子里，每一个虚拟出来的机器叫做一个实例（Instance），因此要应付大流量事件时，可以狂开 Instance 撑过去，这比狂买实体机器便宜多了。

由于 VPS 真的超方便而且很好用，因此迅速受到大家欢迎，久而久之，VPS 这样的服务似乎也就跟云画上了等号，但这个等号里，有个地方却值得进一步讨论。

简单来说，今天一个人在 EC2 买了 100 个 Instance，它们并不会自动联合起来工作，而是要靠人工去规划，例如最常见的是在前面放个逆向代理（Reverse Proxy），然后把请求平均导向到这 100 台机器上（轮询负载均衡， Round-robin Load Balancing ），并且，更重要的是应用本身在撰写时就要考虑到将来能支持跑在多个分散的机器上，例如 Session 要怎么维持？全局内存（Global Memory）如何分享？数据库是否也要散聚在不同机器上？如果分散的话，要怎么维持资料同步？等等这一大堆相关的细节要处理，一个没弄好，呃，就成了 Twitter 第二了。

从这个角度看来，VPS（不论是 EC2 还是 Slicehost）提供的其实是虚拟化与负载均衡服务，至于在这个基础服务之上，用户要怎么玩就是各显神通。但负载均衡与云似乎并不尽然相同呀！

世界上还有其它种类的云吗？

有，例如 Google App Engine （简称 GAE）提供的服务。

简单来说 GAE 是由三个东西组成的，分别是 MapReduce 、 BigTable 和 GFS （Google File System），其中最重要的特色就是 MapReduce。MapReduce 可说是一个演算法，也可说是一个框架（看你读的文献来源），但它基本上是由 Map 与 Reduce 两者组合，运作方式也很简单：

• Map：主节点将工作切割成许多小块丢给子节点去执行，子节点可能会再切割工作成各多的小块给其下的子节点去执行，因此这是一个树状的结构。当子节点完成计算后会将结果传回给主节点。
• Reduce：主节点拿到子节点传回的结果后，将它组合起来，就完成工作了。

对 MapReduce 有兴趣又闲的发慌的朋友可以去看看 Google 发表的一篇论文与简报（保证会睡的很香甜:P）。

类似 GAE 这样的服务，它们最大的特色就是会将工作切割成很多小块，然后经由多台电脑联合起来一起运算，也因为要切割，因此通常会伴随者一个分布式文件系统（在 GAE 的例子里，叫做 GFS），通常也会有一个分布式的文件库，例如 GAE 里叫 Bigtable。

当然前面讲的都是针对底层架构的设计，但对最前端的开发者来说它代表什么意义呢？很简单，开发者可以完全不用管它有 100 台或 10000 台电脑在运作，只要照着 GAE 提供的 SDK 开发程序，将来布署到 GAE 上后就会自动去调用一堆电脑（而且很有可能是分布在世界各地数据中心里的）来发功，从这个角度来说，开发者要担心或处理的细节是比较少的，因此理论上上市时间也是比较短的。

如果不想用 GAE 还有其它选择吗？

有， Hadoop 是 Aapche 基金会里一个基于 Java 的主要计划，基本上可视为开源版的 GAE（很多关键技术是依据 Google 开放的学术论文来实现的，例如 Map Reduce、分布式文件系统等），目前最力挺的开发者是 Yahoo ，用于该公司的搜索引擎上，而 Hadoop 的创始者目前也在 Yahoo 上班（今年红利会不会很伤？:P），这里有一篇 iThome 的中文报道值得一看。

Hadoop 主要由下列三者组成（其它详细说明请看官网）：

• Hadoop Core：主要就是实现 MapReduce；
• HDFS（Hadoop Distributed File System）：参考 GFS 而来的分布式文件系统；
• HBase：基于 HDFS 的分布式资料库（功能等同于 Google Bigtable）。

Hadoop/GAE 与 EC2 是互斥的吗？

不见得，要看比较的面向为何？但实际上它们是可能合作的，其中最著名的例子是纽约时报在 EC2 上用 Hadoop 转了 4TB 的 PDF（这篇文章超级精彩不看可惜）。

故事大略是这样：

NYT 有一大票 1851-1922 年间扫描的一千一百万份文章要从 TIFF 图档格式转换为 PDF，由于数量实在太庞大，转换起来不但耗时甚久，也需要极大数量的机器，就算有钱如 NYT 也不想当凯子爷投资这么多啊~~~（而且因为转换时间太久，也不太可能跑去 BestBuy 刷它个几千台 PC 回来，然后速速转完就退回去 ;P）

最后 NYT 的工程师将所有档案传到 S3 放着，然后到 EC2 开了 100 个 Instance，再装个 Hadoop 利用这 100 台电脑跑分布运算，结果是只花了 24 小时和大约 3000 美金就搞定（由于处理速度实在太快，他们实际上还跑了两次吶……）

这个例子也正好带出下一个主题。

EC2 到底是不是云？

这要看你怎么定义云这个字，以我而言，我倾向认为 MapReduce 与分布式文件系统是云计算的主要特色，因此在这个定义之上，EC2 并不符合首要条件。

但如果我们把问题转成：EC2 可以成为云吗？

那答案就是肯定的，从上面 NYT 的例子可以看出，EC2 提供 100 个 Instance 只是基础架构，之后再上面跑 Hadoop 才是真正发功之所在。由此我们也可以得到另一个结论：硬件本身有无虚拟化并不重要（你可以买 100 台真的电脑连起来，也可以用 EC2 开 100 个 Instance），重要的是在其上协同运算的方式（MapReduce 是这里的关键）。

更简单的二分法则是这样：

• Amazon 只是把硬件虚拟化，然后卖入门级计算能力。
• GAE/Hadoop 则是提供分布式协同运算，打包的计算方案。

因此，或许我们可以把 EC2 视为云的前奏曲，拥有它之后，要不要做成云（例如装上 Hadoop）则是个人选择。

何时选择使用 EC2 或云呢？

这是更重要也更实际的问题，而答案也很单纯，主要就是考虑下列因素：

1、你要解决的问题是否能符合 MapReduce 的矩阵分割方式？

或是更白话一点的讲，你要做的事能不能被切割成小小的一块块来各个击破？例如日志文件的分析就很适合，但 Friend of Friend 数据库就不见得适合。如果你的问题可切割成许多小块，那就可以考虑下一点。

2、Vendor Lock-in 是否是个问题？

这个主要是针对 GAE 而来的，现在如果用了 GAE，基本上它的 Lock-in（Vendor Lock-in 意思是你采用了一个技术，即将自己锁定在这家提供商身上，不能轻易转换提供商）特质非常强烈，例如一定要用 Python 与 Bigtable，整个资料库栏位的规划方式跟传统 RDB 完全不同，操作语法也不一样，将来几乎无法迅速移转到其它主机服务（虽然有人写了 GAE to EC2 转换指南，但有没有胆量用是另外一回事）。喔，更别提市场上 Python 的人才有多贫乏这件事，会 RoR 的人搞不好还多一点。

当然这里可能的另一个选择就是效法 NYT，用 EC2+Hadoop 搞定制化分布式运算，而且用的是 Java，人才四处可得，相对门槛就低一点（但搞不定最后会死在 MapReduce 搞不定上：））

SaaS 是云吗？

这也是个好问题。

现在很多 Software as a Service 的服务商，例如 Salesforce 也都宣称自已提供了云计算服务，这又是怎么回事？我认为比较合理的看法是将云分成三个层次来看：

• 第一层是硬件层（100 台真的电脑，或 100 个 EC2 Instance）
• 第二层是框架（Hadoop、GAE 或者微软的 AZure 等）
• 第三层才是服务（记账、PDF 生成等）

在这样的架构下，SaaS 是属于第三层服务这个范畴。

也就是服务商先搞定第一、二层后，在其上建构自已的专业服务，例如 Salesforce 的主力服务是 CRM，因此它通过云提供一系列的 CRM API 给开发者使用。举个夸张的例子（注意，这例子是假想的），搞不好 Salesforce 也是租 EC2 然后搞了个 Hadoop，接着在上面用 Java 写了一堆 API 给人调用。这时它就是三层皆备，可称云而无愧了。

另外类似的例子则是像 Gmail、Google Reader 等，这些都是基于 GAE 的软件服务（先搞定一、二层，然后建构第三层的专业服务）。

附录

原本我曾认为 EC2 的虚拟化可以做到将许多台实体电脑虚拟化成一台大的服务器，这样工程师就只需要针对一台“超级电脑”来写程式即可，如果是这样，那 EC2 其实也符合分布式运算的标准，但我查来查去只不断看到类似下面的解释：

EC2 是为可以跨多台主机进行扩展的应用而设计的，而不是那些需要大量资源的更大的应用。（EC2 is more designed for applications that scale well across many hosts, rather than larger applications that require huge resources. ） 可扩展性：Amazon 能让你方便地增加或者减少服务器，而不是为一台现有的服务器（Instance）增加更多的电力 / 内存 / 硬盘等。这在你的应用设计时就考虑可以跨多台服务器进行扩展，以支持增加的负载的时候效果最好。（Scalability: Amazon supports easily adding or removing servers, not adding more power/memory/disk to an existing server (instance). This works well when your application is architected to scale across multiple servers to support increased load.）

因此目前先初步认定 EC2 并没有提供这方面的能力，当然如果有错，欢迎指正。

后记

在研究期间叨扰了无数前辈，感谢他们牺牲周未时间情义相挺回答各种无趣的问题，在此致上最高谢意。

另外关于 EC2 vs. Slicehost 的成本或用哪家比较划算这档事，我也小小想了一下，从实际数据看来，如果只是小型的网站或是创业公司，从省钱的角度来看，应该要选 Slicehost，因为它的初始成本最低，例如花个 $20 美元就可以有颇大的空间与流量可上线运行了。

但 EC2/S3 的好处则是安全性、稳定性与扩充性，而它最大的缺点则是成本相对较高，一个 Instance 开着不用一个月就要 $72 美元，如果生意好流量大那要交的费用就更多。

目前台湾地区用 EC2 的网站似乎并不多（ Pixnet 把资料存在 s3 的站就多一点），可能主要是连线反应时间不够快所以接受度不高吧，但我们服务的客户本来就多在北美，所以没差。

作者简介

吕维德，台湾 Macromedia 用户组发起人，RIA 博客 d.CAT 站长。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。