最近因为工作需要,又再度开始接触 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美金就搞定(由于处理速度实在太快,他们实际上还跑了两次吶……)
这个例子也正好带出下一个主题。