使用Google App Engine反馈可用性

Question

我们在Google App Engine上构建应用程序有一些很好的经验,第一个应用程序的目标受众是Google Apps用户,因此在Google基础架构上托管这些应用程序时没有任何问题.

我们非常喜欢它,我们想调查将它用于另一个应用程序,但是这个下一个项目是针对一个对它所处的技术不感兴趣的客户,他们只是希望它能够工作,并且所有的工作都是时间.

在这种情况下,鉴于我们已经涵盖了技术适用性和能力方面,是否有任何担心这些东西仍然相对较新,而且我们可能没有那么多"控制",好像我们已经完成传统托管一样？

Answer 1

你是对的:你没有与传统托管相比更多的控制权.然而,希望收益增加负面因素.App Engine具有极高的可扩展性 - 它运行在运行Google本身的相同硬件上.您多久访问过一次http://google.com并且该页面或搜索结果失败了？

虽然您要让Google运行您的代码,但代码仍然是您可以随意执行的.使用像django-nonrel这样的新项目,您可以直接在App Engine上创建和运行原生Django应用程序,如果它不能满足您的需求,可以很容易地将该应用程序带到托管Django应用程序的ISP (还有很多).更多关于此项目的信息如下

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

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

• 可伸缩的分布式对象数据存储区(见下文)
• 内存缓存
• 网址提取
• 图像服务(调整大小,裁剪等)
• 用户服务/身份验证任务队列,用于后台处理
• Django网页模板
• blobstore用于大文件
• 拒绝服务黑名单
• 过渡任务
• 数据存储区游标
• 发送(和/或接收)电子邮件
• 通过XMPP发送(和/或接收)聊天/即时消息/即时消息

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

要解决@Anurag的"主要痛点":

1A.免费配额相当慷慨......足以为每月获得5MM观看次数的网站提供动力.此外,如果你相信谷歌给他们你的信用卡,他们将提高甚至更高的免费配额水平.查看他们的配额页面并参考"免费默认配额"和"开票已启用默认配额"列中的数字......以下是一些示例:a)请求数:1.3MM默认值,43MM w /计费启用( wBE),b)数据存储区API调用:10MM默认值,140MM wBE,c)URL提取:默认为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.公共路线图上的另一个项目是未来"浏览器推送(Comet)通信的[支持]",所以它也即将到来.

2A."not 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.将任务队列API支持100K调用,但是这被撞1MM WBE ......这是每天的基础上.

3C.Google强烈建议将任务分解为多个子任务.低延迟应用程序被认为不会"占用系统",并且比那些速度慢且从云端邻居消耗更多资源的应用程序获得更好的处理.