服务发现

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

Cloud Service Mesh 会监控这些服务，以便与其客户端共享最新的健康检查信息。因此，当您的某个应用使用其 Cloud Service Mesh 客户端（例如 Envoy 边车代理或无代理 gRPC 应用）发送请求时，它可以利用关于您服务的最新信息。

在 Cloud Service Mesh 环境中，客户端是在虚拟机或容器上运行的应用代码，它编制发送到服务器的请求。服务器是接收此类请求的应用代码。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 客户端处理与规则匹配的请求时，它可以选择应接收请求的服务。

例如：

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

使用此配置时，如果您的应用（在虚拟机上）向 payments.example.com 发送 HTTP 请求，则 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 代理决定如何对流量进行负载平衡，然后将流量发送到其目标。

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

后续步骤