包含无代理 gRPC 服务的 Cloud Service Mesh 概览
本指南简要介绍 Cloud Service Mesh 的架构 无代理 gRPC 服务,包括用例和架构模式。
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 版本 类似于 Envoy 等 Sidecar 代理的配置方式。但是,直接连接到 Cloud Service Mesh 的无代理 gRPC 应用不需要 Sidecar 代理。相反,Cloud Service Mesh 使用开源 xDS API 直接配置 gRPC 应用。这些 gRPC 应用充当 xDS 连接到 Cloud Service Mesh 的全局控制平面。连接后,gRPC 应用会从控制层面接收动态配置,从而支持端点发现、负载均衡、地区故障切换和健康检查。此方法可实现额外的 Cloud 服务网格 部署模式
在第一个图示中,通过使用 Sidecar 代理启用服务网格。
为了配置 Sidecar 代理,Cloud Service Mesh 使用 xDS API。客户 通过边车代理与服务器通信。
在第二个图示中,在没有 Sidecar 代理的情况下,使用无代理 gRPC 客户端启用服务网格。
如果您仅部署 Cloud Service Mesh 配置的 gRPC 服务, 您无需部署任何代理即可创建服务网格。这样可以更轻松地将服务网格功能引入您的 gRPC 应用。
域名解析
名称解析适合通过如下方式用于无代理部署:
- 在连接到服务时,可将
xds
设置为 gRPC 客户端通道中的名称解析方案。目标 URI 的格式为xds:///hostname:port
。未指定端口时,默认值为 80,例如在目标 URIxds:///example.hostname
中就是如此。 - gRPC 客户端通过向 Cloud Service Mesh 发送监听器发现服务 (LDS) 请求来解析目标 URI 中的
hostname:port
。 - 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
名称解析方案。
使用场景
以下使用场景可帮助您了解何时可能需要将 Cloud Service Mesh 与无代理 gRPC 应用搭配使用。您的部署可以包含无代理 gRPC 应用和/或具有 Sidecar 代理的 gRPC 应用。
大规模服务网格中的资源效率
如果您的服务网格包含数百或数千个客户端和后端,您可能会发现运行 Sidecar 代理的总资源用量开始增加。使用无代理 gRPC 应用时,您无需在部署中引入 Sidecar 代理。无代理方法可用于提高效率。
高性能 gRPC 应用
在某些使用场景中,每毫秒的请求和响应延迟时间都非常重要。在这种情况下,如果您使用无代理 gRPC 应用,而不是通过客户端 Sidecar 代理以及可能通过服务器端 Sidecar 代理传递每个请求,您可能会发现延迟时间缩短。
无法部署 Sidecar 代理的环境的服务网格
在某些环境中,您可能无法将 Sidecar 代理作为附加进程与客户端应用或服务器应用一起运行。或者,您可能无法配置机器的网络堆栈进行请求拦截和重定向(例如,使用 iptables
)。在这种情况下,您可以使用
Cloud Service Mesh 与无代理 gRPC 应用引入服务
网格功能。
异构服务网格
由于无代理 gRPC 应用和 Envoy 与 Cloud Service Mesh 通信,因此您的服务网格可以包含两种部署模型。通过结合使用这两种模型,您就可以满足不同应用和不同开发团队的特定运营、性能和功能需求。
从有代理的服务网格迁移到无代理的网格
如果您已有一个具有边车代理的 gRPC 应用, Cloud Service Mesh 已配置,您可以转换为无代理 gRPC 应用。
使用 Sidecar 代理部署 gRPC 客户端时,它会使用 DNS 来解析它所连接的主机名。边车代理拦截 以提供服务网格功能
通过修改 gRPC 客户端使用的名称解析方案,您可以定义 gRPC 客户端是使用无代理路由还是 Sidecar 代理路由来与 gRPC 服务器通信。无代理客户端使用 xds
名称解析方案,而 Sidecar 代理使用 dns
名称解析方案。有些 gRPC 客户端在连接到 gRPC 服务器时甚至可以使用无代理路由,而在连接到其他 gRPC 服务器时使用 Sidecar 代理路由。这样,您就可以逐步迁移到无代理部署。
如需从有代理的服务网格迁移到没有代理的网格, 创建无代理 gRPC 客户端使用的新 Cloud Service Mesh 服务。 您可以使用相同的 API 为现有版本和新版本配置 Cloud Service Mesh。
架构和资源
无代理 gRPC 服务的配置数据模型扩展了 Cloud Service Mesh 配置模型,并具有本指南中所述的一些新增内容和限制。其中有些限制是临时性的,因为无代理 gRPC 不支持 Envoy 的所有功能,而有些限制是使用 RPC 的固有限制。例如,不支持使用 gRPC 的 HTTP 重定向。为了帮您了解本指南中的配置模型,我们建议您熟悉 Cloud Service Mesh 概念和配置。
下图显示了您必须为无代理 gRPC 应用配置的资源。
健康检查
gRPC 健康检查可以检查在后端虚拟机实例或网络端点组 (NEG) 上运行的 gRPC 服务的状态。
如果由于 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 服务器实例。
后续步骤
- 如需了解服务路由 API 及其工作原理,请参阅概览。
- 如需准备使用无代理 gRPC 应用配置 Cloud Service Mesh,请参阅 准备设置 Envoy 和无代理工作负载。
- 如需了解适用于无代理 gRPC 部署的限制,请参阅与无代理 gRPC 相关的限制。