Cloud Service Mesh 负载均衡

Cloud Service Mesh 使用 Sidecar 代理或无代理 gRPC 为您的内部微服务提供全局负载均衡。您可在多个区域中使用实例部署内部微服务(基于边车代理或基于无代理的 gRPC)。Cloud Service Mesh 可为 Sidecar 代理或无代理 gRPC 提供健康状况、路由和后端信息,使它们能够针对一项服务执行优化的流量路由到多个云区域中的应用实例。

在下图中,用户流量通过外部全球负载均衡器进入 Google Cloud 部署。外部负载均衡器根据最终用户的位置将流量分配给 us-central1asia-southeast1 中的前端微服务。

内部部署采用了三项全球微服务:前端、购物车和付款。每项服务都在 us-central1asia-southeast1 这两个区域的代管式实例组上运行。Cloud Service Mesh 使用全局负载均衡算法,该算法会将来自加利福尼亚州用户的流量定向到 us-central1 中部署的微服务。新加坡用户的请求将定向到 asia-southeast1 中的微服务。

传入的用户请求被路由到“前端”微服务。然后,包含“前端”微服务的主机上安装的服务代理会将流量引导至“购物车”微服务。包含“购物车”微服务的主机上安装的边车代理再将流量引导至“付款”微服务。 在无代理 gRPC 环境中,您的 gRPC 应用将处理流量管理。

全球负载均衡部署中的 Cloud Service Mesh。
全局负载均衡部署中的 Cloud Service Mesh(点击可放大)

在以下示例中,如果 Cloud Service Mesh 收到的健康检查结果表明在 us-central1 中运行“购物车”微服务的虚拟机 (VM) 实例健康状况不佳,则 Cloud Service Mesh 会指示前端微服务的边车代理将流量故障切换到在 asia-southeast1 中运行的“购物车”微服务。由于自动扩缩功能已与 Google Cloud 中的流量管理集成,因此 Cloud Service Mesh 会通知 asia-southeast1 中的 MIG 有额外的流量,而 MIG 的大小也会增加。

Cloud Service Mesh 检测到“付款”微服务的所有后端均正常运行,因此 Cloud Service Mesh 会指示购物车的 Envoy 代理将一部分流量(最高可达到客户配置的容量)发送到 asia-southeast1,并将其余流量溢出到 us-central1

在全球负载均衡部署中使用 Cloud Service Mesh 进行故障切换。
在全球负载均衡部署中使用 Cloud Service Mesh 进行故障切换(点击可放大)

Cloud Service Mesh 中的负载均衡组件

在设置 Cloud Service Mesh 期间,您可以配置多个负载均衡组件:

  • 包含配置值的后端服务。
  • 运行健康检查,为部署中的虚拟机和 Google Kubernetes Engine (GKE) pod 的提供健康检查。
  • 对于服务路由 API,MeshGateway 资源和 Route 资源。
  • 对于负载均衡 API,一种全局转发规则,其中包括 VIP 地址、目标代理和网址映射。

与 xDS API 兼容的边车代理(例如 Envoy)在客户端虚拟机实例或 Kubernetes pod 中运行。Cloud Service Mesh 充当控制平面,并使用 xDS API 直接与每个代理通信。在数据平面中,应用将流量发送到转发规则或 Mesh 资源中配置的 VIP 地址。边车代理或 gRPC 应用会拦截流量并将其重定向到相应的后端。

下图显示了在 Compute Engine 虚拟机或 GKE Pod 上运行的应用、组件以及 Cloud Service Mesh 部署中的流量。它显示了用于确定流量路由的 Cloud Service Mesh 和 Cloud Load Balancing 资源。下图显示了旧版负载均衡 API。

要配置的 Cloud Service Mesh 资源。
要配置的 Cloud Service Mesh 资源(点击可放大)

后续步骤