Cloud Service Mesh 负载均衡

Cloud Service Mesh 使用边车代理或无代理 gRPC 为内部微服务提供全球负载均衡。您可在多个区域中使用实例部署内部微服务（基于边车代理或基于无代理的 gRPC）。Cloud Service Mesh 提供健康状况、路由和后端信息， Sidecar 代理或无代理 gRPC，使其能够执行最佳流量 为一项服务路由到多个云区域中的应用实例。

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

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

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

全球负载均衡部署中的 Cloud Service Mesh。
全球负载均衡部署中的 Cloud Service Mesh（点击可放大）

在以下示例中，如果 Cloud Service Mesh 收到健康检查结果 这表示运行购物车的虚拟机 (VM) 实例 us-central1 中的微服务健康状况不佳，则 Cloud Service Mesh 会指示 前端微服务的边车代理，用于将流量故障切换到 Google 购物 在 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，Mesh 或 Gateway 资源和 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 资源（点击可放大）

后续步骤