Google App Engine的架构

关注

原创最新推荐文章于 2025-03-17 16:53:21 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

在以提供物理资源为目的的 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。P rotocol 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）。

Java版的 Google App Engine

根据我的推断，其实 Java版和 Python版唯一的确保就是在 App Server端，其实模块应该区别不大，因为 App Server上 Java code对其他服务的调用都是通过上面提到 Protocol Buffers这个平台无关的协议进行远程调用的，所以 App Server上面的代码是不用关心 Datastore， Memcache和 Images等服务是不是用 Java实现，只要它们起着，就能通过 Protocol Buffers调。

本地 Sandbox开发

为了方便开发和调试，Google App Engine提供一个本地sandbox。

通过下面这张图，我们大概能够明白Sandbox的环境和 Production的环境有什么不同了。唯一的不同就在于Implementation不一样。假设程序调用Datastore的服务，如果在Production的环境下，它会去调真实的Datastore服务，而在Sandbox的环境下，它则会调local stub，也就是一个基于文件的数据库程序。

图 2 Google App Engine架构图 2 （来源： 2009 Google IO）

未来的 Roadmap

1. 不断推出新的 API，比如 Task Queue和 XMPP。

Task Queue一般用于离线操作，而 XMPP有可能和 Google Wave有关。

2. 新的语言（估计不可能）

因为 Google内部仅支持三种语言， C++， Java和 Javascript，而且推出一个新的语言版本的话，是非常劳师动众的，毕竟 Google App Engine的设计和 Windows Azure的设计是完全不同的。所以短期我认为不大可能支持新的语言。

总结

Google App Engine是 Google大战略的一个不可分割的一部分，因为 Google希望能通过 Google App Engine来降低 Web应用开发的难度，只要难度降低了，那么 Web应用替代客户端应用的速度将会更快，如果出现这样的情况的话，那么将会对 Google今后的发展非常有利。通过也希望国内兄弟们能尽快推出山寨版的。