Endpoints 是一个由多种服务、运行时环境和工具组成的分布式 API 管理系统，可提供管理、监控和身份验证功能。
Endpoints 包含以下组件：
Extensible Service Proxy (ESP) 或 Extensible Service Proxy V2 (ESPv2) - 用于引入 Endpoints 功能。
Service Control - 用于应用 API 管理规则。
Service Management - 用于配置 API 管理规则。
Google Cloud CLI - 用于进行部署和管理。
Google Cloud 控制台 - 用于日志记录、监控和共享。
Endpoints 架构
Endpoints 组件
ESP
ESP 是一种基于 NGINX 的代理，它在后端的前面运行，并引入身份验证、监控和日志记录等 Endpoints 功能。ESP 会从 Service Management 中检索服务配置，并使用该配置来验证传入的请求。
ESP 可以部署在容器化环境中，用于验证 JWT 和 Google ID 令牌。它利用频繁缓存和异步调用等多种方法来确保轻量级和高性能。
ESP 支持适用于以下平台：
ESPv2
ESPv2 是一种基于 Envoy 的可扩缩高性能代理，它在 OpenAPI 或 gRPC API 后端的前面运行。使用 ESPv2 的 Endpoints 支持 OpenAPI 规范和 gRPC 规范的第 2 版。
ESPv2 与 Google Service Infrastructure 集成，可大规模实现 API 管理功能，包括身份验证、遥测报告、指标和安全。
ESPv2 支持适用于以下平台：Service Control
Service Control 会在运行时应用 API 管理规则，例如密钥身份验证、监控和日志记录。Service Control 提供以下方法：
检查 - 核查身份验证和 API 密钥，并指示是否应允许调用
报告 - 将日志记录和监控记录报告给系统
Service Management
您需要在 YAML 文件（称为 Endpoints 配置）中描述 gRPC 服务的行为。将 Endpoints 配置和已编译的.proto 文件，
使用 gcloud CLI
用于配置 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 控制台 Google CloudEndpoints 使用 Google Cloud 控制台，以便公开从 Google Cloud 控制台发送的监控和日志记录数据 ESP 或 ESPv2，由 Service Control 记录并与其他 API 共享 API 以及生成 API 密钥以调用 API。
部署场景
部署选项取决于将 ESP 或 ESPv2 用作 Endpoints 代理的方式。ESPv2 可部署为远程代理，ESPv2 和 ESP 均可部署为 Sidecar 模式，如以下部分所述。
远程代理模式
如果使用 ESPv2，则可将 Endpoints 部署为远程代理。此模式用于支持在无服务器平台（例如适用于标准环境的 Cloud Run、Cloud Run Functions 和 App Engine）上运行的应用。
在此模式下，ESPv2 部署为 Cloud Run 应用。您使用 OpenAPI 服务配置中的 x-google-backend 字段将该应用配置为将 ESPv2 用作远程后端。在此部署模式下用作远程代理时，单个 ESPv2 可以支持多个远程后端。
Sidecar 模式
ESP 和 ESPv2 均支持与后端的每个实例一起部署到容器中。这种服务器-本地拓扑结构非常适合面向 Web 的 API 以及微服务。它不但可以避免通常与集中式代理关联的网络跃点，而且还可让 API 管理功能保持出色的性能和可扩缩性。
通常情况下，流量在到达 ESP 或 ESPv2 之前已经过负载平衡。在 Compute Engine 上，负载平衡通过 Cloud Load Balancing 实现。对于 Kubernetes 部署，您可以使用入站代理实现负载平衡。在 Google Kubernetes Engine 中，您可以使用 Cloud Load Balancing 或入站代理实现负载平衡。
ESP 或 ESPv2 启动时会从 Service Management 中获取其服务配置。该服务配置是根据 OpenAPI 规范或 gRPC（服务配置 YAML 文件）生成的，它会告知 ESP 或 ESPv2 需管理的 API 的表面以及相关政策，例如哪些方法要求进行身份验证，哪些方法要求使用 API 密钥。
请求路由
ESP 或 ESPv2 收到请求后会为 Cloud Trace 创建跟踪令牌。
接下来，ESP 或 ESPv2 会将传入请求的路径与 API 的表面进行匹配。找到匹配路由后，ESP 或 ESPv2 会为指定的方法执行必要的身份验证步骤。
如果需要进行 JWT 验证，ESP 或 ESPv2 会使用相应的签名者公钥核查身份验证，并验证 JWT 中的目标对象字段。如果需要 API 密钥，ESP 或 ESPv2 会调用 Service Control API 来验证密钥。
Service Control 会查找密钥以对其进行验证，并确保与密钥关联的项目已启用 API。如果密钥无效或项目未启用 API，则调用会被拒绝并且 Service Control API 会记录该调用。
如果 Service Control 成功验证密钥，则请求将与所有原始标头和一个 JWT 验证标头（如果适用）一起转发到后端。
从后端收到响应后，ESP 或 ESPv2 会将该响应返回给调用者，并将最终的耗时信息发送到 Trace。Service Control API 会记录这些调用点，并将指标和日志写入其相应的目标。
Kubernetes 上的 ESP 或 ESPv2
下图显示了 ESP 作为 Sidecar 容器在 API 服务应用容器前运行的整体架构，其中 my-api API 托管在 my-api.com 中并由一项 Kubernetes 服务提供支持。 使用 ESPv2 的 Sidecar 部署的架构与此相同。
