網址: http://www.dbanotes.net/arch/google_app_engine-intro.html
按：此爲客座博文系列。投稿人吳朱華曾在IBM中國研究院從事與雲計算相關的研究，現在正致力於研究雲計算技術。
通過前面兩篇介紹，大家應該對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的尷尬。
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帳戶就能登錄和使用。下圖爲其截屏：
圖1. 管理界面（點擊看大圖）
使用這個管理界面可執行許多操作，包括創建新的應用程序，爲這個應用設置域名，查看與訪問數據和錯誤相關的日誌，觀察主要資源的使用狀況。
本地開發環境
爲了安全起見，本地開發環境採用了沙箱（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 |
表1. 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千次 |
表2. App Engine的免費額度表
從上面免費額度來看，除了存儲數據的容量外，其它都是非常強大的。
本篇結束，下篇將對App Engine的架構進行介紹。
--EOF--