云计算七问七答

winston

作者 吕维德发布于 2009年3月28日




缘起

最近因为工作需要，又再度开始接触 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站长。