API 101 专栏 · 第 74

Apigee:面向现代架构的 API 管理平台

2025年12月29日
Apigee:面向现代架构的 API 管理平台

关键要点

  • 集中式控制与解耦:Apigee 的 API 代理模型提供了一个外观,将客户端应用程序与后端服务解耦,实现独立的扩展、安全性和现代化工作。
  • 全生命周期管理:该平台为 API 设计、安全、部署、分析和货币化提供了一套全面的套件,将 API 视为受管理的产品。
  • 开发者优先的生态系统:开发者门户、基于策略的安全性和详细的分析等集成工具为 API 生产者和消费者都营造了一个高效的环境。
  • 企业级弹性:结构化故障处理、响应缓存和混合部署选项等功能确保 API 是健壮、高性能且能适应复杂基础设施需求的。

简介:什么是 Apigee?

在当今互联互通的数字环境中,API 是应用程序通信的基本构建块。有效管理这些 API——确保它们安全、可靠、可观察且易于消费——是一个关键挑战。这就是像 Google 的 Apigee 这样的全生命周期 API 管理平台 变得不可或缺的地方。

Apigee 不仅仅是一个网关;它是整个 API 生态系统的综合控制平面。其架构核心在于 API 代理,一个位于后端服务(无论是现代微服务、遗留单体应用还是数据库)和调用它们的客户端应用程序之间的外观。这种抽象是强大的。它将公共 API 契约与私有后端实现解耦,允许团队更改、扩展或保护后端服务,而不会中断依赖它们的消费者。

该平台为 API 生命周期的每个阶段提供工具:从设计和开发到 安全执行、分析和 货币化。支持包括 RESTgRPCGraphQL 在内的架构风格,Apigee 专为现代企业环境的异构性而设计,提供完全托管(Apigee)和客户管理运行时(Apigee 混合)部署模型。对于被行业分析师认定为领导者的组织,Apigee 是数字化转型的战略基础,使他们能够在 Google 所说的"99.99% 可靠性"下大规模运营,即使在黑色星期五等事件期间也是如此。

1flowchart TD
2    subgraph Client_Layer [客户端层]
3        A[移动应用]
4        B[Web 应用]
5        C[合作伙伴服务]
6    end
7
8    A --> G[Apigee API 网关]
9    B --> G
10    C --> G
11
12    G --> H{策略执行<br/>安全、调解、路由}
13
14    H --> I[分析和监控引擎]
15    I --> J[开发者门户]
16
17    H --> K[微服务 1]
18    H --> L[微服务 2]
19    H --> M[遗留系统]
20    H --> N[云服务 / SaaS]
21
22    subgraph Backend_Layer [后端服务层]
23        K
24        L
25        M
26        N
27    end

为什么选择 Apigee?现代 API 管理的战略必要性

采用 API 管理平台是由具体的业务和技术挑战驱动的战略决策。Apigee 解决了 API 生产者(构建和维护 API 的团队)和 API 消费者(使用它们构建应用程序的开发者)的核心痛点。

对于 生产者 来说,关键挑战包括在 Internet 上保护暴露的服务、执行一致的治理和使用策略、获得 API 性能和消费者行为的可见性,以及实现更快的开发者入职。对于 消费者 来说,障碍是查找和理解可用的 API、处理不可靠的后端以及应对不一致的认证方法。Apigee 通过提供一个 统一的、以产品为中心的平台 来弥补这一差距,该平台管理从代码到消费的 API。

战略利益是多方面的:

  • 加速数字化转型与现代化:API 代理层充当缓冲区,允许组织 逐步现代化遗留后端系统 而不会破坏现有集成。团队可以在代理背后将单体应用重构为微服务,向外界呈现一个稳定、一致的界面。这种解耦对于采用敏捷开发实践和加速新数字服务的上市时间至关重要。
  • 统一的安全与治理:Apigee 在边缘巩固了关键的安全功能。它为认证(API 密钥、OAuth 2.0、JWT)、授权、威胁保护(例如,抵御 JSON/XML 威胁和 SQL 注入)和配额管理提供开箱即用的策略。这种集中控制比在每个单独的后端服务中实现这些功能要高效和安全得多。
  • 可扩展性与生态系统发展:Apigee 专为大规模设计,每年处理数千亿次调用。其集成的 开发者门户 是构建生态系统的关键工具。它提供自助式 API 发现、交互式文档和自动密钥生成,大大降低了开发者消费 API 的摩擦并促进创新。
  • 全面的可见性与洞察:你无法管理你无法衡量的东西。Apigee 分析收集整个 API 链的细粒度数据——从客户端应用程序和代理性能一直到后端延迟。这种可见性对于故障排除(识别缓慢的微服务)、业务规划(查看哪些 API 产品最受欢迎)和运营完整性(管理配额合规性和检测异常)至关重要。

如何实现价值:API 代理设计和开发的最佳实践

要充分利用 Apigee 的能力,深思熟虑的 API 代理设计方法至关重要。以下最佳实践来自真实世界的实现,将帮助你构建安全、高性能且可维护的代理。

1. 基础设计与开发标准

从一个清晰、一致的基础开始。采用"框架式"编码:创建可重用的模块化策略配置(例如,一个专用的 AssignMessage 策略用于设置 CORS 请求头)并将它们存储在源代码控制中。这促进了 DRY(不要重复自己)原则 并确保不同 API 代理之间的一致性。

命名约定和文档 对于长期可维护性至关重要。为策略和资源使用清晰、描述性的名称。例如,为 AssignMessage 策略添加前缀 AM-,如 AM-SetCORSHeaders。在你的 ProxyEndpointTargetEndpoint 配置中提供内联注释来解释逻辑,特别是当策略名称本身不足时。

至关重要的是,尽可能利用 Apigee 策略而非自定义代码。用于消息操作、安全和流量管理的内置策略是加固的、优化的且有支持的。仅当无法通过策略表达的复杂逻辑时才使用 JavaScript、Java 或 Python 调用。当需要自定义代码时,JavaScript 通常在灵活性和性能之间取得平衡。

2. 关键技术设计考量

  • 使用 TargetServers 解耦配置:绝不要在 TargetEndpoint 中硬编码后端 URL。相反,使用 TargetServer 配置。这允许你通过简单地指向不同的 TargetServer,在开发、预发布和生产环境中推广相同的 API 代理修订版,从而促进干净的 CI/CD 流水线。
  • 实现稳健的故障处理:绝不要让 Apigee 向客户端应用程序返回原始的系统生成故障。始终使用 FaultRules 部分来捕获所有错误。在 FaultRules 中,使用 AssignMessage 策略(而非 RaiseFault)来制作一致的、用户友好的错误响应,并根据你的组织标准进行格式化。始终包含一个默认的"包罗万象"故障规则。
  • 深思熟虑地管理消息大小:默认情况下,Apigee 将消息载荷限制为 10MB 以防止内存问题。对于需要更大载荷(最高 30MB)的合法用例,你可以配置更高的限制。然而,建议将频繁处理大载荷的代理隔离在专用环境中,以防止它们影响其他 API 的性能——一种"吵闹的邻居"场景。
  • 尽早设计 CORS:如果你的 API 将从 Web 浏览器调用,你必须启用 跨域资源共享(CORS)。在 ProxyEndpoint 的请求 PreFlow 中添加 CORS 策略,以避免以后出现问题。

3. 高效利用持久化:缓存和 KVM

智能缓存是提高 API 性能和减少后端负载的最有效方法之一。

  • 战略性缓存:仅缓存成功的 GET 响应。使用 <SkipCachePopulation> 元素来有条件地避免用错误响应或非 GET 结果填充缓存。
  • 优化缓存键:缓存键必须足够独特以区分请求,但也不要过于具体。通常,包含 request.querystring 就足够了。避免在缓存键中包含 API 密钥(client_id,除非响应确实是每个用户独有的,因为这可能导致存储冗余数据并破坏缓存的目的。
  • 缓存中介数据:将响应缓存填充策略放置在响应的 PostFlow 中,中介策略(如 JSON 到 XML 转换)之后。这会存储最终的、已处理的响应,在每个缓存命中时节省中介成本。
  • 适当地使用键值映射(KVM):KVM 可用于存储配置数据,如功能标志或环境变量。然而,请记住它们 不是长期数据存储,并由数据库支持。将它们用于有限的、小型数据集以避免性能影响。

4. 部署、分析和迭代

Apigee 中的部署是基于修订版的。每次更改都会创建一个可以独立部署或回滚的不可变修订版。你可以通过 UI、Apigee API 或 gcloud CLI 进行部署。为了安全部署,特别是在跨环境推广时,使用 API 的 generateDeployChangeReport 方法来检测潜在的冲突,例如基本路径重叠,然后再进行部署。

部署后,分析是你优化的指南。Apigee 的指标 API 允许你以编程方式检索性能数据,以构建自定义仪表板或自动化检查。你可以查询关键指标,如:

  • 总流量的 sum(message_count)
  • 用于隔离客户端与后端延迟的 avg(total_response_time)avg(target_response_time)
  • apiproxy 分组的 sum(policy_error) 以识别有问题的 API。

这些洞察使你能够从猜测转向数据驱动的决策,迭代地改进你的 API 性能、可靠性和开发者满意度。

1sequenceDiagram
2    participant C as 客户端
3    participant P as Apigee 代理
4    participant B as 后端服务
5    participant A as 分析引擎
6
7    C->>P: API 请求
8    Note over P: 请求 PreFlow:<br/>- 验证 API 密钥<br/>- 检查缓存(缓存查找)
9    alt 缓存命中
10        P-->>C: 返回缓存响应
11    else 缓存未命中
12        P->>B: 转发请求
13        B-->>P: 后端响应
14        Note over P: 响应 PostFlow:<br/>- 转换数据<br/>- 填充缓存
15        P-->>C: 返回中介响应
16    end
17    Note over P, A: 异步发送<br/>分析数据
18    P->>A: 记录指标(延迟、<br/>错误、流量)

结论

实施 Google Apigee API 管理平台是对架构敏捷性和数字产品成熟度的战略投资。它将 API 从简单的技术端点提升为受管理、可扩展且安全的产品,从而驱动业务价值。通过掌握其核心概念——特别是 API 代理的解耦能力 和全面的 策略驱动管理模型——技术团队可以释放显著的优势。

微信咨询

获取方案