包含无代理 gRPC 服务的 Traffic Director 概览

本指南概述了包含无代理 gRPC 服务的 Traffic Director 架构，包括使用场景和架构模式。 本指南介绍了旧版 Traffic Director API。如需了解服务路由 API，请参阅概览。

Traffic Director 的代管式控制层面为服务网格和负载均衡使用场景启用全局路由、负载均衡和地区故障切换。这包括整合 Sidecar 代理和网关代理的部署。Traffic Director 对无代理 gRPC 应用的支持提供了其他部署模型，在该模型中，gRPC 应用可以参与服务网格，而无需边车代理。

在典型示例中，gRPC 客户端会与托管后端逻辑的 gRPC 服务器建立连接。Traffic Director 会为您的 gRPC 客户端提供以下信息：要连接的服务器、如何将请求负载平衡到某个服务器的多个实例，以及在服务器未运行时如何处理请求。

如需全面了解 Traffic Director 的工作原理，请参阅 Traffic Director 概览。

Traffic Director 如何与 gRPC 应用搭配使用

Traffic Director 使用支持的 gRPC 版本配置 gRPC 客户端，类似于如何配置 Sidecar 代理（如 Envoy）。但是，直接连接到 Traffic Director 的无代理 gRPC 应用不需要 Sidecar 代理。Traffic Director 使用开源 xDS API 直接配置 gRPC 应用。这些 gRPC 应用充当 xDS 客户端，连接到 Traffic Director 的全局控制层面。连接后，gRPC 应用会从控制层面接收动态配置，从而支持端点发现、负载均衡、地区故障切换和健康检查。此方法支持其他 Traffic Director 部署模式。

在第一个图示中，通过使用边车代理启用服务网格。

使用边车代理启用的服务网格。
使用边车代理启用的服务网格（点击可放大）

为了配置边车代理，Traffic Director 使用 xDS API。客户端通过边车代理与服务器进行通信。

在第二个图示中，在没有边车代理的情况下，使用无代理 gRPC 客户端启用服务网格。

使用无代理 gRPC 启用的服务网格。
使用无代理 gRPC 启用的服务网格（点击可放大）

如果您仅部署 Traffic Director 配置的 gRPC 服务，则可以创建服务网格，而且完全不必部署任何代理。这样可以更轻松地将服务网格功能引入您的 gRPC 应用。

名称解析方案

名称解析适合通过如下方式用于无代理部署：

  1. 在连接到服务时，可将 xds 设置为 gRPC 客户端通道中的名称解析方案。目标 URI 的格式为 xds:///hostname:port。未指定端口时，默认值为 80，例如在目标 URI xds:///example.hostname 中就是如此。
  2. gRPC 客户端通过向 Traffic Director 发送监听器发现服务 (LDS) 请求来解析目标 URI 中的 hostname:port。
  3. Traffic Director 查找具有匹配端口的已配置转发规则。然后，它会查找与 hostname:port 匹配的主机规则的相应网址映射。它将关联的路由配置返回给 gRPC 客户端。

您在 Traffic Director 中配置的主机规则在所有网址映射中都必须唯一。例如，example.hostname、example.hostname:80 和 example.hostname:8080 都是不同的规则。

不同部署类型的名称解析

对于无代理部署和使用 Envoy 代理的部署，名称解析方案有所不同。

gRPC 客户端使用 xds 名称解析方案连接到服务，从而允许客户端从 Traffic Director 接收服务配置。然后，gRPC 客户端直接与 gRPC 服务器通信。

您可以结合使用边车代理和无代理部署模式来提高灵活性。当您的组织和网络支持具有不同功能要求、运营需求和 gRPC 版本的多个团队时，这种结合的模式尤其有用。

在以下图示中，无代理 gRPC 客户端和具有边车代理的 gRPC 客户端与 gRPC 服务器通信。 具有 Sidecar 代理的 gRPC 客户端使用 dns 名称解析方案。

由无代理 gRPC 客户端和具有 Sidecar 代理的 gRPC 客户端组成的服务网格。
由无代理 gRPC 客户端和具有 Sidecar 代理的 gRPC 客户端组成的服务网格（点击可放大）

使用场景

以下使用场景可帮助您了解何时可能需要将 Traffic Director 与无代理 gRPC 应用搭配使用。您的部署可以包含无代理 gRPC 应用和/或具有 Sidecar 代理的 gRPC 应用。

大规模服务网格中的资源效率

如果您的服务网格包含数百或数千个客户端和后端，您可能会发现运行 Sidecar 代理的总资源用量开始增加。使用无代理 gRPC 应用时，您无需在部署中引入 Sidecar 代理。无代理方法可用于提高效率。

高性能 gRPC 应用

在某些使用场景中，每毫秒的请求和响应延迟时间都非常重要。在这种情况下，如果您使用无代理 gRPC 应用，而不是通过客户端边车代理以及可能通过服务器端边车代理传递每个请求，您可能会发现延迟时间缩短。

无法部署 Sidecar 代理的环境的服务网格

在某些环境中，您可能无法将边车代理作为附加进程与客户端应用或服务器应用一起运行。或者，您可能无法配置机器的网络堆栈进行请求拦截和重定向（例如，使用 iptables）。在这种情况下，您可以将 Traffic Director 与无代理 gRPC 应用搭配使用，为 gRPC 应用引入服务网格功能。

异构服务网格

由于无代理 gRPC 应用和 Envoy 与 Traffic Director 通信，因此您的服务网格可以包含两种部署模型。 通过结合使用这两种模型，您就可以满足不同应用和不同开发团队的特定运营、性能和功能需求。

从有代理的服务网格迁移到无代理的网格

如果您已有含已配置边车代理的 gRPC 应用，则可以转换到无代理 gRPC 应用。

使用边车代理部署 gRPC 客户端时，它会使用 DNS 来解析它所连接的主机名。边车代理会拦截流量，以提供服务网格功能。

通过修改 gRPC 客户端使用的名称解析方案，您可以定义 gRPC 客户端是使用无代理路由还是 Sidecar 代理路由来与 gRPC 服务器通信。无代理客户端使用 xds 名称解析方案，而 Sidecar 代理使用 dns 名称解析方案。有些 gRPC 客户端在连接到 gRPC 服务器时甚至可以使用无代理路由，而在连接到其他 gRPC 服务器时使用 Sidecar 代理路由。这样，您就可以逐步迁移到无代理部署。

要从有代理的服务网格迁移到没有代理的网格，您需要创建无代理 gRPC 客户端使用的新的 Traffic Director 服务。 您可以使用相同的 API 为现有版本和新版本配置 Traffic Director。

具有 gRPC 客户端的服务网格，该客户端使用无代理和基于代理的机制与不同服务通信。
具有 gRPC 客户端的服务网格，该客户端使用无代理和基于代理的机制与不同服务通信（点击可放大）

架构和资源

无代理 gRPC 服务的配置数据模型扩展了 Traffic Director 配置模型，并具有本指南中所述的一些新增内容和限制。其中有些限制是临时性的，因为无代理 gRPC 不支持 Envoy 的所有功能，而有些限制是使用 RPC 的固有限制。例如，不支持使用 gRPC 的 HTTP 重定向。为了帮您了解本指南中的配置模型，我们建议您熟悉 Traffic Director 概念和配置。

下图显示了您必须为无代理 gRPC 应用配置的资源。

无代理 gRPC 支持进行负载均衡的资源。
无代理 gRPC 支持进行负载均衡的资源（点击可放大）

路由规则映射

路由规则映射定义了请求在网格中的路由方式。它包含转发规则、目标 gRPC 代理和网址映射。 路由规则映射仅适用于使用负载均衡 API 的部署。它们不适用于服务路由 API 或 Gateway API。

转发规则

通常情况下，您可以使用所配置的服务的虚拟 IP 地址和端口来创建转发规则。使用 xds 名称解析方案的 gRPC 客户端不会执行 DNS 查找来解析通道 URI 中的主机名。相反，此类客户端会通过向 Traffic Director 发送 LDS 请求来解析目标 URI 中的 hostname[:port]。您不需要执行 DNS 查找，也不需要主机名的 DNS 条目。

因此，Traffic Director 仅使用 URI 中指定的端口来查找转发规则，并忽略 IP 地址。端口的默认值为 80。接着，Traffic Director 会在与转发规则引用的目标代理关联的网址映射中查找匹配的主机规则。

因此，引用目标 gRPC 代理并将 validateForProxyless 字段设置为 TRUE 的转发规则必须将其 IP 地址设置为 0.0.0.0。validateForProxyless 设置为 TRUE 时，系统会拒绝指定除 0.0.0.0 以外的 IP 地址的配置。 此检查检测不到其他路由规则映射中具有相同端口的重复转发规则。

请注意以下几点：

  • 转发规则的负载平衡方案必须是 INTERNAL_SELF_MANAGED。
  • 您可以有多个转发规则，但每个转发规则的 IP:port 必须唯一，并且端口必须与主机规则中指定的端口匹配。
  • 如果有多个转发规则使用与目标 URI 中的端口匹配的端口，则 Traffic Director 会在所有此类转发规则引用的网址映射的主机规则中查找匹配的 hostname[:port]。Traffic Director 会查找主机规则中的 hostname[:port] 与目标 URI 中指定的 hostname[:port] 之间的完全匹配项。系统会跳过包含通配符的主机规则和默认规则。

如果找到多个匹配项，则行为未定义，可能会导致行为无法预测。当同时满足以下两个条件时，通常会发生这种情况：

  • 多个网址映射使用相同的主机名。
  • 采用负载平衡方案 INTERNAL_SELF_MANAGED 的多个转发规则指定相同的端口。

因此，我们建议您不要为由指定相同端口的转发规则引用的多个网址映射使用相同的主机名。

目标 gRPC 代理

目标代理指向网址映射，网址映射又包含用于将流量路由到正确后端的规则。为 gRPC 应用配置 Traffic Director 时，无论您是使用无代理 gRPC 应用，还是使用借助于 Envoy 的 gRPC 应用，都请使用目标 gRPC 代理（而非目标 HTTP 代理）。

目标 gRPC 代理在 REST API 中具有一个名为 validateForProxyless 的字段。默认值为 FALSE。将此字段设置为 TRUE 会启用配置检查，以免您意外启用与无代理 gRPC 不兼容的功能。

在 Google Cloud CLI 中，--validate-for-proxyless 标志等效于 validateForProxyless 字段。

由于 Traffic Director 对无代理 gRPC 应用的支持不包括具有边车代理的 gRPC 应用可用的全部功能，因此您可以使用此字段来确保移除无效配置（可能会在网址映射或后端服务中指定）。配置验证是基于 Traffic Director 在最新版 gRPC 中支持的功能完成的。

网址映射

网址映射定义无代理 gRPC 客户端用于发送流量的路由规则。网址映射包含一个或多个主机规则，格式为 hostname:port。这些主机规则中的每一个都会解析为服务。

配置 gRPC 客户端时，您可指定客户端需要联系的服务的目标 URI。此 URI 也使用 hostname:port 格式。此 URI 对应于网址映射中的主机规则条目。

例如，如果您在 gRPC 客户端中配置目标 URI xds:///myservice:8080，Traffic Director 将向其发送与 myservice:8080 的网址映射主机规则相对应的配置。此配置包括端点列表等信息，每个端点都是一个与特定 gRPC 服务器实例相对应的 IP 地址:端口对。

如果您未在目标 URI 中指定端口，系统会使用 80 作为默认值。这有以下含义：

  • 目标 URI xds:///myservice 与网址映射主机规则 myservice 匹配。
  • 目标 URI xds:///myservice:80 与网址映射主机规则 myservice:80 匹配。
  • 目标 URI xds:///myservice 与网址映射主机规则 myservice:80 不匹配。
  • 目标 URI xds:///myservice:80 与网址映射主机规则 myservice 不匹配。

目标 URI 中的字符串和网址映射主机规则中的字符串必须相同。

如需了解详情，请参阅网址映射限制。

健康检查

gRPC 健康检查可以检查在后端虚拟机实例或网络端点组 (NEG) 上运行的 gRPC 服务的状态。

如果由于 gRPC 服务器未实现 gRPC 健康检查协议而无法使用 gRPC 健康检查，请改用 TCP 健康检查。请勿使用 HTTP、HTTPS 或 HTTP/2 健康检查。

如需了解详情，请参阅 gRPC 健康检查和用于 gRPC 健康检查的额外标志。

后端服务

后端服务定义 gRPC 客户端如何与 gRPC 服务器通信。为 gRPC 创建后端服务时，请将协议字段设置为 GRPC。

  • gRPC 应用还可以通过边车代理访问配置时将协议设置为 GRPC 的后端服务。在这种情况下，gRPC 客户端不得使用 xds 名称解析方案。

  • 在所有 Traffic Director 部署中，后端服务的负载平衡方案必须为 INTERNAL_SELF_MANAGED。

后端

后端托管您的 gRPC 服务器实例。您可以在 Compute Engine 中使用代管或非代管实例组、在 Google Kubernetes Engine 中使用可用区级 NEG 作为后端来托管 gRPC 服务器实例。

后续步骤