Cloud Service Mesh 负载均衡

Cloud Service Mesh 使用 Sidecar 代理或无代理 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 应用将处理流量管理。

<ph type="x-smartling-placeholder">
</ph> 全球负载均衡部署中的 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。

<ph type="x-smartling-placeholder">
</ph> 在全局负载均衡部署中使用 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。

<ph type="x-smartling-placeholder">
</ph> 要配置的 Cloud Service Mesh 资源。
要配置的 Cloud Service Mesh 资源（点击可放大）

后续步骤