包含无代理 gRPC 服务的 Cloud Service Mesh 概览

本指南概述了包含无代理 gRPC 服务的 Cloud Service Mesh 架构，包括使用场景和架构模式。

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

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

如需全面了解 Cloud Service Mesh 的运作方式，请参阅 Cloud Service Mesh 概览。

Cloud Service Mesh 如何与 gRPC 应用搭配使用

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

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

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

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

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

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

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

域名解析

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

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

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

不同部署类型的名称解析

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

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

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

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

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

使用场景

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

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

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

高性能 gRPC 应用

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

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

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

异构服务网格

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

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

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

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

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

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

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

架构和资源

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

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

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

健康检查

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

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

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

后端服务

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

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

  • 在所有 Cloud Service Mesh 部署中，后端服务的负载均衡方案必须为 INTERNAL_SELF_MANAGED。

后端

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

后续步骤