GAE是否具有能够托管数百万活跃用户使用的应用程序的基础架构？

我想知道下列GAE的限制，是否有可能通过在GAE上托管该应用来构建出色的社交应用（如Facebook）？

换句话说，GAE是否具有能够托管6亿活跃用户使用的应用程序的基础架构？

我从几个论坛/博客中提出的限制（如果发现任何不足，请随时添加到列表中）：

1. HTTP请求/响应

   • 要求大小上限：32 MB
   • 最大回应大小：32 MB
   • 所有请求必须在30秒内响应，否则GAE会引发DeadlineExceededException
   • 每个Cron作业必须在10分钟内执行
   • Cron作业无法利用Map Reduce
   • 5秒钟后，到另一个站点的每个GET或POST中止。您可以将其配置为最多等待10秒。（中间服务器必须与Twitter和Facebook多次协作）
   • 客户端无法通过FTP（仅HTTP和HTTPS）连接到GAE。
   • 自定义域没有https。仅适用于your-app-id.appspot.com域。
   • 如果大量用户涌入，则会出现“超出配额”错误

2. 数据库

   • 本地开发中的数据库行为与实际服务器中的行为不同。
   • GQL。没有其他的。
   • 没有查询可以检索1000条以上的记录（如果您希望让客户拥有“一键脱机立即购买”按钮，那就很麻烦了）
   • 如果您需要线性访问大量记录以执行操作，那么您就不走运了（Google的系统已大规模集群化）
   • Memcache值的最大大小为1 MB。
   • 无法进行简单的文字搜索
   • 您无法加入2张桌子。
   • 慢（您必须阅读有关如何使用继承来分离表的知识，以便可以在表中进行搜索，获取键然后获取其父键，以避免反序列化性能）
   • “索引太多”运行时异常
   • 实体在一个索引中最多可以具有5000个属性值
   • 格式*的键名（以两个下划线开头和结尾）是保留的，应用程序不应使用。
   • 密钥名称限制为500个字节（我猜是UTF-8编码的）

3. 语言

   • python或java或Go（或使用JVM的语言，例如Groovy，Scala等）

4. 服务器问题

   • 没有静态IP（调用第三方API可能会有节流和配额问题）
   • 每个应用程序限制为3000个文件
   • 无法控制运行Web应用程序的OS或硬件

我认为让这个问题困扰我的是，您已经在措辞上加上了“事实”，以试图得出确定的“否”。

事实是，您可以开发一个App Engine应用程序，该应用程序可以复制Facebook，Twitter或Tumblr的功能。并且假设该应用程序编写正确，它将可以扩展以支持数亿用户。您不希望这样做的主要原因（这似乎并不是您的考虑因素），原因是在App Engine上运行该大小的服务的成本。

另外，我看不到您列出的任何限制如何阻止您开发这样的应用程序。

1. HTTP请求/响应

   • 最大请求大小：10 MB-错误，增加到32MB。
   • 最大响应大小：10 MB-错误，增加到32MB。

   -如果您开发的社交应用经常需要提供大于10MB的页面，那么您可能做错了。另外，如果您确实需要提供大于32MB的内容，则可以使用blobstore来存储最大2GB的文件。

   • 您无法访问文件系统。（忘记将上传内容保存到文件系统）-错误。您可以从本地文件系统读取文件，还可以将文件上传和读取/写入blobstore。

   -Facebook，Twitter或Tumblr不可能只接受用户上传并将其复制到文件夹。这不是问题。

   • 所有请求必须在10分钟内响应，否则GAE会抛出DeadlineExceededException-错误。实际上是30秒。

   -如果您需要30秒以上的时间才能将结果交付给用户，那么您可能做错了。

   • 每个cron作业必须在30秒内执行-错误的是10分钟。

   -如果不能将一个冗长的任务分成10分钟，则A：您可能做错了； B：您现在可以将该任务移到一个后端实例，该实例对请求没有时间限制。

   • Cron工作无法利用map reduce-从未使用过map reduce，但是我认为这需要引用。

   • 5秒钟后，到另一个站点的每个GET或POST中止。您可以将其配置为最多等待10秒。（必须使用中间服务器才能与Twitter和Facebook多次协作）-正确。

   -如果面向外部API的面向用户的请求花费的时间超过10秒，那么最好还是告诉用户重试。如果不是面向用户的请求，则可以自动重试该任务，直到API响应为止。

   • 客户端无法通过FTP（仅HTTP和HTTPS）连接到GAE。-是的

   -为什么这是个问题？您认为任何大型公司都通过FTP部署更改吗？

   • 自定义域没有https。仅适用于your-app-id.appspot.com域。-是的

   -虽然在路线图上。

   • 如果有大量用户涌入，则会出现“超出配额”错误-一半为真。

   -如果您合理地预算应用程序，您将永远不会看到超出配额的错误。皇家婚礼网站托管在App Engine上，每秒接收32,000个请求。没有超过配额的错误。另外，有没有在Twitter上看到过失败的鲸鱼，或在Tumblr上出现过容量错误？从本质上讲，这就是他们的超出配额错误。

2. 数据库

   • 本地开发中的数据库行为与实际服务器中的行为不同。-错误

   -如果您的意思是在笔记本电脑上运行数据存储区的速度比在App Engine群集上运行数据存储区的速度慢，则为true，否则根本不为true。

   • GQL。没有其他的。-错误

   -大多数开发人员使用db筛选器查询数据存储。另外，您同样可以说MySQL允许“ SQL。

   • 没有查询可以检索1000条以上的记录（如果您希望让客户拥有一个“一键脱机，立即购买”按钮，这会很麻烦）-False。

   -很久以前就取消了1000条记录的限制。此外，请向我显示Facebook，Twitter或Tumblr上任何需要1000多个记录才能呈现的面向用户的页面。

   • 如果您需要线性访问大量记录以执行操作，那么您就不走运了（Google的系统已大规模集群化）

   -我什至不知道你在这里得到什么。大多数人将Google大规模集群的速度视为该系统的巨大优势。

   • Memcache值的最大大小为10 MB。-实际上，每个内存缓存条目为1MB，与其他所有内存缓存实现相同。

   • 无法执行简单的文本搜索-是的。

   -这是一项功能。大多数大型网站都不做自己的文本搜索索引。

   • 您无法加入2张桌子。-是的

   -App Engine开发人员需要将他们的思维方式从单个大规模多联接SQL查询更改为几个较小的单个查询，或者对数据进行非规范化，以便不需要联接。

   • 慢（您必须了解如何使用继承来分离表，以便可以在表中进行搜索，获取键，然后获取其父键以避免反序列化性能）-???

   -需要翻译/引用。

   • “索引太多”运行时异常-True

   -单个应用程序中的索引数有限制。我只看到学术研究应用程序成功了。

   • 一个实体在索引中最多可以具有5000个属性值-True

   -因此，如果某人拥有5000个以上的朋友，那么他们将需要在friends组中两个实体。

   • __*__保留格式的键名（以两个下划线开头和结尾），并且应用程序不应使用该键名。-是的

   -但是呢？

   • 密钥名称限制为500个字节（我想是UTF-8编码的）-True

   -再说一次呢？键名不是用于存储中篇小说，而是用于唯一地标识实体。

3. 语言

   • python或java或Go（必须将其他任何语言翻译为这些语言）-一半为真

   -实际上，您还可以运行在JVM上运行的任何语言，包括PHP和JRuby。尽管不确定为什么会产生问题，但是Python和Java是两种功能强大的语言，具有许多可用的工具，教程和经验丰富的程序员。

4. 服务器问题

   • 没有静态IP（调用第三方API的限制和配额问题）-一半为真

   -大多数第三方API都知道App Engine和/或与Google有关系。Twitter几次不小心阻止了App Engine，并在几个小时内将其修复。

   • 每个应用程序限制为3000个文件-一半为真

   -如果您的Web应用程序确实需要3000多个代码文件，则可以使用zip导入（此外，您可能做错了）。

   • 无法控制运行Web应用程序的OS或硬件-True

   -App Engine是平台即服务。人们正在为购买操作系统或硬件而不必担心。这是App Engine的主要优势，而非限制性。

不可以，App Engine不适合拥有6亿活跃用户的应用程序。

实际上，如此庞大的应用程序可以在其自己的数据中心之外的高度定制的基础架构上运行。可以在Google托管这样的应用程序，但是您可以直接与他们的销售团队合作设计解决方案；您上面列出的沙箱限制早已无关紧要。

如果您只是刚刚起步，那么围绕您将像Facebook一样受欢迎的假设进行设计是很愚蠢的。任何体积如此之大的应用程序都会以递增的方式进行操作，并且会不断进行重构。首先，担心设计将吸引6亿用户的功能。相比之下，重新设计实现以支持不断增长的用户群是一个微不足道的问题。

我认为该FAQ中的要点分为两个主要领域。

首先，有些要点实际上是对可伸缩性的好处，而不是有害的。在高度可扩展的应用程序中，您要争取的一件事是确保每个请求在很大程度上独立于其他请求，并且确保它们都围绕相同的“大小”（就CPU使用率，内存，网络等而言）。

这样，可以轻松地在集群中的节点之间分配请求，而不必担心一组“大”请求使同一节点上的小请求饿死。这使您的基础架构在维护，性能和可靠性方面变得简单。

因此涵盖了以下内容：

• 最大请求/响应大小
• 请求响应时间
• 外部请求响应时间限制
• Memcache的最大大小（实际上，在默认构建的Memcache中，最大值为1 MB，因此很明显Google正在运行一个自定义二进制文件，该二进制文件增加了10倍）
• 最大数据库响应大小（即1,000行限制）
• 等等

第二类是已经过时的东西：

• Google Go现在可以在App Engine中作为一种语言使用。在高性能语言方面，您没有比Go更好的了。我真的很喜欢这个
• 数据存储区可能会失败- 高复制数据存储区并非如此（显然内存缓存可能会失败，但这只是一个缓存）
• 文件数限制是3,000而不是1,000

现在，如果Google开放其基础架构以允许cron作业使用Map Reduce，并让您对整个数据集运行查询，那就太好了。但是到了6亿用户中的相当一部分时，您将已经成为Google的非常大的客户，并且比起App Engine中可用的功能，它将有更多的选择。

如果您提出的想法可以吸引甚至100个用户（更不用说600百万）了，那么您将拥有任何风险投资和技术团队，可以在任何基础架构上进行开发和运行。而且，在这种情况下，您还想保护自己的知识产权，GAE不会提供该知识产权，因为Google希望能够访问每个GAE应用程序的源代码（无论如何，您实际上无法保护Python和Java代码）。
GAE适用于希望摆脱IT基础架构成本且无需保护代码IP而仅保护其数据的企业。