Google App Engine
1. App Engine 概览
App Engine 应用包含一项或者多项服务的单个应用资源组成。每项服务都可以配置为使用不同的运行时和性能设置。在每项服务中，可以部署改服务的“版本”，而每个版本可以在一个或多个“实例”中运行。
2. 应用组件
创建应用资源时，系统会在Google Cloud 项目下创建 App Engine 应用。App Engine 应用时一个顶层容器，用于容纳构成应用的服务、版本和实例资源。当创建App Engine 应用时，所有的资源都将在选择的区域中创建，包括应用代码以及一些列设置、凭证和应用的元数据。
每个App Engine 应用至少包含一项服务，即 default 服务，这项服务可以保存许多版本，具体设置取决于应用的结算状态。
3. 服务
使用 App Engine 中的服务，将大型应用分解成多个可以安全共享 App Engine 功能并相互通信的逻辑组件。通常情况下，App Engine 服务的行为类似于微服务。因此，您可以在单项服务中运行整个应用，也可以设计并部署多项服务作为一组微服务运行。
举例说：用于处理客户请求的应用可以包含若干项服务，各自处理不同的任务，比如：
- 来自移动设备的API请求
- 内部的管理类请求
- 结算流水线和数据分析等后端处理
App Engine 中的每项服务都包含来自应用的源代码以及相应的 App Engine 配置文件。部署到某服务的一组文件代表该服务的一个版本，每向该服务部署一次，就会在其中创建一个新的版本。
4. 版本
通过在每项服务中包含应用的多个版本，可以在该应用的不同版本之间快速切换，以执行回滚，测试或其他临时活动。可以通过迁移或拆分流量，将流量路由到应用的一个活多个特定版本，
5. 实例
可以在一个或多个“实例”上运行服务中的各个版本，默认情况下，App Engine 会扩缩应用资源规模，使其与负载匹配，可以增加运行实例数来保障性能，也能够缩减实例数来最大限度地减少空闲实例并降低费用。
6. 应用请求
应用的每项服务以及这些服务中的每个版本都必须用具有唯一的名称。然后可以用这些唯一名称来确定网址，并将流量分配到对应的特定资源。例如
https://VERSION_ID-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
闯入的用户请求将被路由到配置为处理流量的服务或版本。您还可以选择将符合某些条件的请求路由指定的服务和版本。
7. app.yaml
App Engine 中的 Java 应用使用的是 app.yaml 文件进行配置，该文件包含 CPU、内存、网络和磁盘资源设置、扩缩设置以及环境变量等其他常规设置。
可以在 app.yaml文件中指定 Java 应用的运行时配置，包括版本和网址。该文件充当特定服务版本的部署描述符。必须先为应用 default 服务创建 app.yaml 文件，然后才能为其他服务创建和部署 app.yaml文件。
runtime: java
env: flex
可以为 app.yaml文件指定一个独特的名称，但还必须使用部署命令指定该文件名。例如把 app.yaml命名为 service-name-app.yaml或 app.flexible.yaml，则必须使用下列命令部署
gcloud app deploy service-name-app.yaml
gcloud app deploy app.flexible.yaml
不要将 app.yaml 添加到 ，gcloudignore file。部署必须需要 app.yaml 文件，如果没有添加，则会导致部署失败。
8. app.yaml 通用设置
app.yaml 文件可以包含下列通用设置。有一些是必要的属性。
| Name | 描述 |
|---|---|
| runtime: java | 此设置是必需的，是此应用程序使用的 App Engine 语言运行时的名称。指定 Java，请使用 java. |
| env: flex | 选择灵活的环境 |
| service: service_name | 创建服务时需要。对于默认服务是可选的。每个服务和每个版本之间必须有一个名称。名称可以包含数字、字母和连字符。在柔性环境中（版本名称，服务名称和项目ID）的组合长度，不能超过63个字符，并且不能以连字符开头或结尾。每个服务和每个版本选择一个唯一的名称。不要在服务和版本之间重用名称。 |
| skip_files | 可选的，该skip_files元素指定应用程序目录中的哪些文件不上传到 App Engine。该值是正则表达式或正则表达式列表。上传应用时，从要上传的文件列表中省略与任何正则表达式匹配的任何文件名。如果要跳过名称以结尾的 .bak。请添加如下 skip_files：-^.*.bak$ |
App Engine 柔性环境支持多个 Java 运行时，每个运行时都基于 Java8
选择 jetty 9
runtime_config:
jdk: openjdk8
server: jetty9
选择 Java 8
runtime_config:
jdk: openjdk8
9. app.yaml 网络设置
app.yaml 配置文件中指定网络设置
network:
instance_tag: TAG_NAME
name: NETWORK_NAME
subnetwork_name: SUBNETWORK_NAME
session_affinity: true
forwarded_ports:
- PORT
- HOST-PORT:CONTAINER_PORT
- PORT/tcp
- HOST_PORT:CONTAINER_PORT/udp
| name | 描述 |
|---|---|
| Instance_tag | 具有该名称的标签在创建时分配给服务器的每个实例。在标签的gcloud命令中很有用，可以将操作定位到一组实例。 |
| name | 柔性环境中的每个VM实例在创建时都会分配给 google compute Engine网络。使用此设置指定网络名称。给出短名称，而不是资源路径（例如，default 而不是）如果未指定网络名称，则实例将分配给项目的默认网络。如果要指定子网名称，则必须指定网络名称。 |
| subnetwork_name | 可选的，可以对网络进行分段并使用自定义网。确保name指定了网络，给出短名称，而不是资源路径。子网必须与应用程序位于同一区域。 |
| session_affinity | 可选的。设置为true将 App Engine 配置为将给定用户的多个顺序请求路由到同一个 App Engine实例，例如在会话期间在本地存储用户数据时。会话亲和性允许检查cookie的值以识别到同一用户的多个请求，然后将所有此类的请求定位到同一个实例。如果实例重新启动，运行状态不佳、过载或者是实例数目缩减到不可用，则会话亲缘关系会被破坏，然后将进一步的请求路由到不同的实例，请注意，请用会话关联可能会影响到负载平衡设置，默认是禁用该参数 |
| forwarded_ports | 可选的。将端口从实例转发到Docker容器。必须介于1024和65535之间。并且不能以下端口冲突：22、8080、8090、8443、10000、10001、10400-10500、11211、24231。必须介于 1 和 6223之间，不能以下端口冲突：10001、10400-10500、11211。如果只指定a,则 App Engine 假定它是主机和容器上的相同端口，默认情况下，TCP 和 UDP 流量都被转发。流量必须直接寻址到目标实例的IP地址，而不是通过 appspot.com 域或自定义的域。 |
- 在网络配置设置 app.yaml
network:
forwarded_ports:
- 2222/tcp
- 在 Cloud Console 中指定防火墙规则，或者 gcloud compute furewall-rules create用于允许来自任何源（0.0.0.0/0）和来自的流量 tcp:2222
10. app.yaml 资源设置
用来控制计算机的资源，App Engine 会根据指定的 CPU 和内存量分配机器类型。机器保证至少具有指定的资源级别，也可以拥有更多。
在系统资源中最多指定八个 tmpfs 卷，然后可以通过tmpfs启用需要共享内存的工作负载，并可以改进文件系统 I/O。
resources:
cpu: 2
memory_gb: 2.3
disk_size_gb: 10
volumes:
- name: ramdisk1
volume_type: tmpfs
size_gb: 0.5
| name | 描述 | 默认值 |
|---|---|---|
| cpu | 核心数；必须是1个或者是2到32之间的偶数，或者是32到80之间的4倍数 | 1核 |
| memory_gb | 以GB为单位的RAM。应用程序请求的内存，不包括某些进程开销所需要的~0.4GB内存，每个CPU 内核需要 0.9到6.5GB的总内存。 计算请求的内存： memory_gb = cpu*[0.9-6.5]-0.4 对于上面指定了2个内核的实例，您可以请求1.4到12.6GB。应用程序可用的内存总量由运行时环境设置为环境变量GAE_MEMORY_MB. | 0.6GB |
| disk_size_gb | 大小以GB为单位。最小值为10GB，最大值为10240GB | 10GB |
| name | 如果使用卷，则为必需。卷的名称。名称必需是唯一的并且介于1到63个字符之间。字符可以是小写字母、数字或破折号。第一个字符必须是字母，最后一个字符不能是破折号。该卷作为 ./mnt/NAME | |
| volume_type | 如果使用卷，则为必须，必须是tmpfs | |
| size_gb | 如果使用卷，则为必须，卷的大小，以GB为单位。最小值为0.001GB，最大值为应用程序容器和底层设备上的可用内存量。Google不会为您的系统添加额外的RAM以满足磁盘需求。分配给 tmpfs卷的RAM将从应用程序容器可用的内存中减去，精确度取决于系统。 |
11. app.yaml 拆分健康检查
默认情况下，启用拆分健康检查。可以使用定期健康检查请求来确认 VM 实例 已成功部署，并检查正在运行的实例是否保持健康状态。必须在指定的时间间隔回答每一个运行状态检查。
当一个实例未能相应指定数量的连续健康检查请求，它是不健康的。如果实例不可用，则会重启。如果一个实例没有准备好，那么它将不会收到任何客户端的请求，如果没有可用磁盘空间，运行状况检查也可能失败。
使用两种类型的运行状况检查：
- 活性检查 确认 VM 和 Docker 容器正在运行。App Engine 会重新启动运行状况不佳的实例
- 就绪检查 确认实例已准备接受传入请求。未通过就绪检查的实例不会添加到可用实例池中，
默认情况下，来自健康检查的 HTTP 请求不会转发到应用程序容器，如果想运行状况检查来扩展应用程序，请指定 活动检查 或 就绪检查 的路径。如果应用程序返回 200 OK响应代码，则认为对应用程序的自定义运行状况检查成功。
活性检查
活性检查确认 VM 和 Docker 容器正在运行，被视为运行状况不佳的实例将重新启动。
可以向 app.yaml 文件添加可选的 liveness_check 部分来自定义活动检查请求 app.yaml
liveness_check:
path: "/liveness_check"
check_interval_sec: 30
timeout_sec: 4
failure_threshold: 2
success_threshold: 2
| name | 默认（范围最小-最大） | 描述 |
|---|---|---|
| path | 没有任何 | 如果将活性检查转发到应用程序容器，需要指定一个URL路径。 |
| timeout_sec | 4秒 1-300 | 每个请求的超时间隔，以秒为单位 |
| check_interval_sec | 30秒 1-300 | 检查之间的时间间隔，以秒为单位，该值必须要大于 timeout_sec |
| failure_threshold | 4次检查 1-10 | 连续检查失败次数后，实例运行状况不佳 |
| success_threshold | 2次检查 1-10 | 在成功响应此数量的连接检查后，不健康的实例再次变得健康 |
| initial_delay_sec | 300秒 0-3600 | 实例启动后忽略运行状况检查响应的延迟（以秒为单位）。此设置适用于每个新创建的实例，并且可以让新实例有更多时间启动和运行。如果实例处于启动过程中，该设置会延迟自动修复检查并可能过早的重新创建实例。当实例处于RUNNING模式时。初始延迟计时器启动。例如，如果应用程序的初始化任务需要很长时间才能为流量提供服务，可能希望增加延迟。 |
准备检查
就绪检查确认实例可以接受传入请求。未通过就绪检查的实例不会添加到可用实例池中。可以通过向 app.yaml 文件添加 可选的 readiness_check 部分来自定义运行状况检查请求。
readiness_check:
path: "/readiness_check"
check_interval_sec: 5
timeout_sec: 4
failure_threshold: 2
success_threshold: 2
app_start_timeout_sec: 300
| name | 默认 范围（最小-最大） | 描述 |
|---|---|---|
| path | 没有任何 | 如果希望就绪检查转发到应用程序容器，需要指定一个URL路径 |
| timeout_sec | 4秒 1-300 | 每个请求的超时间隔，以秒为单位 |
| check_interval_sec | 5秒 1-300 | 检查之间的时间间隔，以秒为单位，该值必须大于timeout_sec |
| failure_threshold | 2次检查 1-10 | 连续检查失败次数后，实例运行状况不佳 |
| success_threshold | 2次检查 1-10 | 在成功响应此数量的连续检查后，不健康的实例会变得健康 |
| app_start_timeout_sec | 300秒 1-1800 | 此设置适用于新部署，而不是单个VM。它指定部署中足够的实例通过运行状况检查锁允许的最长时间（以秒为单位）。如果超过此持续时间，则部署将失败并回滚。当 Compute Engine实例已配置且负载均衡后端服务已经创建，计时器开始计时。例如 如果希望在部署期间提供更长的超时以使足够数量的实例变得健康。 |
12. app.yaml 自动缩放服务设置
可以通过添加一个 automatic_scaling 部分来配置自动缩放 app.yaml。
automatic_scaling:
min_num_instances: 1
max_num_instances: 15
cool_down_period_sec: 180
cpu_utilization:
target_uyilization: 0.6
target_concurrent_requests: 10
| name | 描述 |
|---|---|
| automatic_scaling | 默认情况下采用自动缩放，如果要指定任何自动缩放设置，包含这一行 |
| min_num_instances | 为服务提供的最少实例数。部署服务时，会为其提供这么多实例并根据流量进行扩展，必须是1或更大，默认2就是减少延迟 |
| max_num_instances | 可以扩展的最大实例数。项目中的最大实例数受项目资源配额的限制，默认是8 |
| cool_down_period_sec | 自动缩放程序在开始从新实例收集之前应等待的秒数。这可以防止自动缩放程序在实例初始化时手机信息。在此期间收集的使用情况将不可靠。冷却时间必须大于等于60秒，默认120秒 |
| cpu_utilization | 如果指定目标CPU利用率 |
| target_utilization | 目标CPU利用率。CPU使用是所有正在运行的实例的平均值，用于决定何时减少或增加实例数目。如果在实例收到关闭信号25秒后，无论进行中的请求如何，实例都会缩减规模，默认为0.5。 |
| target_concurrent_requests | （beta）每个实例的目标并发连接数。如果指定一个值，则自动缩放器将使用所有正在运行时的实例的平均并发连接数来决定何时减少或增加实例数。实例在收到关闭信号25秒后缩减规模，无论正在处理的请求如何。如果没有设置参数指定值。则自动缩减器不会针对每个实例的并发连接数。连接不同请求，客户端可以重用一个连接来发送多个请求。 |
13. app.yaml 手动缩放服务设置
可以向app.yaml文件中添加一个 manual_scaling 部分来配置手动缩放服务。
manual_scaling:
instances: 5
| name | 描述 |
|---|---|
| manual_scaling | 为服务启用手动扩展所需 |
| instances | 要分配给服务的实例数 |
14. app.yaml 定义环境变量
env_variables:
MY_VAR: "my value"
其中MY_VAR 和 "my value" 是定义的环境变量的名称和值。每个环境变量条目在 env_variables元素下缩进两格（标准的yaml格式）
评论区