最终GAE与AWS架构决策

Question

我知道之前已经有过这样或那样的问题，但是大部分与GAE稳定性有关的主要问题似乎都是在2008年底，2009年初提出来的，或者与大规模的游戏没有直接关系（我很感兴趣）。

基本上，我一直在与我的业务合作伙伴争论是否使用GAE或AWS作为社交游戏引擎的后端，现在是关键时刻。我喜欢GAE（Java）有很多原因，虽然过去常常不稳定，但现在还不错。支持AWS的主要理由是AWS已证明自己每天运行数千万活跃用户的多个游戏。 AWS的明显炙手可热的孩子是Zynga，其Farmville达到80 +百万DAU。这只是在AWS基础架构上运行的非常成功的游戏之一。显着的成就。

所以，这种或那种方式已经知道了。另一方面，GAE没有任何我能找到这些数字的例子。差远了。 我可以相信吗？是否有使用GAE的200万+每日活跃用户的大型社交游戏的单个示例？

我们社交游戏后端的主要考虑因素是：

1. 可靠的CDN（Amazon CloudFront / S3非常适合这种情况，Google显然也是非常出色的DataStore）。
2. 能够扩展而不会崩溃（AWS-EC2在此证明，GAE似乎没有大型游戏应用程序的例子，每秒可以遇到1000个请求.GAE在这方面过去非常不稳定我的主要关注点也是如此。
3. 可靠的无SQL数据库。 （AWS-SimpleDB和Google的DataStore都非常出色。我们真的不需要SQL）。
4. 支持/有人在遇到问题时致电/联系。 （这是GAE最大的担忧之一。我不知道我可以打电话给谁，或者甚至可能。我们有一个SLA和支持。）

我期待你的想法，但请注意，这并不是为了开始任何形式的火焰战争。我喜欢这两种系统，但两者都有积极的和消极的，但我即将做出一个可能不会被推进的架构决策。

此致

沙恩

Answer 1

我从未使用过AWS-EC2，因此我将在Google App Engine上分享我的知识。

1. Google App Engine不是CDN;虽然它可以通过其强大的基础设施提供静态内容，提供靠近用户的缓存，但它并不能保证真正CDN的同类高质量和高可用性服务，因为它不是其职责的一部分。
   更多数据：
   • 使用BlobStore服务的文件的最大大小：2千兆字节
   • 静态文件的最大大小：10兆字节
   • 当前App Engine always returns 200 status用于静态文件，即使在条件获取上也是如此（例如，您必须依赖第三方缓存库，如cirruxcache）。

2. 最近，Google App Engine团队关闭了App Gallery，原因很简单：玩具应用太多了！ 谷歌想要抵消这种成功的企业案例研究的趋势;以下是其中一些：

   • BuddyPoke（病毒式Facebook应用，安装量为6500万）
   • WalkScore（每天向成千上万的房地产合作伙伴网站提供300万请求）
   • Webfillings
   • Snapabug
   • Optimizely
   • Ubisoft Facebook TikTok game

   其他有趣的案例研究here

3. “我们非常了解停机时间和可靠性问题，并正在努力解决这些问题：提高App Engine可靠性是我们的首要任务”Google Developer Relations最近表示经理here。
   App Engine仍处于测试阶段，是一个不断发展的平台，因此您必须做好应对停机和问题的准备。

4. Google App Engine团队刚刚推出App Engine for Business预览，提供99.9％的正常运行时服务水平协议和高级开发人员支持。

以下是我对其价值的看法：
我知道这是一个艰难的电话;阅读了很多articles about GAE我对此感到好奇，因为你可以从最近的灾难性Carlos Ble报告转到Flower Garden或Gri.pe的快乐体验。
App Engine for Business看起来很有前途，我会考虑在严肃的商业项目计划中。 新的SDK 1.4.0是巨大的，它清楚地表明团队正在努力解决一些烦人的问题（热身请求）和放松一些限制（在TaskQueue上10分钟的过程）。

最后要考虑的事情是：如果你要获得大数字，谷歌应用引擎团队可能会将你的应用作为一个成功的案例研究，以推动免费和强大的炒作。

Answer 2

BuddyPoke是在GAE上运行的大型社交应用程序的一个示例。多大我不确定。本文说每日页面浏览量为30米（不是用户）：

http://googleappengine.blogspot.com/2008/10/app-engine-case-studies.html

他们的Facebook页面显示每月270万（不是每日）用户：

http://www.facebook.com/buddypoke

虽然，他们也在其他社交网络上：

http://www.buddypoke.com/

我个人决定选择GAE，主要原因如下：

• 可扩展性的单位是单个请求，而不是像AWS一样的整个实例。
• 我可以在更高级别工作，而不必担心配置实例。

如果您的第4点对您来说很重要，那么您可能会更好地使用AWS。使用GAE，您似乎无能为力，也无法联系。

大约一个星期前，我的应用程序出现问题 - 它突然开始在Google的代码中失败，在过去5天一直运行良好的位置，即自从我上次上传我的应用程序以来。向Google报告问题的唯一方法似乎是通过他们的生产问题模板，在这里：

http://code.google.com/p/googleappengine/issues/entry?template=Production%20issue

我报告了这个问题，但没有听到任何消息。由于它在谷歌的服务器上运行，我无法采取任何“通常”的紧急策略，如重新启动服务器。一个小时之后，问题就解决了 - 我不确定Google的某个人是否看到了我的消息并修复了某些内容，或者它是否已经消失。我更新了我的错误报告，说问题已经修复，但即使是现在一周后问题仍未解决或甚至被确认。此外，由于问题必须公开发布，我的应用程序现在可以从机器人中随机点击。

不可否认，我的应用程序目前仅处于测试阶段，因此只有大约一百个用户，因此对我来说这不是一件大事。如果我获得了数千/数百万次点击，那么谷歌可能会更早地注意到这个问题，或者他们会更加关注我的错误报告。

在您的观点3，即使是我的小型应用程序，只有少量流量也会引发偶尔的数据存储错误（即使在可用性图表中未报告为中断的时间内）。

话虽如此，我仍然喜欢GAE（我正在使用Python版本），并计划坚持下去。 GAE的承诺是它的可扩展性 - 虽然它现在偶尔会因为我的小流量而有所下降，但是当它扩展到更多流量时（即你的第2点）它不应该再落后了，前提是我已正确编码以避免争。我会看看它是怎么回事。

最后关于您的观点1，blobstore和/或静态文件更像是GAE上的CDN，而不是数据存储区。然而，对于非常大量的流量，真正的CDN可能更便宜。它也不一定是CDN，请参阅Google app engine & CDN。