对Google App Engine的可用性反馈

我们在Google App Engine上构建应用的一些很好的体验，第一个应用的目标受众是Google Apps用户，因此在Google基础架构上托管时没有问题。对Google App Engine的可用性反馈

我们非常喜欢它，因此我们希望将它用于另一个应用程序，但是这个下一个项目是针对一个客户，他并不真正对它所处的技术感兴趣，他们只是希望它能够工作，并且一直工作。

在这种情况下，考虑到我们对技术的适用性和能力方面有所涉及，是否有任何担忧，这些东西还是比较新的，我们可能没有像我们已经完成的那样“控制”传统托管？

2010-04-21 Ron Chan

你是正确的：你是不是尽可能多的控制与传统的主机。不过，希望涨幅超过负面。 App Engine具有极高的可扩展性 - 它运行在运行Google本身的相同硬件上。您多久访问一次http://google.com并且该页面或搜索结果失败？

尽管您让Google运行您的代码，但代码仍然是您可以随心所欲的操作。通过像django-nonrel这样的新项目，您可以直接在App Engine上创建并运行原生Django应用程序，并且如果它不能满足您的需求，那么将该应用程序转移到承载主机的ISP相当容易Django应用程序（其中有很多）。下面详细介绍这个项目。

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

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

可扩展的分布式对象数据存储区（参见下文）

内存缓存

的URLFetch

图像服务（调整大小，裁剪等）

用户的服务/认证任务队列后台处理

Django的网站模板

Blob存储大文件

拒绝服务黑名单

transational任务

数据存储光标

电子邮件的发送（和/或接收）

发送（和/或接收）的聊天/ IM /即时消息通过XMPP

你也有一个完整的dashboarded管理控制台，它可以让你监控你的应用程序的使用情况，哟您的帐单设置和历史记录，完整的配额使用情况转储，甚至您可以查看或下载的应用程序日志。

要从@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中讨论过了。谷歌是意识到这种需要并正在处理它。

3b。 TaskQueue API支持10万个电话，但是这被撞到1MM wBE ......这是每天的基础。

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

来源

2010-04-22 01:34:37 wescpy

谢谢你，虽然我已经了解技术限制/偏好/要求，我很满意他们。我最关心的问题是https://groups.google.com/group/google-appengine/browse_thread/thread/a7640a2743922dcf。尽管Google在解释问题方面可能比大多数人都擅长，但就像你所说的那样，这很可能不会发生。但是如果这样的事情再次发生，在停机时间里，没有人会打电话给你，只能坐下来等着。你对此有何看法？ – 2010-04-22 07:28:03

你有一个好点，我们在云计算的时代还处于早期。然而，我认为他们的后验是相当全面的，并且团队正在努力确保这些东西很少（如果有的话）在未来发生。当发生宕机时，您不需要打电话给某人，因为某人*必须*已被分页......这样的系统不会在没有Google不知情的情况下发生。如果您确实需要联系Google，则可以在此创建新的制作问题：http://code.google.com/p/googleappengine/issues/entry – wescpy 2010-04-22 09:02:06

是的，你不会像传统托管那样控制太多。 GAE的主要疮点是

配额等，最多30秒为一个请求，因此彗星/反向AJAX等出窗口或非常困难的。尝试在Google应用引擎上撰写聊天服务器。没有Sql数据库，所以很难移植到其他服务器，如果需要的话，以及谷歌数据库的某些时候有限制，例如，尝试对排序的列以外的列进行比较的查询排序。
长时间运行的过程中，有一个任务api，但如果您想要长时间运行后台处理，则不能满足要求，否则您将不得不在子任务中打开任务，因此事情变得复杂，甚至有配额每秒可以运行多少任务。

如果您的应用程序可以建模为请求 - 响应注册表，并且只需很少的后台处理，GAE就很好。

看到这个太 Feedback on using Google App Engine?

来源

2010-04-21 13:17:11

对Google App Engine的可用性反馈

回答

相关问题