logo标签列表

谷歌应用引擎和谷歌计算引擎有什么区别？

google-app-enginegoogle-compute-enginegoogle-cloud-platform
537
我想知道App Engine和Compute Engine之间的区别是什么。有人能为我解释一下吗？
53
他们的主页没有让我理解清楚，这里的呈现方式很好。这个 StackOverflow 页面对我很有用。因人而异。 :) - Mikeumus
12个回答
570

App Engine 是一种平台即服务（Platform-as-a-Service）。这意味着您只需部署代码，平台会代劳其他所有工作。例如，如果您的应用变得非常成功，App Engine 将自动创建更多实例以处理增加的流量。

了解有关 App Engine 的更多信息

Compute Engine 是一种基础设施即服务（Infrastructure-as-a-Service）。您需要创建和配置自己的虚拟机实例。它提供更多的灵活性，并且通常比 App Engine 成本更低。缺点是您需要自己管理应用程序和虚拟机。

了解有关 Compute Engine 的更多信息

如果必要，您可以混合使用 App Engine 和 Compute Engine。它们都与 Google Cloud Platform 的其他部分良好地配合使用。

编辑（2016 年 5 月）：

另一个重要区别：在没有请求进来时，运行在 App Engine 上的项目可以将实例数量缩减至零。在开发阶段，这非常有用，因为您可以在数周内保持慷慨的免费配额。灵活运行时（即“托管 VM”）需要至少一个实例持续运行。

编辑（2017 年 4 月）：

Cloud Functions（目前处于 beta 版）是从抽象层面上比 App Engine 更高级别的服务，没有实例！它允许开发人员部署小块代码，以响应不同的事件，这些事件可能包括 HTTP 请求、Cloud Storage 中的更改等。

与 App Engine 最大的区别在于，函数按每 100 毫秒定价，而 App Engine 的实例仅在 15 分钟不活动后关闭。另一个优点是 Cloud Functions 立即执行，而对 App Engine 的调用可能需要一个新实例 - 冷启动新实例可能需要几秒钟或更长时间（取决于运行时和您的代码）。

这使得云函数非常适用于以下情况: (a) 很少调用 - 不需要保持实例一直处于开启状态以防万一， (b) 快速变化的负载，其中实例经常旋转和关闭，可能还有更多的使用情况。

了解更多关于云函数的信息

12
如果我想通过 Docker 进行部署，除了价格之外，使用 GAE 和 GCE 有什么区别？ - FullStack
3
嗨，Volgin，你能详细说明一下为什么“计算引擎”比“应用引擎”便宜得多吗？谢谢。 - fangzhzh
31
App Engine 提供了一种自动化的水平（即便利性），而这是在 GCE 上无法获得的。在使用 GAE 五年中，我从未必须安装、打补丁或配置任何软件、复制磁盘等。此外，它还提供相对强大的负载和容量管理 - 根据需要自动启动和关闭实例。总体来说，这些特点让 Google 能够更高价位地收取实例小时费用，而许多公司和个人开发者乐意支付这个溢价，因为 GAE 节省了大量时间，可以更好地改善您自己的应用程序或以其他方式赚钱。 - Andrei Volgin
11
谷歌还提供另一项名为“容器引擎”的服务，专注于Docker和容器管理（Kubernetes）。 - Bram
18
关于"Cloud Functions 立即执行的另一个优点"的快速评论。从实际经验来看，它们有与冷启动相关的相同缺点，这可能会使得一个简单的 sum(a,b) {return a+b} 在冷启动时需要几分钟时间。 - Adam
显示剩余6条评论
115
基本区别在于Google App Engine（GAE）是平台即服务（PaaS），而Google Compute Engine（GCE）是基础设施即服务（IaaS）。
要在GAE中运行应用程序，您只需要编写代码并将其部署到GAE中，无需其他麻烦。由于GAE是完全可扩展的，因此在流量增加时它会自动获取更多的实例，并在流量减少时减少实例。您将按您真正使用的资源付费，我的意思是，您将为您的应用程序实例小时数，传输数据，存储等实际使用的资源付费。但限制是，您只能使用Python、PHP、Java、NodeJS、.NET、Ruby和**Go创建应用程序。
另一方面，GCE以虚拟机的形式为您提供完整的基础设施。您可以对这些虚拟机的环境和运行时拥有完全控制权，因为您可以在那里编写或安装任何程序。实际上，GCE是使用Google数据中心的虚拟方式。在GCE中，您必须手动配置基础设施来处理可扩展性，使用负载均衡器。

GAE和GCE都是Google Cloud Platform的一部分。

更新： 2014年3月，谷歌在应用引擎下推出了一个名为Managed Virtual Machine的新服务。 Managed VMs为应用程序提供了比应用平台更多的灵活性，包括CPU和内存选项。与GCE一样，您可以为应用引擎应用程序在这些VM中创建自定义运行时环境。实际上，应用引擎的Managed VMs在IAAS和PAAS之间模糊了界限。

1
从他们的文档中，您可以通过Docker将VM部署到GAE。https://cloud.google.com/appengine/docs/managed-vms/ - FullStack
现在看来，您也可以在GAE上使用Node.js和Ruby了。 - Blaszard
3
托管虚拟机现在被称为应用引擎灵活环境。 - killjoy
1
我将我的代码部署到了App Engine，当我检查控制台时，我看到了一个Compute Engine VM实例，同时在检查App Engine控制台时，我看到了HTTP servlet请求的痕迹。那么我是在使用App Engine还是Compute Engine？ - EhsanR
我认为关于GAE中“存储”部分的描述：“...你将会被计费Instance-Hours、传输数据、存储等，这些都是你的应用程序实际使用的...”是错误的。GAE实例（大多数情况下）是易失性的。因此，当一个实例关闭时（例如，如果该实例是响应流量激增而创建的，现在在流量下降时被删除），您将丢失所有存储的数据。因此，我认为在GAE中声称您会因“存储”而被“收费”是不正确的，尽管您可以将GAE中的应用程序连接到提供存储的另一个GCP产品，并对后者进行收费，而不是作为GAE的一部分。 - Damilola Olowookere
@DamilolaOlowookere 我的意思是您可以添加持久性存储，这将额外收费（如果您提供外部IP等，则会发生同样的事情）。 - Mostafiz Rahman
69
简而言之：计算引擎为您提供一个服务器，您完全掌控/负责。您可以直接访问操作系统，并安装您需要的所有软件，通常是Web服务器、数据库等等。在应用引擎中，您不管理任何底层软件的操作系统。您只需上传代码（Java、PHP、Python或Go），然后它就会运行...
应用引擎节省了很多麻烦，特别适合经验不足的人，但它有两个重要缺点： 1. 更昂贵（但它有一个免费配额，计算引擎没有） 2. 您的控制力较小，因此某些事情根本不可能，或者只能以一种特定的方式实现（例如保存和编写文件）。
3
您可以通过Docker将虚拟机部署到GAE，这样您就可以管理操作系统等内容。https://cloud.google.com/appengine/docs/managed-vms/ - FullStack
10
“它只是运行”？你是认真的吗？我认为我不是唯一一个在将代码调整到GAE时遇到上传文件或后台处理等问题的人。 - emfi
@emfi 有哪些问题？你能举些例子吗？ - Ziyaddin Sadigov
1
更新：Compute Engine拥有免费配额。 - shamisen
47

为了更简单易懂地解释（因为有时我们会分不清 GAE 标准版和 GAE 弹性版之间的区别）：

计算引擎类似于虚拟个人电脑，您可以部署一个小型网站及数据库等内容。您需要管理所有内容并控制已安装磁盘驱动器。如果您部署了网站，则需要负责设置 DNS 等。

Google 应用引擎 (标准版) 类似于只读沙盒文件夹，您可以将代码上传到其中执行，无需担心其余部分（是的：只读 - 为您安装了一组固定库，不能随意部署第三方库）。DNS / 子域名等映射要容易得多。

Google 应用引擎 (弹性版) 实际上就像一个完整的文件系统（而不仅仅是一个受限文件夹），您具有比标准引擎更多的权限，例如读写权限（但与计算引擎相比较少）。在 GAE 标准版中，为您安装了一组固定库，不能随意部署第三方库。在弹性环境中，您可以安装应用程序所依赖的任何库，包括自定义构建环境（例如 Python 3）。

尽管 GAE 标准版处理起来非常麻烦（虽然谷歌让它听起来很简单），但在面临压力时缩放效果非常好。麻烦之处在于，您需要测试和确保与受限环境的兼容性，并确保您使用的任何第三方库不会使用您不知道的其他第三方库，这些库可能无法在 GAE 标准版上工作。实际上设置需要更长时间，但对于简单部署而言，从长远来看可能更有回报。

“只读”是指我们无法向磁盘文件写入数据吗？ - John Balvin Arias
@JohnBalvinArias 是的，它是一个只读的沙盒容器。您无法访问“外部”世界，也无法向此容器/磁盘写入。它只是供您执行代码的。 - strangetimes
如果我可以使用Docker在GAE中安装软件，这是否意味着谷歌负责创建/分配带有基本配置的Linux实例，然后在其之上运行Docker？从本质上讲，计算引擎增加了VM配置的额外责任。我是对的吗？ - old-monk
40
除了上面提到的App Engine与Compute Engine的比较，这里的列表还包括与Google Kubernetes Engine的比较，以及基于从小型到非常大型的各种应用程序的经验得出的一些注释。有关更多要点，请参见Google Cloud Platform文档中有关App Engine标准版和Flex版本功能的高级描述，在页面选择App Engine环境中。有关App Engine和Kubernetes部署的另一个比较，请参见Daz Wilkin的文章App Engine Flex或Kubernetes Engine。 App Engine标准版 优点
  • 对于低流量应用程序而言，直接成本和维护应用程序的成本都非常经济。
  • 自动扩展速度快。App Engine中的自动扩展基于轻量级实例类别F1-F4。
  • 版本管理和流量分割快捷方便。这些功能是内置在App Engine（标准版和Flex版）中的。
  • 管理最小化，开发人员只需关注他们的应用程序。开发人员无需担心像GCE一样在可靠性方面管理VM，或者像GKE一样学习集群。
  • 访问Datastore非常快。当App Engine首次发布时，运行时与Datastore共存。后来，Datastore作为独立产品Cloud Datastore被拆分出来，但App Engine标准服务与Datastore的共存仍然存在。
  • 支持访问Memcache。
  • App Engine沙盒非常安全。与在GCE或其他虚拟机上开发相比，在操作系统级别防止虚拟机被接管需要自己进行尽职调查，而App Engine标准沙盒默认情况下相对安全。

缺点

  • 实例通常比其他环境更受限制。尽管这有利于快速自动缩放，但许多应用程序可以从更大的实例中受益，例如GCE实例大小高达96个核心。
  • 网络与GCE未集成
  • 无法将App Engine放在Google Cloud负载均衡器后面。仅限于支持的运行时：Python 2.7、Java 7和8、Go 1.6-1.9和PHP 5.5。在Java中，对Servlet有一定的支持，但不是完整的J2EE标准。

App Engine Flex

优点

  • 可以使用自定义运行时
  • 与GCE网络本地集成
  • 版本和流量管理方便，与标准版相同
  • 更大的实例大小可能更适合于大型复杂应用程序，特别是可以使用大量内存的Java应用程序

缺点

  • 网络集成不完美-没有与内部负载均衡器或共享虚拟专用云的集成
  • 通常无法访问托管Memcache

Google Kubernetes Engine

优点

  • 原生集成容器，允许自定义运行时并更好地控制群集配置。
  • 采用了虚拟机的许多最佳实践，例如不可变的运行时环境和轻松回滚到以前的版本。
  • 提供了一致和可重复的部署框架。
  • 基于开放标准，尤其是 Kubernetes，在云和本地之间具有可移植性。
  • 使用 Docker 容器和Google Container Registry可以完成版本管理

Cons

  • 流量拆分和管理需要自己实现，可能要利用 Istio 和 Envoy。
  • 一些管理开销。
  • 需要一些时间来熟悉 Kubernetes 的概念，例如 pod、deployment、service、ingress 和 namespace。
  • 需要公开一些公共 IP，除非使用Private Clusters（目前处于测试版），消除了这种需要，但仍需要提供访问 kubectl 命令将从哪些位置运行的位置。
  • 监视集成不完美。
  • 虽然 Kubernetes Engine 本身支持 L3 内部负载均衡，但 L7 内部负载均衡则需要自行实现，可能要利用 Envoy。

Compute Engine

Pros

  • 易于上手 - 无需学习 Kubernetes 或 App Engine，只需重复利用之前所学就好了。这可能是直接使用 Compute Engine 的主要原因。
  • 完全控制 - 你可以直接利用许多 Compute Engine 功能，并安装最新版本的所有喜爱软件，以保持最前沿。
  • 不需要公共 IP。如果任何内容暴露在公共 IP 上，则某些旧版软件可能过于难以锁定。
  • 你可以利用 Container-Optimized OS 来运行 Docker 容器。

缺点

  • 大多数情况下是自己动手，这对于可靠性和安全性可能会有挑战，但你可以从各个地方重复利用解决方案，包括 Cloud Launcher。
  • 更多的管理开销。虽然 Compute Engine 有许多管理工具，但它们不一定能理解你如何部署应用程序，就像 App Engine 和 Kubernetes Engine 监控工具那样。
  • 自动扩展基于 GCE 实例，可能比 App Engine 慢。
  • 倾向于在雪花般的 GCE 实例上安装软件，这可能需要一些维护工作。
31
根据之前的解释，Google Compute Engine（GCE）是基础设施即服务（IaaS），而Google App Engine（GAE）是平台即服务（PaaS）。您可以查看下面的图表以更好地了解区别（来源和更好地解释，请参见这里）。

Cloud Computing Types

Google Compute Engine
GCE是Google Cloud Platform（GCP）提供的重要服务，因为大多数GCP服务在管理层下使用GCE实例（虚拟机）（不确定哪些服务不使用）。这包括App Engine、Cloud Functions、Kubernetes Engine（之前的Container Engine）、Cloud SQL等。GCE实例是最可定制的单元，因此只有在您的应用程序无法在其他任何GCP服务上运行时才应使用它们。人们经常使用GCE将他们的On-Prem应用程序转移到GCP，因为它需要最少的更改。随后，他们可以选择使用其他GCP服务来处理其应用程序的各个组件。

Google App Engine
GAE是GCP提供的第一个服务（早在Google进入云业务之前）。它可以从0到无限数量的实例进行自动扩展（它在底层使用GCE）。它有两种版本：标准环境和灵活环境。

标准环境非常快速，当没有人使用您的应用时，可以将实例数缩减至0，并且可以在几秒钟内动态扩展和收缩，具有专用的Google服务和用于缓存、身份验证等的库。标准环境的限制是它在沙箱中运行，因此非常受限。您只能使用特定编程语言的托管运行时。最近增加了Node.js（8.x）和Python 3.x。旧版本的运行时适用于Go、PHP、Python 2.7、Java等。

灵活环境更加开放，可以使用自定义运行时，因为它使用Docker容器。因此，如果提供的运行时中没有您需要的运行时，您始终可以为执行环境创建自己的Docker文件。不过，其中的注意事项是，即使没有人使用您的应用，也需要至少运行一个实例，而且扩展和收缩需要几分钟的时间。

不要将GAE的灵活性与Kubernetes Engine混淆，因为后者使用实际的Kubernetes并提供了更多的定制和功能。当您想要无状态容器且应用程序仅依赖于HTTP或HTTPS协议时，GAE Flex非常有用。对于其他协议，Kubernetes Engine（GKE）或GCE是您唯一的选择。请参考我的其他答案以获得更好的解释。
27

如果您熟悉其他流行的服务：

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku或AWS Elastic Beanstalk

Google Cloud Functions -> AWS Lambda函数

19

我将用我能理解的方式来解释：

  • 计算引擎：如果你是一个自己动手做或者有IT团队的人，你只想租用一台带有特定操作系统（例如Linux）的云计算机，那么你可以选择计算引擎。你需要自己完成所有工作。

  • 应用引擎：如果你是Python程序员，并且想要租用一台预配置的云计算机，它带有运行Web服务器的Linux和最新的Python 3以及必要的模块和一些插件，以便与其他外部服务集成，那么你可以选择应用引擎。

  • 无服务器容器（Cloud Run）：如果你想要部署本地设置环境的完全镜像（例如：Python 3.7+ Flask + sklearn），但不想处理服务器、扩展等问题，你可以在本地使用Docker创建一个容器，然后将其部署到Google Run。

  • 无服务器微服务（Cloud Functions）：如果你想编写一堆执行特定任务的API函数，那么你可以选择Google Cloud Functions。你只需要专注于这些特定的函数，其余的工作（服务器、维护、扩展等）都会为你完成，以将你的函数暴露为微服务。

随着深入开发，你会失去一些灵活性，但你不会担心不必要的技术细节。虽然你需要支付更多的费用，但可以通过（IT部分）让别人（Google）来帮你做事情来节省时间和成本。
如果你想不用关心负载均衡、扩展等问题，那么将你的应用程序拆分为一堆“无状态”Web服务，并将任何持久化内容写入到单独的存储（数据库或Blob存储）中非常重要。接着你就能发现Cloud Run和Cloud Functions有多么棒了。
个人而言，我认为 Google Cloud Run 是一个很棒的解决方案，它在开发方面具有绝对的自由（只要是无状态的），将其公开作为Web服务，使用Docker部署你的解决方案即可。让Google成为您的 IT 和 DevOps，您无需关心扩展和维护问题。
我尝试了所有其他选项，每个选项都适用于不同的目的，但 Google Run 真的很棒。对我来说，它是真正的无服务器体验，同时也没有失去开发灵活性。
17

谷歌计算引擎（GCE）

云托管的虚拟机（VMs），在云出现之前，通常称为虚拟专用服务器（VPS）。您可以像使用物理服务器一样使用它们，在其中安装和配置操作系统、应用程序、数据库，并保持操作系统更新等。这就是基础设施即服务（IaaS）。

当您有一个在数据中心的VM或服务器上运行的现有应用程序，并希望轻松将其迁移到GCP时，VMs非常有用。

谷歌应用引擎

App Engine主机和运行您的代码，而无需处理操作系统、网络和许多其他必须使用物理服务器或VM进行管理的内容。将其视为运行时，可以自动部署、版本化和扩展应用程序。这被称为平台即服务（PaaS）。

如果您需要自动化部署和自动化扩展应用程序，则应用引擎非常有用。除非您的应用程序需要自定义操作系统配置，否则与手动配置和管理VM相比，应用引擎通常更具优势。

12

App Engine为开发人员提供了控制Google Compute Engine核心的能力，同时为Google Compute Engine数据处理应用程序提供面向Web的前端。

另一方面，Compute Engine提供了直接和完整的虚拟机操作系统管理。要展示您的应用，您需要资源，而Google Cloud Storage非常适合存储您的资产和数据，无论它们用于什么用途。全球范围内的托管可快速访问数据。可靠性保证在99.95%的正常运行时间，Google还提供备份和恢复数据的功能，而且不可思议的是，存储空间是无限的。

您可以使用Google Cloud Storage管理您的资产，存储、检索、显示和删除它们。您也可以快速读写保存在Cloud Storage中的平面数据表。Google Cloud中的下一个是BigQuery。使用BigQuery，您可以在几秒钟内分析大量的数据，我们谈论的是数百万条记录。访问通过简单的用户界面或代表状态转移(REST)接口处理。

数据存储，正如您所猜测的那样，并不是问题，并且可以扩展到数百TB。BigQuery可通过一系列客户端库进行访问，包括Java、.NET、Python、Go、Ruby、PHP和Javascript等。一种名为NoSQL的类似SQL的语法可通过这些客户端库或Web用户界面访问。

最后，让我们谈谈Google云平台数据库选项Cloud SQL和Cloud Datastore。它们之间有一个主要区别。Cloud SQL用于关系数据库，主要是MySQL，而Cloud Datastore用于使用noSQL的非关系型数据库。对于Cloud SQL，您可以选择在美国、欧洲或亚洲进行托管，每个数据库实例具有100 GB存储空间和16 GB RAM。

Cloud Datastore每月提供高达50K读/写指令和1GB数据存储免费。如果超过这些配额，则需要收取费用。App Engine还可以与Google Cloud平台的其他较少知名的、更具针对性的成员一起使用，包括用于创建API后端的Cloud Endpoints、用于数据分析和趋势预测的Google Prediction API，以及用于多语言输出的Google Translate API。

虽然您可以通过独立使用App Engine实现许多功能，但是当您考虑到其与Google Cloud平台服务之间的轻松高效协作能力时，它的潜力会大幅提升。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接