Service Control 会在运行时应用 API 管理规则，例如密钥身份验证、监控和日志记录。Service Control 提供以下方法：
检查 - 核查身份验证和 API 密钥，并指示是否应允许调用
报告 - 将日志记录和监控记录报告给系统
服务管理
您可以使用 OpenAPI 规范在称为 Endpoints 配置的文本文件中描述 API 的表面和行为。您可以使用 gcloud CLI 将 Endpoints 配置部署到 Service Management，Service Management 用于配置 API 管理规则。其他与配置相关的任务也在此处进行，例如与其他开发者共享 API、在不同项目中启用或停用 API 以及生成 API 密钥。
gcloud CLI
gcloud CLI 提供可用于调用各种 Google Cloud 服务的 Google Cloud CLI。您可以使用 Google Cloud CLI 将 Endpoints 配置部署到 Service Management。
Google Cloud 控制台
Google Cloud 控制台是Google Cloud的图形界面。Endpoints 使用Google Cloud 控制台显示从 ESP 或 ESPv2 发送并由 Service Control 记录的监控和日志记录数据，与其他开发者共享 API，并且其他开发者可以使用控制台生成 API 密钥以调用 API。
[[["易于理解","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-04。"],[[["\u003cp\u003eEndpoints is a distributed API management system that provides management, monitoring, and authentication for APIs using services, runtimes, and tools.\u003c/p\u003e\n"],["\u003cp\u003eEndpoints utilizes either Extensible Service Proxy (ESP) or Extensible Service Proxy V2 (ESPv2) to inject functionality, manage API rules, and validate incoming requests.\u003c/p\u003e\n"],["\u003cp\u003eService Control applies API management rules at runtime, verifying authentication, API keys, and handling logging and monitoring.\u003c/p\u003e\n"],["\u003cp\u003eService Management allows you to define the API's surface and behavior using the OpenAPI specification, and is used for deployment of API management rules via the gcloud CLI.\u003c/p\u003e\n"],["\u003cp\u003eESP/ESPv2 can be deployed in either remote proxy mode, supporting serverless platforms, or sidecar mode alongside the backend, offering high performance and scalability.\u003c/p\u003e\n"]]],[],null,["# Architectural overview of Cloud Endpoints\n\nOpenAPI \\| [gRPC](/endpoints/docs/grpc/architecture-overview \"View this page for the Cloud Endpoints gRPC docs\")\n\n\u003cbr /\u003e\n\nEndpoints is a distributed API management system comprising\nservices, runtimes, and tools. Endpoints provides management,\nmonitoring, and authentication.\n\nThe components that make up Endpoints are:\n\n- Extensible Service Proxy (ESP) or Extensible Service Proxy V2 (ESPv2) - for injecting Endpoints\n functionality.\n\n- Service Control - for applying API management rules.\n\n- Service Management - for configuring API management rules.\n\n- Google Cloud CLI - for deploying and management.\n\n- Google Cloud console - for logging, monitoring and sharing.\n\nEndpoints architecture\n----------------------\n\n\u003cbr /\u003e\n\n\n\u003cbr /\u003e\n\nEndpoints components\n--------------------\n\n### ESP\n\nESP is a NGINX-based proxy that runs in front of the\nbackend and injects Endpoints functionality such as\nauthentication, monitoring, and logging. ESP retrieves a service\nconfiguration from Service Management and uses it to validate incoming\nrequests.\n\nESP is designed for you to deploy it in a containerized\nenvironment and validate JWTs and Google ID tokens. It employs a variety of\ntechniques, such as heavy caching and asynchronous calls to remain lightweight\nand highly performant.\n\nESP support is available for the following platforms:\n\n- [App Engine flexible environment](/endpoints/docs/openapi/set-up-app-engine-standard-environment-espv2)\n- [Compute Engine](/endpoints/docs/openapi/get-started-compute-engine-docker-espv2)\n- [Google Kubernetes Engine](/endpoints/docs/openapi/get-started-kubernetes-engine-espv2)\n- [Kubernetes](/endpoints/docs/openapi/get-started-kubernetes-espv2)\n\n### ESPv2\n\nESPv2 is an [Envoy](https://www.envoyproxy.io/docs/envoy/latest/)-based\nhigh-performance, scalable proxy that runs in front of an OpenAPI or gRPC API backend.\nEndpoints on ESPv2 supports version 2 of the\n[OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) and gRPC specifications.\n\nESPv2 integrates with Google Service Infrastructure to enable API management features\nat scale, including authentication, telemetry reports, metrics, and security.\n[ESPv2](/endpoints/docs/openapi/glossary#extensible_service_proxy_v2) support is available for the following platforms:\n\n- [App Engine Standard environment](/endpoints/docs/openapi/set-up-app-engine-standard-environment-espv2)\n- [Cloud Run functions](/endpoints/docs/openapi/set-up-cloud-functions-espv2)\n- [Cloud Run](/endpoints/docs/openapi/set-up-cloud-run-espv2)\n- [Knative serving](/endpoints/docs/openapi/set-up-cloud-run-anthos-espv2)\n- [Compute Engine](/endpoints/docs/openapi/get-started-compute-engine-docker-espv2)\n- [Google Kubernetes Engine](/endpoints/docs/openapi/get-started-kubernetes-engine-espv2)\n- [Kubernetes](/endpoints/docs/openapi/get-started-kubernetes-espv2)\n\n### Service Control\n\n[Service Control](/service-control) applies API management rules at\nruntime, such as key authentication, monitoring, and logging.\nService Control provides the following methods:\n\n- Check - verifies authentication and API keys, and indicates whether a call\n should be permitted\n\n- Report - notifies the systems of record for logging and monitoring\n\n### Service Management\n\nYou use the [OpenAPI specification](/endpoints/docs/openapi/openapi-overview) to describe the surface and the behavior of your API in a text file referred to as the Endpoints configuration. You deploy the Endpoints configuration to Service Management by using the gcloud CLI, which configures the API management rules. Other configuration related tasks also happen here, such as sharing your API with other developers, enabling or disabling the API in different projects, and generating API keys.\n\n\u003cbr /\u003e\n\n### The gcloud CLI\n\n[The gcloud CLI](/sdk) provides the Google Cloud CLI that you\ncan use to make calls to various Google Cloud services. You use the\nGoogle Cloud CLI to deploy your Endpoints\nconfiguration to Service Management.\n\n### Google Cloud console\n\n[Google Cloud console](/cloud-console) is the graphical user interface for\nGoogle Cloud. Endpoints uses the\nGoogle Cloud console to expose monitoring and logging data that are sent from\nESP or ESPv2 and recorded by Service Control and share APIs with other\ndevelopers, and for them to generate API keys to call the API.\n\nDeployment scenarios\n--------------------\n\nOptions for deployment vary depending upon the use of ESP or ESPv2 as the Endpoints proxy. ESPv2 can be deployed as a remote proxy and both ESPv2 and ESP can be deployed in sidecar mode, as explained in the following sections.\n\n### Remote proxy mode\n\nIf using ESPv2, Endpoints can be deployed as a remote proxy. This mode is used to support applications running on serverless platforms such as Cloud Run, Cloud Run functions, and App Engine for standard environments.\n\nIn this mode, ESPv2 is deployed as a Cloud Run application. The application is configured to use ESPv2 as a remote backend using the `x-google-backend` field in the OpenAPI service config. When functioning as a remote proxy in this deployment mode, a single ESPv2 can support multiple remote backends.\nSee [Configuring Endpoints](/endpoints/docs/openapi/get-started-cloud-run#endpoints_configure) for more details.\n\n### Sidecar mode\n\nBoth ESP and ESPv2 support deployment in a container alongside each instance of your backend. This server-local topology is ideal for both\nweb-facing APIs as well as microservices. It avoids the network hop typically\nassociated with centralized proxies and allows API management that is highly\nperformant as well as scalable.\n\nTypically, load balancing is applied before traffic hits ESP or ESPv2.\n\nOn App Engine, load balancing happens automatically.\n\nOn Compute Engine, it is accomplished by Cloud Load Balancing. For\nKubernetes deployments, you can use an ingress proxy for load balancing. In\nGoogle Kubernetes Engine, you can use either Cloud Load Balancing or an ingress\nproxy for load balancing.\n\nUpon startup, ESP or ESPv2 obtains its service configuration from\nService Management. The service configuration is generated from the\nOpenAPI specification or from\n[gRPC](http://www.grpc.io/),\nthe service configuration YAML file. It tells ESP or ESPv2 both the\nsurface of the API to be managed along with the policies, such as\nwhich methods require authentication, and which require API keys.\n\nRequest routing\n---------------\n\nWhen a request is received, ESP or ESPv2 creates a trace token for\nCloud Trace.\n\nNext, ESP or ESPv2 matches the path of the incoming requests with the\nsurface of the API. After finding a matching route, ESP or ESPv2 performs\nany authentication steps for the specified method.\n\nIf JWT validation is necessary, ESP or ESPv2 validates the authentication\nusing the appropriate public key for the signer, and validates the audience\nfield in the JWT. If an API key is required, ESP or ESPv2 calls the\nService Control API to validate the key.\n\nService Control looks up the key to validate it, and ensures that the\nproject associated with the key has enabled the API. If the key isn't valid or\nthe project hasn't enabled the API, the call is rejected and it is logged via\nthe Service Control API.\n\nIf Service Control successfully validates the key, the request along with\nall original headers, plus a JWT validation header, if appropriate, is forwarded\nto the backend.\n\nWhen a response is received from the backend, ESP or ESPv2 returns the\nresponse to the caller and sends the final timing information to\nTrace. The call points are logged by the Service Control\nAPI, which writes metrics and logs to their appropriate destinations.\n\nESP or ESPv2 on Kubernetes\n--------------------------\n\nThe following diagram shows the overall architecture where ESP\nruns as a side-car container in front of the API service application\ncontainer, with `my-api` API hosted at `my-api.com` and backed by a\n[Kubernetes service](http://kubernetes.io/docs/user-guide/services/). The architecture would be the same for a sidecar deployment with ESPv2.\n\nWhat's next\n-----------\n\n- [About Endpoints](/endpoints/docs/openapi/about-cloud-endpoints)\n- [Cloud Endpoints for OpenAPI](/endpoints/docs/openapi)"]]
