高级流量管理概览

Traffic Director 提供高级流量管理功能，可让您对流量的处理方式进行精细控制。Traffic Director 支持以下使用场景：

精确的流量路由，将请求路由到一项或多项服务
基于权重的流量拆分，以在多个服务之间分配流量
流量镜像政策，向一个调试服务发送请求，并将请求复制到另一个调试服务
精确调整服务后端之间的流量分配，以改进负载平衡

这些高级流量管理功能让您可以实现可用性和性能目标。在这些使用场景中使用 Traffic Director 的一项好处是，您可以更新流量的管理方式，而无需修改应用代码。

如果您使用目标 HTTP 代理配置 Envoy 代理以发送 HTTP 请求，即可使用本文档中介绍的所有功能。
使用 Traffic Director 的无代理 gRPC 服务或应用时，有部分功能不能使用。
如果您使用目标 TCP 代理配置 Envoy 代理以发送 TCP 请求，所有功能均不可用，因为配置中不存在具有目标 TCP 代理的网址映射。

如需了解详情，请参阅功能页面。

如需配置高级流量管理，请使用设置 Traffic Director 时所用的路由规则映射和后端服务资源。反过来，Traffic Director 会配置 Envoy 代理和无代理 gRPC 应用以实施您设置的高级流量管理政策。

概括来讲，您需要执行以下步骤：

根据出站请求的特征，将路由规则映射配置为执行以下操作：
1. 选择请求所路由到的后端服务。
2. （可选）执行额外的操作。
配置后端服务以控制在选择目标服务后如何将流量分配到后端和端点。

流量路由和操作

在 Traffic Director 中，路由规则映射是指转发规则、目标代理和网址映射资源的组合。所有与路由和操作有关的高级流量管理功能都使用网址映射进行配置。

以下部分介绍了您可以在路由规则映射中设置的高级流量管理功能。

请求处理

当客户端发送请求时，系统会按照下述步骤处理请求：

系统将请求与特定的路由规则映射进行匹配，如下所示：
- 如果您使用的是 Envoy：
  - 系统将请求的目标 IP 地址和端口与所有路由规则映射中转发规则的 IP 地址和端口进行比较。系统仅考虑转发规则具有负载平衡方案 INTERNAL_SELF_MANAGED 的路由规则映射。
  - 与请求匹配的转发规则会引用目标 HTTP 或 gRPC 代理，该代理会引用网址映射。此网址映射包含用于路由和操作的信息。
- 如果您使用的是无代理 gRPC：
  - 使用 xds 名称解析方案的 gRPC 客户端不会执行 DNS 查找来解析通道 URI 中的主机名。相反，此类客户端会通过向 Traffic Director 发送 LDS 请求来解析目标 URI 中的 hostname[:port]。
  - 只有负载均衡方案为 INTERNAL_SELF_MANAGED 的转发规则的端口会与目标 URI（例如 xds:///example.hostname:8080）中的端口进行比较。不会使用转发规则的 IP 地址。如果在目标 URI 中未指定端口，则端口的默认值为 80。
  - 与请求匹配的转发规则会引用目标 gRPC 代理，该代理会引用网址映射。此网址映射包含用于路由和操作的信息。
  - 如果有多个转发规则与请求匹配，则包含与目标 URI 中的 hostname[:port] 匹配的主机规则的网址映射将用于路由和操作。
确定适当的网址映射后，系统会评估网址映射以确定目标后端服务并应用操作（后者是可选的）。
选择目标后端服务后，系统会根据后端服务资源中的配置在该目标后端服务的后端或端点之间分配流量。

下一部分（基于主机和路径的简单路由）介绍了第二个步骤。高级路由和操作中介绍了第三个步骤。

基于主机和路径的简单路由

Traffic Director 支持简化的路由方案以及更高级的方案。在简单方案中，您可以指定主机，还可以选择指定路径。系统会对请求的主机和路径进行评估，以确定请求应路由到的服务。

请求的主机名是网址的域名部分，例如，对于网址 http://example.com/video/，其主机名部分是 example.com。
请求的路径是网址中位于主机名后面的部分，例如，对于网址 http://example.com/video/，其路径部分是 /video。

您可以根据路由规则映射中的主机和路径设置简单路由，该映射包含以下内容：

全局转发规则
目标 HTTP 代理或目标 gRPC 代理
网址映射

大多数配置都是在网址映射中完成的。创建初始路由规则映射后，您只需要修改路由规则映射的网址映射部分。在下图中，路径规则的操作与下图中的操作类似。

最简单的规则是默认规则，您在其中使用默认服务仅指定通配符 (*) 主机规则和路径匹配器。创建默认规则后，您可以添加其他规则，以指定不同主机和路径。系统会根据这些规则评估出站请求，如下所示：

如果请求的主机（例如 example.com）与某条主机规则匹配：
1. 接下来，系统会评估路径匹配器。
2. 每个路径匹配器都包含一项或多项根据请求的路径进行评估的路径规则。
3. 如果找到匹配项，则请求会路由到路径规则中指定的服务。
4. 如果主机规则匹配，但没有任何路径规则匹配，则请求将路由到每个路径匹配器包含的默认服务。
如果请求与您指定的任何主机规则都不匹配，则会路由到默认规则中指定的服务。

如需详细了解网址映射的资源字段及其工作原理，请参阅 urlMaps REST API 页面。

高级路由和操作

如果您希望在根据请求的主机和路径路由请求之外执行更多操作，可以设置高级规则来路由请求并执行相应操作。

在较高级别，高级路由和操作的情况如下所示：

与简单路由一样，系统会将请求的主机与您在网址映射中配置的主机规则进行比较。如果请求的主机与主机规则匹配，则系统会评估主机规则的路径匹配器。
路径匹配器包含一项或多项根据请求进行评估的路由规则。系统会根据特定匹配条件（例如前缀匹配）来匹配请求特性 (Attribute)（主机、路径、标头、查询参数），从而按照优先级顺序评估这些路由规则。
选择路由规则后，您就可以应用操作了。默认操作是将请求路由到单项目标服务，但是您也可以配置其他操作。

高级路由

高级路由与前述简单路由类似，不同之处在于您可以指定规则优先级和其他匹配条件。

使用高级路由时，您必须为每项规则指定唯一的优先级。此优先级确定评估路由规则的顺序，数值较低的优先级高于数值较高的优先级。请求与规则匹配后，系统就会应用该规则并忽略其他规则。

高级路由还支持额外的匹配条件。例如，您可以指定：如果标头的名称完全匹配，或者仅有部分匹配（例如前缀或后缀等部分匹配），则规则与请求的标头匹配。规则可以根据正则表达式来评估标头名称，从而进行匹配，或者根据其他条件（例如检查标头是否存在）来进行匹配。

如需详细了解 headerMatches 和 queryParameterMatches 的匹配条件和详细信息，请参阅 urlMaps REST API 页面。

通过将主机、路径、标头、查询参数与优先级和匹配条件相结合，您可以创建满足精确流量管理要求且富有表现力的规则。有关详情，请参阅下表。

基于 HTTP 的应用基于 gRPC 的应用

	基于 HTTP 的应用	基于 gRPC 的应用
HTTP 主机与 gRPC 主机	主机是应用所调用的网址的域名部分。例如，网址 `http://example.com/video/` 的主机部分是 `example.com`。	主机是通道 URI 中用于连接到特定服务的名称。例如，通道 URI `xds:///example.com` 的主机部分是 `example.com`。
HTTP 路径与 gRPC 路径	路径是网址中主机名后面的部分。例如，网址 `http://example.com/video` 的路径部分是 `/video`。	该路径位于 HTTP/2 请求的 `:path` 标头中，它类似于 `/SERVICE_NAME/METHOD_NAME/`。例如，如果您在 `Example` gRPC 服务上调用 `Download` 方法，则 `:path` 标头的内容将类似于 `/Example/Download`。
其他 gRPC 标头（元数据）		gRPC 支持在 gRPC 客户端和 gRPC 服务器之间发送元数据，以提供有关 RPC 调用的额外信息。此元数据采用键值对的形式，这些键值对在 HTTP/2 请求中作为标头传递。

HTTP 主机与 gRPC 主机

主机是应用所调用的网址的域名部分。

例如，网址 http://example.com/video/ 的主机部分是 example.com。

主机是通道 URI 中用于连接到特定服务的名称。

例如，通道 URI xds:///example.com 的主机部分是 example.com。

HTTP 路径与 gRPC 路径

路径是网址中主机名后面的部分。

例如，网址 http://example.com/video 的路径部分是 /video。

该路径位于 HTTP/2 请求的 :path 标头中，它类似于 /SERVICE_NAME/METHOD_NAME/。

例如，如果您在 Example gRPC 服务上调用 Download 方法，则 :path 标头的内容将类似于 /Example/Download。

其他 gRPC 标头（元数据） gRPC 支持在 gRPC 客户端和 gRPC 服务器之间发送元数据，以提供有关 RPC 调用的额外信息。此元数据采用键值对的形式，这些键值对在 HTTP/2 请求中作为标头传递。

操作

Traffic Director 允许您指定 Envoy 代理或无代理 gRPC 应用在处理请求时所执行的操作。您可以使用 Traffic Director 配置以下操作。

操作	API 字段名称	说明
重定向	`urlRedirect`	返回可配置的 3xx 响应代码。此外，它还会使用适当的 URI 设置 `Location` 响应标头，并替换重定向操作中所指定的主机和路径。
网址重写	`urlRewrite`	在将请求发送到选定的后端服务之前，重写网址的主机名部分和/或网址的路径部分。
标头转换	`headerAction`	在向后端服务发送请求前添加或移除请求标头。还可以在接收来自后端服务的响应后添加或移除响应标头。
流量镜像	`requestMirrorPolicy`	除了将请求转发到选定的后端服务，还会以即发即弃的方式将相同请求发送到配置的镜像后端服务。负载平衡器不会等待作为镜像请求发送目标的后端的响应。镜像有助于测试后端服务的新版本。此外，镜像还可用于调试后端服务调试版本的生产错误（而非生产版本的错误）。
基于权重的流量拆分	`weightedBackendServices`	允许将匹配规则的流量分配到多个后端服务，分配的流量与各后端服务分配到的用户定义权重成比例。此功能对于配置分阶段部署或 A/B 测试非常有用。例如，路由操作可以配置为将 99% 的流量发送给一项运行稳定版应用的服务，而将 1% 的流量发送给另一项运行新版应用的服务。
重试	`retryPolicy`	配置负载平衡器重试失败请求的条件、负载平衡器在重试前等待的时长以及允许的最大重试次数。
超时	`timeout`	指定选定路由的超时时长。根据从请求完全处理直到响应完全处理的时间可以计算出超时。超时包括所有重试。
故障注入	`faultInjectionPolicy`	在处理请求时引入错误，以此模拟高延迟、服务过载、服务故障和网络分区等故障。在测试服务对模拟故障的弹性时，这项功能会非常有用。
安全政策	`corsPolicy`	跨域资源共享 (CORS) 政策用于处理有关执行 CORS 请求的设置。

如需详细了解操作及其工作原理，请参阅 urlMaps REST API 页面。

在每项路由规则中，您可以指定以下某种路由操作（在 Google Cloud Console 中称为主要操作）：

将流量路由到单项服务 (service)
在多项服务之间拆分流量 (weightedBackendServices)
重定向网址 (urlRedirect)

此外，您可以将上述任一路由操作与以下一项或多项路由操作（在 Google Cloud Console 中称为附加操作）结合使用：

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

因为操作与特定的路由规则相关联，所以 Envoy 代理或无代理 gRPC 应用可以根据正在处理的请求来应用不同的操作。

在服务的后端之间分配流量

如请求处理中所述，当客户端处理出站请求时，它首先选择目标服务。选择目标服务之后，它就需要确定哪个后端或端点应该接收请求。

上图简化了规则。规则通常是一个主机规则、路径匹配器以及一个或多个路径或路由规则。目标服务是（后端）服务。后端 1、…、后端 n 实际接收并处理请求。例如，这些后端可能是托管服务器端应用代码的 Compute Engine 虚拟机实例。

默认情况下，处理请求的客户端会将请求发送到运行状况良好且有容量的最近后端。为避免造成特定后端过载，它会使用轮循负载平衡算法，对目标服务的其他后端之间的后续请求进行负载平衡。不过在某些情况下，您可能需要更精细地控制此行为。

负载平衡、会话亲和性以及保护后端

您可以在每项服务上设置以下流量分配政策。

政策	API 字段名称	说明
负载平衡模式	`balancingMode`	选择目标服务之后，控制如何选择网络端点组 (NEG) 或代管实例组 (MIG)。您可以配置平衡模式，以根据并发连接和请求速率分配负载。
负载平衡政策	`localityLbPolicy`	设置负载平衡算法，用于在 NEG 或 MIG 的各个后端之间分配流量。您可以从各种不同算法（例如轮循、最少请求等）中进行选择，以优化性能。
会话粘性	`sessionAffinity`	只要后端运行状况良好且有可用容量，就会尽力尝试将来自特定客户端的请求发送到同一个后端。 Traffic Director 支持四种会话亲和性选项：客户端 IP 地址、基于 HTTP Cookie、基于 HTTP 标头，以及由 Traffic Director 本身生成的 Cookie 亲和性。
一致的哈希	`consistentHash`	根据 HTTP 标头、Cookie 或其他属性 (Property) 提供软会话亲和性。
断路器	`circuitBreakers`	设置与后端服务的每个连接的连接数和请求数上限。
离群值检测	`outlierDetection`	指定条件，以便：(1) 从 MIG 或 NEG 中移除运行状况不佳的后端或端点；(2) 在系统认为后端或端点运行状况足够良好时重新添加该后端或端点以再次接收流量。与服务关联的健康检查将确定后端或端点是否被视为健康状况良好。

如需详细了解不同的流量分配选项及其工作原理，请参阅 backendServices REST API 页面。

使用场景示例

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

您可以在配置高级流量管理以及通过高级流量管理设置无代理 gRPC 服务指南中找到更多示例，包括示例代码。

精确的个性化流量路由

您可以根据请求的参数将流量路由到服务。例如，您可以使用此服务为 Android 用户提供更具个性化的体验。在下图中，Traffic Director 将您的服务网格配置为将带有 user-agent:Android 标头的请求发送到 Android 服务（而不是通用服务）。

根据设置为 Android 的 user-agent 标头进行路由。 — 根据设置为 `Android` 的 `user-agent` 标头进行路由（点击可放大）

基于权重的流量拆分，可实现更安全的部署

部署现有生产服务的新版本可能会有风险。即使您的测试在测试环境中通过之后，您可能也不想立即将所有用户都路由到新版本。

Traffic Director 允许您定义基于权重的流量拆分来跨多项服务分配流量。例如，您可以将 1% 的流量发送到新版服务，监控一切正常，然后逐渐增加发送到新服务的流量比例。

Traffic Director 基于权重的流量拆分。 — Traffic Director 基于权重的流量拆分（点击可放大）

流量镜像，方便调试

调试问题时，将生产流量的副本发送到调试服务可能会很有用。Traffic Director 允许您设置请求镜像政策，以便将请求发送到一项服务，并将这些请求的副本发送到另一项服务。

Traffic Director 流量镜像。 — Traffic Director 流量镜像（点击可放大）

针对性能精确调整的负载平衡

根据您的应用特征，您可能会发现，通过精确调整流量在服务后端之间的分配方式可以提高性能和可用性。借助 Traffic Director，您可以应用高级负载平衡算法，以便根据需要分配流量。

与之前的示意图相反，下图显示了目标后端服务（生产服务）和该后端服务的后端（虚拟机 1、虚拟机 2、虚拟机 3）。通过高级流量管理，您可以配置目标后端服务的选择方式，以及流量在该目标服务的各个后端之间的分配方式。

后续步骤

如需详细了解网址映射，请参阅网址映射概览和使用网址映射。
如需将网格外部的流量引导到您的网格中，请参阅网格入站流量。
如需通过 Sidecar 代理部署来设置功能，请参阅使用 Envoy 配置高级流量管理。
如需通过无代理 gRPC 部署来设置功能，请参阅使用无代理 gRPC 服务配置高级流量管理。