何时选择 App Engine 而不是 Cloud Functions 函数? [英] When to choose App Engine over Cloud Functions?

问题描述

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

Sorry, if this is a naive question, but i've watched bunch of talks from google's staff and still don't understand why on earth i would use AE instead of CF?

如果我理解正确的话，这两个服务的整体概念是构建微服务架构".

If i understood it correctly, the whole concept of both of these services is to build "microservice architecture".

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

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

Though, AE must be wrapped into own server. Basically it utilizes a lot of complexities on top of the same capabilities as CF. So, when should i use it instead of CF?

推荐答案

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

Cloud Functions (CFs) and Google App Engine (GAE) are different tools for different jobs. Using the right tool for the job is usually a good idea.

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

Driving a nail using pliers might be possible, but it won't be as convenient as using a hammer. Similarly building a complex app using CFs might be possible, but building it using GAE would definitely be more convenient.

与 GAE 相比，CF 有几个缺点(当然是在构建更复杂的应用程序的情况下):

CFs have several disadvantages compared to GAE (in the context of building more complex applications, of course):

• 它们仅限于 Node.js、Python、Go、Java、.NET Core 和 Ruby.GAE 支持其他几种流行的编程语言
• 它们确实是为轻量级、独立功能而设计的，尝试使用此类组件构建复杂的应用程序很快就会变得尴尬".是的，每个单独请求的相互关系上下文也必须在 GAE 上恢复，只有 GAE 才能从更方便的方式中受益，而这些方式在 CF 上不可用.例如用户会话管理，如其他评论中所述
• GAE 应用有一个应用上下文，可以在各个请求中存活下来，而 CF 没有.这样的上下文使 GAE 应用程序对某些 Google 服务的访问更加高效/性能(甚至可能)，但对于 CF 则不然.例如 memcached.
• GAE 应用的应用上下文的可用性可以为无法在 CF 上运行的其他服务提供更高效/性能更高的客户端库.例如，使用 ndb 客户端库(仅适用于标准 env GAE python 应用程序)访问数据存储比使用通用数据存储客户端库更高效/性能更高.
• GAE 可以更具成本效益，因为它是批发"式的与零售"相比定价(基于实例小时，无论特定实例服务多少请求)CF 的定价(每次调用单独收费)
• 响应时间可能对于 GAE 应用程序通常比 CF 短，因为处理请求的应用程序实例通常已经在运行，因此:
  • 不需要加载/恢复 GAE 应用上下文，它已经可用，CF 需要加载/恢复它
  • 处理代码(大部分时间)已经加载，CFs 的代码仍然需要加载.不确定这个，不过，我想这取决于底层实现.
  • they're limited to Node.js, Python, Go, Java, .NET Core, and Ruby. GAE supports several other popular programming languages
  • they're really designed for lightweight, standalone pieces of functionality, attempting to build complex applications using such components quickly becomes "awkward". Yes, the inter-relationship context for every individual request must be restored on GAE just as well, only GAE benefits from more convenient means of doing that which aren't available on CFs. For example user session management, as discussed in other comments
  • GAE apps have an app context that survives across individual requests, CFs don't have that. Such context makes access to certain Google services more efficient/performant (or even plain possible) for GAE apps, but not for CFs. For example memcached.
  • the availability of the app context for GAE apps can support more efficient/performant client libraries for other services which can't operate on CFs. For example accessing the datastore using the ndb client library (only available for standard env GAE python apps) can be more efficient/performant than using the generic datastore client library.
  • GAE can be more cost effective as it's "wholesale" priced (based on instance-hours, regardless of how many requests a particular instance serves) compared to "retail" pricing of CFs (where each invocation is charged separately)
  • response times might be typically shorter for GAE apps than CFs since typically the app instance handling the request is already running, thus:
    • the GAE app context doesn't need to be loaded/restored, it's already available, CFs need to load/restore it
    • the handling code is (most of the time) already loaded, CFs' code still needs to be loaded. Not to sure about this one, tho, I guess it depends on the underlying implementation.

    这篇关于何时选择 App Engine 而不是 Cloud Functions 函数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！