本系列文章基于公開資料對(duì)Google App Engine的實(shí)現(xiàn)機(jī)制這個(gè)話題進(jìn)行深度探討。在切入Google App Engine之前，首先會(huì)對(duì)Google的核心技術(shù)和其整體架構(gòu)進(jìn)行分析，以幫助大家之后更好地理解Google App Engine的實(shí)現(xiàn)。

本篇將主要介紹Google的十個(gè)核心技術(shù)，而且可以分為四大類：

• 分布式基礎(chǔ)設(shè)施：GFS、Chubby 和 Protocol Buffer。
• 分布式大規(guī)模數(shù)據(jù)處理：MapReduce 和 Sawzall。
• 分布式數(shù)據(jù)庫技術(shù)：BigTable 和數(shù)據(jù)庫 Sharding。
• 數(shù)據(jù)中心優(yōu)化技術(shù)：數(shù)據(jù)中心高溫化、12V電池和服務(wù)器整合。

分布式基礎(chǔ)設(shè)施

GFS

由于搜索引擎需要處理海量的數(shù)據(jù)，所以Google的兩位創(chuàng)始人Larry Page和SergeyBrin在創(chuàng)業(yè)初期設(shè)計(jì)一套名為"BigFiles"的文件系統(tǒng)，而GFS（全稱為"Google FileSystem"）這套分布式文件系統(tǒng)則是"BigFiles"的延續(xù)。

首先，介紹它的架構(gòu)，GFS主要分為兩類節(jié)點(diǎn)：

• Master節(jié)點(diǎn)：主要存儲(chǔ)與數(shù)據(jù)文件相關(guān)的元數(shù)據(jù)，而不是Chunk（數(shù)據(jù)塊）。元數(shù)據(jù)包括一個(gè)能將64位標(biāo)簽映射到數(shù)據(jù)塊的位置及其組成文件 的表格，數(shù)據(jù)塊副本位置和哪個(gè)進(jìn)程正在讀寫特定的數(shù)據(jù)塊等。還有Master節(jié)點(diǎn)會(huì)周期性地接收從每個(gè)Chunk節(jié)點(diǎn)來的更新（"Heart- beat"）來讓元數(shù)據(jù)保持最新狀態(tài)。
• Chunk節(jié)點(diǎn)：顧名思義，肯定用來存儲(chǔ)Chunk，數(shù)據(jù)文件通過被分割為每個(gè)默認(rèn)大小為64MB的Chunk的方式存儲(chǔ)，而且每個(gè)Chunk有唯一一個(gè)64位標(biāo)簽，并且每個(gè)Chunk都會(huì)在整個(gè)分布式系統(tǒng)被復(fù)制多次，默認(rèn)為3次。

下圖就是GFS的架構(gòu)圖：

圖1. GFS的架構(gòu)圖（參片[15]）

接著，在設(shè)計(jì)上，GFS主要有八個(gè)特點(diǎn)：

• 大文件和大數(shù)據(jù)塊：數(shù)據(jù)文件的大小普遍在GB級(jí)別，而且其每個(gè)數(shù)據(jù)塊默認(rèn)大小為64MB，這樣做的好處是減少了元數(shù)據(jù)的大小，能使Master節(jié)點(diǎn)能夠非常方便地將元數(shù)據(jù)放置在內(nèi)存中以提升訪問效率。
• 操作以添加為主：因?yàn)槲募苌俦粍h減或者覆蓋，通常只是進(jìn)行添加或者讀取操作，這樣能充分考慮到硬盤線性吞吐量大和隨機(jī)讀寫慢的特點(diǎn)。
• 支持容錯(cuò)：首先，雖然當(dāng)時(shí)為了設(shè)計(jì)方便，采用了單Master的方案，但是整個(gè)系統(tǒng)會(huì)保證每個(gè)Master都會(huì)有其相對(duì)應(yīng)的復(fù)制品，以便于在 Master節(jié)點(diǎn)出現(xiàn)問題時(shí)進(jìn)行切換。其次，在Chunk層，GFS已經(jīng)在設(shè)計(jì)上將節(jié)點(diǎn)失敗視為常態(tài)，所以能非常好地處理Chunk節(jié)點(diǎn)失效的問題。
• 高吞吐量：雖然其單個(gè)節(jié)點(diǎn)的性能無論是從吞吐量還是延遲都很普通，但因?yàn)槠渲С稚锨У墓?jié)點(diǎn)，所以總的數(shù)據(jù)吞吐量是非常驚人的。
• 保護(hù)數(shù)據(jù)：首先，文件被分割成固定尺寸的數(shù)據(jù)塊以便于保存，而且每個(gè)數(shù)據(jù)塊都會(huì)被系統(tǒng)復(fù)制三份。
• 擴(kuò)展能力強(qiáng)：因?yàn)樵獢?shù)據(jù)偏小，使得一個(gè)Master節(jié)點(diǎn)能控制上千個(gè)存數(shù)據(jù)的Chunk節(jié)點(diǎn)。
• 支持壓縮：對(duì)于那些稍舊的文件，可以通過對(duì)它進(jìn)行壓縮，來節(jié)省硬盤空間，并且壓縮率非常驚人，有時(shí)甚至接近90%。
• 用戶空間：雖然在用戶空間運(yùn)行在運(yùn)行效率方面稍差，但是更便于開發(fā)和測試，還有能更好利用Linux的自帶的一些POSIX API。

現(xiàn)在Google內(nèi)部至少運(yùn)行著200多個(gè)GFS集群，最大的集群有幾千臺(tái)服務(wù)器，并且服務(wù)于多個(gè)Google服務(wù)，比如Google搜索。但由于GFS主要為搜索而設(shè)計(jì)，所以不是很適合新的一些Google產(chǎn)品，比YouTube、Gmail和更強(qiáng)調(diào)大規(guī)模索引和實(shí)時(shí)性的Caffeine搜索引擎等，所以Google已經(jīng)在開發(fā)下一代GFS，代號(hào)為"Colossus"，并且在設(shè)計(jì)方面有許多不同，比如：支持分布式Master節(jié)點(diǎn)來提升高可用性并能支撐更多文件，Chunk節(jié)點(diǎn)能支持1MB大小的chunk以支撐低延遲應(yīng)用的需要。

Chubby

簡單的來說，Chubby 屬于分布式鎖服務(wù)，通過Chubby，一個(gè)分布式系統(tǒng)中的上千個(gè)client都能夠?qū)τ谀稠?xiàng)資源進(jìn)行"加鎖"或者"解鎖"，常用于BigTable的協(xié)作工作，在實(shí)現(xiàn)方面是通過對(duì)文件的創(chuàng)建操作來實(shí)現(xiàn)"加鎖"，并基于著名科學(xué)家Leslie Lamport的Paxos算法。

Protocol Buffer

Protocol Buffer，是Google內(nèi)部使用一種語言中立、平臺(tái)中立和可擴(kuò)展的序列化結(jié)構(gòu)化數(shù)據(jù)的方式，并提供 Java、C++ 和Python 這三種語言的實(shí)現(xiàn)，每一種實(shí)現(xiàn)都包含了相應(yīng)語言的編譯器以及庫文件，而且它是一種二進(jìn)制的格式，所以其速度是使用 XML進(jìn)行數(shù)據(jù)交換的10倍左右。它主要用于兩個(gè)方面：其一是RPC通信，它可用于分布式應(yīng)用之間或者異構(gòu)環(huán)境下的通信。其二是數(shù)據(jù)存儲(chǔ)方面，因?yàn)樗悦枋?，而且壓縮很方便，所以可用于對(duì)數(shù)據(jù)進(jìn)行持久化，比如存儲(chǔ)日志信息，并可被Map Reduce程序處理。與ProtocolBuffer比較類似的產(chǎn)品還有Facebook的 Thrift ，而且 Facebook 號(hào)稱Thrift在速度上還有一定的優(yōu)勢(shì)。

分布式大規(guī)模數(shù)據(jù)處理

MapReduce

首先，在Google數(shù)據(jù)中心會(huì)有大規(guī)模數(shù)據(jù)需要處理，比如被網(wǎng)絡(luò)爬蟲（WebCrawler）抓取的大量網(wǎng)頁等。由于這些數(shù)據(jù)很多都是PB級(jí)別，導(dǎo)致處理工作不得不盡可能的并行化，而Google為了解決這個(gè)問題，引入了MapReduce這個(gè)編程模型，MapReduce是源自函數(shù)式語言，主要通過"Map（映射）"和"Reduce（化簡）"這兩個(gè)步驟來并行處理大規(guī)模的數(shù)據(jù)集。Map會(huì)先對(duì)由很多獨(dú)立元素組成的邏輯列表中的每一個(gè)元素進(jìn)行指定的操作，且原始列表不會(huì)被更改，會(huì)創(chuàng)建多個(gè)新的列表來保存Map的處理結(jié)果。也就意味著，Map操作是高度并行的。當(dāng)Map工作完成之后，系統(tǒng)會(huì)先對(duì)新生成的多個(gè)列表進(jìn)行清理（Shuffle）和排序，之后會(huì)這些新創(chuàng)建的列表進(jìn)行Reduce操作，也就是對(duì)一個(gè)列表中的元素根據(jù)Key值進(jìn)行適當(dāng)?shù)暮喜ⅰ?/p>

下圖為MapReduce的運(yùn)行機(jī)制：

圖2. MapReduce的運(yùn)行機(jī)制（參[19]）

接下來，將根據(jù)上圖來舉一個(gè)MapReduce的例子：比如，通過搜索Spider將海量的Web頁面抓取到本地的GFS集群中，然后Index系統(tǒng)將會(huì)對(duì)這個(gè)GFS集群中多個(gè)數(shù)據(jù)Chunk進(jìn)行平行的Map處理，生成多個(gè)Key為URL，value為html頁面的鍵值對(duì)（Key-ValueMap），接著系統(tǒng)會(huì)對(duì)這些剛生成的鍵值對(duì)進(jìn)行Shuffle（清理），之后系統(tǒng)會(huì)通過Reduce操作來根據(jù)相同的key值（也就是URL）合并這些鍵值對(duì)。

最后，通過MapReduce這么簡單的編程模型，不僅能用于處理大規(guī)模數(shù)據(jù)，而且能將很多繁瑣的細(xì)節(jié)隱藏起來，比如自動(dòng)并行化，負(fù)載均衡和機(jī)器宕機(jī)處理等，這樣將極大地簡化程序員的開發(fā)工作。MapReduce可用于包括"分布grep，分布排序，web訪問日志分析，反向索引構(gòu)建，文檔聚類，機(jī)器學(xué)習(xí)，基于統(tǒng)計(jì)的機(jī)器翻譯，生成Google的整個(gè)搜索的索引"等大規(guī)模數(shù)據(jù)處理工作。Yahoo也推出MapReduce的開源版本Hadoop，而且Hadoop在業(yè)界也已經(jīng)被大規(guī)模使用。

Sawzall

Sawzall可以被認(rèn)為是構(gòu)建在MapReduce之上的采用類似Java語法的DSL（Domain-SpecificLanguage），也可以認(rèn)為它是分布式的AWK。它主要用于對(duì)大規(guī)模分布式數(shù)據(jù)進(jìn)行篩選和聚合等高級(jí)數(shù)據(jù)處理操作，在實(shí)現(xiàn)方面，是通過解釋器將其轉(zhuǎn)化為相對(duì)應(yīng)的MapReduce任務(wù)。除了Google的Sawzall之外，yahoo推出了相似的Pig語言，但其語法類似于SQL。

分布式數(shù)據(jù)庫技術(shù)

BigTable

由于在Google的數(shù)據(jù)中心存儲(chǔ)PB級(jí)以上的非關(guān)系型數(shù)據(jù)時(shí)候，比如網(wǎng)頁和地理數(shù)據(jù)等，為了更好地存儲(chǔ)和利用這些數(shù)據(jù)，Google開發(fā)了一套數(shù)據(jù)庫系統(tǒng)，名為"BigTable"。BigTable不是一個(gè)關(guān)系型的數(shù)據(jù)庫，它也不支持關(guān)聯(lián)（Join）等高級(jí)SQL操作，取而代之的是多級(jí)映射的數(shù)據(jù)結(jié)構(gòu)，并是一種面向大規(guī)模處理、容錯(cuò)性強(qiáng)的自我管理系統(tǒng)，擁有TB級(jí)的內(nèi)存和PB級(jí)的存儲(chǔ)能力，使用結(jié)構(gòu)化的文件來存儲(chǔ)數(shù)據(jù)，并每秒可以處理數(shù)百萬的讀寫操作。

什么是多級(jí)映射的數(shù)據(jù)結(jié)構(gòu)呢？就是一個(gè)稀疏的，多維的，排序的Map，每個(gè)Cell由行關(guān)鍵字，列關(guān)鍵字和時(shí)間戳三維定位．Cell的內(nèi)容是一個(gè)不解釋的字符串，比如下表存儲(chǔ)每個(gè)網(wǎng)站的內(nèi)容與被其他網(wǎng)站的反向連接的文本。 反向的URLcom.cnn.www是這行的關(guān)鍵字；contents列存儲(chǔ)網(wǎng)頁內(nèi)容，每個(gè)內(nèi)容有一個(gè)時(shí)間戳，因?yàn)橛袃蓚€(gè)反向連接，所以archor的ColumnFamily有兩列：anchor: cnnsi.com和anchhor:my.look.ca。ColumnFamily這個(gè)概念，使得表可以輕松地橫向擴(kuò)展。下面是它具體的數(shù)據(jù)模型圖：

圖3. BigTable數(shù)據(jù)模型圖（參[4]）

在結(jié)構(gòu)上，首先，BigTable基于GFS分布式文件系統(tǒng)和Chubby分布式鎖服務(wù)。其次BigTable也分為兩部分：其一是Master節(jié)點(diǎn)，用來處理元數(shù)據(jù)相關(guān)的操作并支持負(fù)載均衡。其二是tablet節(jié)點(diǎn)，主要用于存儲(chǔ)數(shù)據(jù)庫的分片tablet，并提供相應(yīng)的數(shù)據(jù)訪問，同時(shí)Tablet是基于名為SSTable的格式，對(duì)壓縮有很好的支持。

圖4. BigTable架構(gòu)圖（參[15]）

BigTable正在為Google六十多種產(chǎn)品和項(xiàng)目提供存儲(chǔ)和獲取結(jié)構(gòu)化數(shù)據(jù)的支撐平臺(tái)，其中包括有Google Print、Orkut、Google Maps、Google Earth和Blogger等，而且Google至少運(yùn)行著500個(gè)BigTable集群。

隨著Google內(nèi)部服務(wù)對(duì)需求的不斷提高和技術(shù)的不斷地發(fā)展，導(dǎo)致原先的BigTable已經(jīng)無法滿足用戶的需求，而Google也正在開發(fā)下一代BigTable，名為"Spanner（扳手）"，它主要有下面這些BigTable所無法支持的特性：

• 支持多種數(shù)據(jù)結(jié)構(gòu)，比如table，familie，group和coprocessor等。
• 基于分層目錄和行的細(xì)粒度的復(fù)制和權(quán)限管理。
• 支持跨數(shù)據(jù)中心的強(qiáng)一致性和弱一致性控制。
• 基于Paxos算法的強(qiáng)一致性副本同步，并支持分布式事務(wù)。
• 提供許多自動(dòng)化操作。
• 強(qiáng)大的擴(kuò)展能力，能支持百萬臺(tái)服務(wù)器級(jí)別的集群。
• 用戶可以自定義諸如延遲和復(fù)制次數(shù)等重要參數(shù)以適應(yīng)不同的需求。

數(shù)據(jù)庫Sharding

Sharding就是分片的意思，雖然非關(guān)系型數(shù)據(jù)庫比如BigTable在Google的世界中占有非常重要的地位，但是面對(duì)傳統(tǒng)OLTP應(yīng)用，比如廣告系統(tǒng)，Google還是采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫技術(shù)，也就是MySQL，同時(shí)由于Google所需要面對(duì)流量非常巨大，所以Google在數(shù)據(jù)庫層采用了分片（Sharding）的水平擴(kuò)展（Scale Out）解決方案，分片是在傳統(tǒng)垂直擴(kuò)展（ScaleUp）的分區(qū)模式上的一種提升，主要通過時(shí)間，范圍和面向服務(wù)等方式來將一個(gè)大型的數(shù)據(jù)庫分成多片，并且這些數(shù)據(jù)片可以跨越多個(gè)數(shù)據(jù)庫和服務(wù)器來實(shí)現(xiàn)水平擴(kuò)展。

Google整套數(shù)據(jù)庫分片技術(shù)主要有下面這些優(yōu)點(diǎn)：

• 擴(kuò)展性強(qiáng)：在Google生產(chǎn)環(huán)境中，已經(jīng)有支持上千臺(tái)服務(wù)器的MySQL分片集群。
• 吞吐量驚人：通過巨大的MySQL分片集群能滿足巨量的查詢請(qǐng)求。
• 全球備份：不僅在一個(gè)數(shù)據(jù)中心還是在全球的范圍，Google都會(huì)對(duì)MySQL的分片數(shù)據(jù)進(jìn)行備份，這樣不僅能保護(hù)數(shù)據(jù)，而且方便擴(kuò)展。

在實(shí)現(xiàn)方面，主要可分為兩塊：其一是在MySQLInnoDB基礎(chǔ)上添加了數(shù)據(jù)庫分片的技術(shù)。其二是在ORM層的Hibernate的基礎(chǔ)上也添加了相關(guān)的分片技術(shù)，并支持虛擬分片（VirtualShard）來便于開發(fā)和管理。同時(shí)Google也已經(jīng)將這兩方面的代碼提交給相關(guān)組織。

數(shù)據(jù)中心優(yōu)化技術(shù)

數(shù)據(jù)中心高溫化

大中型數(shù)據(jù)中心的PUE（Power UsageEffectiveness）普遍在2左右，也就是在服務(wù)器等計(jì)算設(shè)備上耗1度電，在空調(diào)等輔助設(shè)備上也要消耗一度電。對(duì)一些非常出色的數(shù)據(jù)中心，最多也就能達(dá)到1.7，但是Google通過一些有效的設(shè)計(jì)使部分?jǐn)?shù)據(jù)中心到達(dá)了業(yè)界領(lǐng)先的1.2，在這些設(shè)計(jì)當(dāng)中，其中最有特色的莫過于數(shù)據(jù)中心高溫化，也就是讓數(shù)據(jù)中心內(nèi)的計(jì)算設(shè)備運(yùn)行在偏高的溫度下，Google的能源方面的總監(jiān)ErikTeetzel在談到這點(diǎn)的時(shí)候說："普通的數(shù)據(jù)中心在70華氏度（21攝氏度）下面工作，而我們則推薦80華氏度（27攝氏度）"。但是在提高數(shù)據(jù)中心的溫度方面會(huì)有兩個(gè)常見的限制條件：其一是服務(wù)器設(shè)備的崩潰點(diǎn)，其二是精確的溫度控制。如果做好這兩點(diǎn)，數(shù)據(jù)中心就能夠在高溫下工作，因?yàn)榧僭O(shè)數(shù)據(jù)中心的管理員能對(duì)數(shù)據(jù)中心的溫度進(jìn)行正負(fù)1/2度的調(diào)節(jié)，這將使服務(wù)器設(shè)備能在崩潰點(diǎn)5度之內(nèi)工作，而不是常見的20度之內(nèi)，這樣既經(jīng)濟(jì)，又安全。還有，業(yè)界傳言Intel為Google提供抗高溫設(shè)計(jì)的定制芯片，但云計(jì)算界的頂級(jí)專家JamesHamilton認(rèn)為不太可能，因?yàn)殡m然處理器也非常懼怕熱量，但是與內(nèi)存和硬盤相比還是強(qiáng)很多，所以處理器在抗高溫設(shè)計(jì)中并不是一個(gè)核心因素。同時(shí)他也非常支持使數(shù)據(jù)中心高溫化這個(gè)想法，而且期望將來數(shù)據(jù)中心甚至能運(yùn)行在40攝氏度下，這樣不僅能節(jié)省空調(diào)方面的成本，而且對(duì)環(huán)境也很有利。

12V電池

由于傳統(tǒng)的UPS在資源方面比較浪費(fèi)，所以Google在這方面另辟蹊徑，采用了給每臺(tái)服務(wù)器配一個(gè)專用的12V電池的做法來替換了常用的UPS，如果主電源系統(tǒng)出現(xiàn)故障，將由該電池負(fù)責(zé)對(duì)服務(wù)器供電。雖然大型UPS可以達(dá)到92%到95%的效率，但是比起內(nèi)置電池的99.99%而言是非常捉襟見肘的，而且由于能量守恒的原因，導(dǎo)致那么未被UPS充分利用的電力會(huì)被轉(zhuǎn)化成熱能，這將導(dǎo)致用于空調(diào)的能耗相應(yīng)地攀升，從而走入一個(gè)惡性循環(huán)。同時(shí)在電源方面也有類似的"神來之筆"，普通的服務(wù)器電源會(huì)同時(shí)提供5V和12V的直流電。但是Google設(shè)計(jì)的服務(wù)器電源只輸出12V直流電，必要的轉(zhuǎn)換在主板上進(jìn)行，雖然這種設(shè)計(jì)會(huì)使主板的成本增加1美元到2美元，但是它不僅能使電源能在接近其峰值容量的情況下運(yùn)行，而且在銅線上傳輸電流時(shí)效率更高。

服務(wù)器整合

談到虛擬化的殺手锏時(shí)，第一個(gè)讓人想到肯定是服務(wù)器整合，而且普遍能實(shí)現(xiàn)1:8的整合率來降低各方面的成本。有趣的是，Google在硬件方面也引入類似服務(wù)器整合的想法，它的做法是在一個(gè)機(jī)箱大小的空間內(nèi)放置兩臺(tái)服務(wù)器，這些做的好處有很多，首先，減小了占地面積。其次，通過讓兩臺(tái)服務(wù)器共享諸如電源等設(shè)備，來降低設(shè)備和能源等方面的投入。

本篇結(jié)束，下篇將猜想一下Google整體架構(gòu)。