Google App Engine 和 Google Compute Engine 有什么区别？
我想知道 App Engine 和 Compute Engine 之间的区别是什么。任何人都可以向我解释其中的区别吗？
App Engine 是一种平台即服务。这意味着您只需部署代码，平台会为您完成所有其他工作。例如，如果您的应用非常成功，App Engine 将自动创建更多实例来处理增加的数量。
Compute Engine 是一种基础架构即服务。您必须创建和配置自己的虚拟机实例。它为您提供了更大的灵活性，并且通常比 App Engine 成本低得多。缺点是您必须自己管理应用程序和虚拟机。
Read more about Compute Engine
如有必要，您可以混合使用 App Engine 和 Compute Engine。它们都适用于 Google Cloud Platform 的其他部分。
编辑（2016 年 5 月）：
另一个重要的区别：如果没有请求进入，在 App Engine 上运行的项目可以缩减到零实例。这在开发阶段非常有用，因为您可以持续数周而不会超过实例小时的慷慨免费配额。灵活的运行时（即“托管虚拟机”）需要至少一个实例来持续运行。
编辑（2017 年 4 月）：
Cloud Functions（目前处于测试阶段）在抽象方面比 App Engine 更上一层楼 - 没有实例！它允许开发人员部署一小段代码来执行以响应不同的事件，其中可能包括 HTTP 请求、云存储中的更改等。
与 App Engine 的最大区别在于函数按 100 毫秒计费，而 App Engine 的实例仅在 15 分钟不活动后才会关闭。另一个优点是 Cloud Functions 立即执行，而对 App Engine 的调用可能需要一个新实例 - 并且冷启动一个新实例可能需要几秒钟或更长时间（取决于运行时和您的代码）。
这使得 Cloud Functions 非常适合 (a) 罕见的调用 - 无需让实例保持活动状态以防万一发生某些事情，(b) 快速变化的负载，其中实例经常旋转和关闭，可能还有更多用例。
Read more about Cloud Functions
基本区别在于 Google App Engine (GAE) 是 Platform as a Service (PaaS) 而 Google Compute Engine (GCE) 是 Infrastructure as a Service (IaaS)。
要在 GAE 中运行您的应用程序，您只需编写代码并将其部署到 GAE 中，没有其他令人头疼的问题。由于 GAE 是完全可扩展的，它会在流量增加时自动获取更多实例，并在流量减少时减少实例。你需要为你真正使用的资源付费，我的意思是，你需要为你的应用实际使用的实例小时数、传输数据、存储等付费。但限制是，您只能在 Python、PHP、Java、NodeJS、.NET、Ruby 和 **Go 中创建应用程序。
另一方面，GCE 以虚拟机的形式为您提供完整的基础设施。您可以完全控制这些虚拟机的环境和运行时，因为您可以在那里编写或安装任何程序。实际上，GCE 是虚拟使用 Google 数据中心的方式。在 GCE 中，您必须手动配置基础架构以使用负载均衡器处理可扩展性。
GAE 和 GCE 都是 Google Cloud Platform 的一部分。
更新：2014 年 3 月，Google 在 App Engine 下宣布了一项名为 Managed Virtual Machine 的新服务。托管 VM 在应用平台、CPU 和内存选项方面为应用引擎应用提供了更多的灵活性。与 GCE 一样，您可以在这些 VM 中为应用引擎应用程序创建自定义运行时环境。实际上，App Engine 的托管虚拟机在一定程度上模糊了 IAAS 和 PAAS 之间的界限。
简而言之：计算引擎为您提供了一个您可以完全控制/负责的服务器。您可以直接访问操作系统，并安装所需的所有软件，通常是 Web 服务器、数据库等……
在应用引擎中，您不管理任何底层软件的操作系统。您只需上传代码（Java、PHP、Python 或 Go），瞧——它只是运行...
应用程序引擎省去了很多麻烦，尤其是对于没有经验的人，但它有两个明显的缺点：1. 更昂贵（但它确实有计算引擎没有的免费配额） 2. 你的控制较少，因此某些事情不是可能，或仅以一种特定方式可能（例如保存和写入文件）。
或者让它更简单（因为有时我们无法区分 GAE Standard 和 GAE Flex）：
Compute Engine 类似于虚拟 PC，例如，您可以在其中部署小型网站 + 数据库。您可以管理一切，包括控制已安装的磁盘驱动器。如果你部署一个网站，你负责设置 DNS 等。
Google App Engine（标准）就像一个只读的沙盒文件夹，您可以在其中上传要执行的代码，而不必担心其余部分（是的：只读 - 为您安装了一组固定的库，您无法部署3rd 方库随意）。 DNS / 子域等更容易映射。
Google App Engine（灵活）实际上就像一个完整的文件系统（不仅仅是一个锁定的文件夹），在其中您比标准引擎拥有更多的权力，例如您拥有读/写权限，（但与计算引擎相比更少）。在 GAE 标准中，您为您安装了一组固定的库，您不能随意部署 3rd 方库。在灵活环境中，您可以安装您的应用所依赖的任何库，包括自定义构建环境（例如 Python 3）。
尽管 GAE 标准处理起来非常麻烦（尽管 Google 让它听起来很简单），但在压力下它的扩展性非常好。这很麻烦，因为您需要测试并确保与锁定环境的兼容性，并确保您使用的任何 3rd 方库不使用您不知道的任何其他 3rd 方库，这些库可能不适用于 GAE 标准。在实践中设置它需要更长的时间，但从长远来看，对于简单的部署可能会更有价值。
除了上面列表中的 App Engine 与 Compute Engine 注释之外，此处还包括与 Google Kubernetes Engine 的比较以及一些基于从小型到大型的各种应用程序的经验的注释。有关更多信息，请参阅页面 Choosing an App Engine Environment 上的 Google Cloud Platform 文档对 App Engine Standard 和 Flex 中功能的高级描述。有关 App Engine 和 Kubernetes 部署的另一个比较，请参阅 Daz Wilkin App Engine Flex or Kubernetes Engine 的帖子。
App Engine 标准
优点
就直接成本和维护应用程序的成本而言，对于低流量应用程序来说非常经济。
自动缩放速度很快。 App Engine 中的自动缩放基于轻量级实例类 F1-F4。
版本管理和流量拆分快捷方便。这些功能原生内置于 App Engine（Standard 和 Flex）中。
最少的管理，开发人员只需要专注于他们的应用程序。开发人员无需担心像在 GCE 中那样以可靠的方式管理 VM，或者像在 GKE 中那样学习集群。
访问数据存储的速度很快。 App Engine 首次发布时，运行时与 Datastore 位于同一位置。后来 Datastore 被拆分为独立产品 Cloud Datastore，但 App Engine Standard 与 Datastore 的托管服务仍然存在。
支持访问 Memcache。
App Engine 沙盒非常安全。相比在 GCE 或其他虚拟机上开发，需要自己努力防止虚拟机在操作系统层面被接管，App Engine Standard 沙盒默认相对安全。
缺点
通常比其他环境更受限制实例更小。尽管这有利于快速自动扩展，但许多应用程序可以从更大的实例中受益，例如高达 96 个内核的 GCE 实例大小。
网络未与 GCE 集成
无法将 App Engine 置于 Google Cloud Load Balancer 之后。仅限于支持的运行时：Python 2.7、Java 7 和 8、Go 1.6-1.9 和 PHP 5.5。在 Java 中，有一些对 Servlet 的支持，但不是完整的 J2EE 标准。
App Engine 弹性
优点
可以使用自定义运行时
与 GCE 网络的本地集成
版本和流量管理方便，与标准相同
较大的实例大小可能更适合大型复杂应用程序，尤其是可以使用大量内存的 Java 应用程序
缺点
网络集成并不完美 - 没有与内部负载均衡器或共享虚拟私有云集成
对托管 Memcache 的访问通常不可用
谷歌 Kubernetes 引擎
优点
与容器的原生集成允许自定义运行时和对集群配置的更大控制。
体现了许多使用虚拟机的最佳实践，例如不可变的运行时环境和轻松回滚到以前版本的能力
提供一致且可重复的部署框架
基于开放标准，尤其是 Kubernetes，用于云和本地之间的可移植性。
版本管理可以通过 Docker 容器和 Google Container Registry 完成
缺点
流量拆分和管理是自己动手做的，可能利用 Istio 和 Envoy
一些管理开销
需要一些时间来了解 Kubernetes 概念，例如 pod、部署、服务、入口和命名空间
需要公开一些公共 IP，除非使用现在处于测试阶段的私有集群，消除这种需要，但您仍然需要提供对运行 kubectl 命令的位置的访问权限。
监控集成不完善
虽然 Kubernetes Engine 原生支持 L3 内部负载平衡，但 L7 内部负载平衡是自己动手做的，可能利用 Envoy
计算引擎
优点
易于升级 - 无需升级 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 实例上安装软件，这可能需要一些努力来维护
如前所述，Google Compute Engine (GCE) 是基础架构即服务 (IaaS)，而 Google App Engine (GAE) 是平台即服务 (PaaS)。您可以检查下图以更好地理解差异（取自并更好地解释 here） -
https://i.stack.imgur.com/BYfiO.jpg
Google Compute Engine GCE 是 Google Cloud Platform (GCP) 提供的一项重要服务，因为大多数 GCP 服务都使用管理层下的 GCE 实例 (VM)（不确定哪个不使用）。这包括 App Engine、Cloud Functions、Kubernetes Engine（早期的容器引擎）、Cloud SQL 等。GCE 实例是那里最可定制的单元，因此只能在您的应用程序无法在任何其他 GCP 服务上运行时使用。大多数时候人们使用 GCE 将他们的 On-Prem 应用程序转移到 GCP，因为它只需要很少的更改。之后，他们可以选择将其他 GCP 服务用于其应用程序的单独组件。
Google App Engine GAE 是 GCP 提供的第一个服务（早在 Google 进入云业务之前）。它从 0 自动缩放到无限实例（它在下面使用 GCE）。它有 2 种口味的标准环境和灵活环境。
标准环境非常快，当没有人使用您的应用程序时，可以缩小到 0 个实例，在几秒钟内扩大和缩小规模，并有专门的 Google 服务和库用于缓存、身份验证等。标准环境的警告是它非常严格因为它在沙箱中运行。您必须仅将托管运行时用于特定的编程语言。最近添加的是 Node.js (8.x) 和 Python 3.x。较旧的运行时可用于 Go、PHP、Python 2.7、Java 等。
灵活的环境更加开放，因为它允许您使用自定义运行时，因为它使用 docker 容器。因此，如果您的运行时在提供的运行时中不可用，您始终可以为执行环境创建自己的 dockerfile。需要注意的是，即使没有人使用您的应用程序，它也需要至少运行 1 个实例，而且扩展和缩减需要几分钟。
不要将 GAE 灵活与 Kubernetes Engine 混淆，后者使用实际的 Kubernetes 并提供更多的自定义和功能。当您想要无状态容器并且您的应用程序仅依赖于 HTTP 或 HTTPS 协议时，GAE Flex 非常有用。对于其他协议，Kubernetes Engine (GKE) 或 GCE 是您唯一的选择。检查 my other answer 以获得更好的解释。
如果您熟悉其他受欢迎的服务：
谷歌计算引擎 -> AWS EC2
Google App Engine -> Heroku 或 AWS Elastic Beanstalk
谷歌云函数 -> AWS Lambda 函数
我将以一种对我有意义的方式来解释它：
Compute Engine：如果您是自己动手的人或拥有 IT 团队，并且您只想在云上租用具有特定操作系统（例如 linux）的计算机，那么您可以选择 Compute Engine。你必须自己做所有事情。
App Engine：如果您（例如）是一名 Python 程序员，并且想在云上租用一台预配置的计算机，该计算机具有正在运行的 Web 服务器和最新的 Python 3 以及必要的模块和一些插件以集成其他外部服务，您可以使用 App Engine。
Serverless Container (Cloud Run)：如果你想部署本地设置环境的精确镜像（例如：python 3.7+flask+sklearn）但你不想处理服务器、缩放等。你创建一个容器在您的本地计算机上（通过 docker），然后将其部署到 Google Run。
无服务器微服务（云功能）：如果您想编写一堆执行特定工作的 API（功能），您可以选择谷歌云功能。您只需专注于那些特定功能，其余工作（服务器、维护、扩展等）为您完成，以便将您的功能公开为微服务。
随着深入，您会失去一些灵活性，但您不必担心不必要的技术方面。您还需要多付一点钱，但可以节省时间和成本（IT 部分）：其他人（谷歌）正在为您做这件事。
如果您不想关心负载平衡、缩放等，那么将您的应用程序拆分为一堆“无状态”Web 服务至关重要，这些服务将任何持久性内容写入单独的存储（数据库或 Blob 存储）中。然后你会发现 Cloud Run 和 Cloud Functions 是多么的棒。
就个人而言，我发现 Google Cloud Run 是一个很棒的解决方案，开发中的绝对自由（只要是无状态的），将其公开为 Web 服务，将您的解决方案 docker 化，使用 Cloud Run 进行部署。让 google 成为您的 IT 和 DevOps，您无需关心扩展和维护。
我已经尝试了所有其他选项，每个选项都适用于不同的目的，但 Google Run 真是太棒了。对我来说，它是真正的无服务器，而不会失去开发的灵活性。
谷歌计算引擎 (GCE)
托管在云中的虚拟机 (VM)。在云之前，这些通常被称为虚拟专用服务器 (VPS)。您可以像使用物理服务器一样使用它们，在其中安装和配置操作系统、安装应用程序、安装数据库、使操作系统保持最新等。这称为基础架构-即服务 (IaaS)。
当您在数据中心的虚拟机或服务器上运行现有应用程序并希望将其轻松迁移到 GCP 时，虚拟机最有用。
谷歌应用引擎
App Engine 托管和运行您的代码，而无需您处理操作系统、网络以及您必须使用物理服务器或 VM 管理的许多其他事情。将其视为一个运行时，它可以自动部署、版本化和扩展您的应用程序。这称为平台即服务 (PaaS)。
当您想要自动部署和自动扩展应用程序时，App Engine 最有用。除非您的应用程序需要自定义操作系统配置，否则 App Engine 通常比手动配置和管理虚拟机更有优势。
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，您可以在几秒钟内分析大量数据，我们所说的是数百万条记录。访问是通过一个简单的 UI、一个代表性状态传输或 REST 接口来处理的。
正如您可能怀疑的那样，数据存储不是问题，并且可以扩展到数百 TB。 BigQuery 可通过大量客户端库访问，包括用于 Java、.NET、Python、Go、Ruby、PHP 和 Javascript 的客户端库。可以通过这些客户端库或 Web 用户界面访问一种称为 NoSQL 的类似 SQL 的语法。最后，我们来谈谈谷歌云平台数据库选项，Cloud SQL 和 Cloud Datastore。
有一个主要区别。 Cloud SQL 适用于关系数据库，主要是 MySQL，而 Cloud Datastore 适用于使用 noSQL 的非关系数据库。借助 Cloud SQL，您可以选择在美国、欧洲或亚洲进行托管，每个数据库实例拥有 100 GB 的存储空间和 16 GB 的 RAM。
Cloud Datastore 每月免费提供多达 5 万条读/写指令，每月还可存储 1 GB 的数据。但是，如果您超出这些配额，则需要付费。 App Engine 还可以与 Google Cloud 平台的其他鲜为人知、更有针对性的成员合作，包括用于创建 API 后端的 Cloud Endpoints、用于数据分析和趋势预测的 Google Prediction API，或用于多语言输出的 Google Translate API。
虽然您可以单独使用 App Engine 做相当多的事情，但如果您考虑到它与其他 Google Cloud 平台服务轻松高效地工作的能力，它的潜力会飞涨。
https://i.stack.imgur.com/4gOch.png
关注公众号
不定期副业成功案例分享
