Cloud Service Mesh 概览
本文档适用于希望熟悉 Cloud Service Mesh 及其功能的网络管理员和服务所有者。这是旧版文档，适用于使用负载均衡 API 的配置。
Cloud Service Mesh 是用于应用网络的代管式控制平面。 借助 Cloud Service Mesh，您可以通过流量管理和可观测性等高级应用网络功能提供全球性的高可用性服务。
随着部署中服务和微服务数量的增加，您通常开始遇到常见的应用网络挑战，例如：
- 如何让我的服务具有弹性？
- 如何获取服务流量以及服务如何相互通信？
- 当我的服务相互通信时，我如何理解发生了什么？
- 如何在不中断的情况下更新我的服务？
- 如何管理使部署成为可能的基础架构？
Cloud Service Mesh 可帮助您在基于服务的现代部署中解决这些类型的挑战。Cloud Service Mesh 依赖于 Google Cloud 管理的基础架构，因此您不必管理自己的基础架构。您需要专注于交付应用代码来解决您的业务问题，同时让 Cloud Service Mesh 管理复杂的应用网络。
Cloud Service Mesh
解决应用网络挑战的一种常见模式是使用服务网格。Cloud Service Mesh 支持 符合您需求的服务网格和其他部署模式
在典型的服务网格中，有以下情况：
- 您会将服务部署到 Kubernetes 集群中。
- 每个服务 Pod 都有一个专用代理（通常是 Envoy）作为边车代理运行。
- 每个边车代理都会连接到集群中安装的网络基础架构（一个控制层面）。控制层面告知 Sidecar 代理服务网格中的服务、端点和政策。
- 当 Pod 发送或接收请求时，请求会转到 Pod 的边车代理。例如，边车代理会将请求发送至其预期的目的地，通过这样的方式处理该请求。
在本文档和其他 Cloud Service Mesh 文档的图表中，粉色六边形图标表示代理。控制平面连接到各代理，并提供代理处理请求所需的信息。两个框之间的箭头指示的是流量的方向。例如，Service A 中的应用代码发送请求。该代理对请求进行处理，并将其转发给 Service B。
使用此模型，您可以将网络逻辑从应用代码中移出。您可以专注于交付业务价值，同时让您的基础架构负责处理应用网络。
Cloud Service Mesh 有何不同之处
Cloud Service Mesh 与该模型类似，但在重要方面有所不同。这一切都始于 Cloud Service Mesh 是 Google Cloud 代管式服务。您不需要安装它，它不会在您的集群中运行，您也不需要执行任何维护。
在下图中，Cloud Service Mesh 是控制平面。此 Kubernetes 集群中有四个服务，每项服务都有连接到 Cloud Service Mesh 的 Sidecar 代理。Cloud Service Mesh 提供代理路由请求所需的信息。例如，属于 Service A 的一个 Pod 中的应用代码发送请求。与此 Pod 一起运行的边车代理会处理该请求，并将其路由到 Service B 中的 Pod。
服务网格进阶
与典型服务网格相比，Cloud Service Mesh 支持的部署类型更多。
多集群 Kubernetes
借助 Cloud Service Mesh，您可以获得跨 Kubernetes 集群运行的应用网络。在下图中，Cloud Service Mesh 为 us-central1 和 europe-west1 中的 Kubernetes 集群提供了控制平面。请求可以在 us-central1 中的三项服务、europe-west1 中的两项服务以及两个集群中的服务之间路由。
您的服务网格可以跨多个 Google Cloud 区域中的多个 Kubernetes 集群进行扩展。一个集群中的服务可以与另一个集群中的服务进行通信。您的服务甚至可以包含多个集群内的 Pod。
借助 Cloud Service Mesh 基于邻近度的全局负载均衡，发往 Service B 的请求会路由到可处理该请求的最近 Pod。您还将获得无缝的故障切换；如果某个 Pod 处于关闭状态，即使该 Pod 位于另一个 Kubernetes 集群中，该请求也会自动故障切换到可以为该请求提供服务的另一个 Pod。
虚拟机
Kubernetes 越来越受欢迎，但许多工作负载都部署到虚拟机实例中。Cloud Service Mesh 也可以为这些工作负载解决应用网络问题；基于虚拟机的工作负载与基于 Kubernetes 的工作负载进行互操作。
在下图中，流量通过外部应用负载均衡器进入您的部署。流量会被路由到 asia-southeast1 内 Kubernetes 集群中的 Service A 以及 europe-west1 内虚拟机上的 Service D。
Google 提供了一种使用 Cloud Service Mesh 设置基于虚拟机的工作负载的无缝机制。您只需要向 Compute Engine 虚拟机实例模板添加标志，Google 会处理基础架构的设置。此设置包括安装和配置用于提供应用网络功能的代理。
无代理 gRPC
gRPC 是一种功能丰富的开源 RPC 框架，可用于编写高性能微服务。借助 Cloud Service Mesh，您可以为 gRPC 应用引入应用网络功能（例如服务发现、负载均衡和流量管理）。如需了解详情，请参阅 Cloud Service Mesh 和 gRPC - 适用于服务网格的无代理服务。
在下图中，gRPC 应用将流量路由到一个区域的 Kubernetes 集群中的服务，以及多个不同区域的虚拟机上运行的服务。其中两种服务包括 Sidecar 代理，其他服务则为无代理。
Cloud Service Mesh 支持无代理 gRPC 服务。这些服务使用的是支持 xDS API 的最新版开源 gRPC 库。gRPC 应用可以使用 Envoy 使用的相同 xDS API 连接到 Cloud Service Mesh。
连接应用后，gRPC 库负责处理应用网络功能，例如服务发现、负载均衡和流量管理。这些函数原生在 gRPC 中发生，因此不需要服务代理，因此它们被称为无代理 gRPC 应用。
入站流量和网关
在许多使用场景中，您需要 [处理来自未通过 Cloud Service Mesh 配置的客户端的流量。例如，您可能需要将公共互联网流量通过入站方式传输到您的微服务。您可能还需要将负载均衡器配置为反向代理，使其先处理来自客户端的流量，然后再将流量发送到目标。
在下图中，外部应用负载均衡器为外部客户端启用入站流量，并将流量路由到一个 Kubernetes 集群中的服务。内部应用负载均衡器将内部流量路由到虚拟机上运行的服务。
Cloud Service Mesh 与 Cloud Load Balancing 搭配使用，提供托管式入站流量体验。您可以设置外部或内部负载均衡器，然后配置该负载均衡器，以将流量发送到您的微服务。在上图中，公共互联网客户端通过外部应用负载均衡器访问您的服务。客户端（例如位于您的 Virtual Private Cloud [VPC] 网络中的微服务）使用内部应用负载均衡器来访问您的服务。
对于某些使用场景，您可能希望设置 Cloud Service Mesh 来配置网关。网关本质上就是一个反向代理（通常是在一个或多个虚拟机上运行的 Envoy），用于监听入站请求、对其进行处理并将它们发送到目标位置。这个目标位置可以位于任何 Google Cloud 区域或 Google Kubernetes Engine (GKE) 集群中。您甚至可以使用混合连接，访问位于 Google Cloud 外部但 Google Cloud 可以访问的目标。 如需详细了解何时使用网关，请参阅网格的入站流量。
在下图中，europe-west1 区域中的一个虚拟机运行一个代理，该代理充当三个未运行代理的服务的网关。来自外部应用负载均衡器和内部应用负载均衡器的流量会路由到这个网关，然后再路由到三项服务。
多个环境
无论是在 Google Cloud、本地环境、其他云中，还是在囊括所有这些环境的混合环境中，您的基本应用网络挑战都保持不变。如何将流量传输到这些服务？这些服务如何彼此通信？
在下图中，Cloud Service Mesh 将流量从 Google Cloud 中运行的服务路由到另一个公有云中运行的 Service G，以及它们都在本地数据中心运行的 Service E 和 Service F。Service A、Service B 和 Service C 使用 Envoy 作为边车代理，而 Service D 是无代理 gRPC 服务。
使用 Cloud Service Mesh 时，您可以向 Google Cloud 以外的目的地发送请求。这允许您使用 Cloud Interconnect 或 Cloud VPN，以私密方式将流量从 Google Cloud 内部服务路由到其他环境中的服务或网关。
设置 Cloud Service Mesh
Cloud Service Mesh 的设置包括两个步骤。完成设置过程后，您的基础架构会处理应用网络，Cloud Service Mesh 会根据部署的变化使一切保持最新。
部署应用
首先，将您的应用代码部署到容器或虚拟机。Google 提供了可让您将应用网络基础架构（通常是 Envoy 代理）添加到虚拟机实例和 Pod 的机制。此基础架构设置为与 Cloud Service Mesh 通信并了解您的服务。
配置 Cloud Service Mesh
接下来，您要配置全局服务，并定义应该如何处理流量。如需配置 Cloud Service Mesh，您可以使用 Google Cloud 控制台（针对某些功能和配置）、Google Cloud CLI、Traffic Director API 或其他工具（如 Terraform）。
完成这些步骤后，Cloud Service Mesh 即可配置您的应用网络基础架构。
基础架构处理应用网络
当应用向 my-service 发送请求时，应用网络基础架构（例如 Envoy 边车代理）会根据从 Cloud Service Mesh 收到的信息处理请求。这使得 my-service 的请求可以无缝路由到能够接收请求的应用实例。
监控和持续更新
Cloud Service Mesh 监控构成服务的应用实例。通过这种监控，Cloud Service Mesh 可以发现服务运行状况良好或服务的容量发生了变化，例如在创建新的 Kubernetes Pod 时。Cloud Service Mesh 会根据这些信息持续更新您的应用网络基础架构。
特性
Cloud Service Mesh 的特性可为微服务提供应用网络功能。本部分讨论了一些主要内容。
全代管式控制层面、健康检查和负载均衡
您希望做的是将时间花在交付业务价值上，而不是用在管理基础架构上。Cloud Service Mesh 是一种全代管式解决方案，因此您无需安装、配置或更新基础架构。您可以受益于 Google 用来执行健康检查和全局负载均衡的相同基础架构。
基于开源产品构建
Cloud Service Mesh 使用的控制平面 (xDS API) 与 Envoy 和 Istio 等热门开源项目所使用的控制平面相同。如需查看受支持的 API 版本，请参阅 xDS 控制平面 API。
提供应用网络功能的基础架构（Envoy 或 gRPC，具体取决于您的使用场景）也是开源的，因此您无需担心受限于专有基础架构。
扩缩
从一次性应用网络解决方案，到包含数千项服务的大规模服务网格部署，Cloud Service Mesh 可以满足您的伸缩需求。
服务发现以及跟踪您的端点和后端
当应用向 my-service 发送请求时，您的基础架构会无缝地处理请求并将其发送到正确的目标位置。您无需了解 IP 地址、协议或其他网络复杂性方面的任何知识。
全局负载均衡和故障切换
Cloud Service Mesh 使用 Google 的全球负载均衡和健康检查功能，根据客户端和后端位置、后端邻近度、健康状况和容量以最优方式平衡流量。通过自动将流量故障切换到运行状况良好且具有容量的后端，您就可以提高服务可用性。您可以自定义负载均衡，以分配流量来正确支持您的业务需求。
流量管理
通过高级流量管理（包括基于主机名、路径、标头、Cookie 等的路由和请求操作），您可以确定流量如何在服务之间流动。对于 Canary 部署，您还可以应用重试、重定向和基于权重的流量拆分等操作。借助故障注入、流量镜像和离群值检测等高级模式，您就可以实现提高弹性的 DevOps 使用场景。
可观测性
您的应用网络基础架构会收集遥测信息（例如指标、日志和跟踪记录），这些信息可以在 Google Cloud Observability 中集中汇总。收集好信息后，您可以获取数据洞见并创建提醒，以便在出现问题时获得通知。
VPC Service Controls
您可以使用 VPC Service Controls 为应用的资源和服务提供额外的安全保障。您可以将项目添加到服务边界，以保护资源和服务（例如 Cloud Service Mesh）免受来自边界外的请求的影响。如需详细了解 VPC Service Controls，请参阅 VPC Service Controls 概览。
如需详细了解如何将 Cloud Service Mesh 与 VPC Service Controls 搭配使用，请参阅支持的产品页面。
后续步骤
这是一份主要适用于负载均衡 API 的旧版文档。 我们强烈建议您不要使用负载均衡 API 配置 Cloud Service Mesh。
如需部署 Cloud Service Mesh，请执行以下操作：
如需查找无代理 gRPC 服务的使用场景和架构模式，请参阅无代理 gRPC 服务概览。
如需了解如何通过流量管理来控制流量的处理方式，请参阅高级流量管理概览。
如需了解 Cloud Service Mesh 如何支持 Google Cloud 以外的环境，请参阅以下文档：