探索Google App Engine背後的奧祕

發表於2013-07-29
GoAPP

按：吳朱華曾在IBM中國研究院從事與雲端計算相關的研究，現在正致力於研究雲端計算技術。

本系列文章基於公開資料對Google App Engine的實現機制這個話題進行深度探討。在切入Google App Engine之前，首先會對Google的核心技術和其整體架構進行分析，以幫助大家之後更好地理解Google App Engine的實現。

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

  • 分散式基礎設施：GFS、Chubby 和 Protocol Buffer。
  • 分散式大規模資料處理：MapReduce 和 Sawzall。
  • 分散式資料庫技術：BigTable 和資料庫 Sharding。
  • 資料中心優化技術：資料中心高溫化、12V電池和伺服器整合。

 

分散式基礎設施

GFS

由於搜尋引擎需要處理海量的資料，所以Google的兩位創始人Larry Page和Sergey Brin在創業初期設計一套名為”BigFiles”的檔案系統，而GFS（全稱為”Google File System”）這套分散式檔案系統則是”BigFiles”的延續。

首先，介紹它的架構，GFS主要分為兩類節點：

  • Master節點：主要儲存與資料檔案相關的後設資料，而不是Chunk（資料塊）。後設資料包括一個能將64位標籤對映到資料塊的位置及其組成檔案的表格，資料塊副本位置和哪個程式正在讀寫特定的資料塊等。還有Master節點會週期性地接收從每個Chunk節點來的更新（”Heart-beat”）來讓後設資料保持最新狀態。
  • Chunk節點：顧名思義，肯定用來儲存Chunk，資料檔案通過被分割為每個預設大小為64MB的Chunk的方式儲存，而且每個Chunk有唯一一個64位標籤，並且每個Chunk都會在整個分散式系統被複制多次，預設為3次。

下圖就是GFS的架構圖：

圖1. GFS的架構圖（參片[15]）

接著，在設計上，GFS主要有八個特點：

  • 大檔案和大資料塊：資料檔案的大小普遍在GB級別，而且其每個資料塊預設大小為64MB，這樣做的好處是減少了後設資料的大小，能使Master節點能夠非常方便地將後設資料放置在記憶體中以提升訪問效率。
  • 操作以新增為主：因為檔案很少被刪減或者覆蓋，通常只是進行新增或者讀取操作，這樣能充分考慮到硬碟線性吞吐量大和隨機讀寫慢的特點。
  • 支援容錯：首先，雖然當時為了設計方便，採用了單Master的方案，但是整個系統會保證每個Master都會有其相對應的複製品，以便於在Master節點出現問題時進行切換。其次，在Chunk層，GFS已經在設計上將節點失敗視為常態，所以能非常好地處理Chunk節點失效的問題。
  • 高吞吐量：雖然其單個節點的效能無論是從吞吐量還是延遲都很普通，但因為其支援上千的節點，所以總的資料吞吐量是非常驚人的。
  • 保護資料：首先，檔案被分割成固定尺寸的資料塊以便於儲存，而且每個資料塊都會被系統複製三份。
  • 擴充套件能力強：因為後設資料偏小，使得一個Master節點能控制上千個存資料的Chunk節點。
  • 支援壓縮：對於那些稍舊的檔案，可以通過對它進行壓縮，來節省硬碟空間，並且壓縮率非常驚人，有時甚至接近90%。
  • 使用者空間：雖然在使用者空間執行在執行效率方面稍差，但是更便於開發和測試，還有能更好利用Linux的自帶的一些POSIX API。

現在Google內部至少執行著200多個GFS叢集，最大的叢集有幾千臺伺服器，並且服務於多個Google服務，比如Google搜尋。但由於GFS主要為搜尋而設計，所以不是很適合新的一些Google產品，比YouTube、Gmail和更強調大規模索引和實時性的Caffeine搜尋引擎等，所以Google已經在開發下一代GFS，代號為”Colossus”，並且在設計方面有許多不同，比如：支援分散式Master節點來提升高可用性並能支撐更多檔案，Chunk節點能支援1MB大小的chunk以支撐低延遲應用的需要。

Chubby

簡單的來說，Chubby 屬於分散式鎖服務，通過 Chubby，一個分散式系統中的上千個client都能夠對於某項資源進行”加鎖”或者”解鎖”，常用於BigTable的協作工作，在實現方面是通過對檔案的建立操作來實現”加鎖”，並基於著名科學家Leslie Lamport的Paxos演算法。

Protocol Buffer

Protocol Buffer，是Google內部使用一種語言中立、平臺中立和可擴充套件的序列化結構化資料的方式，並提供 Java、C++ 和 Python 這三種語言的實現，每一種實現都包含了相應語言的編譯器以及庫檔案，而且它是一種二進位制的格式，所以其速度是使用 XML 進行資料交換的10倍左右。它主要用於兩個方面：其一是RPC通訊，它可用於分散式應用之間或者異構環境下的通訊。其二是資料儲存方面，因為它自描述，而且壓縮很方便，所以可用於對資料進行持久化，比如儲存日誌資訊，並可被Map Reduce程式處理。與Protocol Buffer比較類似的產品還有Facebook的 Thrift ，而且 Facebook 號稱Thrift在速度上還有一定的優勢。

分散式大規模資料處理

MapReduce

首先，在Google資料中心會有大規模資料需要處理，比如被網路爬蟲（Web Crawler）抓取的大量網頁等。由於這些資料很多都是PB級別，導致處理工作不得不盡可能的並行化，而Google為了解決這個問題，引入了MapReduce這個程式設計模型，MapReduce是源自函式式語言，主要通過”Map（對映）”和”Reduce（化簡）”這兩個步驟來並行處理大規模的資料集。Map會先對由很多獨立元素組成的邏輯列表中的每一個元素進行指定的操作，且原始列表不會被更改，會建立多個新的列表來儲存Map的處理結果。也就意味著，Map操作是高度並行的。當Map工作完成之後，系統會先對新生成的多個列表進行清理（Shuffle）和排序，之後會這些新建立的列表進行Reduce操作，也就是對一個列表中的元素根據Key值進行適當的合併。

下圖為MapReduce的執行機制：

圖2. MapReduce的執行機制（參[19]）

接下來，將根據上圖來舉一個MapReduce的例子：比如，通過搜尋Spider將海量的Web頁面抓取到本地的GFS叢集中，然後Index系統將會對這個GFS叢集中多個資料Chunk進行平行的Map處理，生成多個Key為URL，value為html頁面的鍵值對（Key-Value Map），接著系統會對這些剛生成的鍵值對進行Shuffle（清理），之後系統會通過Reduce操作來根據相同的key值（也就是URL）合併這些鍵值對。

最後，通過MapReduce這麼簡單的程式設計模型，不僅能用於處理大規模資料，而且能將很多繁瑣的細節隱藏起來，比如自動並行化，負載均衡和機器當機處理等，這樣將極大地簡化程式設計師的開發工作。MapReduce可用於包括”分佈grep，分佈排序，web訪問日誌分析，反向索引構建，文件聚類，機器學習，基於統計的機器翻譯，生成Google的整個搜尋的索引”等大規模資料處理工作。Yahoo也推出MapReduce的開源版本Hadoop，而且Hadoop在業界也已經被大規模使用。

Sawzall

Sawzall可以被認為是構建在MapReduce之上的採用類似Java語法的DSL（Domain-Specific Language），也可以認為它是分散式的AWK。它主要用於對大規模分散式資料進行篩選和聚合等高階資料處理操作，在實現方面，是通過直譯器將其轉化為相對應的MapReduce任務。除了Google的Sawzall之外，yahoo推出了相似的Pig語言，但其語法類似於SQL。

分散式資料庫技術

BigTable

由於在Google的資料中心儲存PB級以上的非關係型資料時候，比如網頁和地理資料等，為了更好地儲存和利用這些資料，Google開發了一套資料庫系統，名為”BigTable”。BigTable不是一個關係型的資料庫，它也不支援關聯（Join）等高階SQL操作，取而代之的是多級對映的資料結構，並是一種面向大規模處理、容錯性強的自我管理系統，擁有TB級的記憶體和PB級的儲存能力，使用結構化的檔案來儲存資料，並每秒可以處理數百萬的讀寫操作。

什麼是多級對映的資料結構呢？就是一個稀疏的，多維的，排序的Map，每個Cell由行關鍵字，列關鍵字和時間戳三維定位．Cell的內容是一個不解釋的字串，比如下表儲存每個網站的內容與被其他網站的反向連線的文字。 反向的URL com.cnn.www是這行的關鍵字；contents列儲存網頁內容，每個內容有一個時間戳，因為有兩個反向連線，所以archor的Column Family有兩列：anchor: cnnsi.com和anchhor:my.look.ca。Column Family這個概念，使得表可以輕鬆地橫向擴充套件。下面是它具體的資料模型圖：

圖3. BigTable資料模型圖（參[4]）

在結構上，首先，BigTable基於GFS分散式檔案系統和Chubby分散式鎖服務。其次BigTable也分為兩部分：其一是Master節點，用來處理後設資料相關的操作並支援負載均衡。其二是tablet節點，主要用於儲存資料庫的分片tablet，並提供相應的資料訪問，同時Tablet是基於名為SSTable的格式，對壓縮有很好的支援。

圖4. BigTable架構圖（參[15]）

BigTable正在為Google六十多種產品和專案提供儲存和獲取結構化資料的支撐平臺，其中包括有Google Print、 Orkut、Google Maps、Google Earth和Blogger等，而且Google至少執行著500個BigTable叢集。

隨著Google內部服務對需求的不斷提高和技術的不斷地發展，導致原先的BigTable已經無法滿足使用者的需求，而Google也正在開發下一代BigTable，名為”Spanner（扳手）”，它主要有下面這些BigTable所無法支援的特性：

  • 支援多種資料結構，比如table，familie，group和coprocessor等。
  • 基於分層目錄和行的細粒度的複製和許可權管理。
  • 支援跨資料中心的強一致性和弱一致性控制。
  • 基於Paxos演算法的強一致性副本同步，並支援分散式事務。
  • 提供許多自動化操作。
  • 強大的擴充套件能力，能支援百萬臺伺服器級別的叢集。
  • 使用者可以自定義諸如延遲和複製次數等重要引數以適應不同的需求。

資料庫Sharding

Sharding就是分片的意思，雖然非關係型資料庫比如BigTable在Google的世界中佔有非常重要的地位，但是面對傳統OLTP應用，比如廣告系統，Google還是採用傳統的關係型資料庫技術，也就是MySQL，同時由於Google所需要面對流量非常巨大，所以Google在資料庫層採用了分片（Sharding）的水平擴充套件（Scale Out）解決方案，分片是在傳統垂直擴充套件（Scale Up）的分割槽模式上的一種提升，主要通過時間，範圍和麵向服務等方式來將一個大型的資料庫分成多片，並且這些資料片可以跨越多個資料庫和伺服器來實現水平擴充套件。

Google整套資料庫分片技術主要有下面這些優點：

  • 擴充套件性強：在Google生產環境中，已經有支援上千臺伺服器的MySQL分片叢集。
  • 吞吐量驚人：通過巨大的MySQL分片叢集能滿足巨量的查詢請求。
  • 全球備份：不僅在一個資料中心還是在全球的範圍，Google都會對MySQL的分片資料進行備份，這樣不僅能保護資料，而且方便擴充套件。

在實現方面，主要可分為兩塊：其一是在MySQL InnoDB基礎上新增了資料庫分片的技術。其二是在ORM層的Hibernate的基礎上也新增了相關的分片技術，並支援虛擬分片（Virtual Shard）來便於開發和管理。同時Google也已經將這兩方面的程式碼提交給相關組織。

資料中心優化技術

資料中心高溫化

大中型資料中心的PUE（Power Usage Effectiveness）普遍在2左右，也就是在伺服器等計算裝置上耗1度電，在空調等輔助裝置上也要消耗一度電。對一些非常出色的資料中心，最多也就能達到1.7，但是Google通過一些有效的設計使部分資料中心到達了業界領先的1.2，在這些設計當中，其中最有特色的莫過於資料中心高溫化，也就是讓資料中心內的計算裝置執行在偏高的溫度下，Google的能源方面的總監Erik Teetzel在談到這點的時候說：”普通的資料中心在70華氏度（21攝氏度）下面工作，而我們則推薦80華氏度（27攝氏度）”。但是在提高資料中心的溫度方面會有兩個常見的限制條件：其一是伺服器裝置的崩潰點，其二是精確的溫度控制。如果做好這兩點，資料中心就能夠在高溫下工作，因為假設資料中心的管理員能對資料中心的溫度進行正負1/2度的調節，這將使伺服器裝置能在崩潰點5度之內工作，而不是常見的20度之內，這樣既經濟，又安全。還有，業界傳言Intel為Google提供抗高溫設計的定製晶片，但云計算界的頂級專家James Hamilton認為不太可能，因為雖然處理器也非常懼怕熱量，但是與記憶體和硬碟相比還是強很多，所以處理器在抗高溫設計中並不是一個核心因素。同時他也非常支援使資料中心高溫化這個想法，而且期望將來資料中心甚至能執行在40攝氏度下，這樣不僅能節省空調方面的成本，而且對環境也很有利。

12V電池

由於傳統的UPS在資源方面比較浪費，所以Google在這方面另闢蹊徑，採用了給每臺伺服器配一個專用的12V電池的做法來替換了常用的UPS，如果主電源系統出現故障，將由該電池負責對伺服器供電。雖然大型UPS可以達到92%到95%的效率，但是比起內建電池的99.99%而言是非常捉襟見肘的，而且由於能量守恆的原因，導致那麼未被UPS充分利用的電力會被轉化成熱能，這將導致用於空調的能耗相應地攀升，從而走入一個惡性迴圈。同時在電源方面也有類似的”神來之筆”，普通的伺服器電源會同時提供5V和12V的直流電。但是Google設計的伺服器電源只輸出12V直流電，必要的轉換在主機板上進行，雖然這種設計會使主機板的成本增加1美元到2美元，但是它不僅能使電源能在接近其峰值容量的情況下執行，而且在銅線上傳輸電流時效率更高。

伺服器整合

談到虛擬化的殺手鐗時，第一個讓人想到肯定是伺服器整合，而且普遍能實現1:8的整合率來降低各方面的成本。有趣的是，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個資料中心在全球的分佈：

探索Google App Engine背後的奧祕

2008年Google全球資料中心分佈圖

　　根據Jeffrey Dean在2009年末的一次演講和最近幾期季報可以推測出Google並沒有在2009年過多地增加全球資料中心的數量，總數應該還是稍多於36個，但很有可能在臺灣、馬來西亞、立陶宛等地增加新的資料中心。

雖然Google擁有資料中心數量很多，但是它們之間存在一定的差異，而且主要可以分為兩類：其一是巨型資料中心，其二是大中型資料中心。

巨型資料中心：伺服器規模應該在十萬臺以上，常坐落於發電廠旁以獲得更廉價的能源，主要用於Google內部服務，也就是內容交付服務，而且在設計方面主要關注成本和吞吐量，所以引入了大量的定製硬體和軟體，來減低PUE並提升處理量，但其對SLA方面要求不是特別嚴厲，只要保證絕大部分時間可用即可。下圖是Google巨型資料中心的一個代表，這個資料中心位於美國俄勒岡州北部哥倫比亞河畔的Dalles市，總佔地面積接近30英畝，並佔用了附近一個1.8GW水力發電站的大部分電力輸出，當這個資料中心全部投入使用後，將消耗103兆瓦的電力，這相當於一箇中小型城市的整個生活用電。

探索Google App Engine背後的奧祕

Google在美國俄勒岡州哥倫比亞河畔的巨型資料中心近景圖

大中型資料中心：伺服器規模在千臺至萬臺左右，可用於本地互動或者關鍵業務，在設計方面上非常重視延遲和高可用性，使得其坐落地點儘可能地接近使用者而且採用了標準硬體和軟體，比如Dell的伺服器和MySQL的資料庫等，常見的PUE大概在1.5和1.9之間。本來坐落於北京朝陽區酒仙橋附近的”世紀互聯”機房的Google中國資料中心也屬於大中型資料中心這類，其採用的硬體有DELL的工作站和Juniper的防火牆等，下圖為其一角。

探索Google App Engine背後的奧祕

Google前中國資料中心的一角（參[26]）

關於兩者的區別：具體請檢視下錶：

巨型資料中心 大中型資料中心
工作負載 內容交付 本地互動/關鍵業務
地點 離發電廠近 離使用者近
設計特點 高吞吐，低成本 低延遲，高可用性
伺服器定製化 多 少
SLA 普通 高
伺服器數量 十萬臺以上 千臺以上
資料中心數量 十個以內 幾十個
PUE估值 1.2 1.5

巨型與大中型資料中心的對比表

總結

最後，稍微總結一下，首先，普通的使用者當訪問Google服務時，大多會根據其請求的IP地址或者其所屬的ISP將這個請求轉發到使用者本地的資料中心，如果本地資料中心無法處理這個請求，它很有可能將這個請求轉發給遠端的內容互動中心。其次，當廣告客戶想接入Google的廣告系統時，這個請求會直接轉發至其專業的關鍵業務資料中心來處理。

探索Google App Engine背後的奧祕

通過前面兩篇介紹，大家應該對Google強大的基礎設施有一定的瞭解。本篇開始介紹構築在這強大基礎設施之上的Google App Engine。

Google App Engine的介紹

由於釋出S3和EC2這兩個優秀的雲服務，使得Amazon已經率先在雲端計算市場站穩了腳跟，而身為雲端計算這個浪潮的發起者之一的Google肯定不甘示弱，並在2008年四月份推出了Google App Engine這項PaaS服務，雖然現在無法稱其為一個革命性的產品，但肯定是現在市面上最成熟，並且功能最全面的PaaS平臺。

Google App Engine 提供一整套開發元件來讓使用者輕鬆地在本地構建和除錯網路應用，之後能讓使用者在Google強大的基礎設施上部署和執行網路應用程式，並自動根據應用所承受的負載來對應用進行擴充套件，並免去使用者對應用和伺服器等的維護工作。同時提供大量的免費額度和靈活的資費標準。在開發語言方面，現支援Java和Python這兩種語言，併為這兩種語言提供基本相同的功能和API。

功能在功能上，主要有六個方面：

  • 動態網路服務，並提供對常用網路技術的支援，比如SSL等 。
  • 持久儲存空間，並支援簡單的查詢和本地事務。
  • 能對應用進行自動擴充套件和負載平衡。
  • 一套功能完整的本地開發環境，可以讓使用者在本機上對App Engine進行開發和除錯。
  • 支援包括Email和使用者認證等多種服務。
  • 提供能在指定時間和定期觸發事件的計劃任務和能實現後臺處理的任務佇列。

使用流程

整個使用流程主要包括五個步驟：

  • 下載SDK和IDE，並在本地搭建開發環境。
  • 在本地對應用進行開發和除錯。
  • 使用GAE自帶上傳工具來將應用部署到平臺上。
  • 在管理介面中啟動這個應用。
  • 利用管理介面來監控整個應用的執行狀態和資費。

由於本系列是專注於GAE的實現和設計兩方面，所以不會對GAE的使用有非常深入地介紹，如果希望大家對GAE的使用方面有更深的理解，具體可以參看一下GAE的官方文件。

Google App Engine的主要組成部分

主要可分為五部分：

  • 應用伺服器：主要是用於接收來自於外部的Web請求。
  • Datastore：主要用於對資訊進行持久化，並基於Google著名的BigTable技術。
  • 服務：除了必備的應用伺服器和Datastore之外，GAE還自帶很多服務來幫助開發者，比如：Memcache，郵件，網頁抓取，任務佇列，XMPP等。
  • 管理介面：主要用於管理應用並監控應用的執行狀態，比如，消耗了多少資源，傳送了多少郵件和應用執行的日誌等。
  • 本地開發環境：主要是幫助使用者在本地開發和除錯基於GAE的應用，包括用於安全除錯的沙盒，SDK和IDE外掛等工具。

應用伺服器

應用伺服器依據其支援語言的不同而有不同的實現。

Python的實現

Python版應用伺服器的基礎就是普通的Python 2.5.2版的Runtime，並考慮在在未來版本中新增對Python 3的支援，但是因為Python 3對Python而言，就好比Java2之於Java1，跨度非常大，所以引入Python3的難度很大。在Web技術方面，支援諸如Django，CherryPy，Pylons和Web2py等Python Web框架，並自帶名為”WSGI”的CGI框架。雖然Python版應用伺服器是基於標準的Python Runtime，但是為了安全並更好地適應App Engine的整體架構，對執行在應用伺服器內的程式碼設定了很多方面的限制，比如不能載入用C編寫Python模組和無法建立Socket等。

Java的實現

在實現方面，Java版應用伺服器和Python版基本一致，也是基於標準的Java Web容器，而且選用了輕量級的Jetty技術，並跑在Java 6上。通過這個Web容器不僅能執行常見的Java Web技術，包括Servlet，JSP，JSTL和GWT等，而且還能跑大多數常用的Java API（App Engine有一個The JRE Class White List來定義哪些Java API能在App Engine的環境中被使用）和一些基於JVM的指令碼語言，例如JavaScript，Ruby或Scala等，但同樣無法建立Socket和Thread，或者對檔案進行讀寫，也不支援一些比較高階的API和框架，包括JDBC，JSF，Struts 2，RMI，JAX-RPC和Hibernate等。

Datastore

Datastore提供了一整套強大的分散式資料儲存和查詢服務，並能通過水平擴充套件來支撐海量的資料。但Datastore並不是傳統的關係型資料庫，它主要以”Entity”的形式儲存資料，一個Entity包括一個Kind（在概念上和資料庫的Table比較類似）和一系列屬性。

Datastore提供強一致性和樂觀（optimistic）同步控制，而在事務方面，則支援本地事務，也就是在只能同一個Entity Group內執行事務。

在介面方面，Python版提供了非常豐富的介面，而且還包括名為GQL的查詢語言，而Java版則提供了標準的JDO和JPA這兩套API。

而且Google已經在今年的Google I/O大會上宣佈將在未來的App Engine for Business套件中包含標準的SQL資料庫服務，但現在還不確定這個SQL資料庫的實現方式，是基於開源的MySQL技術，還是基於其私有的實現，這是一個問題。

服務

Memcache

Memcache是大中型網站所備的服務，主要用來在記憶體中儲存常用的資料，而App Engine也包含了這個服務。有趣的是App Engine的Memcache也是由Brad Fitzpatrick開發。

URL抓取（Fetch）

App Engine的應用可以通過URL抓取這個服務抓取網上的資源，並可以這個服務來與其他主機進行通訊。這樣避免了應用在Python和Java環境中無法使用Socket的尷尬。

Email

App Engine應用使用這個服務來利用Gmail的基礎設施來傳送電子郵件。

計劃任務（Cron）

計劃服務允許應用在指定時間或按指定間隔執行其設定的任務。這些任務通常稱為Cron job。

圖形

App Engine 提供了使用專用影像服務來操作影像資料的功能。影像服務可以調整影像大小，旋轉、翻轉和裁剪影像。它還能夠使用預先定義的演算法提升圖片的質量。

使用者認證

App Engine的應用可以依賴Google帳戶系統來驗證使用者。App Engine還將支援OAuth。

XMPP

　　在App Engine上執行的程式能利用XMPP服務和其他相容XMPP的IM服務（比如Google Talk）進行通訊。

任務佇列（Task Queue）

App Engine應用能通過在一個佇列插入任務（以Web Hook的形式）來實現後臺處理，而且App Engine會根據排程方面的設定來安排這個佇列裡面的任務執行。

Blobstore

因為Datastore最多支援儲存1MB大小的資料物件，所以App Engine推出了Blobstore服務來儲存和呼叫那些大於1MB但小於2G的二進位制資料物件。

Mapper

Mapper可以認為就是”Map Reduce”中的Map，也就是能通過Mapper API對大規模的資料進行平行的處理，這些資料可以儲存在Datastore或者Blobstore，但這個功能還處於內部開發階段。

Channel

其實Channel就是我們常說的”Comet”，通過Channel API能讓應用將內容直接推至使用者的瀏覽器，而不需常見的輪詢。

除了Java版的Memcache，Email和URL抓取都是採用標準的API之外，其他服務無論是Java版還是Python版，其API都是私有的，但是提供了豐富和細緻的文件來幫助使用者使用。

管理介面

用了讓使用者更好地管理應用，Google提供了一整套完善的管理介面，地址是http://appengine.google.com/ ，而且只需使用者的Google帳戶就能登入和使用。下圖為其截圖：

探索Google App Engine背後的奧祕

管理介面

　　使用這個管理介面可執行許多操作，包括建立新的應用程式，為這個應用設定域名，檢視與訪問資料和錯誤相關的日誌，觀察主要資源的使用狀況。

本地開發環境

為了安全起見，本地開發環境採用了沙箱（Sandbox）模式，基本上和上面提到的應用伺服器的限制差不多，比如無法建立Socket和Thread，也無法對檔案進行讀寫。Python版App Engine SDK是以普通的應用程式的形式釋出，本地需要安裝相應的Python Runtime，通過命令列方式啟動Python版的Sandbox，同時也可以在安裝有PyDev外掛的Eclipse上啟動。Java版App Engine SDK是以Eclispe Plugin形式釋出，只要使用者在他的Eclipse上安裝這個Plugin，使用者就能啟動本地Java沙箱來開發和除錯應用。

程式設計模型

因為App Engine主要為了支撐Web應用而存在，所以Web層程式設計模型對於App Engine也是最關鍵的。App Engine主要使用的Web模型是CGI，CGI全稱為”Common Gateway Interface”，它的意思非常簡單，就是收到一個請求，起一個程式或者執行緒來處理這個請求，當處理結束後這個程式或者執行緒自動關閉，之後是不斷地重複這個流程。由於CGI這種方式每次處理的時候，都要重新起一個新的程式或者執行緒，可以說在資源消耗方面還是很厲害的，雖然有執行緒池（Thread Pool）這樣的優化技術。但是由於CGI在架構上的簡單性使其成為GAE首選的程式設計模型，同時由於CGI支援無狀態模式，所以也在伸縮性方面非常有優勢。而且App Engine的兩個語言版本都自帶一個CGI框架：在Python平臺為WSGI。在Java平臺則為經典的Servlet。最近，由於App Engine引入了計劃任務和任務佇列這兩個特性，所以App Engine已經支援計劃任務和後臺程式這兩種程式設計模型。

限制和資費

首先，談一下App Engine的使用限制，具體請看下錶：

類別 限制
每個開發者所擁有的專案 10個
每個專案的檔案數 1000個
每個專案程式碼的大小 150MB
每個請求最多執行時間 30秒
Blobstore（二進位制儲存）的大小 1GB
HTTP Response的大小 10MB
Datastore中每個物件的大小 1MB

App Engine的使用限制

這些限制對開發者是一種障礙，但對App Engine這樣的多租戶環境而且卻是非常重要的，因為如果一個租戶的應用消耗過多的資源的話，將會影響到在臨近應用的正常使用，而App Engine上面這些限制就是為了是執行在其平臺上面應用能安全地執行著想，避免了一個吞噬資源或惡性的應用影響到臨近應用的情況。除了安全的方面考慮之後，還有伸縮的原因，也就是說，當一個應用的所佔空間（footprint）處於比較低的狀態，比如少於1000個檔案和大小低於150MB等，那麼能夠非常方便地通過複製應用來實現伸縮。

接著，談一下資費情況，App Engine的資費情況主要有兩個特點：其一是免費額度高，現有免費的額度能支撐一箇中型網站的執行，且不需付任何費用。其二是資費專案非常細粒度，普通IaaS服務資費，主要就是CPU，記憶體，硬碟和網路頻寬這四項，而App Engine則除了常見的CPU和網路頻寬這兩項之外，還包括很多應用級別的專案，比如：Datastore API和郵件API的呼叫次數等。具體資費的機制是這樣的：如果使用者的應用每天消費的各種資源都低於這個額度，那們使用者無需支付任何費用，但是當免費額度被超過的時候，使用者就需要為超過的部分付費。因為App Engine整套資費標準比較複雜，所以在這裡就主要介紹一下它的免費額度，具體請看下錶：

型別 數量（每天）
郵件API呼叫 7000次
傳出（outbound）頻寬 10G
傳入（inbound）頻寬 10G
CPU時間 46個小時
HTTP請求 130萬次
Datastore API 1000萬次
儲存的資料 1G
URL抓取的API 657千次

App Engine的免費額度表

從上面免費額度來看，除了儲存資料的容量外，其它都是非常強大的。

本篇將首先介紹App Engine的一些設計理念，接著將對App Engine的組成部分等進行介紹。

設計理念

App Engine在設計理念方面，主要可以總結為下面這五條：

  • 重用現有的Google技術：大家都知道，重用是軟體工程的核心理念之一，因為通過重用不僅能減低開發成本，而且能簡化架構。在App Engine開發的過程中，重用的思想也得到了非常好的體現，比如Datastore是基於Google的BigTable技術，Images服務是基於Picasa的，使用者認證服務是利用Google Account的，Email服務是基於Gmail的等。
  • 無狀態：為了讓更好地支援擴充套件，Google沒有在應用伺服器層儲存任何重要的狀態，而主要在Datastore這層對資料進行持久化，這樣當應用流量突然爆發時，可以通過為應用新增新的伺服器來實現擴充套件。
  • 硬限制：App Engine對執行在其之上的應用程式碼設定了很多硬性限制，比如無法建立Socket和Thread等有限的系統資源，這樣能保證不讓一些惡性的應用影響到與其臨近應用的正常執行，同時也能保證在應用之間能做到一定的隔離。
  • 利用Protocol Buffers技術來解決服務方面的異構性：應用伺服器和很多服務相連，有可能會出現異構性的問題，比如應用伺服器是用Java寫的，而部分服務是用C++寫的等。Google在這方面的解決方法是基於語言中立，平臺中立和可擴充套件的Protocol Buffer，並且在App Engine平臺上所有API的呼叫都需要在進行RPC（Remote Procedure Call，遠端方面呼叫）之前被編譯成Protocol Buffer的二進位制格式。
  • 分散式資料庫：因為App Engine將支撐海量的網路應用，所以獨立資料庫的設計肯定是不可取的，而且很有可能將面對起伏不定的流量，所以需要一個分散式的資料庫來支撐海量的資料和海量的查詢。

組成部分

探索Google App Engine背後的奧祕

GAE的架構圖（圖源自參[6]）

　　簡單而言，其架構可以分為三個部分：前端，Datastore和服務群：

前端

共包括四個模組：

  • Front End：既可以認為它是Load Balancer，也可以認為它是Proxy，它主要負責負載均衡和將請求轉發給App Server（應用伺服器）或者Static Files等工作。
  • Static Files：在概念上，比較類似於CDN（Content Delivery Network，內容分發網路），用於儲存和傳送那些應用附帶的靜態檔案，比如圖片，CSS和JS指令碼等。
  • App Server：用於處理使用者發來的請求，並根據請求的內容來呼叫後面的Datastore和服務群。
  • App Master：是在應用伺服器間排程應用，並將排程之後的情況通知Front End。

Datastore

它是基於BigTable技術的分散式資料庫，雖然其也可以被理解成為一個服務，但是由於其是整個App Engine唯一儲存持久化資料的地方，所以其是App Engine中一個非常核心的模組。其具體細節將在下篇和大家討論。

服務群

整個服務群包括很多服務供App Server呼叫，比如Memcache，圖形，使用者，URL抓取和任務佇列等。

Python版和Java版App Engine在實現方面的區別

因為大多數服務都可以被這兩個版本共享，所以兩者之間的區別主要集中在App Server端，Python版App Server應該是經過Google修改的Python Runtime，版本號應該是2.5.2，而Java版App Server是基於Jetty 6的，因為它的體積和最常用的Tomcat相比更嬌小，這樣能使得一臺伺服器支援更多的應用，而且其應該經過Google的一定的修改。

流程

在這裡舉一個普通的HTTP請求的處理流程為例：

  • 使用者傳送一個HTTP請求。
  • Front End接受這個請求，並將這個請求轉發給一個空閒的App Server。
  • App Server會處理這個請求。
  • 檢查用於處理這個請求的Handler是不是已經被初始化了，如果沒有的話，需要對這個Handler進行初始化。
  • 呼叫服務群的使用者認證服務來對使用者進行認證，如果失敗的話，需要終止整個請求的處理工作，並返回使用者無法被認證的資訊。
  • 檢視這個請求所需的資料是否已經快取在Memcahe中，如果沒有的話，將對Datastore發出查詢請求來得到資料。
  • 通過整合上步得到資料來生成相關的HTML，並返回給使用者。
  • 由於HTML裡面會包含對一些靜態檔案的引用，比如圖片和CSS等，所以當使用者收到HTML之後，還會通過Front End對Static Files裡面儲存的靜態檔案進行讀取。

本篇會首先會從程式設計師角度來介紹一下Datastore在使用方面的一些資訊，之後會接著介紹Datastore是如何構建的。

使用方面

首先，在程式設計方面，Datastore是基於”Entity（實體）”這個概念，而且Entity和”物件”這個概念比較類似，同時Entity可以包括多個Property（屬性），Property的類別有整數，浮點和字串等，比如，可以設計一個名為”Person”的Entity，它包含名為”Name”的字串Property和名為”Age”的整數Property。由於Datastore是”Schema-less”的，所以資料的Schema都由應用維護，而且能非常方便地對一個Entity所包含的屬性進行增刪和修改。在儲存方面，一個Entity的例項可以被認為是一個普通的”Row（行）”，而包含所有這種Entity的例項的Table被稱為Kind，比如，所有通過”Person”這個Entity生成例項，比如小吳，小朱和小華等，它們都會存放在同一個名為”Person”的Kind中。在結構方面，雖然也能通過特定的方式在Datastore中實現關係型結構，但是Datastore在設計上是為層次（Hierarchical）性結構”度身定做”的，有Root Entity和Child Entity之分，比如，可以把”Person”作為Root Entity（父實體），”Address”作為”Person”的Child Entity，兩者合在一起可以稱為一個”Entity Group”。這樣做的好處是能將這兩個實體集中一個BigTable本地分割槽中，而且能對這兩個實體進行本地事務。

接下來，將談一下Datastore支援那些高階功能：其一是提供名為GQL（Google Query Language）的查詢語言，GQL是SQL的一個非常小的子集，包括對”>”，”<”和”=”等操作符。其二是App Engine會根據程式碼中查詢語句來自動生成相應Index，但不支援對Composite Index生成。其三是雖然由於Datastore分散式的設計，所以在速度方面和傳統的關係型資料庫相比一定的差距，但是Google的架構師保證大部分對Datastore的操作能在200ms之內完成，同時也得益於它的分散式設計，使得它在擴充套件性方面特別出色。其四是Datastore也支援在實體之間建立關係，比如在Python版App Engine中可以使用ReferenceProperty在實體間構建一對多和多對多的關係。

下表為Datastore和傳統的關係型資料庫之間的比較：

Datastore 關係型資料庫
SQL支援 只支援一些基本的查詢 全部支援
主要結構 層次（Hierarchical） 關係
Index 部分可自動建立 手動建立
事務 只支援在一個Entity Group內執行 支援
平均執行速度（ms） 低於200 低於100
擴充套件型 非常好 很困難，而且需要進行大量的修改

Datastore和關係型資料庫之間的比較

　　最後，在介面方面，Python版提供一套私有的API和框架，在基本功能方面，比較容易學習，但在部分高階功能方面，比如關係和事務等方面，學習難度很高；Java版的API是基於JDO和JPA這兩套官方的ORM標準，但是和現在事實的標準Hibernate有一定的差異。

實現方面

在實現方面，Datastore是在BigTable的基礎上構建的，所以本段會首先重新介紹一下BigTable，之後會介紹Datastore的兩個組成部分：Entities Table和Index，最後會講一下它在事務和備份這兩方面所採用的機制。

BigTable

在本系列的第一篇已經按照Google的Paper對BigTable技術做了一定的介紹，但其實BigTable本身其實沒有之前介紹的那樣複雜，其實就是一個非常巨大的Table，這也是是它之所以名為”BigTable”的原因，而且結構非常簡單，就是一個個ROW，每個ROW都有一個Name和一組Cloumn，但是為了支援海量的資料，它將這個大的Table進行分片（Sharding）處理，每臺伺服器儲存一個海量的Table的一小部分，並且為了查詢效率，會對這個Table進行排序。就像App Engine的創始人之一Ryan Barrett所說的那樣”BigTable is a sharded, sorted array “。

探索Google App Engine背後的奧祕

BigTable簡化版模型

　　在功能方面，首先，BigTable支援基本的CRUD操作，也就是增加(Create)，查詢(Read)，更新(Update)和刪除(Delete)。其次支援對Single-Row的事務與基於字首和範圍的掃描。

Entities Table

它是Datastore最核心的Table，是以BigTable的形式存在的，主要用於儲存所有的Entity，而且是格式非常簡單，每行都會有一個Row Name，也稱為Entity Key（可認為它是一個Entity的Primary Key），而且只有唯一一個Column，主要用於存放被序列化的Entity。每個Entity的Key的生成是基於它的父Entity（如果有的話）和其父之上的Entity，直到其Root Entity。以下圖為例，timmy的父Entity是jane，jane的父Entity兼Root Entity是Ethel，所以最後timmy的Entity Key是”/Grandparent:Ethel/Parent:Jane/Child:Timmy”。

探索Google App Engine背後的奧祕

Entity Key的例子

Index

Index主要是為方便和加速查詢而生的，所以在切入Index之前，先介紹一下Datastore主要支援那些查詢，主要有三類：其一是基於Kind的，其二是基於Property值的，其三是基於多個Property值的。

Index表也是以BigTable的形式存在，但是和上面的Entities Table是分離的，主要用來單獨存放那些需要被Index的資料，而且由於怕Index表體積太大，所以不會有時將其放置在記憶體中以提升查詢速度。

主要有下面這幾種Index表：

  • Kind Index：用於加速那些用於獲取所有屬於某個Kind的Entity的查詢，比如把所有屬於Person這個Kind的Entity，包括小吳，小朱和小華等提取出來，Kind Index表每行有Kind和Entity Key這兩個列，此Index會有系統自動生成。
  • Single-property Index：用於加速那些基於單一屬性值的查詢，比如要找出所有Age在20之下的Person，Age就是所謂的那個單一屬性值，Single-property Index表每行除了Kind和Entity Key之外，還有屬性名和屬性值這兩個列，此Index也會有系統自動生成，還會根據升降序的不同，生成兩個表。
  • Composite Index：用於加速那些基於對多個屬性值的查詢，Composite Index表基本和上面的Single-property Index表非常類似，但是每行包括多個屬性名和屬性值，而且由於此Index消耗資源非常多，所有由開發人自己確定是不是需要這個Index，系統不自動生成。

事務

原則上所有對單一Entity的Write操作都是事務的，並基於上面提到的BigTable的Single-Row事務和Optimistic Concurrency Control這兩個技術，下面是流程：首先，系統會讀這個Entity的Committed Timestamp（提交時間戳），Write會以序列（Serialized）的形式寫入到BigTable的日誌中，之後，系統會將日誌更新到BigTable的表中，如果成功的話，系統會更新這個Entity的Committed Timestamp，但如果系統發現在更新之前，Committed Timestamp發生了變化，也就是說另一個事務在這個事務執行過程中已經對這個Entity進行了操作，在這個時候，系統會重新執行這個事務。由於在整個事務過程採用Optimistic Concurrency Control，而不是Locking，所以在吞吐量方面表現不錯。

如果要對多個Entity執行事務，那就需要將這幾個Entity設為一個Entity Group，也就意味著將這幾個Entity放在同一臺物理機上。在執行的時候，會將以Root Entity的Committed Timestamp為準來對所有參與事務的Entity進行和上面差不多的事務操作。

備份

與BigTable基於Row級別的備份不同的是，Datastore是基於Enity Group級別，而且採用Paxos演算法，所以Datastore的備份方法比BigTable的更安全。

總體而言，Datastore在設計理念上和傳統的關係型資料庫有很大的不同，所以其在反應速度和寫資料方面不是最優的，但是現在Web應用以讀為主，而且需要能通過簡單的擴充套件就能支援其海量的資料，而這兩點卻是Datastore所擅長，所以Datastore非常適合支撐Web應用。

本篇是本系列的最終章，將總結一下App Engine在使用方面的注意點，最佳實踐和適用場景，最後會談一下我對App Engine的一些期望。

注意點

  • 執行速度偏慢：由於其分散式的設計，所以在速度方面不是最優的，比如普通的Memcache能在幾毫秒完成操作，而App Engine的Memcache則大概需要50(毫)秒才能完成操作。
  • 私有API：其API有很多都是私有，特別是在其服務方面，雖然Google提供了很不錯的文件，但是在學習和移植等方面，成本都很高。
  • 執行會出現失敗的情況：根據很多人的實際經驗，App Engine會不定時出現執行失敗的情況，特別是Datastore和URLFetch這兩部分，雖然Google已經將Datastore方面出現錯誤的機率從原先的0.4降至現在的0.1，但是失敗的情況是很難避免的。
  • 有時會停機：雖然總體而言，停機並不頻繁，但是在今年初出現長達136分鐘故障導致部分使用者的應用無法正常執行，其發生原因來自於其備份資料中心出現了問題。
  • 無法選擇合適的資料中心：比如，你應用所面對的使用者主要在歐洲，但是你應用所屬App Engine伺服器卻很有可能是被部署在一個美國的資料中心內，雖然你的應用很有可能在將來移動至歐洲某個資料中心，但是你卻無法控制整個過程。
  • 有時會處理請求超時：雖然能平均在100至200ms之間完成海量的請求，但是有時會出現處理請求超時的情況。
  • 不支援裸域名：只支援類似CNAME的子域名。

最佳實踐

  • 適應App Engine的資料模型：因為其資料模型，並不是傳統的關係模式，而且在效能方面表現也和關係型資料庫差別很大，所以如果想要用好非常關鍵的Datastore，那麼理解和適應其資料模型是不可或缺的。
  • 對應用進行切分：由於App Engine對每個應用都有一定資源限制，而且為了讓應用更SOA化和更模組化，可以對一個應用切分多個子應用，比如，可以分成一個用於前端的Web應用和多個用於REST服務的後臺應用。
  • 極可能多地利用Memcache，這樣不僅能減少昂貴的Datastore操作，而且能減輕Datastore的壓力。
  • 在上面提到過，由於App Engine在執行某些操作時會出現失敗的情況，比如Datastore方面，所以要在設計和實現這兩方面做好相應的異常處理工作。
  • 由於Datastore不是關係型資料庫，導致在執行常見的求總數操作時顯的有點”捉襟見肘”，所以最好使用Google推薦的Sharded Counters技術來計算總數。
  • 由於Blobstore還只是剛走出試驗期而已，而且其他模組對靜態檔案（比如圖片等）支援不佳，比如Datastore只支援1MB以內的物件，同時每個應用只能最多上傳一千個檔案，而且速度不是最優，所以推薦使用其他專業的雲端儲存，比如Amazon的S3或者Google馬上就要推出的Google Storage等。
  • 儘量使用批處理方式，不論是在使用Datastore還是傳送郵件等。
  • 不要手動建立Index：因為App Engine會自動根據你在程式碼中查詢來建立相關的Index。

適用場景

現在而言，App Engne主要適用於下面這三個場景：

  • Web Hosting：這是最常見的場景，在App Engine上已經部署了數以十萬計的小型網站（其中有很多主要為了學習目的），而且還部署了一些突發流量很大的網站，其中最著名的例子就是美國白宮的”Open For Questions”這個站點，主要用於讓美國人民給奧巴馬總統提問的，這個站點在短短的幾個小時內處理接近百萬級別的流量。
  • REST服務：這也是在App Engine平臺上很常見的場景，最出名的例子就是BuddyPoke，BuddyPoke的客戶端就是一個Flash應用，在使用者的瀏覽器上執行，而它的伺服器端則是以REST服務的形式放置在App Engine上，每當Flash客戶端需要讀取和儲存資料的時候，它都會發請求給後端的REST服務，來讓其執行相關的Datastore操作。
  • 依賴Google服務的應用：比如應用能夠通過App Engine的Email服務來傳送大規模的電子郵件。

未來的期望

  • 更穩定的表現，更少的超時異常和更快的反應速度，特別是在Datastore和Memcached這兩方面。
  • 支援對資料中心的選擇，雖然現在App Engine會根據應用的使用者群的所在地來調整應用所在的資料中心，但由於整個過程對開發者而言是不可控的，所以希望能在建立應用的時候，能讓使用者自己選擇合適的資料中心。
  • SLA，如果App Engine能像S3那樣設定一些SLA條款，這樣將使使用者更放心地在App Engine上部署應用。
  • 新的語言：比如PHP，但是如果在現有的App Engine架構上新增一門新的語言，整個工作量會非常大的，因為App Engine有接近一半的模組是語言特定的，比如應用伺服器和開發環境等，所以短期內我認為不太可能支援新的語言。

總體而言，Google App Engine是Google大戰略中一個不可分割的一部分，因為Google希望能通過App Engine來降低Web應用開發的難度，只要難度降低了，那麼Web應用替代客戶端應用的整體速度將會加快，如果出現這樣的情況的話，那麼將會對Google今後的發展非常有利。

本系列文章結束。

參考資料：

 

相關文章