高级流量管理概览

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

注意 ：本指南仅支持通过 Google Cloud API 使用 Cloud Service Mesh， 不支持 Istio API。如需了解详情，请参阅 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 资源与其相关联。

配置

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

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

1. 配置 Mesh 资源以标识服务网格。

2. 配置 Route 资源以根据 特征：

   1. 选择请求所路由到的后端服务。

   2. （可选）执行额外的操作。

3. 配置后端服务以控制在选择目标服务后如何将流量分配到后端和端点。

流量路由和操作

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

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

请求处理

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

1. 系统将请求与特定的 Route 资源进行匹配，如下所示：

   • 如果您使用的是 Envoy：
     • 将 HTTP 请求中的主机标头与 hostnames 进行匹配 字段以选择正确的HTTPRoute或GRPCRoute资源 请求的 Route 资源。只有 HTTPRoute 和 GRPCRoute 资源具有 hostnames 字段。
     • 系统会匹配 IP 地址，以便使用 TCPPRoute 路由 TCP 流量。
     • SNI 和 ALPN 用于使用 TLSRoute 进行 TLS 穿透。
     • HTTPRoute 和 GRPCRoute 资源与 Mesh 或 Gateway 的主机名必须各不相同。如果您尝试将多个 具有冲突主机名的路由，则配置会被拒绝。
     • 同样，TCPRoute 的 IP:Port 字段必须是唯一的，或者 配置被拒绝。
     • 同样，SNI 和 ALPN 对于 TLSRoute 也必须是唯一的。
     • 如果存在重叠的主机名（如 a.example.com 和 *.example.com，则请求与更具体的路线匹配。
   • 如果您使用的是无代理 gRPC：
     • 无代理 gRPC 客户端使用 xds 名称解析方案。它们通过向 Cloud Service Mesh 发送请求来解析目标 URI 中的 hostname[:port]。
     • 仅比较 GRPCRoute 资源的端口 发送到目标 URI 中的端口（例如， xds:///example.hostname:8080）。目标 URI 必须完全匹配 GRPCRoute 的 hostnames 字段中的字符串。

2. Route 资源可以包含更多路由信息和规则。

3. 选择目标后端服务后，系统会根据后端服务资源中的配置在该目标后端服务的后端或端点之间分配流量。

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

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

Cloud Service Mesh 支持简化的路由方案， 高级架构。在简单方案中，您可以指定主机，还可以选择指定路径。系统会对请求的主机和路径进行评估，以确定请求所路由到的后端服务。

• 请求的主机名是网址的域名部分，例如，对于网址 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 文档。

高级路由和操作

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

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

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

高级路由

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

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

通过使用“匹配”功能组合主机、路径、标头和查询参数 您可以根据具体流量创建极富表现力的规则 管理要求有关详情，请参阅下表。

	基于 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 请求中作为标头传递。

操作

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

注意：将 Envoy 与 Cloud Service Mesh 搭配使用时，以下所有功能都可用。某些功能无法使用 将无代理 gRPC 应用与 Cloud Service Mesh 结合使用时。如需了解详情，请参阅功能页面和无代理 gRPC 的限制页面。

操作	API 字段名称	说明
重定向	redirect [pathredirect?]	返回可配置的 3xx 响应代码。此外，它还会使用适当的 URI 设置 Location 响应标头，并替换重定向操作中所指定的主机和路径。
网址重写	urlRewrite	在将请求发送到选定的后端服务之前，重写网址的主机名部分和/或网址的路径部分。
标头转换	requestHeaderModifier/responseHeaderModifier?	在向后端服务发送请求前添加或移除请求标头。还可以在接收来自后端服务的响应后添加或移除响应标头。
流量镜像	requestMirrorPolicy	除了将请求转发到选定的后端服务，还会以即发即弃的方式将相同请求发送到配置的镜像后端服务。负载平衡器不会等待作为镜像请求发送目标的后端的响应。 镜像有助于测试后端服务的新版本。 此外，镜像还可用于调试后端服务调试版本的生产错误（而非生产版本的错误）。
基于权重的流量拆分	weightDestination.serviceName	允许将匹配规则的流量分配到多个后端服务，分配的流量与各后端服务分配到的用户定义权重成比例。 此功能对于配置分阶段部署或 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 实际接收并处理请求。例如，这些后端可能是托管服务器端应用代码的 Compute Engine 虚拟机实例。

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

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

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

政策	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 标头进行路由（点击可放大）

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

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

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

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

流量镜像，方便调试

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

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

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

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

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

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

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

后续步骤

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