by jkeen
16. July 2009 10:37
对于中小企业，有可能将所有OA系统都搬到Google App Engine上去，从而节省成本。之前有考虑过将公司的Blog系统部署到App Engine上去，但因为对技术的掌握还不足够，另外有一个实际的情况也要考虑，那就是国内会在"某些时候"将Google的某些网站封掉，这带来了应用风险。
对Google App Engine感兴趣的同事可以一起研究一下。http://app.apjcorp.com/
Google App Engine介绍：
2008年4月7号，Google在Campfire One上介绍了一种简化创建、运行和构建伸缩性Web应用的工具——Google App Engine。简而言之，Google App Engine允许你本地使用Google基础设施构建Web应用，待其完工之后再将其部署到Google基础设施之上。
这次发布的是没有包含全部特性的预览版，提供了一个配额系统，它限制了在预览期间应用免费可用的存储、CPU和带宽。一旦预览期结束，配额仍将免费，但是开发者需要按需购买额外资源。额外资源的价格尚未公布（甚至可能尚未确定）。
预览版的配额包括：3个应用/开发者、500MB存储/应用、2000封邮件/天（连续24小时）、10 GB入站带宽、10 GB出站带宽、200M CPU兆周、650k HTTP请求、2.5M Datastore API调用和160k URL Fetch API调用。
技术：开发环境和API
尽管Google说‘未来将支持更多的语言’，但是目前技术栈是基于Python的，它是Google认同的语言之一。出于安 全和伸缩性的目的，Google提供了一个运行在安全沙箱中的Python运行时环境，它提供对底层操作系统有限制的访问。该环境包括标准库，并可通过模 块进行扩展，编写模块的语言目前不支持C语言。
该环境包括Python标准库。当然，调用那些违反沙箱限制的库方法（如打开socket或写文件）将不会成功。为了方便起见，几个核心特性不被支持的标准库中的模块被禁用了。那些引入它们的代码会出错。
应用代码只能用Python书写。不支持使用C来编写扩展。
其他安全限制包括：出站通信（outbound communication）只能通过所提供的邮件和URL fetch API进行，通过HTTP和HTTPS作为传输的入站通信（inbound communication）使用标准端口，禁止文件系统写操作和禁止子进程或代码在请求/响应循环外执行（例如后台操作和批操作）。
此外，Google提供了访问一个Datastore、Google用户帐号、URL fetch和邮件服务的API。App Engine还包括一个简化的Web应用框架和Django 0.96.1，尽管App Engine Datastore不是关系型的，而且也不能使用全部的Django API。
Datastore API背后由Google的BigTable支持，但是它与一个简单的对象持久化API（或一个对象关系映射框架，即使Google强调这个Datastore不是关系型的）有很多相同之处。
Subscribe