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 服务的行为。您可以使用 gcloud CLI 将 Endpoints 配置和已编译的.proto 文件部署到配置 API 管理规则的 Service Management。
其他与配置相关的任务也在此处进行，例如与其他开发者共享 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，并且其他开发者可以使用 Google Cloud 控制台生成 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 部署的架构与此相同。
