網址: http://www.dbanotes.net/arch/google_app_engine_arch_guess.html
按：此爲客座博文系列。投稿人吳朱華 曾在IBM中國研究院從事與雲計算相關的研究，現在正致力於研究雲計算技術。
本文是基於現有的公開資料和個人的經驗來對Google的整體架構進行總結和猜想。
在軟件工程界，大家有一個共識，那就是"需求決定架構"，也就是說，架構的發展是爲了更好地支撐應用。那麼本文在介紹架構之前，先介紹一下Google所提供的主要產品有哪些？
產品
對於Google和它幾個主要產品，比如搜索和郵件等，大家已經非常熟悉了，但是其提供服務的不只於此，並主要可分爲六大類：
- 各種搜索：網頁搜索，圖片搜索和視頻搜索等。
- 廣告系統：AdWords和AdSense。
- 生產力工具：Gmail和Google Apps等。
- 地理產品：地圖，Google Earth和Google Sky等。
- 視頻播放：Youtube。
- PaaS平臺：Google App Engine。
設計理念
根據現有的資料，Google的設計理念主要可以總結出下面這六條：
- Scale，Scale，Scale Scale：因爲Google大多數服務所面對的客戶都是百萬級別以上的，導致Scale也就是伸縮已經深深植入Google的DNA中，而且 Google爲了幫助其開發人員更好地開發分佈式應用和服務，不僅研發了用於大規模數據處理MapReduce框架，還推出了用於部署分佈式應用的 PaaS平臺Google App Engine。
- 容錯：一個分佈式系統，就算是構建在昂貴的小型機或者大型機之上，也會不時地出現軟件或者硬件方面的錯誤，何況Google的分佈式系統還是澆築 在便宜的X86服務器之上，即使其設備標稱的MTBF（平均故障間隔時間）很高，但是由於一個集羣內的設備極多，導致其錯誤發生的機率非常高，比如李開復 曾經提過這樣一個例子：在一個擁有兩萬臺X86服務器的集羣中，每天大約有110臺機器會出現宕機等惡劣情況，所以容錯是一個不可被忽視的問題，同時這點 也被Google院士Jeffrey Dean在多次演講中提到。
- 低延遲：延遲是影響用戶體驗的一個非常重要的因素，Google的副總裁Marissa Mayer曾經說過："如果每次搜索的時間多延遲半秒的話，那麼使用搜索服務的人將減少20%"，從這個例子可以看出，低延遲對用戶體驗非常關鍵，而且爲 了避免光速和複雜網絡環境造成的延時，Google已在很多地區設置了本地的數據中心。
- 廉價的硬件和軟件：由於Google每天所處理的數據和請求在規模上是史無前例的，所以現有的服務器和商業軟件廠商是很難爲Google"度身定 做"一套分佈式系統，而且就算能夠設計和生產出來，其價格也是Google所無法承受的，所以其上百萬臺服務器基本採用便宜的X86系統和開源的 Linux，並開發了一整套分佈式軟件棧，其中就包括上篇提到的MapReduce，BigTable和GFS等。
- 優先移動計算：雖然隨着摩爾定律的不斷髮展，使得很多資源都處於不斷地增長中，比如帶寬等，但是到現在爲止移動數據成本遠大於移動計算的成本，所以在處理大規模數據的時候，Google還是傾向於移動計算，而不是移動數據。
- 服務模式：在Google的系統中，服務是相當常用的，比如其核心的搜索引擎需要依賴700-1000個內部服務，而且服務這種松耦合的開發模式在測試，開發和擴展等方面都有優勢，因爲它適合小團隊開發，並且便於測試。
整體架構的猜想
在整體架構這部分，首先會舉出Google的三種主要工作負載，接着會試着對數據中心進行分類，最後會做一下總結。
三種工作負載
對於Google而言，其實工作負載並不僅僅只有搜索這一種，主要可以被分爲三大類：
- 本地交互：用於在用戶本地爲其提供基本的Google服務，比如網頁搜索等，但會將內容的生成和管理工作移交給下面的內容交付系統，比如：生成搜索所需的Index等。通過本地交互，能讓用戶減少延遲，從而提高用戶體驗，而且其對SLA要求很高，因爲是直接面對客戶的。
- 內容交付：用於爲Google大多數服務提供內容的存儲，生成和管理工作，比如創建搜索所需的Index，存儲YouTube的視頻和GMail 的數據等，而且內容交互系統主要基於Google自己開發那套分佈式軟件棧。還有，這套系統非常重視吞吐量和成本，而不是SLA。
- 關鍵業務：主要包括Google一些企業級事務，比如用於企業日常運行的客戶管理和人力資源等系統和賺取利潤的廣告系統（AdWords和AdSense），同時關鍵業務對SLA的要求非常高。
兩類數據中心
按照2008年數據，Google在全球有37個數據中心，其中19個在美國，12個在歐洲，3個在亞洲(北京、香港、東京)，另外3個分佈於俄羅斯和南美。下圖顯示其中36個數據中心在全球的分佈：
圖1. 2008年Google全球數據中心分佈圖
根據 Jeffrey Dean 在2009年末的一次演講和最近幾期季報可以推測出Google並沒有在2009年過多地增加全球數據中心的數量，總數應該還是稍多於36個，但很有可能在臺灣、馬來西亞、立陶宛等地增加新的數據中心。
雖然Google擁有數據中心數量很多，但是它們之間存在一定的差異，而且主要可以分爲兩類：其一是巨型數據中心，其二是大中型數據中心。
巨型數據中心 ：服務器規模應該在十萬臺以上，常坐落於發電廠旁以獲得更廉價的能源，主要用於Google內部服 務，也就是內容交付服務，而且在設計方面主要關注成本和吞吐量，所以引入了大量的定製硬件和軟件，來減低PUE並提升處理量，但其對SLA方面要求不是特 別嚴厲，只要保證絕大部分時間可用即可。下圖是Google巨型數據中心的一個代表，這個數據中心位於美國俄勒岡州北部哥倫比亞河畔的Dalles市，總 佔地面積接近30英畝，並佔用了附近一個1.8GW水力發電站的大部分電力輸出，當這個數據中心全部投入使用後，將消耗103兆瓦的電力，這相當於一箇中 小型城市的整個生活用電。
圖2. Google在美國俄勒岡州哥倫比亞河畔的巨型數據中心近景圖
大中型數據中心 ：服務器規模在千臺至萬臺左右，可用於本地交互或者關鍵業務，在設計方面上非常重視延遲和高可用 性，使得其坐落地點儘可能地接近用戶而且採用了標準硬件和軟件，比如Dell的服務器和MySQL的數據庫等，常見的PUE大概在1.5和1.9之間。本 來坐落於北京朝陽區酒仙橋附近的"世紀互聯"機房的Google中國數據中心也屬於大中型數據中心這類，其採用的硬件有DELL的工作站和Juniper 的防火牆等，下圖爲其一角。
圖3. Google前中國數據中心的一角（參[26]）
關於兩者的區別：具體請查看下錶：
| 巨型數據中心 | 大中型數據中心 | |
| 工作負載 | 內容交付 | 本地交互/關鍵業務 |
| 地點 | 離發電廠近 | 離用戶近 |
| 設計特點 | 高吞吐，低成本 | 低延遲，高可用性 |
| 服務器定製化 | 多 | 少 |
| SLA | 普通 | 高 |
| 服務器數量 | 十萬臺以上 | 千臺以上 |
| 數據中心數量 | 十個以內 | 幾十個 |
| PUE估值 | 1.2 | 1.5 |
表1. 巨型與大中型數據中心的對比表
總結
最後，稍微總結一下，首先，普通的用戶當訪問Google服務時，大多會根據其請求的IP地址或者其所屬的ISP將這個請求轉發到用戶本地的數據中 心，如果本地數據中心無法處理這個請求，它很有可能將這個請求轉發給遠端的內容交互中心。其次，當廣告客戶想接入Google的廣告系統時，這個請求會直 接轉發至其專業的關鍵業務數據中心來處理。
圖4. 總結
因爲本文是基於現有的公開資料和個人的經驗的總結和猜想，所以和Google實際的運行情況沒有任何聯繫。
本篇結束，下篇 將對Google App Engine及其主要組成部分進行介紹。