我想知道应用程序引擎和计算引擎之间的区别是什么。谁能给我解释一下其中的区别?
应用引擎是一个平台即服务。这意味着您只需部署代码，平台就会为您完成其他所有工作。例如，如果你的应用变得非常成功，应用引擎会自动创建更多的实例来处理增加的容量。
阅读更多关于应用程序引擎
计算引擎是一种基础设施即服务。您必须创建并配置自己的虚拟机实例。它给你更多的灵活性，通常成本比App Engine低得多。缺点是你必须自己管理你的应用程序和虚拟机。
阅读更多关于计算引擎的信息
如果需要，你可以混合应用程序引擎和计算引擎。它们都可以很好地与谷歌云平台的其他部分协同工作。
编辑(2016年5月):
一个更重要的区别是:如果没有请求进入，在App Engine上运行的项目可以缩小到零实例。这在开发阶段是非常有用的，因为您可以在不超过慷慨的免费实例小时配额的情况下工作数周。灵活的运行时(即“托管虚拟机”)需要至少一个实例持续运行。
编辑(2017年4月):
云功能(目前处于测试阶段)在抽象方面是App Engine的下一个级别-没有实例!它允许开发人员部署一小段代码，以响应不同的事件，其中可能包括HTTP请求、云存储中的更改等。
App Engine最大的不同在于功能是以100毫秒为单位定价的，而App Engine的实例只会在不活动15分钟后关闭。另一个优点是云函数立即执行，而调用应用程序引擎可能需要一个新的实例-冷启动一个新实例可能需要几秒钟或更长的时间(取决于运行时和你的代码)。
这使得云函数非常适合(a)很少的调用——不需要为了以防发生什么事情而保持一个实例是活的，(b)在实例经常旋转和关闭的情况下快速改变负载，以及可能的更多用例。
阅读更多关于云功能的信息
简单地说:计算引擎给你一个服务器，你可以完全控制/负责。你可以直接访问操作系统，安装你想要的所有软件，通常是web服务器、数据库等……
在应用引擎中，你不需要管理任何底层软件的操作系统。你只需要上传代码(Java, PHP, Python或Go)，瞧——它就会运行……
应用引擎节省了大量的头痛，特别是对于没有经验的人，但它有2个显著的缺点: 1. 更贵(但它有一个计算引擎没有的免费配额) 2. 您的控制更少，因此某些事情是不可能的，或者只能以一种特定的方式实现(例如保存和写入文件)。
基本区别是谷歌应用程序引擎(GAE)是平台即服务(PaaS)，而谷歌计算引擎(GCE)是基础设施即服务(IaaS)。
To run your application in GAE you just need to write your code and deploy it into GAE, no other headache. Since GAE is fully scalable, it will automatically acquire more instances in case the traffic goes higher and decrease the instances when traffic decreases. You will be charged for the resources you really use, I mean, you will be billed for the Instance-Hours, Transferred Data, Storage etc your app really used. But the restriction is, you can create your application in only Python, PHP, Java, NodeJS, .NET, Ruby and **Go.
另一方面，GCE以虚拟机的形式为您提供完整的基础设施。您可以完全控制这些虚拟机的环境和运行时，因为您可以在其中编写或安装任何程序。实际上，GCE是虚拟使用谷歌数据中心的方式。在GCE中，您必须使用负载均衡器手动配置基础设施来处理可伸缩性。
GAE和GCE都是谷歌云平台的一部分。
更新:2014年3月谷歌在应用引擎下宣布了一项名为托管虚拟机的新服务。托管虚拟机在应用平台、CPU和内存选项上为应用引擎应用程序提供了更多的灵活性。像GCE一样，您可以在这些虚拟机中为应用程序引擎应用程序创建自定义运行时环境。实际上，App Engine的托管虚拟机在一定程度上模糊了IAAS和PAAS之间的界限。
应用程序引擎为开发人员提供了控制谷歌计算引擎核心的能力，以及为谷歌计算引擎数据处理应用程序提供面向web的前端。
另一方面，计算引擎提供直接和完整的虚拟机操作系统管理。要呈现你的应用程序，你需要资源，而谷歌云存储是存储你的资产和数据的理想选择，无论它们是用来做什么。通过在全球各地托管，您可以快速访问数据。可靠性在99.95%的正常运行时间得到保证，谷歌还提供了备份和恢复数据的能力，信不信由你，存储是无限的。
您可以使用谷歌云存储管理您的资产，存储，检索，显示和删除它们。您还可以快速读写保存在云存储中的平面数据表。谷歌云阵容中的下一个是BigQuery。使用BigQuery，你可以在几秒钟内分析大量数据，我们说的是数百万条记录。访问是通过直接的UI或具象状态传输或REST接口来处理的。
正如您可能怀疑的那样，数据存储不是问题，而且可以扩展到数百TB。BigQuery可以通过一系列客户端库访问，包括Java、。net、Python、Go、Ruby、PHP和Javascript的客户端库。可以通过这些客户端库或web用户界面访问类似sql的语法NoSQL。最后，让我们谈谈谷歌云平台数据库选项，云SQL和云数据存储。
这里有一个主要的区别。云SQL适用于关系数据库，主要是MySQL，而云数据存储适用于使用noSQL的非关系数据库。使用Cloud SQL，您可以选择在美国、欧洲或亚洲托管，每个数据库实例有100gb的存储空间和16gb的RAM。
云数据存储免费提供每月最多50 K的读/写指令和每月存储1 GB的数据。但是，如果您超过了这些配额，就需要支付费用。App Engine还可以与谷歌云平台的其他不太知名、更有目标的成员合作，包括用于创建API后端的云端点，用于数据分析和趋势预测的谷歌预测API，或用于多语言输出的谷歌翻译API。
虽然你可以用App Engine自己做相当多的事情，但当你考虑到它能够轻松高效地与其他谷歌云平台服务一起工作时，它的潜力就会飙升。
或者让它更简单(因为有时我们无法区分GAE Standard和GAE Flex):
计算引擎类似于虚拟PC，例如，你可以在其中部署一个小型网站+数据库。您可以管理所有内容，包括对已安装磁盘驱动器的控制。如果你部署一个网站，你要负责设置DNS等。
谷歌应用程序引擎(标准)就像一个只读的沙箱文件夹，你可以上传代码来执行，不用担心其他的(是的:只读-有一组固定的库为你安装，你不能随意部署第三方库)。DNS /子域等更容易映射。
谷歌应用程序引擎(灵活)实际上就像一个完整的文件系统(不仅仅是一个锁定的文件夹)，在那里你有更多的权力比标准引擎，例如，你有读/写权限，(但比计算引擎少)。在GAE标准中，您已经为您安装了一组固定的库，并且您不能随意部署第三方库。在Flexible环境中，你可以安装你的应用所依赖的任何库，包括自定义构建环境(比如Python 3)。
尽管GAE Standard处理起来非常麻烦(尽管谷歌使它听起来很简单)，但在压力下它的伸缩性非常好。这很麻烦，因为您需要测试并确保与锁定环境的兼容性，并确保您使用的任何第三方库不会使用您不知道的可能无法在GAE标准上工作的任何其他第三方库。在实践中需要更长的时间来设置它，但从长期来看，简单的部署可能会更有回报。
In addition to the App Engine vs Compute Engine notes above the list here also includes a comparison with Google Kubernete Engine and some notes based on experience with a wide range of apps from small to very large. For more points see the Google Cloud Platform documentation high level description of features in App Engine Standard and Flex on the page Choosing an App Engine Environment. For another comparison of deployment of App Engine and Kubernetes see the post by Daz Wilkin App Engine Flex or Kubernetes Engine.
应用引擎标准
Pros
Very economical for low traffic apps in terms of direct costs and also the cost of maintaining the app. Auto scaling is fast. Autoscaling in App Engine is based on lightweight instance classes F1-F4. Version management and traffic splitting are fast and convenient. These features are built into App Engine (both Standard and Flex) natively. Minimal management, developers need focus only on their app. Developers do not need to worry about managing VMs in a reliable, as in GCE, or learning about clusters, as with GKE. Access to Datastore is fast. When App Engine was first released, the runtime was co-located with Datastore. Later Datastore was split out as the standalone product Cloud Datastore but the co-location of App Engine Standard serving with Datastore remains. Access to Memcache is supported. The App Engine sandbox is very secure. Compared with development on GCE or other virtual machines, where you need to do your own diligence to prevent the virtual machine from being taken over at the operating system level, the App Engine Standard sandbox is relatively secure by default.
Cons
实例通常比其他环境更受约束 小。虽然这对快速自动缩放很有好处，但许多应用程序都可以 受益于更大的实例，例如GCE实例大小可达96 内核。 网络没有与GCE集成 不能把应用引擎后面的谷歌云负载均衡器。局限于 支持的运行时:Python 2.7, Java 7和8,Go 1.6-1.9和PHP 5.5. 在Java中，有一些对servlet的支持，但不支持完整的J2EE标准。
App Engine Flex
Pros
可以使用自定义运行时吗 本机集成GCE网络 版本和流量管理方便，与标准相同 较大的实例大小可能更适合大型复杂应用程序，特别是可能使用大量内存的Java应用程序
Cons
网络集成不完善——没有与内部负载均衡器或共享虚拟私有云集成 对托管Memcache的访问通常不可用
谷歌Kubernetes引擎
Pros
Native integration with containers allows custom runtimes and greater control over cluster configuration. Embodies many best practices working with virtual machines, such as immutable runtime environments and easy ability to roll back to previous versions Provides a consistent and repeatable deployment framework Based on open standards, notably Kubernetes, for portability between clouds and on-premises. Version management can accomplished with Docker containers and the Google Container Registry
Cons
Traffic splitting and management is do-it-yourself, possibly leveraging Istio and Envoy Some management overhead Some time to ramp up on Kubernetes concepts, such as pods, deployments, services, ingress, and namespaces Need to expose some public IPs unless using Private Clusters, now in beta, eliminate that need but you still need to provide access to locations where kubectl commands will be run from. Monitoring integration not perfect While L3 internal load balancing is supported natively on Kubernetes Engine, L7 internal load balancing is do-it-yourself, possibly leveraging Envoy
计算引擎
Pros
Easy to ramp up - no need to ramp up on Kubernetes or App Engine, just reuse whatever you know from previous experience. This is probably the main reason for using Compute Engine directly. Complete control - you can leverage many Compute Engine features directly and install the latest of all your favorite stuff to stay on the bleeding edge. No need for public IPs. Some legacy software may be too hard to lock down if anything is exposed on public IPs. You can leverage the Container-Optimized OS for running Docker containers
Cons
Mostly do-it-yourself, which can be challenging to do adequately for reliability and security, although you can reuse solutions from various places, including the Cloud Launcher. More management overhead. There are many management tools for Compute Engine but they will not necessarily understand how you have deployed your application, like the App Engine and Kubernetes Engine monitoring tools do Autoscaling is based on GCE instances, which can be slower than App Engine Tendency is to install software on snowflake GCE instances, which can be some effort to maintain
谷歌计算引擎(GCE)是基础设施即服务(IaaS)，而谷歌应用程序引擎(GAE)是平台即服务(PaaS)。你可以查看下面的图表，以更好地理解差异(从这里更好地解释)-
Google Compute Engine GCE is an important service provided from Google Cloud Platform (GCP) since most of the GCP services use GCE instances (VMs) beneath the management layer (not sure which one don't). This includes App Engine, Cloud Functions, Kubernetes Engine (Earlier Container Engine), Cloud SQL, etc. GCE instances are the most customisable unit there and thus should only be used when your application can't run on any other GCP services. Most of the time people use GCE to transfer their On-Prem applications to GCP, since it requires minimal changes. Later, they can choose to use other GCP services for separate component of their apps.
谷歌应用引擎 GAE是GCP提供的第一个服务(早在谷歌进入云业务之前)。它从0自动扩展到无限实例(它在下面使用GCE)。它有标准环境和灵活环境两种口味。
标准环境非常快，当没有人使用你的应用程序时，可以缩小到0个实例，在几秒钟内扩大和缩小，并有专用的谷歌服务和库用于缓存，身份验证等。标准环境的警告是，它是非常限制性的，因为它运行在沙箱中。您必须仅针对特定的编程语言使用托管运行时。最近添加的是Node.js (8.x)和Python 3.x。旧的运行时可用于Go, PHP, Python 2.7, Java等。
Flexible Environment更加开放，因为它允许您在使用docker容器时使用自定义运行时。因此，如果您的运行时在提供的运行时中不可用，您总是可以为执行环境创建自己的dockerfile。需要注意的是，它要求至少有一个实例在运行，即使没有人在使用你的应用，再加上放大和缩小需要几分钟。
不要将GAE flexible与Kubernetes Engine混淆，因为后者使用了实际的Kubernetes，并提供了更多的自定义和特性。当您需要无状态容器并且应用程序仅依赖HTTP或HTTPS协议时，GAE Flex非常有用。对于其他协议，Kubernetes Engine (GKE)或GCE是您唯一的选择。看看我的另一个答案，你会有更好的解释。
我会用一种对我来说有意义的方式来解释:
Compute Engine: If you are do-it-yourself person or have an IT team and you just want to rent a computer on cloud that has specific OS (for example linux), you go for the Compute Engine. You have to do everything by yourself. App Engine: If you are (for example) a python programmer and you want to rent a pre-configured computer on cloud that has Linux with a running web-server and the latest python 3 with necessary modules and some plug-ins to integrate with other external services, you go for the App Engine. Serverless Container (Cloud Run): If you would like to deploy the exact image of your local setup environment (for example: python 3.7+flask+sklearn) but you do not want to deal with server, scaling, etc. You create a container on your local machine (through docker) and then deploy it to Google Run. Serverless Microservice (Cloud Functions): If you want to write bunch of APIs (functions) that do specific job, you go for google Cloud Functions. You just focus on those specific functions, the rest of the job (server, maintenance, scaling, etc.) is done for you in order to expose your functions as microservices.
随着深入，你会失去一些灵活性，但你不必担心不必要的技术方面。你也多花了一点，但你节省了时间和成本(IT部分):其他人(谷歌)正在为你做这件事。
如果你不想关心负载平衡、伸缩性等，将你的应用程序分割成一堆“无状态”的web服务是至关重要的，这些服务将任何持久化的内容写入单独的存储(数据库或blob存储)。然后你会发现云运行和云函数是多么棒。
就我个人而言，我发现谷歌Cloud Run是一个很棒的解决方案，在开发中绝对自由(只要是无状态的)，将其作为web服务公开，docker您的解决方案，与Cloud Run一起部署。让谷歌成为你的IT和DevOps，你不需要关心扩展和维护。
我已经尝试了所有其他的选择，每一个都适合不同的目的，但谷歌运行只是棒极了。对我来说，它是真正的无服务器，而不会失去开发的灵活性。
谷歌计算引擎(GCE)
托管在云中的虚拟机(vm)。在云技术出现之前，这些服务器通常被称为虚拟专用服务器(VPS)。您可以像使用物理服务器一样使用这些服务器，在其中安装和配置操作系统，安装应用程序，安装数据库，保持操作系统的最新状态，等等。这被称为基础设施即服务(IaaS)。
当您在数据中心的VM或服务器上运行现有应用程序，并希望轻松地将其迁移到GCP时，VM最有用。
谷歌应用引擎
App Engine托管并运行你的代码，而不需要你处理操作系统、网络，以及许多你必须在物理服务器或VM上管理的其他事情。可以把它看作一个运行时，它可以自动部署、版本化和扩展应用程序。这被称为平台即服务(PaaS)。
当你想要自动部署和自动扩展你的应用程序时，App Engine是最有用的。除非应用程序需要自定义操作系统配置，否则App Engine通常比手动配置和管理虚拟机更有优势。
