突破 Google App Engine Python 锁定？ [关闭]答案

【问题标题】：Breaking out of the Google App Engine Python lock-in? [closed]突破 Google App Engine Python 锁定？ [关闭]
【发布时间】：2009-05-21 11:12:59
【问题描述】：

在编写Google App Engine Python 代码时，是否有任何指导方针可以在没有 Google 基础架构的情况下在其他平台上运行？

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

编辑：

为了澄清，问题真的是：

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

【问题讨论】：

我记得曾经读到过有人在他自己的服务器上安装了 SDK 并使用它来为 GAE 应用程序提供服务。不过我不记得那个页面了，反正这只是某种实验。

标签： python google-app-engine open-source lock-in

【解决方案1】：

要使应用完全可移植，需要许多组件：

运行时环境本身。这可以通过设置模拟 App Engine 环境（其本身基本上是略微增强的 CGI）的 CGI 或 FastCGI 服务器来相对简单地移植。大部分执行此操作的代码已经在 SDK 中。不幸的是，目前还没有简单的预打包工具包。
数据存储。迄今为止最复杂的移植 API。正在进行许多努力：AppScale 在 EC2/Eucalyptus/Xen 上运行并使用 HyperTable 或 HBase 后端；它仍然是测试版质量，他们不会单独分发数据连接器（这是完整的 run-your-app-on-your-own-cloud 解决方案的开始）。 Jens 正在/正在编写 SQLite backend，还有我自己的项目 BDBDatastore，它使用 BDB-JE 作为后端，并且功能齐全（尽管是 beta 质量）。其他人提到的AppDrop 只是将开发服务器用作后端，因此不适合生产使用。
用户 API 需要替换为其他内容，例如基于 OpenID 的 API。同样，相当简单，但还没有预制的解决方案。
Memcache API 需要一个使用标准 C memcache 后端的后端。
其他 API 具有完美功能的后端作为 SDK 的一部分，因此不需要移植。
Cron 支持以及后台处理、XMPP 等在可用时也需要实现。

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

【讨论】：

+1，优秀而详细的分析加上有用的指针。
总结：现在还没有解决方案，但是很多人都在朝着这个方向努力:)。谢谢。
自 09 年 5 月以来，这项工作是否取得了明显进展？
我最近没有从 AppScale 人员那里听到太多消息，尽管我认为他们仍在努力。 TyphoonAE 取得了惊人的进展，而作者 Tobias 在与最新的 App Engine 创新保持同步方面做得非常出色。
TypoonAE 不再维护（最后一次发布是在 2010 年）。 AppScale 已将开源平台商业化 (appscale.com)，已准备好生产并经常发布。

【解决方案2】：

使用适用于 App-Engine 的高级框架。这样您就可以在需要时将代码移植到其他服务器。

django 已打补丁并移植到Appengine patch 项目中，是appengine 上使用最多的固件。

您可能希望将此逐步介绍参考running a django app on App engine

就运行应用引擎应用程序的并行基础架构而言，这还很遥远。 App Engine 本身并没有像人们想象的那样流行，也没有谷歌希望的那样流行。另外，在内置 WebApp 框架上开发比在 django 上更难。

至少在未来几年内，运行应用引擎应用程序的并行基础架构不太可能出现。相反，很可能会看到 django 和其他流行的框架在应用引擎上开箱即用，而这方面的工作目前正在参考项目中进行。

【讨论】：

我要指出 app-engine-patch 的一个问题是它不使用 Django 模型。相反，它直接向开发人员公开 GAE 模型。这不一定是坏事。你可以用 Django 模型做一些不能用 GAE 做的事情，而且抽象会很容易泄漏。但是，这意味着在从 GAE 本地移植回 Django 时，您至少会重写模型，并且由于语法差异，您将触及每个查询：在大型项目中这不是一件小事。
我同意 esm，基本的堆栈是 wsgiapp、缓存、数据存储，其他一切都无关紧要。 Wsgiapp 和缓存是标准的和持久的存储，具有 bigtable 特性正在快速出现（mongo、tokyo、memcachedb）。
“App Engine 本身并没有像人们想象的那样流行，谷歌也希望它如此流行。此外，在内置 WebApp 框架上开发比在 django 上更难。” - 我不同意这两种说法。正如我们所说，人们正在开发开源基础设施——例如 AppScale。
您可以改用 google-app-engine-django (code.google.com/p/google-app-engine-django)，因为这确实为您提供了一个模拟标准 Django 模型的 BaseModel 类，因此理论上应该更容易移植您的后期申请。

【解决方案3】：

您可以使用 Django python 框架构建 AppEngine 应用程序（尽管支持的版本比最新的 Django 版本稍逊一筹）。您失去可移植性的地方（至少现在是这样）是在使用 GQL/BigTable 进行持久性时。这是谷歌专有的数据库平台。正如 Hank 所说，这是实际使用 AppEngine 的最大原因之一，但它也是最大的单一锁定点。

这里有几个链接指向 AppEngine 和 GQL/BigTable 中的 Django 支持：

【讨论】：

【解决方案4】：

到目前为止，我找到了一个名为app-drop 的实验主机，它能够托管谷歌应用引擎项目。这应该意味着至少可能在 google 基础架构之外运行应用引擎项目。

然而，这显然还不适合生产。

【讨论】：

我可能错了，但我的直觉告诉我现在不要指望它作为生产替代品。

【解决方案5】：

代码大部分应该是可移植的（它们很好地指出了哪些模块不能在 AppEngine 上使用，哪些 AppEngine 特定代码对应于哪些禁止模块），但 AppEngine 的全部意义在于获取访问权限到 Google 的基础架构。如果您不打算使用 AppEngine 的基础架构，那么将代码写入 AppEngine 限制没有多大意义。

【讨论】：

澄清一下，问题真的是：如果我现在在 google app-engine 上开发，我以后可以迁移到另一个平台，还是锁定？
在这种情况下，becomingGuru 可能会给你答案。

【解决方案6】：

AppDrop 是 AppEngine 到 Amazon Web Services / Elastic Computing 的概念验证端口，于 2008 年 4 月完成。它使用平面文件而不是 BigTable，并且在单个实例中运行，因此存在扩展问题；但它的开发者说他只用了四天，也许这些限制可以由其他人解决。

【讨论】：

它实际上不是一个端口 - 它是 dev_appserver 的修改版本。

【解决方案7】：

我最近通过使用 WHIFF 资源非常轻松地从 vanilla Unix 到应用程序引擎的反向迁移。基本上将任何依赖于平台的东西配置为资源，然后在不同的配置上交换/替换资源。

http://piopio.appspot.com/W1000_1000.resources

另见

http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki

有关资源交换/配置的详细示例。（注意：链接最终可能会消失，应用程序是实验性的。）

【讨论】：

【解决方案8】：

查看typhoonae。它处于测试阶段，但非常实用 - 我们将其中一个应用程序移至运行此堆栈的内部服务器。

【讨论】：

【解决方案9】：

AppScale 是 Google App Engine 最成熟的开源实现。它自 2008 年开始开发，目前支持所有四种语言：Python、Java、Go 和 PHP。今天，它有用户在生产环境中运行他们的应用程序。

常见问题解答解释了支持哪些 API 以及缺少哪些 API： https://github.com/AppScale/appscale/wiki/FAQs

（免责声明：我从事该项目）

【讨论】：