1、1. Google 的核心技 术按：此为客座博文系列。投稿人吴朱华曾在 IBM中国研究院从事与云计算相关的研究，现在正致力于研究云计算技术。本系列文章基于公开资料对 Google App Engine 的实现机制这个话题进行深度探讨。在切入 Google App Engine 之前，首先会对 Google的核心技术和其整体架构进行分析，以帮助大家之后更好地理解 Google App Engine 的实现。本篇将主要介绍 Google 的十 个核心技术，而且可以分为四大类： 分布式基础设施：GFS、Chubb y 和 Protocol Buffer。 分布式大规模数据处理：MapReduce 和
2、 Sawzall。 分布式数据库技术：BigTable 和数据库 Sharding。 数据中心优化技术：数据中心高温化、12V 电池和服务器整合。 1.1 分布式基础设施1.1.1 GFS由于搜索引擎需要处理海量的数据，所以 Google 的两位创始人 Larry Page 和Sergey Brin在创业初期设计一套名为“BigFiles“的文件系统，而 GFS（全称为“Google File System“）这套分布式文件系统则是“BigFiles“的延续。首先，介绍它的架构，GFS 主要分为两类节点： Master 节点：主要存储与数据文件相关的元数据，而不是 Chunk（数据块）。元数据
3、包括一个能将 64 位标签映 射到数据块的位置及其组成文件的表格，数据块副本位置和哪个进程正在读写特定的数据块等。还有 Master 节点会周期性地接收从每个Chunk节点来的更新（“Heart -beat“）来让元数据保持最新状态。 Chunk节点：顾名思义，肯定用来存储 Chunk，数据文件通过被分割为每个默认大小为 64MB 的 Chunk 的方式 存储，而且每个 Chunk 有唯一一个 64 位标签，并且每个 Chunk 都会在整个分布式系统被复制多次，默认为 3 次。 下图就是 GFS 的架构图：图 1. GFS 的架构图（参片15）接着，在设计上，GFS 主要有八个特点： 大文件和
4、大数据块：数据文件的大小普遍在GB 级别，而且其每个 数据块默认大小为 64MB，这样做的好处是减少了元数据的大小，能使 Master 节点能够非常方便地将元数据放置在内存中以提升访问效率。 操作以添加为主：因为文件很少被删减或者覆盖，通常只是进行添加或者读取操作，这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。 支持容错：首先，虽然当时为了设计方便，采用了单 Master的方案，但是整个系统会保证每个 Master 都会有其相对应的复制品，以便于在 Master节点出现问题时进行切换。其次，在 Chunk 层，GFS 已经在设计上将节点失败视 为常态，所以能非常好地处理 Chunk 节点
5、失效的问题。 高吞吐量：虽然其单个节点的性能无论是从吞吐量还是延迟都很普通，但因为其支持上千的节点，所以总的数据吞吐量是非常惊人的。 保护数据：首先，文件被分割成固定尺寸的数据块以便于保存，而且每个数据块都会被系统复制三份。 扩展能力强：因为元数据偏小，使得一个 Master节点能控制上千个存数据的Chunk 节点。 支持压缩：对于那些稍旧的文件，可以通过对它进行压缩，来节省硬盘空间，并且压缩率非常惊人，有时甚至接近 90%。 用户空间：虽然在用户空间运行在运行效率方面稍差，但是更便于开发和测试，还有能更好利用 Linux 的自带的一些 POSIX API。 现在 Google 内部至少运行着
6、 200 多个GFS 集群，最大的集群 有几千台服务器，并且服务于多个 Google 服务，比如 Google 搜索。但由于 GFS 主要为搜索而设计，所以不是很适合新的一些 Google 产品，比 YouTube、Gmail和更强调大规模索引和实时性的 Caffeine 搜索引擎等，所以 Google 已经在开发下一 代 GFS，代号为“Colossus“，并且在设计方面有许多不同，比如：支持分布式Master 节点来提升高可用性并能支撑更多文件，Chunk节点能支持1MB 大小 的 chunk 以支撑低延迟应用的需要。1.1.2 Chubby简单的来说，Chubby 属于分布式锁服务，通过
7、 Chubby，一个分布式系统中的上千个client 都能 够对于某项 资源进行“加锁“或者“ 解锁“，常用于 BigTable 的协作工作，在实现方面是通过对文件的创建操作来实现“加锁“ ，并基于著名科学家 Leslie Lamport 的 Paxos 算法。1.1.3 Protocol BufferProtocol Buffer，是 Google 内部使用一种语言中立、平台中立和 可扩展的序列化结构化数据的方式，并提供 Java、C+ 和 Python 这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，而且它是一种二进制的格式，所以其速度是使用 XML 进行数据交换的 10
8、倍 左右。它主要用于 两个方面：其一是 RPC 通信，它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面，因为它自描述，而且压缩很方便，所以可用于对数据进行持久化，比如存储日志信息，并可被 Map Reduce 程序处理。与 Protocol Buffer 比较类似的产品还有Facebook 的 Thrift ，而且 Facebook 号称 Thrift 在速度上还有一定的优势。1.2 分布式大规模数据处理1.2.1 MapReduce首先，在 Google 数据中心会有大规 模数据需要处理，比如被网络爬虫（Web Crawler）抓取的大量网页等。由于这些数据很多都是PB 级别，
9、导致处理工作不得不尽可能的并行化，而 Google 为了解决这个问题 ，引入了 MapReduce 这个编程模型，MapReduce 是源自函数式语言，主要通过“Map（映射）“和“Reduce（化简）“这两个步骤来并行处理大规模的数据集。Map 会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作，且原始列表不会被更改，会创建多个新的列表来保存 Map的处理结果。也就意味着，Map 操作是高度并行的。当 Map 工作完成之后，系统会先对新生成的多个列表进行清理（Shuffle）和排序，之后会这些新创建的列表进行 Reduce 操作，也就是对一个列表中的元素根据Key 值进行适当的合
10、并。下图为 MapReduce 的运行机制：图 2. MapReduce 的运行机制（参 19）接下来，将根据上图来举一个 MapReduce 的例子：比如，通过搜索 Spider将海量的 Web页面抓取到本地的GFS 集群中，然后 Index 系统将会对这个 GFS 集群中多个数据 Chunk 进行平行的 Map 处理，生成多个 Key 为 URL，value 为 html页面的键值对（Key-Value Map），接着系统会对这些刚生成的键值对进行 Shuffle（清理），之后系统会通过Reduce 操作来根据相同 的 key 值（也就是 URL）合并这些键值对。最后，通过 MapRedu
11、ce 这么简单 的编程模型，不仅能用于 处理大规模数据，而且能将很多繁琐的细节隐藏起来，比如自动并行化，负载均衡和机器宕机处理等，这样将极大地简化程序员的开发工作。MapReduce 可用于包括“分布 grep，分布排序，web 访问日志分析，反向索引构建，文档聚类，机器学习，基于统计的机器翻译，生成 Google 的整个搜索的索引“等大规模数 据处理工作 。Yahoo也推出 MapReduce 的开源版本 Hadoop，而且Hadoop 在业界也已经被大规模使用。1.2.2 SawzallSawzall 可以被 认为是构建在 MapReduce之上的采用类似 Java 语法的 DSL（Dom
12、ain-Specific Language），也可以认为 它是分布式的 AWK。它主要用于对大规模分布式数据进行筛选和聚合等高级数据处理操作，在实现方面，是通过解释器将其转化为相对应的MapReduce 任 务。除了 Google 的 Sawzall 之外，yahoo 推出了相似的 Pig 语言，但其语法类似于 SQL。1.3 分布式数据库技术1.3.1 BigTable由于在 Google 的数据中心存 储 PB 级以上的非关系型数据时候 ，比如网页和地理数据等，为了更好地存储和利用这些数据，Google 开发了一套数据库系统，名为“BigTable“。BigTable 不是一个关系型 的数
13、据库，它也不支持关联（Join ）等高级 SQL 操作，取而代之的是多级映射的数据结构，并是一种面向大规模处理、容错性强的自我管理系统，拥有 TB 级的内存和 PB 级的存储能力，使用结构化 的文件来存储数据，并每秒可以处理数百万的读写操作。什么是多级映射的数据结构呢？就是一个稀疏的，多维的，排序的 Map，每个 Cell 由行关键字，列关键字和时间戳三维定位Cell 的内容是一个不解释的字 符串，比如下表存储每个网站的内容与被其他网站的反向连接的文本。 反向的 URL n.www 是这行的关键字；conte nts 列存储网页内容，每个内容有一个时间戳，因为有两个 反向连接，所以archor
14、 的 Column Family 有两列： anchor: 和 anchhor:my.look.ca。Column Family 这个概念，使得表可以 轻松地横向扩展。下面是它具体的数据模型图：图 3. BigTable 数据模型图（参4）在结构上，首先，BigTable 基于GFS 分布式文件系统和 Chubby 分布式锁服务。其次BigTable也分为两部分：其一是 Master 节点，用来处理元数据相关的操作并支持负载均衡。其二是 tablet 节点，主要用于存储数据库的分片 tablet，并提供相应的数据访问，同时Tablet 是基 于名为 SSTable的格式，对压缩有很 好的支持
15、。图 4. BigTable 架构图（参15）BigTable 正在为 Google 六十多种产品和项目提供存储和获取结构化数据的支撑平台，其中包括有Google Print、 Orkut、Google Maps、Googl e Earth和 Blogger 等，而且 Google至少运行着 500 个 BigTable集群。 随着 Google 内部服务对需求 的不断提高和技术的不断地发展，导致原先的BigTable 已经无法满足用户的需求，而 Google 也正在开发下一代BigTable，名为“Spanner（扳手）“，它主要有下面这些 BigTable 所无法支持的特性： 支持多种数据
16、结构，比如 table，familie，group和 coprocessor 等。 基于分层目录和行的细粒度的复制和权限管理。 支持跨数据中心的强一致性和弱一致性控制。 基于 Paxos 算法的强一致性副本同步，并支持分布式事务。 提供许多自动化操作。 强大的扩展能力，能支持百万台服务器级别的集群。 用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。 1.3.2 数据库 ShardingSharding 就是分片的意思，虽然非关系型数据库比如 BigTable 在Googl e 的世界中占有非常重要的地位，但是面对传统 OLTP应用，比如广告系统，Google 还是采用传统的关系型数
17、据库技术，也就是 MySQL，同时由于 Google所需要面对流量非常巨大，所以 Google 在数据库层采用了分片（Sharding）的水平扩展（Scale Out）解决方案，分片是在传统垂直扩展（Scale Up）的分区模式上的一种提升，主要通过时间，范围和面向服务等方式来将一个大型的数据库分成多片，并且这些数据片可以跨越多个数据库和服务器来实现水平扩展。Google 整套数据库分片技术 主要有下面这些优点： 扩展性强：在 Google 生产环 境中，已经有支持上千台服务器的 MySQL 分片集群。 吞吐量惊人：通过巨大的MySQL分片集群能满足巨量的查询请求。 全球备份：不仅在一个数据中
18、心还是在全球的范围，Google 都会对 MySQL 的分片数据进行备份，这样不仅能保护数据，而且方便扩展。 在实现方面，主要可分为两块：其一是在 MySQL InnoDB 基础上添加了数据库分片的技术。其二是在 ORM 层的 Hibernate 的基础上也添加了相关的分 片技术，并支持虚拟分片（Virtu al Shard）来便于开发和管理。同时 Google 也已经将这两方面的代码提交给相关组织。1.4 数据中心优化技术1.4.1 数据中心高温化大中型数据中心的 PUE（Power Usage Effectiveness）普遍在 2 左右，也就是在服务器等计算设备上耗 1度电，在空调等辅助
19、设备上也要消耗一度电。对一些非常出色的数据中心，最多也就能达到 1.7，但是 Google 通过一些有效的设计使部分数据中心到达了业界领先的1.2，在这些设计当中，其中最有特色的莫过于数据中心高温化，也就是让数据中心内的计算设备运行在偏高的温度下，Google 的能源方面的总监 Erik Teetzel 在谈到这点的时候说：“普通的数据中心在 70华氏度（ 21 摄氏度）下面工作，而我们则推荐 80 华氏度（27 摄氏度）“。但是在提高 数据中心的 温度方面会有两个常见的限制条件：其一是服务器设备的崩溃点，其二是精确的温度控制。如果做好这两点，数据中心就能够在高温下工作，因为假设数据中心的管理
20、员能对数据中心的温度进行正负1/2 度的调节，这将使服务器设备能在崩溃点 5 度之内工作，而不是常见的 20 度之内，这样既经济 ，又安全。还有，业界传言Intel 为Googl e 提供抗高温设计的定制芯片，但云计算界的顶级专家James Hamilton 认为不太可能，因为虽然处理器也非常惧怕热量，但是与内存和硬盘相比还是强很多，所以处理器在抗高温设计中并不是一个核心因素。同时他也非常支持使数据中心高温化这个想法，而且期望将来数据中心甚至能运行在 40 摄氏度下，这样不仅能节省空调方面的成本，而且对环境也很有利。1.4.2 12V 电池由于传统的UPS 在资源方面比较浪费，所以 Googl
21、e 在这 方面另辟蹊径，采用了给每台服务器配一个专用的12V 电池的做法来替换了常用的UPS，如果主电源系统出现故障，将由该电池负责对服务器供电。虽然大型 UPS 可以达到 92%到 95%的效率，但是比起内置电池的 99.99%而言是非常捉襟见肘的，而且由于能量守恒的原因，导致那么未被 UPS 充分利用的电力会被转化成热能，这将导致用于空调的能耗相应地攀升，从而走入一个恶性循环。同时在电源方面也有类似的“神来之笔“ ，普通的服务 器电源会同时提供 5V和 12V 的直流电。但是 Google 设计的服务器电 源只输出 12V 直流电，必要的转换在主板上进行，虽然这种设计会使主板的成本增加1
22、美元到 2美元，但是它不仅能使电源能在接近其峰值容量的情况下运行，而且在铜线上传输电流时效率更高。1.4.3 服务器整合谈到虚拟化的杀手锏时，第一个让人想到肯定是服务器整合，而且普遍能实现 1:8 的整合率来降低各方面的成本。有趣的是，Google 在硬件方面也引入类似服务器整合的想法，它的做法是在一个机箱大小的空间内放置两台服务器，这些做的好处有很多，首先，减小了占地面积。其次，通过让两台服务器共享诸如电源等设备，来降低设备和能源等方面的投入。2. Google 的整体架 构猜想本文是基于现有的公开资料和个人的经验来对Google 的整体架构进行总结和猜想。在软件工程界，大家有一个共识，那就
23、是“需求决定架构“ ，也就是说，架构的发展是为了更好地支撑应用。那么本文在介绍架构之前，先介绍一下Google 所提供的主要产品有哪些？2.1 产品对于 Google 和它几个主要产 品，比如搜索和邮件等，大家已经非常熟悉了，但是其提供服务的不只于此，并主要可分为六大类： 各种搜索：网页搜索，图片搜索和视频搜索等。 广告系统：AdWords 和 AdSense。 生产力工具：Gmail和 Google Apps 等。 地理产品：地图，Google Earth和 Google Sky 等。 视频播放：Youtube。 PaaS 平台： Google App Engine。 2.2 设计理念根据现
24、有的资料，Google 的设计理 念主要可以总结出下面这六条： Scale，Scale，Scale Scale：因为 Google 大多数服务所面 对的客户都是百万级别以上的，导致 Scale 也就是伸缩已经深深植入 Google 的DNA 中，而且 Google 为了帮助其开发人员更好地开发分布式应用和服务，不仅研发了用于大规模数据处理MapReduce 框架 ，还推出了用于部署分布式应用的 PaaS 平台Googl e App Engine。 容错：一个分布式系统，就算是构建在昂贵的小型机或者大型机之上，也会不时地出现软件或者硬件方面的错误，何况 Google 的分布式系统还是浇筑在便宜的
25、 X86服务器之上，即使其设备标称的 MTBF（平均故障间隔时间）很高，但是由于一个集群内的设备极多，导致其错误发生的几率非常高，比如李开复曾经提过这样一个例子：在一个拥有两万台 X86 服务器的集群中，每天大约有110 台机器会出现宕机等恶劣情况，所以容错是一个不可被忽视的问题，同时这点也被 Google 院士Jeffrey Dean 在 多次演讲中提到。 低延迟：延迟是影响用户体验的一个非常重要的因素，Google 的副总裁Marissa Mayer曾经说过：“ 如果每次搜索的时间多延迟半秒的话，那么使用搜 索服务的人将减少 20%“，从这个例子可以看出，低延迟对用户体验非常关键，而且为了
26、避免光速和复杂网络环境造成的延时，Google 已在很多地区设置了本地的数据中心。 廉价的硬件和软件：由于 Google 每天所处理的数据和请求在规模上是史无前例的，所以现有的服务器和商业软件厂商是很难为 Google“度身定做 “一套分布式系统，而且就算能够设计和生产出来，其价格也是Google 所无法承受的，所以其上百万台服务器基本采用便宜的 X86系统和开源的 Linux，并开发了一 整套分布式软件栈，其中就包括上篇提到的MapReduce ，BigTable 和 GFS 等。 优先移动计算：虽然随着摩尔定律的不断发展，使得很多资源都处于不断地增长中，比如带宽等，但是到现在为止移动数据成
27、本远大于移动计算的成本，所以在处理大规模数据的时候，Google 还是倾向 于移动计算，而不是移动数据。 服务模式：在 Google 的系统 中，服务是相当常用的，比如其核心的搜索引擎需要依赖 700-1000 个内部服务，而且服务这种松耦合的开发模式在测试，开发和扩展等方面都有优势，因为它适合小团队开发，并且便于测试。 2.3 整体架构的猜想在整体架构这部分，首先会举出Google 的三种主要工作负载，接着会试着对数据中心进行分类，最后会做一下总结。2.3.1 三种工作负载对于 Google 而言，其实工作负 载并不仅仅只有搜索这一种，主要可以被分为三大类： 本地交互：用于在用户本地为其提供
28、基本的 Google服务，比如网页搜索等，但会将内容的生成和管理工作移交给下面的内容交付系统，比如：生成搜索所需的Index 等。通过本地交互，能让用户减少延迟，从而提高用户体验，而且其对 SLA要求很高，因为是直接面对客户的。 内容交付：用于为 Google 大多数服务提供内容的存储，生成和管理工作，比如创建搜索所需的 Index，存储 YouTube 的视频和 GMail 的数据等，而且内容交互系统主要基于 Google 自己开发那套分 布式软件栈。还有，这套系统非常重视吞吐量和成本，而不是 SLA。 关键业务：主要包括 Google一些企业级事务，比如用于企业日常运行的客户管理和人力资源
29、等系统和赚取利润的广告系统（AdWords 和 AdSense），同时关键业务对 SLA的要求非常 高。 2.3.3 两类数据中心按照 2008 年数据，Google 在全球有37 个数据中心，其中 19 个在美国，12 个在欧洲，3个在亚洲(北京、香港、东京) ，另外 3 个分布于俄罗斯和南美。下图显示其中 36 个数据中心在全球的分布：图 1. 2008 年Google 全球数据中心分布图根据 Jeffrey Dean 在 2009年末的一次演讲和最近几期季报可以推测出 Google并没有在2009 年过多地增加全球数据中心 的数量，总数应该还是稍多于 36 个，但很有可能在台湾、马来西亚
30、、立陶宛等地增加新的数据中心。虽然 Google 拥有数据中心数 量很多，但是它们之间存在一定的差异，而且主要可以分为两类：其一是巨型数据中心，其二是大中型数据中心。巨型数据中心：服务器规模应该在十万台以上，常坐落于发电厂旁以获得更廉价的能源，主要用于 Google内部服务，也就是内容 交付服务，而且在设计方面主要关注成本和吞吐量，所以引入了大量的定制硬件和软件，来减低 PUE 并提升处理量，但其对 SLA 方面要求不是特别严厉，只要保证绝大部分时间可用即可。下图是 Google 巨型数据中心的一个代表，这个数据中心位于美国俄勒冈州北部哥伦比亚河畔的 Dalles 市，总占地面积接近 30 英
31、亩，并占用了附近一个 1.8GW 水力发电站的大部分电力输出，当这个数据中心全部投入使用后，将消耗 103 兆瓦的电力，这相当于一个中小型城市的整个生 活用电。图 2. Google 在美国俄 勒冈州哥伦比亚河畔的 巨型数据中心近景图大中型数据中心：服务器规模在千台至万台左右，可用于本地交互或者关键业务，在设计方面上非常重视延迟和高可用性，使得其坐落地点尽可能地接近用户而且采用了标准硬件和软件，比如 Dell 的服务器和 MySQL 的数据库等，常见的 PUE 大概在 1.5 和 1.9 之间。本来坐落于北京朝阳区酒仙桥附近的“世纪互联“ 机房的 Google 中国数据中心也属于大中型数据中心
32、这类，其采用的硬件有 DELL 的工作站和 Juniper 的防火墙等，下图为其一角。图 3. Google 前中国数据中心的一角（参26）关于两者的区别：具体请查看下表： 巨型数据中心 大中型数据中心工作负载 内容交付 本地交互/关键业务地点 离发电厂近 离用户近设计特点 高吞吐，低成本 低延迟，高可用性服务器定制化 多 少SLA 普通 高服务器数量 十万台以上 千台以上数据中心数量 十个以内 几十个PUE 估值 1.2 1.5表 1. 巨型与大中型数据中心的对比表2.4 总结最后，稍微总结一下，首先，普通的用户当访问 Google 服务时，大多会根据其请求的 IP地址或者其所属的 ISP
33、将这个请求转发到用户本地的数据中心，如果本地数据中心无法处理这个请求，它很有可能将这个请求转发给远端的内容交互中心。其次，当广告客户想接入 Google 的广告系统时，这个请求会 直接转发至其专业的关键业务数据中心来处理。图 4. 总结因为本文是基于现有的公开资料和个人的经验的总结和猜想，所以和 Google 实际的运行情况没有任何联系。 3. Google App Engine 的简介通过前面两篇介绍，大家应该对Google 强大的基础设施有一定的了解。本篇开始介绍构筑在这强大基础设施之上的 Google App Engine。3.1 Google App Engine 的介绍由于发布 S3
34、 和 EC2这两个优秀的云服务，使得 Amazon 已经率先在云计算市场站稳了脚跟，而身为云计算这个浪潮的发起者之一的 Google 肯定不甘示弱，并在 2008 年四月份推出了 Google App Engine 这项 PaaS 服务，虽然现在无法称其为一 个革命性的产品，但肯定是现在市面上最成熟，并且功能最全面的 PaaS 平台。Google App Engine 提供一整套开发组件来让用户轻松地在本地构建和调试网络应用，之后能让用户在 Google 强大的基础设施 上部署和运行网络应用程序，并自动根据应用所承受的负载来对应用进行扩展，并免去用户对应用和服务器等的维护工作。同时提供大量的免
35、费额度和灵活的资费标准。在开发语言方面，现支持 Java 和 Python 这两种语言，并为这两种语言提供基本相同的功能和 API。3.1.1 功能在功能上，主要有六个方面： 动态网络服务，并提供对常用网络技术的支持，比如 SSL等 。 持久存储空间，并支持简单的查询和本地事务。 能对应用进行自动扩展和负载平衡。 一套功能完整的本地开发环境，可以让用户在本机上对App Engine 进行开发和调试。 支持包括 Email 和用户认证等 多种服务。 提供能在指定时间和定期触发事件的计划任务和能实现后台处理的任务队列。 3.2.2 使用流程整个使用流程主要包括五个步骤： 下载 SDK和 IDE，并
36、在本地搭建开发环境。 在本地对应用进行开发和调试。 使用 GAE自带上传工具来将应用部署到平台上。 在管理界面中启动这个应用。 利用管理界面来监控整个应用的运行状态和资费。 由于本系列是专注于 GAE 的实现和设计两方面，所以不会对 GAE 的使用有非常深入地介绍，如果希望大家对 GAE的使用方面有更深的理解，具体可以参看一下 GAE 的官方文档。3.2 Google App Engine 的主要组成部分主要可分为五部分： 应用服务器：主要是用于接收来自于外部的 Web 请求。 Datastore：主要用于对信息进行持久化，并基于 Google 著名的 BigTable技术。 服务：除了必备的
37、应用服务器和 Datastore之外，GAE 还自带很多服务来帮助开发者，比如：Memcache，邮件，网页抓取，任务队列，XMPP 等。 管理界面：主要用于管理应用并监控应用的运行状态，比如，消耗了多少资源，发送了多少邮件和应用运行的日志等。 本地开发环境：主要是帮助用户在本地开发和调试基于 GAE的应用，包括用于安全调试的沙盒，SDK 和 IDE 插件等工具。 3.3 应用服务器应用服务器依据其支持语言的不同而有不同的实现。3.3.1 Python 的实现Python 版应用服务器的基础 就是普通的Python 2.5.2 版的 Runtime，并考虑在在未来版本中添加对 Python 3
38、 的支持，但是因为 Python 3 对 Python 而言，就好比 Java2 之于Java1，跨度非常大，所以引入 Python3 的难度很大。在 Web 技术方面，支持诸如Django，CherryPy，Pylons 和 Web2py 等 Python Web 框架，并自带名为“WSGI“ 的 CGI 框架。虽然 Python 版应用服务器是 基于标准的Python Runtime，但是为了安全并更好地适应 App Engine 的整体架构，对运行在应用服务器内的代码设置了很多方面的限制，比如不能加载用 C 编写Python 模块和无 法创建 Socket 等。3.3.2 Java 的实
39、现在实现方面，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 和 T
40、hread，或者对文件 进行读写，也不支持一 些比较高阶的 API 和框架，包括 JDBC，JSF ，Strut s 2，RMI，JAX-RPC 和 Hibernate 等。3.4 DatastoreDatastore 提供了一整套强大的分布式数据存储和查询服务，并能通过水平扩展来支撑海量的数据。但 Datastore并不是传统的关系型数据库，它主要以“Entity“的形式存储数据，一个 Entity 包括一个 Kind（在概念上和数据库的 Table 比较类似）和一系列属性。Datastore 提供强一致性和乐观（optimistic）同步控制，而在事务方面，则支持本地事务，也就是在只能同一
41、个 Entity Group内执行事务。在接口方面，Python 版提供了 非常丰富的接口，而且还包括 名为 GQL的查询语言，而Java版则提供了标准的 JDO 和 JPA这两套 API。而且 Google 已经在今年的 Google I/O 大会上宣布将在未来的 App Engine for Business 套件中包含标准的 SQL 数据库服务，但现在还不 确定这个 SQL 数据库的实现方式，是基于开源的 MySQL 技术，还是基于其私有的实现，这是一个问题。3.5 服务3.5.1 MemcacheMemcache 是大中型网站所备的服务，主要用来在内存中存储 常用的数据，而 App E
42、ngine也包含了这个服务。有趣的是 App Engine 的 Memcache也是由 Brad Fitzpatrick 开发。3.5.2 URL 抓取（Fetch）App Engine 的应用可以通过 URL 抓取这个服务抓取网上的资源，并可以这个服务来与其他主机进行通信。这样避免了应用在 Python 和Java 环境中无法使 用 Socket 的尴尬。3.5.3 EmailApp Engine 应用使用这个服务来利用 Gmail 的基础设施来发送 电子邮件。3.5.4 计划任务（Cron）计划服务允许应用在指定时间或按指定间隔执行其设定的任务。这些任务通常称为 Cron job。3.5.
43、5 图形App Engine 提供了使用专用图像服务来操作图像数据的功能。图像服务可以调整图像大小，旋转、翻转和裁剪图像。它还能够使用预先定义的算法提升图片的质量。3.5.6 用户认证App Engine 的应用可以依赖 Google 帐户系统来验证用户。App Engine 还将支持OAuth 。3.5.7 XMPP在 App Engine 上运行的程序能利用XMPP 服务和其他兼容 XMPP的 IM 服务（比如 Google Talk）进行通信。3.5.8 任务队列（Task Queue ）App Engine 应用能通过在一个队列插入任务（以 Web Hook 的形式）来实现后台处理，而
44、且 App Engine 会根据调度方面的设置来安排这个队列里面的任务执行。3.5.9 Blobstore因为 Datastore 最多支持存储 1MB大小的数据对象，所以 App Engine 推出了 Blobstore 服务来存储和调用那些大于1MB 但小于 2G 的二进制数据对象。3.5.10 MapperMapper 可以认为 就是“Map Reduce“中的 Map，也就是能通过 Mapper API 对大规模的数据进行平行的处理，这些数据可以存储在 Datastore 或者Blobstore ，但这个功能还处于内部开发阶段。3.5.11 Channel其实 Channel 就是我们
45、常说的 “Comet“，通过 Channel API 能让应用将内容直接推至用户的浏览器，而不需常见的轮询。除了 Java 版的 Memcache，Email和 URL 抓取都是采用标准的 API 之外，其他服务无论是Java 版还是 Python版，其 API 都是私有的，但是提供了 丰富和细致的文档来帮助用户使用。3.6 管理界面用了让用户更好地管理应用，Google 提供了一整套完善的管理界面，地址是http:/ ，而且只需用户的 Google 帐户就能登录和使用。下图为其截屏：图 1. 管理界面（点击看大图）使用这个管理界面可执行许多操作，包括创建新的应用程序，为这个应用设置域名，查看
46、与访问数据和错误相关的日志，观察主要资源的使用状况。3.7 本地开发环境为了安全起见，本地开发环境采用了沙箱（Sandbox）模式，基本上和上面提到的应用服务器的限制差不多，比如无法创建 Socket 和 Thread，也无法对文 件进行读写。Python 版App Engine SDK 是以普通的应用程序的形式发布，本地需要安装相应的 Python Runtime，通过命令行方式启动 Python版的 Sandbox，同时也可以在安装有 PyDev 插件的Eclipse 上启动。 Java 版App Engine SDK 是以Eclis pe Plugin 形式发布，只要用户在他的Eclip
47、se 上安装这个 Plugin，用户就能启动本地 Java 沙箱来 开发和调试应用。3.8 编程模型 因为 App Engine 主要为了支撑 Web应用而存在，所以 Web层编程模型对于 App Engine 也是最关键的。App Engine 主要使用的 Web 模型是 CGI，CGI 全称为“Common Gateway Interface“，它的意思非常简单，就是收到一个请求，起一个进程或者线程来处理这个请求，当处理结束后这个进程或者线程自动关闭，之后是不断地重复这个流程。由于 CGI这种方式每次处理的时候，都要重新起一个新的进程或者线程，可以说在资源消耗方面还是很厉害的，虽然有线程池
48、（Thread Pool）这样的优化技术。但是由于 CGI 在架构上的简单性使其成为 GAE 首选的编程模型，同时由于 CGI 支持无状态模式，所以也在伸 缩性方面非常有优势。而且 App Engine 的两个语言版本都自带一个 CGI 框架：在 Python 平台为WSGI 。在 Java平台则为经典的 Servlet。最近，由于 App Engine 引入了计划任务和任务队列这两个特性，所以 App Engine 已经支持计划任务和后台进程这两种编程模型。3.9 限制和资费首先，谈一下 App Engine 的使用限 制，具体请看下表：类别 限制每个开发者所拥有的项目 10 个每个项目的文
49、件数 1000 个每个项目代码的大小 150MB每个请求最多执行时间 30 秒Blobstore（二进制存储）的大小 1GBHTTP Response 的大小 10MBDatastore 中每个对象的大小 1MB表 1. App Engine 的使用限制虽然这些限制对开发者是一种障碍，但对 App Engine 这样的多租户环境而且却是非常重要的，因为如果一个租户的应用消耗过多的资源的话，将会影响到在临近应用的正常使用，而 App Engine 上面这些限制就是为了是运行在其平台上面应用能安全地运行着想，避免了一个吞噬资源或恶性的应用影响到临近应用的情况。除了安全的方面考虑之后，还有伸缩的原因，也就是说，当一个应用的所占空间（footprint ）处于比较低的状态，比如少于1000 个文件和大小低于 150MB 等，那么能够非常方便地通 过复制应用来实现伸缩。接着，谈一下资费情况，App Engine 的资费情况主要有两个特点：其一是免费额度高，现有免费的额度能支撑一个中型网站的运行，且不需
