何时选择 App Engine 而不是 Cloud Functions？答案

【问题标题】：When to choose App Engine over Cloud Functions?何时选择 App Engine 而不是 Cloud Functions？
【发布时间】：2018-04-13 22:37:15
【问题描述】：

抱歉，如果这是一个幼稚的问题，但我已经看过 google 员工的大量演讲，但仍然不明白为什么我会使用 AE 而不是 CF？

如果我理解正确的话，这两个服务的整个概念都是构建“微服务架构”。

CF 和 AE 都是无状态的
两者都假设在有限的时间内执行
两者都可以与 dbs 和其他 gcp api 交互。

不过，AE 必须封装到自己的服务器中。基本上，它在与 CF 相同的功能之上利用了许多复杂性。那么，我什么时候应该使用它来代替 CF？

【问题讨论】：

标签： google-app-engine google-cloud-platform google-cloud-functions serverless

【解决方案1】：

Google Cloud Functions 是在观看事件时触发的简单、单一用途的函数。

这些功能将无需构建您自己的应用服务器来处理轻量级 API。

主要用例：

数据处理/ETL：侦听和响应 Cloud Storage 事件，例如文件创建、更改或删除）
Webhooks：通过简单的 HTTP 触发器，响应来自 GitHub 等 3 方系统的事件）
轻量级 API：从轻量级、松散耦合的逻辑部分组成应用程序
移动后端：监听并响应来自 Firebase Analytics、实时数据库、身份验证和存储的事件
物联网：数以千计的设备流式传输事件，这些设备又调用谷歌云函数来转换和存储数据

App Engine 旨在在完全托管的无服务器平台上构建高度可扩展的应用程序。它将帮助您更多地关注代码。基础设施和安全将由 AE 提供

它将支持许多流行的编程语言。您可以通过提供 docker 容器将任何框架引入应用引擎。

用例：

现代网络应用程序以零配置部署和零服务器管理快速接触客户。

可扩展的移动后端：与 Firebase 的无缝集成提供了易于使用的前端移动平台以及可扩展且可靠的后端。

参考Cloud functions和App Engine的官方文档页面

【讨论】：

【解决方案2】：

@Cameron 指出的主要区别在于云功能可靠地响应事件。例如。如果您想对云存储桶的更改执行脚本，则有一个专用的云函数触发器。在 GAE 中复制这种逻辑会更加麻烦。 Firestore 集合更改也是如此。

此外，GAE 的 B 机器（用于基本或手动扩展的后端机器）具有长达 24 小时的方便运行时间。云功能目前最多只能运行 9 分钟。此外，GAE 允许您将 cron 作业封装为应用程序代码旁边的 yaml。这使得开发一个服务器较少的事件驱动服务更加干净。

当然，其他答案比我的更能涵盖这些方面。但我想指出 Cloud Functions 的主要优势是触发选项。如果您希望函数或服务相互通信，GAE 可能是更好的选择。

【讨论】：

【解决方案3】：

由于 Cloud Functions 和 App Engine 都是无服务器服务，我就是这么认为的。

对于微服务 - 我们可以使用 CF 或 App Engine。不过我更喜欢CF。

对于单体应用 - 应用引擎非常适合。

【讨论】：

【解决方案4】：

Cloud Functions (CF) 和 Google App Engine (GAE) 是用于不同工作的不同工具。为工作使用正确的工具通常是个好主意。

用钳子打钉子可能是可能的，但不如用锤子方便。同样，使用 CF 构建一个复杂的应用程序可能是可能的，但使用 GAE 构建它肯定会更方便。

与 GAE 相比，CF 有几个缺点（当然，在构建更复杂的应用程序的情况下）：

它们仅限于 Node.js、Python、Go、Java、.NET Core 和 Ruby。 GAE 支持其他几种流行的编程语言
它们确实是为轻量级的独立功能而设计的，试图使用这些组件构建复杂的应用程序很快就会变得“尴尬”。是的，每个单独请求的相互关系上下文也必须在 GAE 上恢复，只有 GAE 从更方便的方式中受益，而这些方式在 CF 上不可用。例如，其他 cmets 中讨论的用户会话管理
GAE 应用程序有一个应用程序上下文，可以在各个请求中生存，CF 没有。这样的上下文使 GAE 应用程序对某些 Google 服务的访问更加高效/高性能（甚至可能），但对于 CF 则不然。例如 memcached。
GAE 应用程序的应用程序上下文的可用性可以为无法在 CF 上运行的其他服务支持更高效/高性能的客户端库。例如，使用 ndb 客户端库（仅适用于标准 env GAE python 应用程序）访问数据存储可能比使用通用数据存储客户端库更高效/高性能。
与 CF 的“零售”定价（每次调用单独收费）相比，GAE 的“批发”定价（基于实例小时，无论特定实例服务多少请求）可能更具成本效益李>
GAE 应用的响应时间可能通常比 CF 短，因为处理请求的应用实例通常已经在运行，因此：
- GAE 应用上下文不需要加载/恢复，它已经可用，CF 需要加载/恢复它
- 处理代码（大部分时间）已经加载，CF 的代码仍然需要加载。不确定这一点，我猜这取决于底层实现。

【讨论】：

请注意，没有什么能阻止我们混合这两个概念。 AppEngine 应用程序可以通过云功能启动作业。
@chaiyachaiya 是的，这也是可能的，如果它在应用程序的上下文中更有意义的话。
CF 不仅限于 Node.js，因为它现在也支持 Python。
Go 也支持

【解决方案5】：

App Engine 更适合应用程序，这些应用程序具有许多功能以各种相互关联（甚至不相关）的方式运行，而云功能更具体地是响应某些事件并执行某些特定操作的单一用途功能.

App Engine 提供多种语言选择和更多管理选项，而云功能在这些领域受到限制。

您可以轻松地在 App Engine 上复制 Cloud Functions，但使用一堆离散的 Can Functions 复制大型 App Engine 应用程序会很复杂。例如，Spotify 的后端是基于 App Engine 的。

另一种说法是，对于一个非常大的应用程序，从一个更复杂的系统（如 App Engine）开始可以生成一个不太复杂的代码库，或者至少更容易管理或理解。

最终，它们都在 Google 类似的底层基础架构上运行，由您决定哪一个适用于手头的任务。此外，没有什么能阻止您在一个项目中混合两者的元素。

【讨论】：

Spotify 示例具有误导性：它是在引入 CF 之前开发的。
我仍然认为它是比 Cloud Functions 更适合 App Engine 的复杂应用程序的一个很好的例子，因为它需要会话管理之类的东西，并且由许多单独的组件组成，呈现为一个内聚的应用程序。
我不能创建“相互关联”的 CF 吗？我很确定这没有问题。如果我理解正确，那么您的其余答案会说 AE 比 CF 更复杂 - 我明白这一点，但我没有看到任何好处。
再说一遍，AE 假设是无状态的，所以我不明白它如何帮助管理会话？
我正在尝试如何更清楚地表达它，但现实情况是这很困难，因为您认为最终可以使用它们中的任何一个来完成类似的工作是正确的。我认为最好的说法是，有时使用更复杂的系统 (AE) 来构建大型项目意味着整个应用程序最终会比在更简单的系统 (CF) 上更简单。