Anthos Service Mesh 和 Traffic Director 现已更名为 Cloud Service Mesh。如需了解详情，请参阅 Cloud Service Mesh 概览。

此页面由 Cloud Translation API 翻译。

高级流量管理概览

本文档适用于网格或平台管理员和服务对相关知识有中高级的熟悉程度， Cloud Service Mesh 和服务网格概念以及谁决定和配置流量在 Cloud Service Mesh 部署中进行管理。

Cloud Service Mesh 提供高级流量管理功能让您可以精细地控制流量的处理方式。 Cloud Service Mesh 支持以下用例：

将请求路由到一项或多项服务进行精细的流量路由。
基于权重的流量拆分，用于在多个服务之间分配流量。
流量镜像政策：将请求发送到一项调试服务；复制到另一个可用区TCPRoute 不支持流量镜像或 TLSRoute 资源。
微调服务后端之间的流量分配，以提升负载负载均衡

这些高级流量管理功能让您可以实现可用性和性能目标。使用 Google Kubernetes Engine 的 Cloud Service Mesh 就是，您可以更新而无需修改应用代码。

Cloud Service Mesh 服务网格中的流量管理依赖于以下各项资源：

Mesh 资源，用于标识服务网格并代表负责转发流量和应用政策。Mesh 资源还会标识流量拦截端口。
Gateway 资源，用于标识中间代理并代表用于监听“IP 地址:端口”对列表的组件流量，以及应用政策。
Route 资源，该资源可以是多种类型之一，其中包含网格的流量路由信息。Route 项资源识别客户端可用于将流量路由到后端的主机名和端口服务。Route 资源类型有以下几种：
- HTTPRoute，仅在使用 Envoy 代理的网格中可用。当您使用 HTTPRoute 资源将 Envoy 代理配置为发送 HTTP 那么本文档中的所有功能均可使用。
- TCPRoute，仅在使用 Envoy 代理的网格中可用。
- TLSRoute，仅在使用 Envoy 代理的网格中可用。
- GRPCRoute，可在使用 Envoy Sidecar 代理和无代理 gRPC。将无代理 gRPC 服务或应用与 Cloud Service Mesh 中介绍的一些功能，文档不可用。
后端服务，与 Route 资源相关联。

配置

如需配置高级流量管理，请使用相同的 Route 和设置 Cloud Service Mesh 时使用的后端服务资源。 Cloud Service Mesh 进而配置 Envoy 代理和无代理 gRPC 来强制执行您设置的高级流量管理政策。

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

配置 Mesh 资源以标识服务网格。
配置 Route 资源以根据特征：
1. 选择请求所路由到的后端服务。
2. （可选）执行额外的操作。
配置后端服务以控制在选择目标服务后如何将流量分配到后端和端点。

流量路由和操作

在 Cloud Service Mesh 中，流量根据 Mesh 资源中的值进行路由。 Route 资源和后端服务资源。所有高级流量管理使用 Route 配置与路由和操作相关的功能对象的操作。

以下部分介绍了高级流量管理功能，您可以在 Route 对象中设置。

请求处理

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

请求与特定 Route 资源匹配，如下所示：
- 如果您使用的是 Envoy： <ph type="x-smartling-placeholder">
  - 将 HTTP 请求中的主机标头与 hostnames 进行匹配字段，以选择正确的HTTPRouteGRPCRoute 请求的 Route 资源。只有HTTPRoute和GRPCRoute 资源包含 hostnames 字段。
  - 系统会使用 TCPPRoute 匹配该 IP 地址，以便路由 TCP 流量。
  - SNI 和 ALPN 用于通过 TLSRoute 实现 TLS 传递。
  - HTTPRoute 和 GRPCRoute 资源与 Mesh 或 Gateway 的主机名必须各不相同。如果您尝试将多个主机名冲突，系统会拒绝配置。
  - 同样，TCPRoute 的 IP:Port 字段必须是唯一的，或者配置被拒绝。
  - 同样，SNI 和 ALPN 对于 TLSRoute 也必须是唯一的。
  - 如果存在重叠的主机名（如 a.example.com 和 *.example.com，则请求与更具体的路线匹配。
- 如果您使用的是无代理 gRPC：
  - 无代理 gRPC 客户端使用 xds 名称解析方案。他们通过发送请求来解析目标 URI 中的 hostname[:port] Cloud Service Mesh
  - 仅比较 GRPCRoute 资源的端口发送到目标 URI 中的端口（例如， xds:///example.hostname:8080).目标 URI 必须完全匹配 GRPCRoute 的 hostnames 字段中的字符串。
Route 资源可以包含更多路由信息和规则。
选择目标后端服务后，系统会根据后端服务资源中的配置在该目标后端服务的后端或端点之间分配流量。

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

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

Cloud Service Mesh 支持简化的路由方案，高级架构。在简单架构中，您需要指定主机和（可选）路径。系统会评估请求的主机和路径，以确定后端服务请求所路由到的 IP 地址

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

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

全局 Mesh
HTTPRoute 或 GRPCRoute

大部分配置都在 HTTPRoute 中完成。创建初始路由规则映射，只需修改 HTTPRoute 资源即可。

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

如果请求的主机（例如 example.com）与 HTTPRoute:
1. 接下来，系统会评估 RouteRule。RouteRule 指定了如何匹配以及在流量匹配时如何路由流量。
2. 每个 RouteRule 包含一个或多个路由匹配项，这些路由匹配项会进行评估请求路径
3. 如果找到匹配项，则请求将路由到 RouteAction。

如需详细了解 HTTPRoute 的资源字段及其工作原理，请参阅网络服务 API 文档。

高级路由和操作

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

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

与简单路由一样，系统会将请求的主机您在 HTTPRoute 或 GRPCRoute 中配置的规则。如果请求的 host 与主机名匹配，则评估 HTTPRoute 或 GRPCRoute。
选择路由后，您可以应用操作。

高级路由

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

如需详细了解 headerMatches 和 queryParameterMatches 的匹配条件和详细信息，请参阅 network services 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 请求中作为标头传递。

操作

Cloud Service Mesh 可让您指定 Envoy 代理或无代理 gRPC 应用在处理请求时采用。以下操作使用 Cloud Service Mesh 进行配置

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

有关操作及其工作原理的详情，请参阅 Network Services API 页面。

在每条路由规则中，您可以指定以下路由操作之一：

将流量路由到单项服务 (destination.serviceName)
在多项服务之间拆分流量 (destination.weight)
重定向网址 (redirect)

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

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

由于操作与特定规则相关联，因此 Envoy 代理或无代理 gRPC 应用可以根据资源。

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

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

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

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

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

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

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

有关不同流量分配选项的详情，具体运作方式，请参阅以下文档：

backendServices REST API 页面
后端服务概览。

使用场景示例

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

您可在以下位置找到更多示例，包括示例代码：使用 Envoy 配置高级流量管理以及使用无代理 gRPC 服务配置高级流量管理。

精确的个性化流量路由

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

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

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

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

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

Cloud Service Mesh 基于权重的流量拆分。 — 基于 Cloud Service Mesh 权重的流量拆分（点击可放大）

流量镜像，方便调试

调试问题时，将生产流量的副本发送到调试服务可能会很有用。借助 Cloud Service Mesh 从而将请求发送到一项服务以及这些服务的副本请求会发送到其他服务

Cloud Service Mesh 流量镜像。 — Cloud Service Mesh 流量镜像（点击可放大）

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

根据您的应用特征，您可能会发现，通过精确调整流量在服务后端之间的分配方式可以提高性能和可用性。借助 Cloud Service Mesh 先进的负载均衡算法，让流量根据满足您的需求

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

Cloud Service Mesh 负载均衡。 — Cloud Service Mesh 负载均衡（点击可放大）

如需详细了解如何使用 Cloud Service Mesh 进行负载均衡，请参阅高级负载均衡概览。

后续步骤

如需将网格外部的流量引导到您的网格中，请参阅网格入站流量。