作者 Geoffrey Wiseman譯者 胡鍵 發布于 2008年4月14日 上午3時59分 社區 Architecture, SOA

?

2008年4月7號，Google在Campfire One上介紹了一種簡化創建、運行和構建伸縮性Web應用的工具——Google App Engine。簡而言之，Google App Engine允許你本地使用Google基礎設施構建Web應用，待其完工之后再將其部署到Google基礎設施之上。

這次發布的是沒有包含全部特性的預覽版，提供了一個配額系統，它限制了在預覽期間應用免費可用的存儲、CPU和帶寬。一旦預覽期結束，配額仍將免費，但是開發者需要按需購買額外資源。額外資源的價格尚未公布（甚至可能尚未確定）。

預覽版的配額包括：3個應用/開發者、500MB存儲/應用、2000封郵件/天（連續24小時）、10 GB入站帶寬、10 GB出站帶寬、200M CPU兆周、650k HTTP請求、2.5M Datastore API調用和160k URL Fetch API調用。

技術：開發環境和API

盡管Google說‘未來將支持更多的語言’，但是目前技術棧是基于Python的，它是Google認同的語言之一。出于安 全和伸縮性的目的，Google提供了一個運行在安全沙箱中的Python運行時環境，它提供對底層操作系統有限制的訪問。該環境包括標準庫，并可通過模 塊進行擴展，編寫模塊的語言目前不支持C語言。

該環境包括Python標準庫。當然，調用那些違反沙箱限制的庫方法（如打開socket或寫文件）將不會成功。為了方便起見，幾個核心特性不被支持的標準庫中的模塊被禁用了。那些引入它們的代碼會出錯。

應用代碼只能用Python書寫。不支持使用C來編寫擴展。

其他安全限制包括：出站通信（outbound communication）只能通過所提供的郵件和URL fetch API進行，通過HTTP和HTTPS作為傳輸的入站通信（inbound communication）使用標準端口，禁止文件系統寫操作和禁止子進程或代碼在請求/響應循環外執行（例如后臺操作和批操作）。

此外，Google提供了訪問一個Datastore、Google用戶帳號、URL fetch和郵件服務的API。App Engine還包括一個簡化的Web應用框架和Django 0.96.1，盡管App Engine Datastore不是關系型的，而且也不能使用全部的Django API。

Datastore API背后由Google的BigTable支持，但是它與一個簡單的對象持久化API（或一個對象關系映射框架，即使Google強調這個Datastore不是關系型的）有很多相同之處：

你們中的大多數，在使用這個Datastore時可能會有點不習慣：如我所說，它不是SQL。這是個巨大的區別。然而，我們想 了一下之后，認為這個Datastore可能會引起你們的興趣，因為它讓一些事情變簡單了。比如說，我們的Datastore沒有模式，這意味著它可以支 持任意的新屬性或列，你可以用代碼創建，無需把所有事情預先設計好并創建一個模式。這就回到了我們盡可能簡化Web應用編寫的目標：只需開始編碼就好了。 你的數據模型可以隨你應用的演變而演變。

即使Datastore違背了SQL，我們仍然支持你想要的傳統關系數據庫的許多強大功能。對于任何你提供的單個屬性或屬性集 合，Datastore都提供了高效查詢。它還支持對查詢結果的排序，包括按多屬性進行排序。它對寫操作支持事務，通過事務分組來控制。對于提取或創建大 量實體，它也支持批操作。它給你機會讓你來控制你實體的主鍵，以獲得更好的查詢效率和更短的URL。

并且，即使Datastore不是SQL，我們也為你提供了類SQL查詢以簡化查詢的表達，叫做GQL。GQL受到了jQuery和FBQL的啟發：底層的存儲不是SQL，但是幾乎你想要的所有查詢仍然可以完成。

你可能已經注意到我們的Datastore缺少一個大特性，那就就是連接（join）。這是因為連接通常是分布式系統效率問題的根源，當你有不止一臺機器時：很難在跨多個機器和多個硬盤的分布式系統上進行連接操作。

盡管Datastore API支持事務，但是它們有嚴格的限制，而且和實體組關聯：

每個實體都屬于一個實體組，在一個事務內可以操作一個或多個實體。實體組關系告訴App Engine在分布式網絡的同一部分保存幾個實體。一個事務為一個實體組設置Datastore操作，所有這些操作按組實施，如果事務失敗就全部撤銷。

當應用創建一個實體時，它可以分配另一個實體作為新實體的父。給一個新實體分配父時，將使它進入父實體所在的實體組。

沒有父的實體是根實體。一個實體的父實體也可以有父。從一個實體到根的父實體鏈就是這個實體的路徑，路徑的成員是實體的祖先。實體的父只能在創建時定義，之后就不能修改。

祖先是同一根實體的所有實體都在相同的實體組中，組中的所有實體存儲在同一Datastore節點中。單個事務可以修改單個組中的多個實體，或通過將組中現有實體變成為新實體的父來把一個新實體加到組中。

因為App Engine迫使你以一種特殊的方式（如Datastore on BigTable，而不是數據庫）來處理你的開發，Google聲稱你的應用將更易于伸縮，而且這種伸縮性幾乎是透明的：

當一個Web應用變得流行起來時，突如其來的流量可以壓垮各種規模的應用，從創業公司到大公司都發現需要一 年幾次的重新架構他們的數據庫和整個應用。通過自動復制和負載均衡，利用Bigtable和Google的可伸縮基礎設施中的其他組件，Google App Engine使得應用可以從一個用戶伸縮到百萬級用戶。

User API允許通過Google帳號進行用戶驗證和登錄，以及訪問帳號的綽號和郵件。其他更多的用戶信息可以從應用保存在Datastore中的用戶信息直接獲取。

URL fetch API能通過提取HTTP和HTTPs URL（支持GET、POST、HEAD、PUT和DELETE，因此這似乎可以支持REST功能）檢索遠程服務器的信息。

Mail API允許App Engine應用異步發送郵件，如果郵件服務器不可用時允許重試。

App Engine SDK包含模擬App Engine Python運行時環境的服務器，以及：

• 模擬模塊引入限制，只允許處理程序引入被許可的模塊，它們來自標準庫、包含在App Engine Python環境中的第三方庫，以及應用目錄中的模塊
• 模擬應用緩沖行為
• 使用本地文件模擬App Engine Datastore
• 模擬包含有登錄和注銷頁面的Google帳號，登錄參數可以是任何郵件地址。
• 通過提取你計算機的URL模擬URL fetch服務
• 使用你選擇的SMTP服務器或Sendmail配置模擬郵件服務

乍一看，絕大多數的應用配置似乎可用YAML來寫。

動機和競爭

Google的公告稱他們的動機是，簡化Web應用的構建、部署和伸縮性：

嗯，我們構建Web應用是因為我們想要更多的Web應用被創建出來。我們注意到，目前創建一個Web應用真的很難：即使部署一個最簡單的Web應用也有巨大的前端挑戰。你需要做很多事情。當然，首先你必須為你的應用編寫代碼。

但是接著，你還需書寫你的Apache Web服務器配置和啟動腳本，安裝你的數據庫，創建所有表和設置口令，安裝監視器來了解你的流量和日志，決定你如何推出代碼的新版本等等。

那只是我們注意到的技術方面的挑戰。然后，一旦你完成了所有那些系統管理員的工作，你就有了另一個挑戰：你必須著手去找你能使 用的機器來運行你的應用，不論是物理的還是虛擬的提供商?，F在，就要花錢了：即使是最簡單的應用，一周用幾次，你都必須支付一大筆預支費用來讓它在一個傳 統主機托管提供商處運行。

那么，這就是財務或物理方面的挑戰。然后，一旦你搞定了整件事情并且運行了，而且找到地方并為此付費來測試它，你又面臨了另一 個挑戰：隨著你應用的成長，你必須去維護它。你的機器崩潰了，你的配置有錯誤，你的硬盤壞了，你的流量開始增長，你必須重新分享你的數據庫，安裝更多更多 的機器。隨著應用的成長，任何事情都象是一場激戰。

所有這些激戰正是我們試圖通過App Engine避免的。它們是我們正試圖解決的問題。

其他人已經揣測出了言外之意。很多人指出了Google與Amazon和微軟在未來云計算和Web服務方面的競爭，常常將App Engine與Amazon的Web服務EC2、S3、SQS和SimpleDB相提并論：

• O'Reilly Radar認為：

  自 從Amazon Web服務有這么好的開局之后，我們都知道這只不過是時間問題（我們可以有把握地假定下一個將會是微軟）。盡管拿AWS與GAE作對比是顯而易見的，但是 它們真的不是同一類工具。Amazon已發布的一組獨立服務可以被用來創建一個通用的計算平臺。盡管這些服務可以一起工作，但是它們沒有作為整體打包在一 起。

  另一方面，App Engine是一個驅動Web應用的引擎。它將AWS提供的許多特性進行了整體打包：存儲類似S3、自動伸縮性和處理能力類似EC2，Datastore 類似SimpleDB。App Engine還提供了AWS沒有的特性，如Python運行時，Google特定的API，以及可能是最吸引人的免費服務部分。

• VentureBeat：“Google App Engine準備與Amazon競爭”

其他人暗示微軟也正攜一些工具向這個方向挺進，比如Ray Ozzie's Mesh strategy和SQL Server Data Services，但是可能已經太晚了：

• Network world 說，“Google再次領先微軟”
• ZDNet問：“Google App Engine：微軟將何時圍捕競爭者？”

看看事情的另一角度，某些人暗示這會使Google在收購方面棋高一著，這是一種風險基礎設施（venture infrastructure）形式：

• Business Week認為Google和Amazon間的競爭沒有提及這一點：鼓勵創業公司在Google的基礎設施上開發他們的應用，這使Google“不僅可以很好地了解人們想要的應用和需要克服的問題，而且能敏銳地發現Google想收購的有前途的新創業公司”。
• ZDNet補充：它可以節約Google在收購方面的金錢：“想象一下，如果收購一家已經使用Google技術的公司會省下多少時間和努力？”
• GigaOM說：“這種虧本銷售的服務將那些創業公司帶進了Google的大門，這使得這家公司可以訪問最新的想法并可從天才企業家池中做出選擇”

• 在“Google如何吃掉Amazon的午餐”中，Kevin Kelleher稱這為投資：

  在這次采訪中，我大聲地推測Amazon所做事情很像公司風險投資的（如Intel投資部）做法——投資和他們以后要合作（或者要收購）的創業公司。只是不用硬通貨，而是基礎設施。我得說，非常精明。

  高管的反應是：Amazon根本沒這么做，而且永遠不會用Web服務那么做。我心里想了一下，但是沒說：嗯，如果你們不這樣做，有人會這么做的。

  現在，有些人正在說Google正在這么做。隨著有價值的Google員工整理他們的桌子并啟動一家新的創業公司，推出GAE是Google將他們重新召回的最好策略。這也是從Amazon身下抽走地毯的絕佳方法，戰略上明智而且盈利上也明智。

反饋、分析和資源

• 遍布網上和博客的其他分析：
  • Jaiku，a Google新近收購的公司，宣布它將移植到App Engine。
  • TechCrunch
  • news.com
  • Farhan Mashraqi說：這大大推進了Python語言，和blist所做的一樣。
  • fuzzmeister在Digg上的評論暗示這會有重大影響，“這會演變成對Web站點托管和運行方式有根本性改變的事情”
  • Wayne Pan認為‘免費’角度是最大的新聞，App Engine要真正吸引人需要支持其他語言和外部服務模型。
  • Nate Koechley指出Guido Van Rossum是GAE團隊成員之一。
  • FaceReviews指出Robert Scoble在公告發布之后與Pownce進行了交談，他們覺得沒有什么特別的。
  • Adnans記錄了一些API相關的筆記。
  • Technosailor說他沒看出有什么新意，既沒有創新，也不令人感到震撼。他是個懷疑論者。
• 以下論壇已經就App Engine開始了一些討論：
  • The Wait List
  • How to debug on the server.
  • Using the django ORM
  • One-way application creation
• 預了解更多關于Google App Engine的信息：
  • 訪問Google Code上的Google App Engine站點。
  • 觀看YouTube上的視頻。
  • 參與官方論壇的討論。
  • 訪問官方博客
  • 研究application gallery或Jaiku上的一些App Engine應用。
  • 閱讀google代碼知識庫上的FAQ。
  • 閱讀一些關于App Engine的文章，包括
    • Running Django
    • Serving Dynamic Images
    • Uploading Data and Making it Searchable
    • The Django Form Validation Framework
    • Logging Events in your Application

查看英文原文：Google 'simplifies web development' with AppEngine

轉載于:https://www.cnblogs.com/Henrya2/archive/2008/12/28/1363928.html

總結

以上是生活随笔為你收集整理的Google推出Web开发利器：App Engine的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。