我的《云计算核心技术剖析》读书笔记之Google App Engine

一、历史

Amazon发布了 S3和EC2这两个优秀的云服务，Salesforce也推出了其精心设计的 Force.com乎台，这也是业界第一款PaaS服务，身为云计算这个浪潮发起者之一的Google不甘 示弱，也推出了 •款PaaS服务来帮助用户快速搭建Web应用，并将其部署至Google的某础设 施之上，使用户无需在运维方面花时间和精力，这就是Google App Engine。表3-5列出了它主要的一些里程碑。

表3-5 Google App Engine的里程碑

二、功能

在设计上，和上面提到的Force.com主要支持商业应用不同的是，Google AppEngine主要 支持普通的Web类应用，并提供下面6方面的功能。

□支持Web应用，并提供对常用网络技术的支持，比如SSL等。

□提供持久存储空间，并支持简单的査询和本地事务。

□能对应用进行自动扩展和负载平衡。

□ 一套功能完整的本地开发环境，可以让用户在本机上对基T App Engine的应用进行调试。 口支持E-mail、用户认证和Memcache等多种服务。

□提供能在指定时间触发事件的计划任务和能实现后台处理的任务队列。

三、使用流程

在使用方面，AppEngine是属于比较容易的，它的整个使用流程主要槪括为以下5个步骤。

(1) 下载SDK和IDE，并在本地搭建开发环境。

(2) 在本地对应用进行开发和调试。

⑶使用App Engine自带上传工具来将应用部署到平台上。

(4) 在管理界面中启动这个应用。

(5) 利用管理界而来监控整个应用的运行状态和资费。

四、主要组成部分

整个App Engine主要卩]*分为5个模块。

□应用服务器。主要是用于接收来自于外部的Web请求。

□ Datastore。主要用干对信息进行持久化，并基于Google著名的BigTable技术。

□服务。除了必备的应用服务器和Datastore之外，App Engine还自带很多服务来帮助开

发者，比如Memcache、邮件、网页抓取、任务队列和XMPP等。

□管理界面。主要用于管理应用并监控应用的运行状态，比如消耗了多少资源，发送了多 少邮件和应用运行的H志等。

□本地开发环境。主要是帮助用户在本地开发和调试基于App Engine的应用，包括用于 安全调试的沙盒、SDK和IDE插件等工具。

接下来将对这5个模块进行详细介绍。

1.应用服务器

在应用服务器这块，App Engine会依据其支持语言的不同而有不同的实现。下面将分別介 绍Python版和Java版的实现。

• Python從的实现

Python版应用服务器的基础就是普通的Python 2.5.2版的Rimtime，并考虑在未来版本中添

加对Python 3的支持。但由于Python 3对Python而言，就好比Java 2之于Java 1,跨度非常大， 所以引入Python3的难度很大a在Web技术方面，支持诸如Django、CherryPy、Pylons和Web2py 等Python Web框架，并自带名为WSGI的CGI框架。虽然Python版的应用服务器是基于标准 的PythonRimtime，但是为了安全并更好地适应AppEngine的整体架构，对运行在应用服务器 内的代码设置f很多方商的限制，比如不能加载用C编写的Python模块和无法创建Socket (端 口）等。

• Java版的实现

在实现方面，Java版的应用服务器和Python版基本一致，也是基于标准的Java Web容器， 而且选用了轻量级的Jetty技术，并跑在Java6上。通过这个Web容器，不仅能运行常见的Java Web技术，包括Servlet、JSP、JSTL和GWT等，rfn•且还能跑大多数常用的Java API (App Engine 的The JRE Class White List用来定义哪些Java API能在App Engine的环境中被使用）和一些某 于JVM的脚本语言，如JavaScript、Ruby或Scala等，但N样无法创建Socket和线程或者对文 件进行读写，也不支持一些比较髙级的API和框架，包括JDBC、JSF、Struts2、RM1、MX-RPC 和 Hibernate 等。

2. Datastore

Datastore提供了一整套强大的分布式数据存储和査询服务，并能通过水平扩展来支撑海量 数据。但Datastore并不是传统的关系型数据库，它主要以Entity的形式存储数据。一个Entity 包括一个Kind (它在槪念上和数据库的表格比较类似）和一系列属性。

Datastore提供强一致性和乐观同步控制，而在事务方面则支持本地事务，也就是只能在同 一个实体组（Entity Group)内执行事务。

在接U方面，Python版提供/非常丰富的接U,而且还包括名为GQL的査询语言，rfrtJava 版则提供T标准的JDO和JPA这两套API。

Google已经在2010年的Google 1/0大会上宣布将在未来的App Engine for Business套件中 包含标准的SQL数据库服务，但现在还不确定这个SQL数据库的实现方式，即到底是基于开 源的MySQL技术，还是基于其自己的私有实现。

3. 服务

为了吏好地支撑应用的运行，App Engine提供了非常多的服务，具体有下面这11种。

• Memcache

Memcache是大中型网站必备的服务，主要用来在内存中存储常用的数据，而App Engine 也包含了这个服务。有趣的是，App Engine的Memcache也是由Memcache的原作者Brad Fitzpatrick 开发的。

• URL抓取（Fetch)

App Engine的应用可以通过URL抓取这个服务来抓取网上的资源，并可以通过这个服 务来与其他主机进行通信。这样就避免了应用在Python和Java环境中无法使用Socket的 尴尬。

• E-mail

App Engine应用可以通过这个服务来利用Gmail的基础设施发送电子邮件。

•计划任务（Cron)

计划任务服务允许应用在指定时间或按指定间隔执行其设定的任务，这些任务通常称为 Cron Job 0

參图像（Image)

App Engine提供了专用的图像服务來操作图像数据。同时，图像服务可以用来调整图像大 小，旋转、翻转和裁剪图像，而且它还能够使用预先定义的算法提升图片质量。

•用户认证

App Engine的应用可以依赖Google账户系统来验证用户。App Engine还将支持OAuth。

• XMPP

在App Engine上运行的程序能利用XMPP服务和其他兼容XMPP的IM服务（比如Google Talk)进行通信。

•任务队列

App Engine应用能通过在一个队列插入任务（以Web Hook的形式）来实现后台处理，而 且App Engine会根据调度方面的设置来安排这个队列里面的任务执行。

• Blobstore

因为Datasto^e最多支持存储lMB大小的数据对象，所以AppEngine推出了Blobstore(二 进制存储）服务来存储和调用那些太于1MB但小于2GB的二进制数据对象。

• Mapper

Mapper可以认为就是MapReduce中的Map，也就是能通过Mapper API对大规模数据进 行并行处理，而这些数据可以存储在Datastore或者Blobstore，但这个功能还处于内部开发 阶段。

• Channel

Channd其实就是我们常说的Comet技术。通过ChanndAPI，能让应用将内容直接推至用 户的浏览器，而不需常见的轮询（Poll)。

除了 Java版的Memcache、E-mai丨和URL抓取采用标准的API之夕卜，其他服务无论是Java 版的还是Python版的，其API都是私有的，但是它们提供了丰富、细致的文档来帮助用户使 用。

4. 管理界面

为了让用户更好地管理应用，Google提供了一整套完善的管理界面（其地址是http:// appengine.google.com/)，而且只需用户的Google账户就能登录和谏用。图3_5为Google管理 界面的截屏。

使用这个管理界面可执行许多操作，包括创建新的应用程序，为这个应用设置域名，査看 与访问数据和错误相关的日志，査询数据库中的数据，观察主要资源的使用状况和设置用于网络安全的黑名单（Blacklist)等。

5. 本地开发环境

为了安全起见，本地开发环境采用f沙盒模式，其限制基本上和上面提到的应用服务器差 不多，比如无法创建Socket和线程，也无法对文件进行读写。和应用服务器相同的是，SDK会 依据芄支持语言的不同而有不同的实现。Python版的App Engine SDK是以普通的应用程序的 形式发布的，本地需要安装相应的Python运行时（Runtime),通过命令行方式启动Python版 的沙盒，同时也可以在安装有PyDev插件的Eclipse上启动。Java版的App Engine SDK是以 Eclispe插件形式发布的，只要用户在他的Eclipse上安装这个插件，用户就能启动本地Java沙 盒来开发和调试应用。

五、编程模型

就像上面所提到的那样，App Engine主要为了支撑Web应用而存在，所以Web层编程模 型对于App Engine也是最关键的。而App Engine主要使用的Web模型是CGI(Common Gateway Interface，通用网关接口），它的意思非常简单，就是当收到一个请求时，启动一个进程或者线 程来处理这个请求，处理结束后这个进程或者线程将自动关闭，之后会不断地重复这个流程。 由于CGI这种编程模型在每次处理的时候都要重新启动一个新的进程或者线程，可以说在资源 消耗方面还是很厉害的，即便有线程池这样的优化技术。但是由于在架构上的简单性，CG1还 是成为App Engine首选的编程模型，同时由于CGI支持无状态模式，所以在伸缩性方面也非 常有优势。而且App Engine的两个语言版本都自带一个CGI框架：在Python平台为WSGI， 在Java平台则为经典的Servlet。最近，由于App Engine引入了计划任务和仟务队列这两个特 性，所以App Engine也已经支持计划仟务和后台进程这两种编程模型。 

3.4.6限制和资费

首先，介绍一下App Engine的使用限制，具体情况见表3-6。

表3-6 App Engine的使用限制

虽然这些限制对开发者是一种障碍，但对App Engine这样的多租户环境却是非常電要的。 因为如果一个租户的应用消耗过多资源的话，将会影响到临近应用的正常使用，而App Engine 上面这些限制就是为了能安全运行在其平台上面的应用，避免了一个吞噬资源或恶性的应用影 响到临近应用的情况。除了安全方面的考虑之外，还有伸缩的原因。也就是说，当一个应用所 占的空间处于比较低的状态时，比如少于1000个文件和大小低于150MB等，能够非常方便地 通过复制应用来实现伸缩。

接着，谈一下资费情况。App Engine的资费情况主要有两个特点：其一是免费额度高，现 有免费的额度能支撑一个中型网站的运行，且不需付仟何费用，其二是资费项目非常细粒度， 比如普通IaaS服务资费，主要就是CPU、内存、硬盘和网络带宽这4项，而App Engine则除 了常见的CPU和网络带宽这两项之外，还包括很多应用级别的项目，比如Datastore API和邮 件API的调用次数等。具体资费的机制是这样的：如果用户的应用每天消费的各种资源都低于 这个额度，那么用户无需支付任何费用，但是当超过免费额度的时候，用户就需要为超过的部 分付费。因为App Engine整套资费标准比较复杂，所以在这里主要介绍一下它的免费额度，具 体请看表3-7。

表3-7 App Engine的免费额度表

从表3-7的免费额度来看，除了存储数据的容量外，其他都是非常强大的。