Google App Engine的架构-引用

引用说明：原文来自于http://lylhelin.iteye.com/blog/799352 ，为了方便本人阅读，文本格式略有调整。

 

 

        在以提供物理资源为目的的 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。主要提供下列功能：

     （1）负载均衡；

     （2）静态文件的传输；

     （3）html的生成；

     （4）转发请求给应用服务器。

    2. 应用服务器（ App Server），它能同时运行多个应用的 runtime（ python/java）。

    3. 服务群（ Service Group），服务群现在主要包括下列服务：

     （1）Datastore；

     （2）Memcache；

     （3）Images；

     （4）User；

     （5）URLFetch；

     （6）Email

    4. 应用管理节点（ App Master），它主要负责应用的启停和计费。

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

二、设计理念

 

    1. 重用现有的 Google 技术

     大家都知道，重用是软件工程的核心理念之一，无论是过去的模块化思想还是现在的 SOA，它们核心都是与重用紧密相连的。在Google App Engine开发的工程中，重用的思想也体现的非常好，比如在 Datastore是基于 Google的 bigtable技术， Images服务是基于 picasa的， user服务是利用 Google Accounts 的，等等。可以这么说，在其这么多模块里面，真的很难找到一个是完全重新开发的。

 

    2. 利用现有的 Protocol Buffers 的 RPC 技术

     应用服务器和很多服务相连，有可能会出现很多问题，最明显的问题就是异构的问题，比如一些服务是用 Java写的，而另一些是用C++写的。怎么办呢？使用 Web Service 版，但 Web Service 效率不高怎么办？而一些问题也同样困扰着  Google，而 Google 的解决方法是 Protocol Buffers。P rotocol buffers -一种可扩展的序列化结构化数据的方式，语言中立，平台中立并被用于通信协议，数据存储等许多方面，并且其速度有可能是 XML的 10倍。

 

    3. Shared Nothing 的架构

     Google App Engine 有一个大家都非常称赞的优点，那个优点就是伸缩性很强。那么它是怎么做到的呢？其实它是利用一个说起很简单，但做起来很难的道理。那个道理就是 Shared Nothing。他们通过在 App Server 那层做到了 Shared Nothing，而将所有和持久化相关的东西都和 datastore，这样使 App Server 那层做到了 scalable，并且 datastore 本身就是一个分布式的数据库。当所有的模块都是 scalable 的时候，那么我们可以认为 Google App Engine是 scalable 的。

 

    4. 分布式的数据库

     其 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 今后的发展非常有利。通过也希望国内兄弟们能尽快推出山寨版的。

参考资料

·       From Spark Plug to Drive Train: Life of an App Engine Requesthttp://code.google.com/events/io/sessions/FromSparkPlugToDriveTrain.html

·       Google AppEngine - A Second Look

http://highscalability.com/google-appengine-second-look

·         Google App Engine Blog

http://googleappengine.blogspot.com/

·         Bigtable: A Distributed Storage System for Structured Data

http://labs.google.com/papers/bigtable.html

·         The Google File System

http://labs.google.com/papers/gfs.html

·         Google发布新版本的 Protocol Buffers

http://www.infoq.com/cn/news/2009/05/google-protocol-buffers

 

原文：http://feiibm.blog.sohu.com/124693385.html