5

我们有一些在 Google App Engine 上构建应用程序的良好经验，第一个应用程序的目标受众是 Google Apps 用户，因此在托管在 Google 基础架构上没有问题。

我们非常喜欢它，以至于我们想研究将它用于另一个应用程序，但是下一个项目是为一个对它所采用的技术并不真正感兴趣的客户提供的，他们只是希望它能够工作，并且可以工作所有时间。

在这种情况下，考虑到我们已经涵盖了技术适用性和功能方面，是否有任何担心这些东西仍然相对较新并且我们可能不像我们使用传统托管那样“控制”？

4

2 回答 2

8

您是对的：与传统托管相比，您没有那么多控制权。然而，希望收益超过负面影响。App Engine 具有极强的可扩展性——它运行在与 Google 本身相同的硬件上。您多久访问一次http://google.com并且该页面或搜索结果失败？

尽管您让 Google 运行您的代码，但代码仍然是您自己的事。使用django-nonrel等新项目，您可以直接在 App Engine 上创建和运行原生 Django 应用程序，如果它不能满足您的需求，可以很容易地将该应用程序带到托管 Django 应用程序的 ISP （而且有很多）。更多关于这个项目的信息如下。

您不必担心硬件、操作系统、提供机器映像、数据库、Web 服务器、前端负载均衡器、CDN/边缘缓存、软件/软件包升级、许可费用等。所有这些都是与您已经或将要创建以解决特定问题的 Web 或其他应用程序相切。不管你喜不喜欢，所有这些额外的基础设施都是必需的；但是使用 App Engine，您只需要考虑您的应用程序/解决方案，而无需考虑这些额外的东西。

显然，您失去的另一件事是您的一些执行环境。为确保您与您的云邻居（资源占用、安全问题等）很好地合作，您必须在沙箱中执行，这意味着您的应用无法创建本地文件、打开网络套接字等。但是，App Engine 提供了一个丰富的 API 和产品功能集，让您至少可以创建有意义的应用程序：

  • 可扩展的分布式对象数据存储（见下文）
  • 内存缓存
  • URLFetch
  • 图像服务（调整大小、裁剪等）
  • 用于后台处理的用户服务/身份验证任务队列
  • Django 网页模板
  • 用于大文件的 blobstore
  • 拒绝服务黑名单
  • 事务性任务
  • 数据存储游标
  • 发送（和/或接收）电子邮件
  • 通过 XMPP 发送（和/或接收）聊天/IM/即时消息

您还拥有一个完整的仪表板管理控制台，可让您监控应用程序的使用情况、计费设置和历史记录、配额使用情况的完整转储，甚至可以查看或下载您的应用程序日志。

要解决@Anurag 的“主要痛点”：

1a。免费配额相当慷慨……足以为每月获得 5MM 浏览量的网站提供动力。此外，如果您相信 Google 会将您的信用卡提供给他们，他们会进一步提高免费配额水平。查看他们的配额页面并参考“免费默认配额”和“启用计费的默认配额”列中的数字......这里有一些示例：a）请求数：默认 1.3MM，启用计费时为 43MM（ wBE)，b) 数据存储 API 调用：10MM 默认，140MM wBE，c) URL Fetches：657K 默认，46MM wBE

1b。请求最多 30 秒：这对您来说更安全，因为您的应用程序现在与其他人一起在操场上。谷歌必须确保所有的云邻居都能很好地相互配合，并且不会占用 CPU。但是，App Engine 团队正在研究一种允许更长时间运行后台任务的方法……目前还没有时间表，但它在公共路线图上。

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。公共路线图上的另一个项目是未来“[支持]浏览器推送（彗星）通信”，所以它也即将到来。

2a。“不是 SQL”是 Google App Engine 的最大优势之一！关系数据库无法扩展，必须在某个时候进行分片以防止 RDBMS 崩溃。然而，移植确实有点困难，因为它不是传统的！基于Google Bigtable，您可以将 App Engine 数据存储区视为可扩展的分布式对象数据库。App Engine 允许您使用 Query 对象模型查询数据存储区，或者如果您坚持，它们还提供类似SQL 的 GqlQuery 接口。

2b。对于像django-nonrel这样的新先锋项目，如果您创建一个 Django 应用程序并使用它的 ORM，您可以使用一个纯 Django 应用程序并直接在 App Engine 上运行它。同样，您可以将其从 App Engine 中移出，并将其直接转移到托管 Django 应用程序的更传统的 ISP 供应商。查询保持完全相同，您不必关心它是否执行 SQL。

3a。上面的 1b 已经解决了长时间运行的进程。谷歌意识到了这一需求并正在努力解决。

3b。TaskQueue API支持 100k 次调用，但这已达到 1MM wBE ......而且这是每天一次。

3c。Google 强烈鼓励将任务分解为多个子任务。低延迟应用程序被认为不会“占用系统”，并且比那些速度慢且消耗更多云邻居资源的应用程序得到更好的处理。

于 2010-04-22T01:34:37.850 回答
2

是的，您不会像使用传统托管那样拥有更多的控制权。GAE的主要痛点是

  1. 配额等，请求最多 30 秒，因此彗星/反向 ajax 等超出窗口或非常困难。尝试在谷歌应用引擎上编写一个聊天服务器。

  2. 不是 Sql 数据库，如果需要的话，很难移植到其他服务器，并且有时会限制 google 数据库，例如尝试对一个查询进行排序，该查询在除排序的列之外的不同列上进行比较。

  3. 长时间运行的进程，有一个 Task api，但如果你想做长时间运行的后台处理，这还不够，否则你将不得不在子任务中中断你的任务，所以事情变得复杂，甚至每个任务的数量都有配额秒你可以运行。

如果您的应用程序可以建模为请求-响应注册表，GAE 就很好，几乎没有后台处理。

也看到了 关于使用 Google App Engine 的反馈？

于 2010-04-21T13:17:11.797 回答