内部 HTTP(S) 负载平衡器的流量管理概览

内部 HTTP(S) 负载平衡支持高级流量管理功能,可让您使用以下功能:
  • 流量导向。根据 HTTP(S) 参数(例如主机、路径、标头和其他请求参数)智能路由流量。
  • 流量操作。根据请求和响应执行操作(例如重定向和标头转换)。
  • 流量政策。微调负载平衡行为(例如高级负载平衡算法)。

您可以使用网址映射和后端服务来设置这些功能。如需了解详情,请参阅以下主题:

使用场景示例

很多使用场景都需要流量管理。本部分提供了几个概要示例。

流量导向:基于标头的路由

通过流量导向,您可以根据请求标头等 HTTPS 参数将流量定向至服务实例。例如,如果用户的设备是移动设备且请求标头中含有 user-agent:Mobile,则流量导向可以将该流量发送到被指定用于处理移动流量的服务实例,并将不具有 user-agent:Mobile 的流量发送至被指定用于处理其他设备流量的实例。

Cloud Load Balancing 流量导向(点击放大)
Cloud Load Balancing 流量导向

流量操作:基于权重的流量拆分

部署新版本的现有生产服务通常会产生一些风险。即使在预演阶段通过了测试,您可能也不会希望让全体用户立即使用新版本。借助内部 HTTP(S) 负载平衡,您可以跨多个后端服务按百分比拆分流量。

例如,您可以将 95% 的流量发送到旧版服务,将 5% 的流量发送到新版服务。在验证新的生产版本可以按预期正常运行后,您可以逐渐改变百分比,直到 100% 的流量到达新版服务。流量拆分通常用于部署新版本、A/B 测试、服务迁移及类似流程。

Cloud Load Balancing 流量拆分
Cloud Load Balancing 流量拆分

流量政策:请求镜像

您的单位可能有特定的合规性要求,规定将所有流量镜像到其他服务,例如可以在数据库中记录请求详情以用于日后重现的服务。

流量管理组件

概括地说,内部 HTTP(S) 负载平衡器利用地区网址映射地区后端服务资源来实现流量管理。

您可以使用地区网址映射来设置流量导向和流量操作。与网址映射关联的 Google Cloud 资源包括:

  • 路由规则
  • 规则匹配
  • 规则操作

您可以使用地区后端服务来设置流量政策。与后端服务关联的 Google Cloud 资源包括:

  • 局部负载平衡器政策
  • 一致的哈希负载平衡器设置
  • 断路器
  • 离群值检测
下图展示了用于实现各项功能的资源。

Cloud Load Balancing 流量导向(点击放大)
Cloud Load Balancing 数据模型(点击可放大)

将请求路由到后端

在内部 HTTP(S) 负载平衡中,流量后端通过两阶段方法决定:

  • 负载平衡器选择具有后端的后端服务。后端可以是非代管实例组中的 Compute Engine 虚拟机实例、代管实例组 (MIG) 中的 Compute Engine 虚拟机或者网络端点组 (NEG) 中使用 Google Kubernetes Engine (GKE) 节点的容器。负载平衡器根据地区网址映射中定义的规则选择后端服务。
  • 后端服务根据地区后端服务中定义的政策选择后端实例。

配置路由时,您可以选择以下模式之一:

  • 简单主机和路径规则
  • 高级主机、路径和路由规则

对于每个网址映射,您可以选择使用简单主机和路径规则或高级主机、路径和路由规则。这两种模式互相排斥。每个网址映射仅可包含其中一种模式。

简单主机和路径规则

在简单主机和路径规则模式下,网址映射按网址映射概览中所述的方式运行。

下图显示了简单主机和路径规则的逻辑流程。

简单网址映射流程
简单网址映射流程

该流程最初会使用主机规则来评估请求。主机是由请求指定的网域。如果请求 hosthosts 字段中的某个条目匹配,则使用关联的路径匹配器。

接下来,该流程会评估路径匹配器。该流程按“最长路径优先匹配”顺序评估路径规则,但您可以按任意顺序指定路径规则。找到最确切的匹配后,请求将被路由到相应的后端服务。如果请求不匹配,则使用默认后端服务。

如下示例是一个典型的简单主机和路径规则,其中视频流量流向 video-backend-service,所有其他流量流向 web-backend-service

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

高级主机、路径和路由规则

与简单主机和路径规则相比,高级主机、路径和路由规则提供了额外的配置选项。这些选项支持更高级的流量管理模式,还可修改某些语义。例如,路由规则具有相关联的优先级值,并按优先级顺序进行解释(而不是使用“最长路径优先匹配”语义)。

与之前的简单主机和路径规则示例一样,您可以使用地区网址映射来配置高级流量管理。例如,以下网址映射会配置路由,其中 95% 的流量路由到一个后端服务,5% 的流量路由到另一个后端服务。

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

主机规则

当请求到达您的负载平衡器时,系统将根据网址映射中定义的 hostRules 对请求中的 host 字段进行评估。每个主机规则由一个或多个主机和单个路径匹配器 (pathMatcher) 组成。如果您未定义 hostRules,则该请求将路由到 defaultService

如需了解详情,请参阅地区网址映射 API 文档中的 hostRules[]defaultService

路径匹配器

请求与主机规则匹配后,负载平衡器会评估主机所对应的路径匹配器。

路径匹配器由以下几个部分组成:

  • 一个或多个路径规则 (pathRules) 或路由规则 (routeRules)
  • 默认服务 (defaultService),即没有其他后端服务匹配时使用的默认后端服务。
如需了解详情,请参阅地区网址映射 API 文档中的 pathMatchers[]pathMatchers[].pathRules[]pathMatchers[].routeRules[]

路径规则

路径规则 (pathRules) 指定一个或多个网址路径,例如 //video。路径规则通常适用于之前所述的基于简单主机和路径的路由类型。

如需了解详情,请参阅地区网址映射 API 文档中的 pathRules[]

路由规则

路由规则 (routeRules) 会与传入请求中的信息进行匹配,并根据匹配情况作出路由决策。

路由规则可以包含各种不同的匹配规则 (matchRules) 和各种不同的路由操作 (routeAction)。

匹配规则根据 HTTP(S) 请求的路径、标头和查询参数来评估传入的请求。匹配规则支持各种匹配类型(例如前缀匹配)和修饰符(例如不区分大小写)。这样,您可以实现多种操作,例如根据存在的自定义 HTTP 标头向一组后端发送 HTTP(S) 请求。

如果您有多个路由规则,负载平衡器会按优先级顺序(根据 priority 字段)执行这些规则,您可以借此为匹配、路由和其他操作指定自定义逻辑。

在给定的路由规则中,当完成首个匹配时,负载平衡器会停止评估匹配规则,并且忽略所有剩余的匹配规则。

Google Cloud 会执行以下操作:

  1. 查找与请求匹配的首个匹配规则。
  2. 停止查看任何其他匹配规则。
  3. 应用相应路由操作中的操作。

路由规则包含多个组件,如下表中所述。

路由规则组件 (API field name) 说明
优先级 (priority) 分配给指定路径匹配器中的路由规则的数字(范围为 0-2,147,483,647,即 (2^31)-1)。

优先级决定路由规则的评估顺序。优先级数字越大表明规则的优先级越低,因此优先级为 4 的规则会优先于优先级为 25 的规则进行评估。系统会应用与请求相匹配的首个规则。

优先级数字无需连续。您不能创建多个具有相同优先级的规则。
说明 (description) 最多包含 1024 个字符的可选说明。
服务 (service) 规则相匹配时流量所指向的后端服务资源的完整或部分网址。
匹配规则 (matchRules) 根据请求进行评估的一个或多个规则。这些 matchRules 可以匹配请求的所有或部分 HTTP 特性,例如路径、HTTP 标头和查询 (GET) 参数。

matchRule 中,必须满足所有匹配条件才能使 routeRulerouteActions 生效。如果 routeRule 有多个 matchRules,则 routeRulerouteActions 在请求与 routeRule 的任意 matchRules 匹配时生效。
路由操作 (routeAction) 允许您指定在满足匹配规则条件时要执行的操作。这些操作包括流量拆分、网址重写、重试和镜像以及故障注入和 CORS 政策。
重定向操作 (urlRedirect) 您可以配置操作,以便在满足匹配规则条件时通过 HTTP 重定向进行响应。此字段不能与路由操作结合使用。
标头操作 (headerAction) 您可以配置在满足 matchRules 中的条件时的请求和响应标头转换规则。

如需了解详情,请参阅地区网址映射 API 文档中的以下字段:

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

匹配规则

匹配规则 (matchRules) 匹配请求的一个或多个特性,并执行路由规则中指定的操作。以下列表提供了一些可使用匹配规则匹配的请求特性示例:

  • 主机名:主机名是网址的域名部分;例如,网址 http://example.net/video/hd 的主机名部分为 example.net。在该请求中,主机名包含在 Host 标头中,如以下示例 curl 命令所示,其中 10.1.2.9 是经过负载平衡的 IP 地址:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • 路径在主机名后,例如 /images。匹配规则可以指定是需要匹配整个路径,还是只需匹配该路径的前导部分。

  • 其他 HTTP 请求参数,例如允许 Cookie 匹配的 HTTP 标头,以及基于查询参数(GET 变量)的匹配。

如需查看受支持匹配规则的完整列表,请参阅地区网址映射 API 文档中的 pathMatchers[].routeRules[].matchRules[]

路由操作

路由操作是在路由规则与请求的特性匹配时执行的特定操作。

路由操作 (API field name) 说明
重定向 (urlRedirect) 返回可配置的 3xx 响应代码。此外,它还会使用适当的 URI 设置 Location 响应标头,并替换重定向操作中所指定的主机和路径。
网址重写 (urlRewrite) 在将请求发送到选定的后端服务之前,重写网址的主机名部分和/或网址的路径部分。
标头转换 (headerAction) 在向后端服务发送请求前添加或移除请求标头。还可以在接收来自后端服务的响应后添加或移除响应标头。
流量镜像 (requestMirrorPolicy) 除了将请求转发到选定的后端服务,还会以“即发即弃”的方式将相同请求发送到配置的镜像后端服务。负载均衡器不会等待它将镜像请求发送到的后端做出的响应。

镜像有助于测试后端服务的新版本。此外,镜像还可用于调试后端服务调试版本的生产错误(而非生产版本的错误)。
加权流量拆分 (weightedBackendServices) 允许将匹配规则的流量分配到多个后端服务,分配给个别后端服务的流量与分配给该服务的用户定义权重成正比。

此功能对于配置分阶段部署或 A/B 测试非常有用。例如,路由操作可以配置为将 99% 的流量发送给一项运行稳定版应用的服务,而将 1% 的流量发送给另一项运行新版应用的服务。
重试 (retryPolicy) 配置负载平衡器重试失败请求的条件、负载平衡器在重试前等待的时长以及允许的最大重试次数。
超时 (timeout) 指定选定路由的超时时长。根据从请求完全处理直到响应完全处理的时间可以计算出超时。超时包括所有重试。
故障注入 (faultInjectionPolicy) 在处理请求时引入错误,以此模拟高延迟、服务过载、服务故障和网络分区等故障。在测试服务对模拟故障的弹性时,这项功能会非常有用。
延迟注入 (faultInjectionPolicy) 对请求的用户自定义部分引入延迟,然后再将这些请求发送到所选后端服务。
中止注入 (faultInjectionPolicy) 使用用户定义的 HTTP 状态代码直接响应一小部分请求,而不将这些请求转发到后端服务。
安全政策 (corsPolicy) 跨域资源共享 (CORS) 政策用于处理有关执行 CORS 请求的内部 HTTP(S) 负载平衡设置。

您可以指定以下某种路由操作(在 Google Cloud Console 中称为主要操作)

  • 将流量路由到单项服务 (service)。
  • 在多项服务之间拆分流量(weightedBackendServices weight:x,其中 x < 100)。
  • 重定向网址 (urlRedirect)。

此外,您可以将上述任一路由操作与以下一项或多项路由操作(在 Cloud Console 中称为附加操作)结合使用

  • 流量镜像 (requestMirrorPolicy)。
  • 重写网址主机/路径 (urlRewrite)。
  • 重试失败的请求 (retryPolicy)。
  • 设置超时 (timeout)。
  • 向一定比例的流量引入故障 (faultInjectionPolicy)。
  • 添加 CORS 政策 (corsPolicy)。
  • 处理请求/响应标头 (headerAction)。

如需详细了解路由操作的配置和语义,请参阅地区网址映射 API 文档中的以下内容:

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

从 HTTP 到 HTTPS 的重定向

对于内部 HTTP(S) 负载平衡器,如果您需要将 HTTP 流量重定向到 HTTPS,则可以创建两条共用一个内部 IP 地址的转发规则。

如果两条转发规则共用一个内部 IP 地址,您必须预留该 IP 地址并添加 --purpose=SHARED_LOADBALANCER_VIP 标志:

gcloud beta compute addresses create \
    --addresses=10.1.2.99 \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

如需查看完整示例,请参阅为内部 HTTP(S) 负载平衡器设置 HTTP 到 HTTPS 的重定向

流量政策

通过使用后端服务资源,您可以配置流量政策,以便在实例组或网络端点组 (NEG) 内实现经过微调的负载平衡。这些政策只有在使用地区网址映射选择了后端服务后才会生效(如前所述)。

通过流量政策,您可以执行以下操作:

  • 控制后端服务中实例之间的负载平衡算法。
  • 控制与上游服务建立的连接数。
  • 控制从后端服务中逐出运行状况不佳的主机。

您可以在地区后端服务中配置以下流量政策功能。

流量政策 (API field name) 说明
负载均衡位置政策 (LocalityLbPolicy)

对于后端服务,流量分配依据负载均衡模式和负载均衡位置政策

均衡模式决定了应发送到每个后端(实例组或 GCE_VM_IP_PORT NEG)的流量的权重/比例。负载均衡政策 (LocalityLbPolicy) 决定了可用区内或实例组中的后端如何进行负载均衡。当后端服务收到流量时,它首先会根据后端的均衡模式将流量定向到后端(实例组或 GCE_VM_IP_PORT NEG)。选择后端后,系统会根据位置政策在每个可用区内的实例或端点之间分配流量。对于区域级代管式实例组,位置政策适用于每个组成可用区。

如需了解受支持的均衡模式,请参阅均衡模式

如需了解受支持的负载均衡政策算法,请参阅区域级后端服务 API 文档中的 localityLbPolicy

会话粘性 (consistentHash)

包括基于 HTTP Cookie 的亲和性、基于 HTTP 标头的亲和性、客户端 IP 地址亲和性和生成的 Cookie 亲和性。只要后端运行状况良好且有可用容量,会话亲和性就会尽力尝试将来自特定客户端的请求发送到同一个后端。

如需详细了解会话亲和性,请参阅区域级后端服务 API 文档中的 consistentHash

离群值检测 (outlierDetection)

一组指定从 NEG 中逐出健康状况不佳的后端虚拟机或端点的政策,以及将后端或端点视为健康状况良好,足以再次接收流量的条件。

如需详细了解会话亲和性,请参阅区域级后端服务 API 文档中的 outlierDetection

熔断 (circuitBreakers)

对连接数和每个后端服务连接的请求数设置上限。

如需详细了解会话亲和性,请参阅区域级后端服务 API 文档中的 circuitBreakers

后续步骤