zz http://feiibm.blog.sohu.com/124693359.html
在以提供物理资源为目的的IaaS （Infrastructure as a Service ）领域里， Amazon EC2是当之无愧的领先者。而在以提供平台为目标的PaaS（Platform as a Service）领域里，Google App Engine 的美誉度是非常高的，我也对其非常关注和爱好，经历我长达一年的学习和钻研，已经对Google App Engine大致的架构有所了解。希望大家能通过我的介绍能够理解其工作原理，设计的一些tradeoff和其设计的核心思想，更希望能让大家不要再把Google App Engine看的过分神秘，它的实现只是一个工程问题，不是一个科学问题（比如，X86芯片的频率超过4GHz），只要有足够资源作保证，我 敢说其实只需要几十个普通的程序员（中国的），就能基本实现其大多数功能。那么我首先给大家介绍一下Google App Engine的总体架构。
总体架构
简单而言，其架构可以用四部分：
1. 前端， 包括Front End 和Static Files。主要提供下列功能：
a. 负载均衡；
b. 静态文件的传输；
c. html的生成；
d. 转发请求给应用服务器。
2. 应用服务器（App Server）。它能同时运行多个应用的 runtime（python/java）。
3. 服务群（Service Group）。服务群现在主要包括下列服务：
a. Datastore；
b. Memcache；
c. Images；
d. User；
e. URLFetch；
f. Email
4. 应用管理节点（App Master）。它主要负责应用的启停和计费。
图1 Google App Engine架构图1 （来源：2009 Google IO）
设计理念
重用现有的Google技术
大家都知道，重用是软件工程的核心理念之一，无论是过去的模块化思想还是现在的SOA，它们核心都是与重用紧密相连的。在Google App Engine开发的工程中，重用的思想也体现的非常好，比如在Datastore是基于Google的bigtable技术，Images服务是基于picasa的，user服务是利用Google Accounts的，等等。可以这么说，在其这么多模块里面，真的很难找到一个是完全重新开发的。
利用Protocol Buffers的RPC技术
应用服务器和很多服务相连，有可能会出现很多问题，最明显的问题就是异构的问题，比如一些服务是用Java写的，而另一些是用C++写的。怎么办呢？使用Web Service版，但Web Service效率不高怎么办？而一些问题也同样困扰着Google，而Google的解决方法是Protocol Buffers。Protocol buffers-一种可扩展的序列化结构化数据的方式，语言中立，平台中立并被用于通信协议，数据存储等许多方面，并且其速度有可能是XML的10倍。
Shared Nothing 的架构
Google App Engine有一个大家都非常称赞的优点，那个优点就是伸缩性很强。那么它是怎么做到的呢？其实它是利用一个说起很简单，但做起来很难的道理。那个道理就是Shared Nothing。他们通过在App Server那层做到了Shared Nothing，而将所有和持久化相关的东西都和datastore，这样使App Server那层做到了scalable，并且datastore本身就是一个分布式的数据库。当所有的模块都是scalable的时候，那么我们可以认为Google App Engine是scalable的。
分布式的数据库
其Datastore的实现就是利用Google的BigTable技术，同时也是最有争议的一块。
BigTable是一个用来存储结构数据的分布式存储系统。与平时常用的数据库不同，BigTable并非一个支持sql语言的关系数据库，而是map方式的，列导向的数据库（一列数据连续存储）。BigTable为读进行了优化，对数据库的读取访问远远大于写入是互联网服务的重要特点。并且BigTable还利用Google的分布式文件系统技术（GFS）。