当前位置：文江博客话题详情

关于 Google App Engine 可用性的反馈

发布于 2024-08-29 20:23:27 字数 269 浏览 8 评论 0原文

我们在 Google App Engine 上构建应用程序时获得了一些良好的经验，第一个应用程序的目标受众是 Google Apps 用户，因此在 Google 基础设施上托管它不会出现任何问题。

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

寂寞笑我太脆弱 2024-09-05 20:23:28

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

尽管您让 Google 运行您的代码，但该代码仍然是您可以随心所欲地执行的。通过 django-nonrel 这样的新项目，您可以创建和直接在 App Engine 上运行本机 Django 应用程序，如果它不能满足您的需求，那么可以很容易地将应用程序带到托管 Django 应用程序的 ISP（而且有很多这样的应用程序）。下面详细介绍该项目。

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

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

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

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

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

1a。免费配额相当慷慨......足以为每月获得 5 毫米浏览量的网站提供支持。此外，如果您相信 Google 会向他们提供您的信用卡，他们会将免费配额级别提高到更高。查看他们的配额页面< /strong> 并参考“免费默认配额”和“启用计费默认配额”列中的数字...以下是一些示例： a) 请求数：默认 1.3MM，启用计费的 43MM (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. “不是 SQL”是 Google App Engine 的最大优势之一！关系数据库无法扩展，必须在某个时刻进行分片以防止 RDBMS 崩溃。然而，确实如此，移植稍微困难一些，因为它不是传统的！基于Google Bigtable ，您可以将 App Engine 数据存储区视为可扩展的分布式对象数据库。 App Engine 允许您使用查询来查询数据存储区对象模型，或者如果您坚持的话，它们还提供类似 SQL 的 GqlQuery 接口。

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

3a.长时间运行的进程已在上面的 1b 中得到解决。 Google意识到这一需求并正在努力解决。

3b. TaskQueue API 支持 100k 调用，但增加到 1MM wBE...而且这是每天的情况。

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

You are correct: you are not in as much control vs. traditional hosting. However, hopefully the gains outweight the negatives. App Engine is extremely scalable -- it runs on the same hardware that runs Google itself. How often have you visited http://google.com and had that page or a search result fail?

Although you are letting Google run your code, the code is still your's to do as you please. With new projects like django-nonrel, you can create and run native Django apps directly on top of App Engine, and if it doesn't meet your needs down the line, it's fairly easy to take that app to an ISP that hosts Django apps (and there are plenty of those). More on this project below.

You don't have to worry about hardware, operating systems, coming up with a machine image, databases, web servers, front-end load balancers, CDNs/edge caching, software/package upgrades, license fees, etc. All these things are tangential to the web or other application that you have or will create to solve a particular problem. All this additional infrastructure is required whether you like it or not; but with App Engine, you only need to think about your app/solution and none of this extra stuff.

Obviously another thing you lose is some of your execution environment. To ensure that you're playing nicely with your cloud neighbors (resource hogging, security issues, etc.), you must execute in a sandbox, meaning your app cannot create local files, open network sockets, etc. However, App Engine provides a rich set of APIs and product features so that you at least can create meaningful apps:

scalable distributed object datastore (see below)
Memcache
URLFetch
images service (resize, crop, etc.)
users service/authentication task queues for background processing
Django web templating
blobstore for large files
denial-of-service blacklisting
transational tasks
datastore cursors
sending (and/or receiving) of email
sending (and/or receiving) of chat/IM/instant messages via XMPP

You also have a full dashboarded administration console which will let you monitor your app's usage, your billing settings and history, a full dump of your quota usage, and even your application logs which you can view or download.

To address the "main sore points" from @Anurag:

1a. the free quotas are fairly generous... enough to power a website that gets 5MM views/month. also, if you trust Google to give them your credit card, they will bump up the free quota levels even higher. look at their quota page and refer to the numbers in both the "Free Default Quota" and "Billing Enabled Default Quota" columns... here are some examples: a) # of Requests: 1.3MM default, 43MM w/billing enabled (wBE), b) Datastore API calls: 10MM default, 140MM wBE, c) URL Fetches: 657K default, 46MM wBE

1b. 30s max for requests: this is more security for you, because your app is now in a playground with others. Google has to ensure that all cloud neighbors play nicely with each other and not hog the CPU. However, the App Engine team is working on a way to allow for longer running background tasks... there's no timetable yet, but it is on the public roadmap.

1c. writing a chat server on App Engine is not only possible, but it is quite simple. here's one created using App Engine's XMPP API -- it's pretty dumb and just echoes back to the sender what they transmitted to us (be aware that you must have already invited the user to chat):

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. another item on the the public roadmap is future "[support] for Browser Push (Comet) communication", so that's coming too.

2a. "not SQL" is one of Google App Engine's greatest strengths! relational databases don't scale and must be sharded at some point to keep an RDBMS from falling over. it is true however, that it is slightly more difficult to port because it is not traditional! Based on Google Bigtable, you can think of the App Engine datastore as a scalable distributed object database. App Engine lets you query the datastore using a Query object model, or if you insist, they also provide a SQL-like GqlQuery interface.

2b. with new avantgarde projects like django-nonrel, if you create a Django app and use its ORM, you can take a pure Django app and run it directly on top of App Engine. likewise, you can it off of App Engine and move it directly to more traditional ISP vendor that hosts Django applications. the queries stay exactly the same, and you don't have to care if it does SQL or not.

3a. long-running processes are already addressed in 1b above. Google is aware of this need and are working on it.

3b. the TaskQueue API supports 100k calls, but that's bumped to 1MM wBE... and this is on a daily basis.

3c. Google strongly encourages breaking up tasks into multiple subtasks. low latency apps are seen not to "hog the system" and are given better treatment than those which are slow and consume more resources from their cloud neighbors.

回复收藏 0 原文

拥抱没勇气 2024-09-05 20:23:28

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

配额等，请求最多 30 秒，因此 comet/reverse ajax 等超出窗口或非常困难。尝试在谷歌应用引擎上编写聊天服务器。
不是 Sql 数据库，因此很难在需要时移植到其他服务器，并且有时会受到 google 数据库的限制，例如尝试对查询进行排序，该查询在除排序列之外的不同列上进行比较。
长时间运行的进程，有一个任务API，但如果你想进行长时间运行的后台处理，这还不够，否则你将不得不在子任务中中断你的任务，所以事情变得复杂，甚至还有如何进行的配额每秒可以运行许多任务。

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

也看到这个
有关使用 Google App Engine 的反馈？