高级流量管理概览

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

将请求精确路由到（一项或多项）服务
基于请求和响应的操作（例如重定向和标头转换）
精确调整服务后端之间的流量分配，以改进负载平衡

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

使用场景示例

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

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

精确的个性化流量路由

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

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

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

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

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

流量镜像，方便调试

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

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

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

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

高级流量管理的工作原理

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

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

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

流量路由和操作

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

您可以在路由规则映射中设置以下高级流量管理功能。

请求处理

当客户端发送请求时，系统会按以下方式处理请求：

系统将请求与特定的路由规则映射进行匹配。匹配方式如下所示：
1. 如果您使用的是 Envoy：
  1. 系统将请求的目标 IP 地址和端口与所有路由规则映射中转发规则的 IP 地址和端口进行比较。系统仅考虑转发规则具有负载平衡方案 INTERNAL_SELF_MANAGED 的路由规则映射。
  2. 与请求匹配的转发规则会引用目标 HTTP 或 gRPC 代理，该代理会引用网址映射。此网址映射包含用于路由和操作的信息。
2. 如果您使用的是无代理 gRPC：
  1. 请求的 IP 地址将被忽略，因为在创建引用目标 gRPC 代理的转发规则时，您只能使用 0.0.0.0 IP 地址。系统仅考虑转发规则具有负载平衡方案 INTERNAL_SELF_MANAGED 的路由规则映射。
  2. 系统会将目标 URI（例如 xds:///foo.myservice:8080）中的端口与具有负载平衡方案 INTERNAL_SELF_MANAGED 的转发规则的端口进行比较。系统不会使用转发规则的 IP 地址。
  3. 与请求匹配的转发规则会引用目标 gRPC 代理，该代理会引用网址映射。此网址映射包含用于路由和操作的信息。
确定适当的网址映射后，系统会评估网址映射以确定目标后端服务并应用操作（后者是可选的）。
选择目标后端服务后，系统会根据后端服务资源中的配置在该目标后端服务的后端或端点之间分配流量。

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

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

Traffic Director 支持简化的路由方案以及更高级的方案。下一部分（高级路由和操作）介绍了更高级的路由方案，包括操作。在简单方案中，您可以指定主机，还可以选择指定路径。系统会对请求的主机和路径进行评估，以确定请求应路由到的服务。

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

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

基于主机和路径的简单路由是在路由规则映射中进行设置的，该映射包含以下内容：

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

大多数配置都是在网址映射中完成的；创建初始路由规则映射后，您通常只需要修改路由规则映射的网址映射部分。在这里展示的图中，路径规则具有与下一张图类似的操作。

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

如果请求的主机（例如 example.com）与主机规则匹配：

接下来，系统会评估路径匹配器。
每个路径匹配器都包含一项或多项根据请求的路径进行评估的路径规则。
如果找到匹配项，则请求会路由到路径规则中指定的服务。
每个路径匹配器都包含一项默认服务，如果主机规则匹配但没有路径规则匹配，则请求会路由到该服务。

如果请求与您指定的任何主机规则都不匹配，则会路由到默认规则中指定的服务。

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

高级路由和操作

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

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

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

高级路由

高级路由与上述简单路由类似，不同之处在于您可以指定规则优先级和额外的匹配条件，如下所述。

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

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

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

HTTP 主机与 gRPC 主机

如果您编写的是基于 HTTP 的应用，则主机是该应用所调用的网址的域名部分。例如，网址 http://example.com/video/ 的主机部分是 example.com。

如果您编写的是基于 gRPC 的应用，则主机是客户端在通道 URI 中用于连接到特定服务的名称。例如，通道 URI xds:///example.com 的主机部分是 example.com。

HTTP 路径与 gRPC 路径

如果您编写的是基于 HTTP 的应用，则路径是网址中位于主机名后面的部分，例如 http://example.com/video 中的 /video。

如果您编写的是基于 gRPC 的应用，则路径位于 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 请求的设置。

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

如需了解有关不同流量分配选项及其工作原理的额外信息，请参阅后端服务 API 参考文档。

后续步骤

如需详细了解如何在 Sidecar 代理部署中设置这些功能，请参阅配置高级流量管理。
如需详细了解如何在无代理 gRPC 部署中使用这些功能，请参阅通过高级流量管理设置基于虚拟机的无代理 gRPC 服务。