Cloud Service Mesh 提供了服务发现功能。配置 Cloud Service Mesh 时，您可以创建后端服务。您还可以定义路由规则，以指定出站请求（您的应用代码发送并由 Cloud Service Mesh 客户端处理的请求）与特定服务的匹配方式。当 Cloud Service Mesh 客户端处理与规则匹配的请求时，它可以选择应接收请求的服务。
例如：
您有一个运行应用的虚拟机。该虚拟机配有连接到 Cloud Service Mesh 的 Envoy 边车代理，并代表应用处理出站请求。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-03。"],[],[],null,["# Service discovery\n=================\n\nCloud Service Mesh provides service and endpoint discovery. These features\nlet you group the virtual machine (VM) instances and container instances that\nrun your code as *endpoints* of your services.\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/v1.25/docs/overview).\n\nCloud Service Mesh monitors these services so that it can share\nup-to-date [health check](/load-balancing/docs/health-check-concepts) information\nwith its clients. Therefore, when one of your applications uses its\nCloud Service Mesh client (such as an Envoy sidecar proxy or a\nproxyless gRPC application) to send a request, it benefits from up-to-date\ninformation about your services.\n\nIn the context of Cloud Service Mesh, a *client* is application code\nthat runs on a VM or container that formulates requests to send to a server. A\n*server* is application code that receives such requests.\nA *Cloud Service Mesh client* is an Envoy or gRPC or other xDS client\nthat is connected to Cloud Service Mesh and is part of the data plane.\n\nIn the data plane, Envoy or gRPC does the following:\n\n1. It examines a request and matches the request to a *backend service*, a resource that you configure during deployment.\n2. After the request is matched, Envoy or gRPC applies any previously configured traffic or security policies, chooses a backend or endpoint, and directs the request to that backend or endpoint.\n\nService discovery\n-----------------\n\nCloud Service Mesh provides service discovery. When you configure\nCloud Service Mesh, you create backend services. You also define routing rules\nthat specify how an *outbound request* (a request sent by your application code\nand handled by a Cloud Service Mesh client) is matched to a particular service.\nWhen a Cloud Service Mesh client handles a request that matches a rule, it can\nchoose the service that should receive the request.\n\nFor example:\n\n- You have a VM running your application. This VM has an Envoy sidecar proxy that is connected to Cloud Service Mesh and handles outbound requests on behalf of the application.\n- You configured a backend service named `payments`. This backend service has two network endpoint group (NEG) backends that point to various container instances that run the code for your `payments` service.\n- You configured a `Mesh` resource defining a mesh called `sidecar-mesh`.\n- You configured a `Route` resource that defines traffic destinations for the backend service `payments` and the hostname `helloworld-gce`.\n\nWith this configuration, when your application (on the VM) sends an HTTP request\nto `payments.example.com`, the Cloud Service Mesh client knows that\nthis request is destined for the `payments` service.\n\nWhen you use Cloud Service Mesh with proxyless gRPC services, service discovery\nworks similarly. However, a gRPC library acting as a Cloud Service Mesh client\nonly gets information about the services for which you specify an xDS resolver.\nBy default, Envoy gets information about all services configured on the\nVirtual Private Cloud (VPC) network specified in the Envoy bootstrap file.\n\nEndpoint discovery\n------------------\n\nService discovery enables clients to know about your services. Endpoint\ndiscovery enables clients to know about the instances that are running your\ncode.\n\nWhen you create a service, you also specify the backends for that\nservice. These backends are either VMs in managed instance groups (MIGs) or\ncontainers in NEGs. Cloud Service Mesh monitors these MIGs and NEGs so that it\nknows when instances and endpoints are created and removed.\n\nCloud Service Mesh continuously shares up-to-date information about these\nservices with its clients. This information enables clients to avoid sending\ntraffic to endpoints that no longer exist. It also enables clients to learn\nabout new endpoints and take advantage of the additional capacity\nthat these endpoints provide.\n\nBeyond adding endpoints into MIGs or NEGs and setting up Cloud Service Mesh,\nyou don't need any additional configuration to enable service discovery with\nCloud Service Mesh.\n\nSidecar proxy traffic interception in Cloud Service Mesh\n--------------------------------------------------------\n\nCloud Service Mesh supports the sidecar proxy model. Under this model, when an\napplication sends traffic to its destination, the traffic is intercepted and\nredirected it to a port on the sidecar proxy on the host where the application\nis running. The sidecar proxy decides how to load balance the traffic, and then\nsends the traffic to its destination.\n\nWith Cloud Service Mesh and the service routing APIs, traffic interception is\nmanaged automatically.\n\nWhat's next\n-----------\n\n- To learn how Cloud Service Mesh delivers global load balancing for your internal microservices with sidecar proxies, see [Cloud Service Mesh load balancing](/service-mesh/v1.25/docs/service-routing/load-balancing).\n- To learn more about Cloud Service Mesh, see the [Cloud Service Mesh overview](/service-mesh/v1.25/docs/overview)."]]
