服务发现

Cloud Service Mesh 提供服务和端点发现。借助这些功能，您可以对将代码运行为服务端点的虚拟机 (VM) 实例和容器实例进行分组。

Cloud Service Mesh 会监控这些服务，以便与其客户端共享最新的运行状况检查信息。因此，如果您的某个应用使用其 Cloud Service Mesh 客户端（例如 Envoy 边车代理或 无代理 gRPC 应用）来发送请求，可受益于 与您的服务相关的信息

在 Cloud Service Mesh 中，“客户端”是指应用代码 。答 server 是接收此类请求的应用代码。 Cloud Service Mesh 客户端为 Envoy、gRPC 或其他 xDS 客户端，连接到 Cloud Service Mesh 并且是数据层面的一部分。

在数据层面中，Envoy 或 gRPC 执行以下操作：

  1. 它会检查请求，并将请求与后端服务（您在部署期间配置的资源）相匹配。
  2. 请求匹配后，Envoy 或 gRPC 会应用之前配置的所有 选择后端或端点，然后 将 向该后端或端点发送请求

服务发现

Cloud Service Mesh 提供服务发现。配置时 Cloud Service Mesh，则您需要创建后端服务。您还可以定义路由规则，以指定出站请求（您的应用代码发送并由 Cloud Service Mesh 客户端处理的请求）与特定服务的匹配方式。当 Cloud Service Mesh 客户端处理与规则匹配的请求时，它可以选择应接收请求的服务。

例如：

  • 您有一个运行应用的虚拟机。此虚拟机具有 Envoy 边车代理 连接到 Cloud Service Mesh 并 代表应用。
  • 您配置了名为 payments 的后端服务。此后端服务有两个网络端点组 (NEG) 后端，它们指向运行 payments 服务代码的各个容器实例。
  • 您配置了一个 Mesh 资源，用于定义一个名为 sidecar-mesh 的网格。
  • 您配置了一项 Route 资源，定义了以下流量的目的地： 后端服务 payments 和主机名 helloworld-gce。

使用此配置时，当应用（在虚拟机上）发送 HTTP 请求时， payments.example.com，则 Cloud Service Mesh 客户端会知道 该请求发往 payments 服务。

如果您将 Cloud Service Mesh 与无代理 gRPC 服务搭配使用，则服务发现的工作原理类似。但是，充当 Cloud Service Mesh 客户端的 gRPC 库仅获取您为其指定 xDS 解析器的服务的相关信息。默认情况下，Envoy 会获取在 Envoy 引导文件中指定的 Virtual Private Cloud (VPC) 网络上配置的所有服务的信息。

端点发现

服务发现可让客户端了解您的服务。端点发现则使客户端可以了解运行您代码的实例。

创建服务时，您还需要指定该服务的后端。这些后端是代管式实例组 (MIG) 中的虚拟机或 NEG 中的容器。Cloud Service Mesh 会监控这些 MIG 和 NEG， 知道何时创建和移除实例和端点。

Cloud Service Mesh 会持续分享关于这些服务的最新信息 为客户提供更多服务此信息可让客户端避免将流量发送到不再存在的端点。它还能让客户端了解新端点并利用这些端点提供的额外容量。

除了将端点添加到 MIG 或 NEG 并设置 Cloud Service Mesh 之外， 您无需进行任何其他配置即可通过 Cloud Service Mesh。

Cloud Service Mesh 中的 Sidecar 代理流量拦截

Cloud Service Mesh 支持 Sidecar 代理模型。在此模型下， 应用将流量发送到其目的地，流量会被拦截，并且 已将其重定向到应用所在主机边车代理上的端口 正在运行。Sidecar 代理决定如何对流量进行负载平衡，然后将流量发送到其目标。

借助 Cloud Service Mesh 和服务路由 API，系统会自动管理流量拦截。

后续步骤