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

按：此为客座博文系列。投稿人吴朱华曾在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希望能通过AppEngine来降低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--