Google App Engine和Google Compute Engine有什么区别？
Answers:
App Engine是平台即服务。这意味着您只需部署代码，平台即可为您完成其他所有工作。例如，如果您的应用非常成功，则App Engine将自动创建更多实例来处理增加的数量。
Compute Engine是基础架构即服务。您必须创建和配置自己的虚拟机实例。它为您提供了更大的灵活性，并且其成本通常比App 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可能需要一个新实例-冷启动一个新实例可能需要几秒钟或更长时间（取决于运行时和您的代码）。
这使得Cloud Functions非常适合（a）罕见的调用-无需万一发生故障就无需保持实例存活；（b）实例不断旋转和关闭的快速变化的负载，以及可能更多的用例。
基本区别在于Google App Engine（GAE）是平台即服务（PaaS），而Google Compute Engine（GCE）是基础架构即服务（IaaS）。
要在GAE中运行您的应用程序，您只需要编写代码并将其部署到GAE中，就没有其他麻烦了。由于GAE具有完全可伸缩性，因此在流量增加时会自动获取更多实例，而在流量减少时会减少实例。您将为您真正使用的资源付费，我的意思是，您将为您的应用实际使用的Instance-Hours，Transferd Data，Storage等收费。但限制是，您只能在Python，PHP，Java，NodeJS，.NET，Ruby和** Go中创建应用程序。
另一方面，GCE以虚拟机的形式为您提供了完整的基础架构。您可以在其中编写或安装任何程序，因此可以完全控制这些VM的环境和运行时。实际上，GCE是虚拟使用Google数据中心的方式。在GCE中，必须使用Load Balancer手动配置基础结构以处理可伸缩性。
GAE和GCE都是Google Cloud Platform的一部分。
更新： 2014年3月，Google在App Engine下宣布了一项名为“ 托管虚拟机”的新服务。托管虚拟机为应用程序引擎应用程序提供了比应用程序平台，CPU和内存选项更多的灵活性。与GCE一样，您可以在这些VM中为App Engine应用程序创建自定义运行时环境。App Engine的实际托管虚拟机在一定程度上模糊了IAAS和PAAS之间的边界。
简而言之：计算引擎为您提供一台您完全控制/负责的服务器。您可以直接访问操作系统，并安装所需的所有软件，通常是Web服务器，数据库等。
在App Engine中，您不管理任何基础软件的操作系统。您只需上传代码（Java，PHP，Python或Go）并瞧瞧-它就可以运行...
App Engine可以省去很多麻烦，尤其是对于没有经验的人们，但它有2个明显的缺点：1.价格更高（但它确实有免费配额，而计算引擎没有）2.您控制较少，因此某些事情不是可能，或只能以一种特定方式（例如保存和写入文件）。
或使其更简单（因为有时我们无法区分GAE Standard和GAE Flex）：
Compute Engine类似于虚拟PC，例如，您将在其中部署小型网站+数据库。您可以管理一切，包括控制已安装的磁盘驱动器。如果您部署网站，则负责设置DNS等。
Google App Engine（标准）就像一个只读的沙盒文件夹，您可以在其中上传要执行的代码，而不必担心其余的代码（是的：只读-已为您安装了一组固定的库，您无法部署第三方图书馆）。DNS /子域等非常容易映射。
Google App Engine（Flexible）实际上就像一个完整的文件系统（不仅仅是一个锁定的文件夹），在其中，您拥有比Standard引擎更大的功能，例如，您拥有读/写权限（但比Compute Engine少） ）。在GAE标准中，已为您安装了一组固定的库，并且您不能随意部署第三方库。在Flexible环境中，您可以安装应用程序依赖的任何库，包括自定义构建环境（例如Python 3）。
尽管GAE Standard的处理非常繁琐（尽管Google听起来很简单），但在承受压力的情况下，它的伸缩性确实很好。这很麻烦，因为您需要测试并确保与锁定环境的兼容性，并确保您使用的任何第三方库都不会使用您不知道的其他第三方库可能无法在GAE标准下运行。在实践中设置它需要花费更长的时间，但是从长远来看，对于简单部署而言，它可能会带来更多回报。
除了以上列表中的App Engine与Compute Engine注释外，此处的清单还包括与Google Kubernete Engine的比较以及一些基于从小型到大型应用程序的经验的注释。有关更多信息，请参阅“ 选择App Engine环境 ”页上的Google Cloud Platform文档对App Engine Standard和Flex中功能的高级描述。有关App Engine和Kubernetes部署的另一个比较，请参阅Daz Wilkin App Engine Flex或Kubernetes Engine的帖子。
App Engine标准
优点
- 就直接成本以及维护应用程序的成本而言，对于低流量应用程序而言非常经济。
- 自动缩放速度很快。App Engine中的自动缩放基于轻量级实例类F1-F4。
- 版本管理和流量分割快速便捷。这些功能是内置于App Engine（标准和Flex）中的。
- 最少的管理，开发人员只需要专注于他们的应用程序。开发人员无需担心像GCE中那样以可靠的方式管理VM，也不必担心像GKE中那样学习集群。
- 快速访问数据存储区。首次发布App Engine时，运行时与数据存储库位于同一位置。后来，数据存储区被拆分为独立的产品Cloud数据存储区，但与数据存储区一起使用的App Engine Standard仍在同一地点。
- 支持访问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 Flex
优点
- 可以使用自定义运行时
- 与GCE网络的本机集成
- 版本和流量管理方便，与Standard相同
- 较大的实例大小可能更适合大型复杂的应用程序，尤其是可能使用大量内存的Java应用程序
缺点
- 网络集成不是完美的-无法与内部负载均衡器或共享虚拟私有云集成
- 通常无法访问托管的Memcache
Google Kubernetes引擎
优点
- 与容器的本机集成允许自定义运行时并更好地控制群集配置。
- 体现了许多与虚拟机一起使用的最佳实践，例如不可变的运行时环境和轻松回滚到以前版本的能力
- 提供一致且可重复的部署框架
- 基于开放标准，尤其是Kubernetes，可实现云与本地之间的可移植性。
- 可以使用Docker容器和Google Container Registry完成版本管理
缺点
- 流量分割和管理是自己做的，可能会利用Istio和Envoy
- 一些管理开销
- 需要一段时间来逐步扩展Kubernetes概念，例如Pod，部署，服务，入口和名称空间
- 需要公开一些公共IP，除非使用现在处于beta版的Private Clusters消除了这种需求，但是您仍然需要提供对运行kubectl命令的位置的访问权限。
- 监控整合并不完美
- 虽然Kubernetes Engine本身支持L3内部负载平衡，但L7内部负载平衡是自己做的，可能会利用Envoy
计算引擎
优点
- 易于扩展-无需在Kubernetes或App Engine上进行扩展，只需重用您以前的经验即可。这可能是直接使用Compute Engine的主要原因。
- 完全控制-您可以直接利用Compute Engine的许多功能，并安装所有您喜欢的东西的最新版本，以保持最新发展。
- 不需要公共IP。如果公共IP上暴露了某些遗留软件，可能很难锁定。
- 您可以利用容器优化的操作系统来运行Docker容器
缺点
- 通常情况下，您需要自己动手做，尽管要在包括Cloud Launcher在内的多个地方重用解决方案，但要在可靠性和安全性方面进行适当的工作可能会充满挑战。
- 更多的管理开销。有许多用于Compute Engine的管理工具，但它们不一定像App Engine和Kubernetes Engine监视工具那样了解您如何部署应用程序。
- 自动缩放基于GCE实例，该实例可能比App Engine慢
- 趋势是在雪花GCE实例上安装软件，这可能需要一定的维护工作
如前所述，Google Compute Engine（GCE）是基础架构即服务（IaaS），而Google App Engine（GAE）是平台即服务（PaaS）。您可以检查下图，以更好地理解它们之间的区别（来自此处并作了更好的解释）-
Google Compute Engine
GCE是Google Cloud Platform（GCP）提供的一项重要服务，因为大多数GCP服务都使用管理层下的GCE实例（VM）（不确定哪个不这样做）。其中包括App Engine，Cloud Functions，Kubernetes Engine（早期容器引擎），Cloud SQL等。GCE实例是其中最可自定义的单元，因此仅当您的应用程序无法在任何其他GCP服务上运行时才应使用。人们大多数时候都使用GCE将其本地应用程序转移到GCP，因为它需要的更改很少。以后，他们可以选择将其他GCP服务用于其应用程序的单独组件。
Google App Engine
GAE是GCP提供的第一项服务（早在Google进入云业务之前）。它会自动从0缩放到无限实例（在下面使用GCE）。它具有2种口味：标准环境和灵活环境。
Standard Environment确实非常快，当没有人使用您的应用程序时，它可以缩减为0个实例，可以在数秒之内扩展和缩减，并具有专用于Google服务和库的缓存，身份验证等。因为它在沙盒中运行 您只需要对特定的编程语言使用托管运行时。最近添加的是Node.js（8.x）和Python3.x。较早的运行时适用于Go，PHP，Python 2.7，Java等。
Flexible Environment更加开放，因为它允许您使用自定义运行时，因为它使用Docker容器。因此，如果您的运行时在提供的运行时中不可用，则始终可以为执行环境创建自己的dockerfile。需要注意的是，即使没有人使用您的应用程序，它也需要至少运行1个实例，并且放大和缩小需要几分钟。
不要将GAE flexible与Kubernetes Engine混淆，因为后者会使用实际的Kubernetes，并提供更多的自定义和功能。当您需要无状态容器且应用程序仅依赖HTTP或HTTPS协议时，GAE Flex很有用。对于其他协议，Kubernetes Engine（GKE）或GCE是您的唯一选择。检查我的其他答案以获得更好的解释。
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。可以通过许多客户端库（包括Java，.NET，Python，Go，Ruby，PHP和Javascript的客户端库）访问BigQuery。提供了一种称为NoSQL的类似于SQL的语法，可以通过这些客户端库或通过Web用户界面进行访问。最后，让我们谈谈Google Cloud平台数据库选项，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平台服务轻松有效地结合在一起使用的能力，则这是潜在的飞速发展。
我将以一种对我有意义的方式进行解释：
Compute Engine：如果您是自己动手或拥有IT团队，并且只想在具有特定OS（例如linux）的云上租用计算机，则可以使用Compute Engine。您必须自己做所有事情。
App Engine：例如，如果您是python程序员，并且想在云上租用预配置的计算机，该计算机具有运行Web服务器的Linux和具有必要模块以及与之集成的某些插件的最新python 3其他外部服务，则可以使用App Engine。
无服务器容器（云运行）：如果您想部署本地安装环境的精确映像（例如：python 3.7 + flask + sklearn），但又不想处理服务器，扩展等，则创建一个容器在本地计算机上（通过docker），然后将其部署到Google Run。
无服务器微服务（云函数）：如果您想编写一堆可以完成特定工作的API（函数），则可以使用Google云函数。您只需专注于这些特定功能，就可以完成剩下的工作（服务器，维护，扩展等），以将您的功能公开为微服务。
当您深入研究时，会失去一些灵活性，但不必担心不必要的技术方面。您还可以支付更多，但可以节省时间和成本（IT部门）：其他人（google）正在为您完成。
如果您不想关心负载平衡，扩展等问题，将您的应用程序拆分为一堆“无状态” Web服务非常重要，该服务可将持久性内容写入单独的存储（数据库或Blob存储）中。然后您将发现Cloud Run和Cloud Functions多么出色。
我个人发现Google Cloud Run是一个很棒的解决方案，具有绝对的开发自由（只要是无状态的），可以将其作为Web服务公开，可以为您的解决方案提供泊坞窗，并通过Cloud Run进行部署。让google作为您的IT和DevOps，您无需关心扩展和维护。
我尝试了所有其他选项，每个选项都有不同的用途，但Google Run真棒。对我来说，这是真正的无服务器，同时又不会失去开发的灵活性。
Google Compute Engine（GCE）
云中托管的虚拟机（VM）。在云之前，这些通常称为虚拟专用服务器（VPS）。您将以与使用物理服务器相同的方式使用这些物理服务器，在该物理服务器上安装和配置操作系统，安装应用程序，安装数据库，使操作系统保持最新状态，等等。这称为基础架构-即服务（IaaS）。
当现有应用程序在数据中心的VM或服务器上运行并且想要轻松将其迁移到GCP时，VM最有用。
Google App引擎
App Engine托管并运行您的代码，而无需您处理操作系统，网络以及您必须通过物理服务器或VM管理的许多其他事情。将其视为运行时，可以自动部署，版本化和扩展您的应用程序。这称为平台即服务（PaaS）。
当您想要自动部署和自动扩展应用程序时，App Engine最有用。除非您的应用程序需要自定义操作系统配置，否则App Engine通常比手动配置和管理VM更具优势。