本文介绍了打破 Google App Engine Python 锁定?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

是否有编写 Google App Engine Python 代码的指南,该代码无需 Google 的基础架构即可运行在其他平台上?

Are there any guidelines to writing Google App Engine Python code that would work without Google's infrastructure on other platforms?

是否有任何已知的尝试创建一个开源框架,该框架可以在其他平台上运行专为 Google App Engine 设计的应用程序?

Is there any known attempt to create an open source framework which can run applications designed for Google App Engine on other platforms?

澄清一下,问题确实是:

To clarify, the question really is:

如果我现在在 Google App Engine 上开发应用程序,我以后是否可以迁移到另一个平台,还是会被锁定?

If I develop an application on Google App Engine now, will I be able to migrate to another platform later, or is it a lock in?

推荐答案

使应用程序完全可移植需要许多组件:

There's a number of components required to make an app fully portable:

  • 运行时环境本身.这可以相对简单地移植,通过设置模拟 App Engine 环境的 CGI 或 FastCGI 服务器(它本身基本上是稍微增强的 CGI).执行此操作的大部分代码已在 SDK 中.不幸的是,目前还没有简单的预打包工具包.
  • 数据存储.迄今为止最复杂的移植 API.正在进行多项工作:AppScale 在 EC2/Eucalyptus/Xen 上运行并使用 HyperTable 或 HBase后端;它仍然是非常测试版的质量,他们不单独分发数据连接器(这是一个完整的运行你的应用程序在你自己的云解决方案的开始).Jens 正在/正在编写一个 SQLite 后端,还有我自己的项目,BDBDatastore,它使用 BDB-JE 作为后端,并且完全功能性(虽然测试质量).其他人提到的 AppDrop 只是使用开发服务器作为后端,因此不适合生产使用.
  • 用户 API 需要替换为其他内容,例如基于 OpenID 的 API.同样,相当简单,但还没有预制的解决方案.
  • Memcache API 需要一个使用标准 C 内存缓存后端的后端.
  • 其他 API 具有功能完善的后端作为 SDK 的一部分,因此实际上不需要移植.
  • Cron 支持以及后台处理、XMPP 等在可用时也需要实施.
  • The runtime environment itself. This can be ported relatively simply, by setting up a CGI or FastCGI server that emulates the App Engine environment (which itself is basically slightly-enhanced CGI). Most of the code to do this is already in the SDK. Unfortunately, there's no easy pre-packaged toolkit for this yet.
  • The datastore. By far the most complicated API to port. There are a number of efforts underway: AppScale runs on EC2/Eucalyptus/Xen and uses a HyperTable or HBase backend; it's still very much beta quality and they don't distribute the data connector separately (it's the beginnings of a complete run-your-app-on-your-own-cloud solution). Jens is/was writing an SQLite backend, and there's my own project, BDBDatastore, which uses BDB-JE as the backend, and is fully functional (though beta quality). AppDrop, which others have mentioned, simply uses the development server as a backend, and hence isn't suitable for production use.
  • The users API needs replacing with something else, such as an OpenID based API. Again, fairly simple, but no premade solutions yet.
  • The Memcache API needs a backend that uses standard C memcache backends.
  • The other APIs have perfectly functional backends as part of the SDK, so don't really need porting.
  • Cron support would also need implementing, as would background processing, XMPP, etc, when they become available.

如您所见,还有很多工作要做,但要使您的 App Engine 应用在 Google 环境之外运行,没有任何基本障碍.事实上,如果您有兴趣,我们非常欢迎您参与其中 - 我和其他人计划将各个部分的解决方案组合成一个单一的OpenEngine"解决方案,用于托管您自己的应用程序.

As you can see, there's a lot of work to be done, but no fundamental barriers to making your App Engine app run outside Google's environment. In fact, if you're interested, you're more than welcome to participate - I and others have plans to combine the solutions for the various pieces into a single 'OpenEngine' solution for hosting your own apps.

这篇关于打破 Google App Engine Python 锁定?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-15 01:44