探索Google App Engine背后的奥秘(6)- 总结

作者:  ikewu  | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及 版权声明
网址:  http://www.dbanotes.net/arch/google_app_engine-summary.html

按：此为客座博文系列。投稿人 吴朱华曾在IBM中国研究院从事与云计算相关的研究，现在正致力于研究云计算技术。

本篇是本系列的最终章，将总结一下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今后的发展非常有利。

本系列文章结束。

参考资料：

• Google's Dr. Kai-Fu Lee on Cloud Computing
• The Cost of Latency
• Google App Engine Blog
• Bigtable: A Distributed Storage System for Structured Data
• From Spark Plug to Drive Train: Life of an App Engine Request
• Google Megastore
• Google App Engine官方文档
• Google Architecture
• Google App Engine - a first look
• Google Chose Jetty for App Engine
• Google App Engine is Down - Backup Data Center Having Problems
• 面向虚拟基础设施的云服务，第 2 部分: Platform as a Service (PaaS) 和 AppScale
• 传Google正在开发新的服务器文件系统
• Google File System
• Designs, Lessons and Advice from Building Large Distributed Systems
• The Chubby lock service for loosely-coupled distributed systems
• Google's Will Power and Data Center Efficiency
• MapReduce
• MapReduce的论文
• Protocol Buffer 简介
• Google data centers snub Africa, Oz, and anything near Wyoming Or do they?
• Google揭秘服务器创新技术 内置电池替换UPS
• 开源数据库 Sharding 技术（Share Nothing）
• Google File System II: Dawn of the Multiplying Master Nodes
• Transactions Across Datacenters
• 探秘Google全球数据中心与中国机房
• 揭开Google数据中心五大神话
• 俄勒冈州的Google数据中心耗电惊人
• Google App Engine For Java - Microblogging Case Study
• Under the covers of the App Engine Datastore
• Google Megastore
• Megastore/Bigtable Replication的文章

--EOF--