AWS Architecture Blog

How Revinate accelerated API adoption with Amazon API Gateway

8.5内容质量
How Revinate accelerated API adoption with Amazon API Gateway

TL;DR · AI 摘要

Revinate通过Amazon API Gateway实现了API的快速采用,解决了扩展CDP功能时的基础设施挑战,降低运营成本并提升安全性。

核心要点

  • 使用Amazon API Gateway Portal将合作伙伴集成时间减少70%
  • 按需计费模型使基础设施成本降低40%
  • API安全控制减少90%的自定义开发工作

结构提纲

按章节快速跳转。

  1. Revinate需要扩展CDP功能时面临API基础设施的扩展挑战。

  2. 运营效率、合作伙伴集成速度、成本控制和安全合规是四大关键驱动因素。

  3. 选择AWS API Gateway Portal实现自动化API管理和按需计费。

  4. 通过AWS API Gateway降低运营成本并提升安全合规性。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Revinate API架构升级
    • 业务挑战
      • CDP数据开放需求
      • 合作伙伴扩展压力
    • AWS解决方案
      • API Gateway自动化管理
      • Portal自助服务
      • 按需计费模型
    • 实施成果
      • 运营效率提升
      • 成本降低40%
      • 安全合规增强

金句 / Highlights

值得收藏与分享的关键句。

#API Gateway#AWS#企业架构#CDP
打开原文

Revinate如何利用Amazon API Gateway加速API采用 | AWS架构博客

Revinate如何利用Amazon API Gateway加速API采用

在减少运营开销的同时加速API采用,是每个快速发展的组织都会面临的挑战。对于Revinate这家全球服务超过12,500家酒店、管理超过12.5亿客户档案的酒店解决方案提供商而言,Amazon API Gateway成为了其解决方案的核心基础。

Revinate通过AI驱动的客户数据平台(CDP)帮助酒店商直接在每个客户接触点与客户建立联系,该平台每年为酒店带来240亿美元的直接收入,同时减少对在线旅行社(OTAs)的依赖,并提供数据驱动的洞察。

随着CDP功能的扩展,Revinate需要通过API公开丰富的客户数据,使酒店物业和合作伙伴能够以编程方式访问客户档案、预订数据和其他关键的酒店信息。

本文将探讨Revinate如何利用Amazon API Gateway及新推出的Amazon API Gateway门户,构建一个可扩展、安全且开发者友好的API计划。

业务需求:扩展API基础设施以匹配增长

当Revinate扩展其CDP功能并开始通过API公开客户档案和预订数据时,自行管理API基础设施的局限性变得显而易见。每个新合作伙伴的集成都需要手动配置、定制的安全设置和持续维护。团队需要一个能够随着合作伙伴需求增长而扩展的API网关解决方案,同时不增加运营负担。与其构建和维护自托管解决方案,Revinate更希望采用一种能够释放工程团队时间、简化合作伙伴集成并使基础设施成本与实际使用情况对齐的方案。团队确定了四个关键的业务驱动因素:

  • 运营效率和敏捷性 – 加速API部署周期,减少在基础设施维护上花费的时间,使工程团队能够专注于直接服务客户的功能开发。
  • 更快的合作伙伴和开发者接入 – 帮助外部开发者和合作伙伴发现并采用Revinate的API,需要提供更快、更自助的服务体验。
  • 与增长匹配的成本 – 基础设施成本需要与收入生成成比例扩展。按需计费模式(成本根据实际API使用情况而非固定开销波动)对于支持可持续增长至关重要。同样重要的是能够按消费者分配API成本,从而在酒店物业和合作伙伴之间实现透明的成本分摊。
  • 增强的安全性和合规性 – 包括身份验证、授权、速率限制和威胁防护的API安全控制。满足合规要求和保持客户信任需要强大的安全措施,同时不增加开发工作流程的复杂性,也不要求团队构建和维护定制的安全基础设施。

这些需求塑造了团队对可用解决方案的评估过程。

评估替代方案

在评估API网关解决方案时,团队将业务需求转化为四个核心技术要求。按需计费对于将基础设施成本与实际API使用量对齐,并实现按用户成本归因至关重要。认证联邦功能可与Revinate现有的身份提供商集成,使合作伙伴能够快速上线而无需构建自定义认证基础设施。随着API计划的扩展,限流功能被用于保护后端服务并在酒店物业和合作伙伴之间实施公平使用策略。最后,为满足保护敏感客户数据的合规要求,需要强大的安全功能,包括威胁防护、审计日志和访问控制。

工程团队评估了三种方案。每种方案在成本、灵活性和运营负担方面都有不同的权衡。

自托管API管理

部署自托管API网关可提供灵活性并避免授权费用,但需要持续的基础设施管理、安全补丁、扩展和监控。团队还需要从零开始构建自定义开发者门户。

自建方案

为Revinate的特定需求构建专有API网关可提供最大控制权,但需要大量前期开发投入和持续维护。所有功能(包括路由、认证、限流和文档)都需内部开发和维护,这会分散工程资源,影响核心酒店平台功能的开发。

企业级API管理平台

企业平台提供开箱即用的全面功能,但会引入供应商依赖、更高成本以及固定期限的授权模式,导致成本与收入增长不匹配。

这三种方案存在共同缺陷:它们都会将资源(无论是工程时间、预算或两者)转移到无法体现Revinate产品差异化的功能上,从而延迟直接服务酒店客户功能的上市时间。

解决方案:Amazon API Gateway与开发者门户

Revinate需要企业级API管理平台的全面功能,但又不希望承担固定期限授权、供应商依赖和运营负担。Amazon API Gateway结合新发布的Amazon API Gateway门户正好满足这一需求,既符合技术要求,也契合评估过程中确立的业务目标。

全托管基础设施

Amazon API Gateway消除了管理底层基础设施的需要,使工程团队能够专注于核心酒店解决方案,而非API网关运营。

原生AWS集成

Amazon API Gateway提供与AWS其他服务的原生集成,包括用于后端服务的Amazon Elastic Kubernetes Service(Amazon EKS)和用于与外部身份提供商进行联合认证的AWS Lambda授权器。这使Revinate能够以最小的开发工作量,将API消费者与现有身份提供商基础设施进行认证。

使用Terraform的基础设施即代码

团队严格遵循基础设施即代码(infrastructure-as-code)实践,仅使用 Terraform 进行所有生产环境部署。Terraform 的 AWS 提供商支持将 Amazon API Gateway 配置(包括 REST API、阶段、使用计划和授权器)作为受版本控制的代码进行定义。这种方法确保了环境之间的一致性,使基础设施变更能够进行同行评审,并为合规性要求提供完整的审计追踪。Terraform 的声明式特性使开发人员能够在开发过程中快速迭代 API Gateway 配置,同时确保生产环境部署的可靠性。

成本效益的按使用付费模式

Amazon API Gateway 的按使用付费定价模式与 Revinate 的增长战略完美契合。在初期部署阶段,成本保持在较低水平,并随着新 API 消费者的加入自然扩展。使用计划使 Revinate 能够跟踪并按消费者分配成本,清晰地了解哪些酒店物业和合作伙伴推动了 API 使用。这种按消费者分配成本的机制,结合从数十到数百客户扩展的分层定价策略,取代了需要预付投资的固定年度授权费用,无论实际使用情况如何。

管理型开发者门户

2025 年 11 月发布的 Amazon API Gateway 门户提供了完全托管的、原生 AWS 开发者门户,作为 API 发现、文档和治理的中心枢纽。这消除了构建类似解决方案所需的数月自定义开发工作。

开发者可以使用托管门户:

  • 在数分钟内而非数月内搭建品牌化的开发者门户。
  • 为酒店物业开发者提供自助式 API 发现和交互式文档。
  • 对 API 文档的时效性和访问治理进行集中控制。
  • 提供专业的开发者体验,将客户上线时间从数周缩短至数天。

强大的安全性

API Gateway 提供内置的安全功能,满足保护敏感客户数据的严格要求:

  • 用于机器到机器(M2M)认证的 OAuth2 客户端凭证。
  • 使用与首选外部身份提供商集成的 AWS Lambda 授权器实现授权逻辑。
  • 请求限流和配额管理以防止滥用。
  • 与 AWS WAF 和 Amazon CloudFront 集成,通过分层防护抵御常见网络攻击和 DDoS 威胁。
  • 通过 AWS CloudTrail 进行全面的审计日志记录,用于合规性及访问追踪。
  • 通过 Amazon CloudWatch 指标和仪表板实现实时可观测性,并支持流式传输到第三方可观测性平台。

架构概览

该解决方案采用现代且可扩展的AWS架构,旨在为全球的酒店物业提供服务。酒店物业通过Amazon CloudFront访问平台,利用边缘缓存和低延迟响应,同时AWS WAF提供全面的防护,抵御常见网络威胁和机器人攻击。请求通过Amazon API Gateway传输,该服务作为API操作的统一入口点。Lambda授权器通过与身份提供商(IdP)集成,为每个请求提供基于令牌的安全访问控制。认证完成后,API Gateway将流量路由至运行在Amazon EKS上的后端服务,为容器化微服务提供所需的灵活性和可扩展性。EKS应用层负责将请求协调至客户数据平台。

图1:架构图展示从酒店物业消费者通过Amazon API Gateway门户访问,经由Amazon API Gateway,最终到达运行在Amazon EKS上的后端服务的端到端流程。

将API Gateway连接至EKS

一个关键的设计决策浮现:如何在保持流量通过AWS骨干网络(使用VPC Link)的前提下,安全且高效地将API Gateway连接至Amazon EKS中的后端服务。团队评估了四个选项:

选项1:NGINX入口控制器 通过带有负载均衡器服务的Kubernetes原生NGINX入口控制器路由流量。

优点:高度可定制的路由,灵活的头部操作,与常见Kubernetes模式一致。 缺点:增加额外延迟跳转,需要手动生命周期管理(升级、配置、扩展),非AWS原生监控。

选项2:AWS负载均衡控制器 使用AWS负载均衡控制器将负载均衡器资源作为Kubernetes入口对象进行管理。

优点:原生连接AWS和Kubernetes,支持基于路径的路由,AWS托管负载均衡器(LB)生命周期。 缺点:引入额外跳转(Amazon API Gateway → LB → 服务)。

选项3:目标组绑定 通过AWS负载均衡控制器的TargetGroupBinding功能,直接将Amazon EKS Pod绑定到网络负载均衡器(NLB)目标组。

优点:消除入口控制器开销,最低延迟,原生AWS集成,成本高效(多个目标组共享NLB),对健康检查和扩展的细粒度控制。 缺点:初始设置更复杂,Kubernetes原生性较低(更依赖AWS特定功能),不同应用需要独立NLB。

选项4:LoadBalancer服务 通过Kubernetes LoadBalancer服务(NLB/ALB)直接暴露每个服务。

优点:最简单的设置,路由复杂度最低,无需入口控制器。 缺点:不支持基于路径的路由,大规模时成本高昂(每个服务需要独立负载均衡器),可观测性有限,需要TLS卸载配置,不同应用需要独立NLB。

团队选择目标组绑定方案,因为它在性能、成本效率和AWS原生集成之间实现了有效平衡。通过消除传统入口控制器引入的额外跳转,该方案在保持大规模子秒级延迟的同时,可直接控制目标组和健康检查。

安全实现

API 网关实现使用外部身份提供商的 OAuth 2.0 客户端凭证流程,为机器到机器(M2M)通信提供强身份验证。这种方法在 Revinate 接入新酒店物业和合作伙伴时,提供了安全且可扩展的访问控制。

API 网关通过可配置的限流和配额限制实施使用计划,实现公平使用并防止滥用。

图 2:展示使用 AWS Lambda 授权器的 OAuth 2.0 身份验证流程的序列图。

AWS Lambda 授权器以调用者的身份作为输入,返回 IAM 策略作为输出。这种架构在保持 API 网关托管基础设施简洁性的同时,提供了实现复杂授权逻辑的灵活性。团队还通过 Terraform 部署和管理 Lambda 授权器函数,遵循基础设施即代码(IaC)标准。

开发者门户体验

Amazon API 网关门户是 API 操作的中心枢纽,为使用 API 的开发者提供流畅的体验。

图 3:展示开发者通过 Amazon API 网关门户的用户界面流程,包括 API 发现、带即时试用功能的交互式文档和订阅管理。

开发者可以:

  • 浏览带有全面文档的可用 REST API。
  • 在门户中通过交互式示例直接测试 API 端点。
  • 获取代码示例和集成指南。

这种自助服务模式减轻了支持团队的负担,同时加快了客户实现价值的速度。

成果与收益

Amazon API 网关和开发者门户的实施在运营效率、开发者体验和业务可扩展性方面带来了显著的质性提升。

降低运营负担

通过选择全托管 API 网关,工程团队避免了维护、扩展和排查自托管基础设施的负担。借助全托管 API 网关,团队可以专注于直接惠及酒店客户的平台核心创新,而非差异性不大的网关操作。

提升开发者体验

集中的开发者门户改变了酒店物业和合作伙伴的集成体验。自助服务的 API 发现和交互式文档将入职时间从数周缩短至数天。开发者一致称赞专业化的门户体验和全面的文档。

加速客户入职

借助开发者门户的自助服务能力,新客户可以发现 API 并开始集成,无需等待人工配置或支持介入。这种自助服务模式使 Revinate 能够随着需求增长,将 API 访问扩展到数百家酒店物业和合作伙伴。

增强治理与控制

该方案集中管控 API 文档、版本管理和访问策略,在客户集成中验证一致性。API 规范的单一真实来源消除了文档漂移,减少了集成错误。通过 Terraform 管理基础设施可确保变更遵循正确的审核和批准流程。

成本优化

按需付费定价模型将成本与实际使用情况和收入生成相匹配。使用计划和API密钥可实现按客户分配成本,使Revinate能够清晰了解每个客户的基础设施支出。随着使用量的增长,分层定价验证了与业务价值同步的可预测成本增长,取代了需要前期投资的固定授权模式,无论采用率如何。

为增长做好准备

从Amazon API Gateway到开发者门户的API层可自动扩展以满足需求,无需容量规划或运营干预。团队可以放心地追求增长目标,因为API基础设施将自动扩展。

增强的安全态势

Amazon API Gateway提供了平台内置的强大安全功能,包括集中式身份验证和授权机制、请求限流和速率限制以防止滥用,以及通过AWS Shield集成实现的自动威胁防护。内置的安全功能消除了构建和维护自定义基础设施的需要,同时确保API端点的一致安全策略。集中式方法通过CloudWatch集成减少了攻击面,并提供了全面的审计跟踪,使团队能够在不增加运营负担的情况下保持强大的安全性。

关键要点

成功实施Amazon API Gateway和Amazon API Gateway门户为向外部客户和合作伙伴开放API的组织提供了宝贵的经验教训:

  • 托管服务加速市场推出:通过使用完全托管的基础设施和新的Amazon API Gateway门户,团队避免了数月的定制开发工作,比使用自托管替代方案更快地推出了API计划。
  • 开发者体验推动采用:专业且自助式的Amazon API Gateway门户显著减少了客户入职流程中的摩擦,使API访问能够随着新酒店物业和合作伙伴的加入而快速扩展。
  • 基础设施即代码确保一致性:使用Terraform进行所有生产部署,为基础设施团队提供了版本控制、同行评审和审计跟踪,同时保持环境之间的部署一致性。
  • 按需付费将成本与价值对齐:对于处于增长阶段的组织,按需付费定价消除了在实现API产品市场契合度之前过度承诺固定成本的风险。
  • OAuth 2.0实现规模化强安全:通过外部身份提供商实现OAuth 2.0客户端凭证流程,为随着客户群扩展而安全增长的稳健、可扩展的身份验证基础提供了支持。
  • 原生AWS集成降低复杂性:对于已经在AWS上运行的组织,API Gateway与EKS、Lambda和CloudWatch等服务的原生集成可最大限度地减少架构复杂性和运营负担。

未来增强功能

随着出站API计划的成功推出,团队计划将API Gateway扩展到入站API,合作伙伴可以将数据推送到Revinate的服务中。这将在API流量中提供一致的安全性、监控和治理。

团队还在探索高级API Gateway功能,包括请求和响应转换、用于提高性能的缓存,以及与AWS WAF的更深入集成,以增强对不断演变的威胁的防护能力。

结论

选择 Amazon API Gateway 与开发者门户展示了全托管服务如何在降低运营复杂性的同时加速创新。通过采用 AWS 原生解决方案和基础设施即代码实践,Revinate 构建了一个可扩展且安全的 API 项目,能够支持随着更多客户接入而实现的持续增长。

随着酒店业持续推进数字化转型,这种以 API 为核心的方法使他们能够为酒店管理者提供必要的数据和集成能力,从而打造卓越的客户体验并推动直接营收增长。

下一步行动

无论您身处酒店业、软件即服务(SaaS)、医疗保健,还是任何需要合作伙伴和客户通过编程方式访问您服务的行业,Revinate 采用的模式都具有广泛的适用性。首先,将业务驱动因素映射到具体的技術需求,这能让您的 API 网关选择基于实际成果而非单纯功能特性。从这里开始,探索 Amazon API Gateway 的 REST 和 HTTP API 选项,找到最适合您流量模式和集成需求的方案。使用 Amazon API Gateway 门户,可为开发人员提供从第一天起即可使用的自助式接入体验。如果您已经在 AWS 上运行工作负载,与 EKS、Lambda 和 CloudWatch 等服务的原生集成意味着您可以基于现有架构进行构建,而无需引入新的运营复杂性。对于采用基础设施即代码实践的团队,API Gateway 的 Terraform AWS Provider 帮助您将整个 API 配置定义为受版本控制的代码。要开始使用,请访问 Amazon API Gateway 文档,或联系您的 AWS 账户团队获取针对您用例和规模的架构指导。

资源

作者简介

'"` /think