Google应用引擎(AppEngine)初窥
程序员文章站
2022-05-05 12:10:09
...
首先声明的是我没有写过AppEngine的应用,我们只是在文档中探索,也许你能找到你感兴趣的东西。
任何把你限制在某台机器的时代将过去。AppEngine没有磁盘访问,没有线程,没有超级用户,没有系统命令调用,什么都没有,除了基于服务的访问。服务就是一切,因为可以通过装载平衡等幕后的一些手段来升级服务,而不需要程序的安装或者补丁等。
使用CGI接口并没有错,这个应用容器世界有着和CGI类似的特性:获得request,处理request,结束然后重复。CGI之所以被淘汰是因为每一次request都用启动新的进程,这样是非常慢而且很消耗资源的。使用AppEngine,你只需要写一个能够在这些速度非常快的平台上部署的应用。
AppEngine模式很抽象,但是却很实用。你的应用存在云系统中,并不和任何单个的机器或者群集中单个的机器相关。CPU就像一群忙碌的蜂群平行的运行着你的应用,巫师们则在可以扭曲现实的时光口袋中之中随意的指挥着这一切。这种抽象应用的实现是使用一种他们已经有实际经验并且非常熟悉的动态语言(Python)。这是非常好的方式,也是在预料之中的。
也许有人问了:LAMP(Linux,Apache,MySQL,PHP)已经过时了吗?答案当然不会是微软宣称的那样。其实AppEngine比EC2,S3,SQS和SDB更容易使用。在AWS中创建应用是一种专门的技术。这就是为什么我会把AppEngine和Heroku放在一起比较。Heroku用RoR而AppEngine使用Python。使用AppEngine很简单,基本上除了创建一个web应用之外基本不需要做别的。当然,如果没有服务器,你的web应用也没地方运行,这也就是Amazon(Simple DB)为什么大行其道的原因。但对用过PHP等LAMP开源软件的使用者来说,AppEngine也具有很大优势。
AppEngine简单的来说就是个基于请求和响应系统。你只需要写一个服务,然后在队列中等待获得一些CPU时间来运行自己的服务。打个比方,如果你想写一个服务程序来每隔一小时发送一次Email,那么你需要谁每隔一小时调用你的服务来发邮件?这个就是Google想做的。
下面就是关于App Engine的一些信息,虽然很多是从文档中直接引用的,但是仍不失为一种分享知识的方式...
下面是一个"hello world"的例子:
这段代码定义了一个request handler,MainPage,映射到根目录(/).当webapp接收到一个HTTP GET request后,它生成一个MainPage类,并调用实例的get方法。在这个方法中,可以用self.request得到关于request的信息。这个方法通过在self.response中设置了它自己的属性来处理response,然后退出。webapp了发送一个基于MainPage实例最终状态的response。
任何把你限制在某台机器的时代将过去。AppEngine没有磁盘访问,没有线程,没有超级用户,没有系统命令调用,什么都没有,除了基于服务的访问。服务就是一切,因为可以通过装载平衡等幕后的一些手段来升级服务,而不需要程序的安装或者补丁等。
使用CGI接口并没有错,这个应用容器世界有着和CGI类似的特性:获得request,处理request,结束然后重复。CGI之所以被淘汰是因为每一次request都用启动新的进程,这样是非常慢而且很消耗资源的。使用AppEngine,你只需要写一个能够在这些速度非常快的平台上部署的应用。
AppEngine模式很抽象,但是却很实用。你的应用存在云系统中,并不和任何单个的机器或者群集中单个的机器相关。CPU就像一群忙碌的蜂群平行的运行着你的应用,巫师们则在可以扭曲现实的时光口袋中之中随意的指挥着这一切。这种抽象应用的实现是使用一种他们已经有实际经验并且非常熟悉的动态语言(Python)。这是非常好的方式,也是在预料之中的。
也许有人问了:LAMP(Linux,Apache,MySQL,PHP)已经过时了吗?答案当然不会是微软宣称的那样。其实AppEngine比EC2,S3,SQS和SDB更容易使用。在AWS中创建应用是一种专门的技术。这就是为什么我会把AppEngine和Heroku放在一起比较。Heroku用RoR而AppEngine使用Python。使用AppEngine很简单,基本上除了创建一个web应用之外基本不需要做别的。当然,如果没有服务器,你的web应用也没地方运行,这也就是Amazon(Simple DB)为什么大行其道的原因。但对用过PHP等LAMP开源软件的使用者来说,AppEngine也具有很大优势。
AppEngine简单的来说就是个基于请求和响应系统。你只需要写一个服务,然后在队列中等待获得一些CPU时间来运行自己的服务。打个比方,如果你想写一个服务程序来每隔一小时发送一次Email,那么你需要谁每隔一小时调用你的服务来发邮件?这个就是Google想做的。
下面就是关于App Engine的一些信息,虽然很多是从文档中直接引用的,但是仍不失为一种分享知识的方式...
- Google App Engine的项目主页做得非常好。包括FAQ,文章,Blog,论坛,例程,教学和一个如何用DJango的文章。现在论坛上已经有很多先驱者的足迹了。
- 支持Python是第一步,以后还会增加其他语言的支持。
- 不需要获得管理员权限。程序是在沙箱(sandbox)中运行的,这种环境非常安全,对于特定的操作系统只提供受限的访问权限。这些限制允许App Engine 在多台服务器之间分发web请求,也可以因为网络阻塞关闭或者开启这些服务器。
- 一个应用只能通过给定的URL或者email服务或者API来访问其它计算机,其他的计算机只能通过HTTP请求(或者HTTPS)的标准端口来访问这个应用。
- 应用不能直接写文件系统。它可以读文件,但是只能读和这个应用一起传到App Engine上的那些文件。所有的应用必须使用App Engine自身的存储来保持持久数据。
- 应用程序的代码只能是对web请求的响应,而且要求在短时间内返回响应数据。对于request的处理,是必须而且是只能给出一个response,而不能在响应后执行一些别的代码。
- 数据存储不再像传统关系型数据库那样。数据对象或者实体都有一种或者一组属性。Query能够获得由属性值过滤和排序的一种给定的实体。属性值可以使任何支持的属性值类型。
- 数据库使用乐观锁来进行同步控制。在一个事务中,如果要和另外一个进程同步更新一个实体,那么在这次事务中对于实体的更新次数总是相同的。
- 对于事务的处理:数据存储在分布网络中使用"实体组"(entity groups)来实现事务。一个事物操作单个组中的实体。在你的应用中,可以在实体创建完成后把它分配给某个组。
- 邮件服务:App Engine提供一套邮件系统为你的应用服务。
- 目前有500M容量的,5百万的月浏览次数和10G/日的带宽是免费的。意思是如果你需要额外的,那么就不是免费的了。
- 开发者可以使用Windows,Max OS或者Linux SDK。Python 2.5是必需的。
- SDK中包含了一个模拟App Engine的服务器程序。
- Google Api Engine支持任何由纯Python写的框架(或者任何使用CGI适配器,支持WSGI的框架),包括Django,CherryPy,Pylon和web.py。如果你需要以上某种框架来支持你的应用,只需要把代码拷贝到应用所在目录就可以了。
- Google有它自己的框架,名为"webapp"。很有微软风格的命名方式。
下面是一个"hello world"的例子:
import wsgiref.handlers from google.appengine.ext import webapp class MainPage(webapp.RequestHandler): def get(self): self.response.headers['Content-Type'] = 'text/plain' self.response.out.write('Hello, webapp World!') def main(): application = webapp.WSGIApplication( [('/', MainPage)], debug=True) wsgiref.handlers.CGIHandler().run(application) if __name__ == "__main__": main()
这段代码定义了一个request handler,MainPage,映射到根目录(/).当webapp接收到一个HTTP GET request后,它生成一个MainPage类,并调用实例的get方法。在这个方法中,可以用self.request得到关于request的信息。这个方法通过在self.response中设置了它自己的属性来处理response,然后退出。webapp了发送一个基于MainPage实例最终状态的response。