请求的路由方式

区域 ID

REGION_ID 是 Google 根据您在创建应用时选择的区域分配的缩写代码。此代码不对应于国家/地区或省,尽管某些区域 ID 可能类似于常用国家/地区代码和省代码。对于 2020 年 2 月以后创建的应用,REGION_ID.r 包含在 App Engine 网址中。对于在此日期之前创建的现有应用,网址中的区域 ID 是可选的。

详细了解区域 ID

本页面介绍了用户发出的 HTTP 请求到达服务相应版本的方式。请求可以通过以下方式路由:

上述方式仅适用于已部署的应用。当您在本地进行测试时,路由行为取决于您正在使用的特定运行时和开发环境。

使用网址进行路由

一旦您的应用能够在 App Engine 中运行,您就可以使用以下网址向应用发送 HTTP 请求:
https://PROJECT_ID.REGION_ID.r.appspot.com

其中,PROJECT_ID 是包含该应用的 Google Cloud 项目的 ID。

此网址将请求发送到您已配置为接收流量的版本的应用默认服务。

服务和版本的网址

如果您的应用创建了多项服务,则每项服务都有自己的网址。服务的每个版本也都有自己的网址,因此您可以先行部署并测试一个新的版本,然后再将其配置为接收流量。

特定服务和版本的网址采用以下格式:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

如果您不需要定位特定版本,则可以省略 VERSION-dot-

如需检索应用的服务和版本的 ID,您可以使用以下任何工具:

控制台

在 Google Cloud 控制台中,您可以查看相应的实例服务版本页面。

gcloud

运行 gcloud app instances list 命令可以列出特定 Cloud 项目中的资源 ID。

API

如需以编程方式检索资源 ID,请参阅 Admin API 中的 list 方法

示例网址

以下是 App Engine 的一些示例网址,其中显示了 App Engine 分配给您的应用的 appspot.com 网域以及您可以为应用设置的自定义网域。

  • default 服务的可用实例发送请求:
    
    https://PROJECT_ID.REGION_ID.r.appspot.com
    https://CUSTOM_DOMAIN

    default 服务中的流量配置的任何版本都会收到请求。

  • 向特定服务的可用实例发送请求:
    
    https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://SERVICE_ID.CUSTOM_DOMAIN

    为所定位服务中的流量配置的任何版本都会收到请求。如果您定位的服务不存在,则系统会对请求进行软路由

  • default 服务中特定版本的可用实例发送请求:
    
    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.CUSTOM_DOMAIN

    如果未定位服务,请求会发送到 default 服务。

软路由

如果一个请求与主机名的 PROJECT_ID.REGION_ID.r.appspot.com 部分匹配,但包含不存在的服务、版本或实例名称,则该请求会被路由到 default 服务。软路由不适用于自定义网域;如果主机名无效,发送到自定义网域的请求将返回 HTTP 404 状态代码。

定向路由

如果以下网址格式存在,那么这些网址格式必定可以被路由到其目标。您在调度文件中定义的格式永远不会拦截和重新路由这些请求:

  • 向特定服务和版本的可用实例发送请求
    
    https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN
  • 如果您使用的是手动扩缩服务,可以通过包含实例 ID 来定位实例并向其发送请求。实例 ID 是一个整数,范围介于 0 到正在运行的实例总数之间,可以按如下方式指定:

    向特定实例中的特定服务和版本发送请求:

    https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN

使用调度文件进行路由

您可以创建调度文件以替换 App Engine 基于网址的路由规则并定义自己的自定义路由规则。使用调度文件,您可以根据传入请求网址中的路径或主机名将请求发送到特定服务。

创建调度文件

如需创建调度文件,请执行以下操作:

  1. 在项目的根目录或 default 服务的根目录中创建名为 dispatch.yaml 的文件。

  2. 按照 dispatch.yaml 参考文档中的说明在该文件中定义路由规则。

对于路由规则,请注意以下事项:

  • 您最多可以定义 20 个路由规则。每个规则都必须包含 urlservice 元素。
  • 这些规则必须使用 HTTP 网址格式,这种格式采用“.”表示法分隔子网域。不支持使用 HTTPS“-dot-”表示法定义的网址。
  • 这些规则也适用于您在 Cron 文件中定义的网址。

例如,您可以创建一个调度文件,将诸如 https://simple-sample.uc.r.appspot.com/mobile/ 的移动请求路由到移动前端,并将诸如 https://simple-sample.uc.r.appspot.com/work/ 的工作器请求路由到静态后端:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

部署调度文件

如需部署调度文件,请运行以下命令:

    gcloud app deploy dispatch.yaml

使用 Cloud Load Balancing 进行路由

Cloud Load Balancing 是一个单独的产品,可为在 Google Cloud 上运行的所有应用启用高级网络配置。

为无服务器应用启用 HTTP(S) 负载均衡后,您可以执行以下操作:

  • 配置无服务器应用,使其通过未与其他服务共享的专用 IPv4 和/或 IPv6 IP 地址提供服务。

  • 重复使用用于 Compute Engine、Google Kubernetes Engine 和 Cloud Storage 的相同 SSL 证书和私钥。这样就不需要为无服务器应用管理单独的证书。

负载均衡器不会干扰 dispatch.yaml 文件中的路由规则或与之交互。在无服务器 NEG 将流量定向到 App Engine 之前,不会评估 dispatch.yaml 规则。

注意事项:

  • 我们建议您使用入站流量控制,以使应用仅接收从负载均衡器和 VPC(如果使用 VPC)发送的请求。否则,用户可以使用应用的 App Engine 网址来绕过负载均衡器、Google Cloud Armor 安全政策、SSL 证书和通过负载均衡器传递的私钥。

有关 App Engine 网址的额外详细信息

了解网址中的区域 ID

REGION_ID 是 Google 根据您在创建应用时选择的区域分配的缩写代码。此代码不对应于国家/地区或省,尽管某些区域 ID 可能类似于常用国家/地区代码和省代码。对于 2020 年 2 月以后创建的应用,REGION_ID.r 包含在 App Engine 网址中。对于在此日期之前创建的现有应用,网址中的区域 ID 是可选的。

您可以使用以下工具查看应用的区域 ID:

控制台

在 Google Cloud 控制台中,您可以查看应用的实例服务版本的网址。

所有这些网址都包含地区 ID。

gcloud

部署应用或服务时,gcloud app deploy 命令会在部署成功后显示网址。此网址包含区域 ID。

如需查看已部署服务的网址,请执行以下操作:

  1. 输入 gcloud app versions list 命令列出特定服务的版本。例如,如需列出默认服务的版本,请输入 gcloud app versions list --service=default

  2. 输入 gcloud app versions describe 命令。该命令的输出结果包含带应用区域 ID 的版本网址。例如,如需为默认服务描述版本 20191023t101741,请输入 gcloud app versions describe 20191023t101741 --service=default

域名包含在请求数据中

请求对应的域名包含在传递给您的应用的请求数据中。因此,您可以使用请求数据来控制您的应用如何根据请求中的域名进行响应。例如,如果您希望重定向到一个官方网域,可以在应用编码中检查 Host 请求标头,然后根据域名作出相应的响应。