我们有一些在 Google App Engine 上构建应用程序的良好经验，第一个应用程序的目标受众是 Google Apps 用户，因此它托管在 Google 基础架构上没有问题。
我们非常喜欢它，因此我们想研究将它用于另一个应用程序，但是下一个项目是为一个对它所采用的技术并不真正感兴趣的客户而设计的，他们只是希望它能够正常工作一直都在。
在这种情况下，考虑到我们已经涵盖了技术适用性和功能方面，是否有任何担忧认为这些东西仍然相对较新，并且我们可能不像我们用传统方法完成它那样“可控”托管？
【问题讨论】：
标签： python google-app-engine google-apps
您是对的：与传统托管相比，您没有那么多控制权。然而，希望收益超过负面影响。 App Engine 具有极强的可扩展性——它运行在与 Google 本身相同的硬件上。您多久访问一次http://google.com 并且该页面或搜索结果失败？
尽管您让 Google 运行您的代码，但代码仍由您自己来做。对于像 django-nonrel 这样的新项目，您可以直接在 App Engine 上创建和运行原生 Django 应用，如果它不能满足您的需求，将该应用程序带到托管 Django 应用程序的 ISP 是相当容易的（并且有很多这样的应用程序）。更多关于这个项目的信息如下。
您不必担心硬件、操作系统、提供机器映像、数据库、Web 服务器、前端负载平衡器、CDN/边缘缓存、软件/软件包升级、许可费用等。所有这些东西与您已经或将要创建以解决特定问题的 Web 或其他应用程序无关。无论您喜欢与否，所有这些额外的基础设施都是必需的；但是使用 App Engine，您只需要考虑您的应用/解决方案，而无需考虑这些额外的东西。
显然，您丢失的另一件事是您的一些执行环境。为确保您与您的云邻居（资源占用、安全问题等）很好地合作，您必须在沙箱中执行，这意味着您的应用无法创建本地文件、打开网络套接字等。但是，App Engine 提供了一个丰富的 API 和产品功能集，让您至少可以创建有意义的应用：
您还拥有一个完整的仪表板管理控制台，可让您监控应用的使用情况、计费设置和历史记录、配额使用情况的完整转储，甚至可以查看或下载您的应用程序日志。
从@Anurag 解决“主要痛点”：
1a。免费配额相当慷慨……足以为每月获得 5MM 浏览量的网站提供动力。此外，如果您相信 Google 会将您的信用卡提供给他们，他们会提高免费配额水平，甚至更高。查看 their quota page 并参考“免费默认配额”和“启用计费的默认配额”列中的数字...这里有一些示例：a)请求数：1.3MM 默认，43MM 启用计费 (wBE)，b) 数据存储 API 调用：10MM 默认，140MM wBE，c) URL 提取：657K 默认，46MM wBE
1b。请求最多 30 秒：这对您来说更安全，因为您的应用程序现在与其他人一起在操场上。谷歌必须确保所有的云邻居都能很好地相互配合，并且不会占用 CPU。但是，App Engine 团队正在研究一种允许更长时间运行后台任务的方法……目前还没有时间表，但 it is on the public roadmap。
1c。在 App Engine 上编写聊天服务器不仅可行，而且非常简单。这是使用 App Engine 的 XMPP API 创建的一个——它非常愚蠢，只是将他们发送给我们的内容回显给发件人（请注意，您必须已经邀请用户聊天）：
from google.appengine.api import xmpp
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
class XMPPHandler(webapp.RequestHandler):
def post(self):
msg = xmpp.Message(self.request.POST)
msg.reply("I got your msg: '%s'" % msg.body)
application = webapp.WSGIApplication([
('/_ah/xmpp/message/chat/', XMPPHandler),
], debug=True)
def main():
run_wsgi_app(application)
if __name__ == '__main__':
main()
1d。 the public roadmap 上的另一个项目是未来“[支持] 浏览器推送（彗星）通信”，所以它也即将到来。
2a。 “不是 SQL”是 Google App Engine 的最大优势之一！关系数据库无法扩展，必须在某个时候进行分片以防止 RDBMS 崩溃。但是，是正确的，因为它不是传统的，所以移植起来稍微困难一些！基于 Google Bigtable，您可以将 App Engine 数据存储区视为可扩展的分布式对象数据库。 App Engine 允许您query the datastore using a Query object 模型，或者如果您坚持，他们还提供 SQL-like GqlQuery interface。
2b。对于像django-nonrel 这样的新先锋项目，如果您创建一个 Django 应用程序并使用它的 ORM，您可以使用一个纯 Django 应用程序并直接在 App Engine 上运行它。同样，您可以将其从 App Engine 中移出，并将其直接转移到托管 Django 应用程序的更传统的 ISP 供应商。查询保持完全相同，您不必关心它是否执行 SQL。
3a。上面的 1b 已经解决了长时间运行的进程。 Google 意识到了这一需求并正在努力解决。
3b。 TaskQueue API 支持 100k 次调用，但这已达到 1MM wBE...而且这是每天一次。
3c。 Google 强烈鼓励将任务分解为多个子任务。低延迟应用程序被认为不会“占用系统”，并且比那些速度慢且消耗更多云邻居资源的应用程序得到更好的处理。
【讨论】：
是的，您不会像使用传统托管那样拥有更多的控制权。 GAE的主要痛点是
配额等，请求最多 30 秒，因此彗星/反向 ajax 等超出窗口或非常困难。尝试在谷歌应用引擎上编写一个聊天服务器。
不是 Sql 数据库，如果需要的话很难移植到其他服务器，并且有时会受到谷歌数据库的限制，例如尝试对一个查询进行排序，该查询在除已排序的列之外的不同列上进行比较。
长时间运行的进程，有一个Task api但是如果你想做长时间运行的后台处理是不够的，否则你将不得不在子任务中中断你的任务，所以事情变得复杂，甚至每秒可以运行多少个任务的配额。
如果您的应用可以建模为请求-响应注册表，GAE 是很好的选择，几乎不需要后台处理。
【讨论】：