最近因為工作需要，又再度開始接觸 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美金就搞定(由于處理速度實在太快，他們實際上還跑了兩次吶……)
這個例子也正好帶出下一個主題。
京公網安備 11010502049343號