云计算讨论

 

从主机服务到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的软件服务（先搞定一、二层，然后建构第三层的专业服务）。