java - 为 Google App Engine 优化应用架构和实现

Question

据我了解，GAE 的计费都归结为实例小时数(“IH”)，或者有多少服务器实例在一段时间内运行。然而，这显然不是那么简单，因为除了 IH 之外，您还必须全天注意配额和资源限制(因为配额每 24 小时补充一次)。

我正在设计我的第一个 GWT/GAE 应用程序，并且看过许多文章(其中一些在下面引用)，其中作者谈论他们必须对其代码进行的主要重构 - 发布后 - 在为了帮助最大限度地减少与 Google 的结算和运营成本。

在一个例子中，一名开发人员对其 GAE 应用实现了一系列优化，导致同一应用从每天 7 美元(约合 220 美元/月)降至 0 美元，因为它最终处于“免费”配额和计费之下资源阈值。

作为 GAE 的新手，我想知道是否有任何一套原则或实践我可以预先纳入我的应用程序的架构/设计中，一旦渗透到实现的功能代码中并部署到 GAE，将会使应用程序尽可能高效地运行(从货币角度而言)。

以下是我到目前为止所做的一些推论:

• 最大化缓存并最小化数据存储命中
• 尝试将尽可能多的异步请求处理推送到后端实例
• 启用并发 HTTP 请求处理，以便同一实例可以同时处理多个请求

所以我的问题是:我所做的这些概括是否有任何错误，如果是，为什么(或者它们是有条件的，在某些情况下适用但在其他情况下不适用)？我在这里遗漏了什么重要的东西吗？例如，如何确定哪些代码属于后端实例(资源限制稍微宽松一些)，使用哪种特定于 GAE 的分析工具(AppStats、SpeedTracer 等)来查看瓶颈等。

另外，一些被引用的文章:

• Configuring Max Idle and Minimum Latency
• GAE 自己的 scaling best practices
• CPU optimization 的例子

Answer 1

根据经验，有大量的 App Engine 优化策略 list ，其适用性取决于应用程序的性质。以下是我所知道的更多提示:

• 对于提供大量相对静态内容的应用，enabling the (as yet undocumented) edge caching可能对您的每周账单来说是一件好事。

• 即使是 concurrent requests/threadsafe已启用，每个前端实例 could only process 8 (for Python) to 10 (Java, Go) simultaneous incoming request在调度程序决定为您启动一个新实例之前。

• 为了克服上述限制，我认为有一个 Google I/O 视频建议您将发送到前端实例的任何面向用户的请求的响应时间缩短为 ~100 毫秒。

• 根据上述策略，如果您有任何需要大量处理或数据存储 I/O 的任务，请将任务卸载到 push task queue ，并立即响应请求。您可以指定 target of the task queue ，但为此目的，它不需要是后端，前端实例就足够了，并提供无限的可扩展性。

• 如果您使用上述策略但仍需要将处理或 I/O 的结果提供给用户，请使用 Channel API或任何其他消息服务异步发回结果。

• 任务队列是分配应用程序工作负载的绝佳工具。你可以 customize its behavior in detail ，并且它们对于确保您的应用程序很好地扩展具有无可估量的值(value)。您甚至可以使用推队列和拉队列在实例之间进行双向通信。

_{稍后我会补充更多的点。}