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

Question

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

google-app-enginegoogle-cloud-platformgoogle-cloud-functionsserverless

101

抱歉，如果这是一个幼稚的问题，但我看了很多谷歌员工的演讲，仍然不明白为什么我会使用AE而不是CF？

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

CF和AE都是无状态的
两者都应在有限的时间内执行
两者都可以与数据库和其他GCP API交互。

尽管如此，AE必须包装进自己的服务器。基本上，它利用了与CF相同的功能的许多复杂性。那么，在什么情况下我应该使用AE而不是CF？

- stkvtflw

5个回答

32

App Engine 更适合那些拥有许多功能、以各种相互关联（甚至无关）方式运行的应用程序，而云函数则更专注于响应某些事件并执行某些特定操作的单一用途函数。

App Engine 提供了多种语言和更多的管理选项，而云函数在这些领域受到限制。

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

换句话说，对于一个显著庞大的应用程序来说，从更复杂的系统像 App Engine 开始可以导致代码库不太复杂，或者至少更容易管理或理解。

最终，这两者都在 Google 的类似基础设施上运行，取决于你决定哪个适合手头的任务。此外，没有什么阻止你在单个项目中混合使用两者的元素。

- Cameron Roberts

5

Spotify 的例子具有误导性：它是在协同过滤推荐算法被引入之前开发的。 - stkvtflw

2

我仍然认为它是一个很好的例子，展示了一个复杂应用程序比云函数更适合使用App Engine，因为它需要诸如会话管理之类的东西，并由许多个体组件组成，呈现为一个连贯的应用程序。 - Cameron Roberts

1

再次强调，AE应该是无状态的，所以我不明白它如何帮助管理会话？ - stkvtflw

谢谢，Cameron！我想我明白你的意思了，只是我不太清楚它究竟如何“更适合支持复杂应用程序”。 - stkvtflw

1

我正在努力思考如何更清晰地表达，但实际上很难，因为你的想法是正确的，你最终可以使用它们中的任何一个来完成类似的工作。我认为最好的方法是，有时候使用更复杂的系统（AE）来构建大型项目意味着整个应用程序的复杂程度比在更简单的系统（CF）上要低。 - Cameron Roberts

显示剩余4条评论

7

Google Cloud Functions是简单的、单一目的的函数，它们在观察事件时被触发。

这些函数将消除构建自己的应用程序服务器来处理轻量级API的需要。

主要用例：

数据处理/ETL：监听并响应Cloud Storage事件，例如文件创建、更改或删除）
Webhooks：通过简单的HTTP触发器，响应来自第三方系统（如GitHub）的事件
轻量级API：从轻量级、松散耦合的逻辑组成应用程序
移动后端：监听并响应来自Firebase Analytics、Realtime Database、Authentication和Storage的事件
物联网：数千个设备流式传输事件，并调用Google Cloud函数来转换和存储数据

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

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

用例：

现代Web应用程序，可以通过零配置部署和零服务器管理快速接触客户。

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

请参考云函数和应用引擎的官方文档页面。

- Ravindra babu

1

正如@Cameron所指出的，云函数的主要区别在于可靠地响应事件。例如，如果您想在云存储桶中的更改上执行脚本，则有专用的云函数触发器。在GAE中复制此逻辑将更加繁琐。Firestore集合更改也是如此。

此外，GAE的B机器（基本或手动缩放的后端机器）具有方便的长时间运行时间，最长可达24小时。云函数目前仅运行9分钟。此外，GAE允许您将cron作业封装为应用程序代码旁边的yaml文件。这使得开发服务器少的事件驱动服务更加清洁。

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

- GregK

0

由于Cloud Functions和App Engine都是无服务器服务，这是我的感觉。

对于微服务 - 我们可以选择CF或App Engine。我更喜欢CF。

对于单体应用程序 - App Engine非常适合。

- Nagaraju Dorasala Subbaraidu

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dan Cornilescu · Accepted Answer

云函数（Cloud Functions，CFs）和Google应用引擎（Google App Engine，GAE）是不同的工具，用于不同的任务。在做任何工作时使用正确的工具通常是个好主意。

用钳子敲钉子也许是可能的，但不如使用锤子方便。同样地，使用CFs构建复杂的应用程序也许是可能的，但使用GAE来构建肯定会更方便。

与GAE相比，CFs有几个劣势（当然是在构建更复杂的应用程序的情况下）：

它们仅限于Node.js、Python、Go、Java、.NET Core和Ruby语言。而GAE支持其他流行的编程语言。
它们真正为轻量级的独立功能设计，试图使用这些组件来构建复杂的应用程序很快就变得“笨拙”。是的，对于每个单独的请求，必须像GAE那样恢复每个单独请求的相互关系上下文，但只有GAE才有更方便的方法来完成这一点。例如用户会话管理，如其他评论中所讨论的。
GAE应用程序具有跨单独请求生存的应用程序上下文，而CFs则没有。这样的上下文使得对某些Google服务的访问对于GAE应用程序更加高效/性能（或者甚至纯粹的可能），但对于CFs则不是这样。例如memcached。
GAE应用程序的应用程序上下文可支持更有效/高性能的其他服务客户端库，而这些服务客户端库不能在CFs上运行。例如使用ndb客户端库访问数据存储（仅适用于标准环境的GAE Python应用程序）可能比使用通用数据存储客户端库更加高效/性能。
GAE可以更具成本效益，因为其采用“批发”定价（基于实例小时数，无论特定实例提供多少请求），而CFs采用“零售”定价（每个调用都会单独收费）。
由于通常负责处理请求的应用程序实例已经在运行，因此GAE应用程序的响应时间可能比CFs更短，因此：
- GAE 应用程序上下文不需要加载/恢复，它已经可用，但 CF 需要加载/恢复它。
- （大多数情况下）处理代码已经加载；CF 的代码仍需要加载。不太确定这一点，我猜它取决于底层实现。