导读

在本次会议中，我们将通过Buy with Prime API的视角深入探讨管理和扩展高性能GraphQL API的高级策略。这是亚马逊第一个允许开发者将Prime和非Prime购物功能集成到其电子商务系统中的API。您将了解创新的版本管理技术、精简的发布流程，以及联合GraphQL架构的扩展解决方案。我们将探讨基于Amazon Fargate的模式和Buy with Prime实施中使用的生成式AI测试方法的实际案例。加入我们，提升您的GraphQL基础设施的可扩展性和弹性。

演讲精华

以下是小编为您整理的本次演讲的精华。

在不断演进的电子商务领域中，亚马逊的Buy with Prime服务应运而生，成为了一场颠覆性的变革。它使商家能够无缝整合亚马逊的Prime服务，并将备受推崇的Prime体验延伸至自己的商店。亚马逊的解决方案架构师Joseph登台，揭开了这项创新服务的内在运作，并阐明了他们的GraphQL API服务在其中扮演的关键角色。

Buy with Prime的核心是一个复杂的GraphQL API，这是一个至关重要的组件，使客户能够以编程方式与该服务进行交互。高级软件工程师Matt Quinlan深入探讨了他们GraphQL模式的架构细节，揭示了他们为解决版本控制、跨多个团队的组合以及对客户的稳定发布所设计的巧妙解决方案。

据所呈现的数据显示，注册或整合Buy with Prime的商家见证了令人瞩目的20%购物者转化率增长。此外，令人印象深刻的是，每四笔订单中就有三笔是通过Buy with Prime下单的，这证明了该服务吸引新购物者和提高参与度的能力。对于商家而言，整合Buy with Prime提供了双赢的局面，使他们能够利用Prime的送货承诺、无缝退货的客户服务，同时提高购物者转化率和订单量。

版本控制模式:大师级方法 随着Buy with Prime迅速发展以满足不断变化的市场需求，建立一个健壮的版本控制系统变得至关重要。现有客户需要无缝过渡到新版本而不中断体验，同时新功能和增强功能也需要快速推出。于是，“模式投影”这一巧妙的解决方案彻底改变了他们的模式版本控制方法。

这种方法的基础是一个精心设计的基础模式，带有诸如@added和@removed等编写指令，用于指示版本差异。这些指令就像灯塔一样，指导着一个专门的构建工具生成最终将提供给客户的特定版本模式。

例如，考虑一个具有以下结构的基础模式:

type Product @added(version: 2) { description: String createDate: Int @removed(version: 2) createDateString: String @added(version: 2， alias: “createDate”) }

这个基础模式将产生两个不同的版本模式:

版本1: type Product { createDate: Int }

版本2: type Product { description: String createDateString: String }

为了进一步增强版本控制能力，Matt和他的团队引入了@source指令，这是一个强大的工具，使自定义数据获取器能够根据请求的版本解析适当的字段。这种巧妙的解决方案确保了客户在版本之间无缝过渡，而不会中断现有集成。

联合模式:跨团队编排和谐 由于多个团队拥有GraphQL API后面的不同服务，将这些分散的模式组合成一个统一的API成为了一个巨大的挑战。然而，Buy with Prime的工程师设计出了一种优雅的解决方案，不仅促进了组合，而且还使团队能够独立开发和测试。

他们的方法大胆而独特——他们将GraphQL组合层推送到每个服务中。与依赖单一的、单片的GraphQL组合层不同，每个服务现在都拥有自己的GraphQL反向代理，负责在其领域内组合相关的模式。

例如，Product服务中包含一个GraphQL代理，可以无缝地将Product模式与来自Inventory服务的Inventory模式组合起来。这种架构决策使Inventory团队能够独立开发和测试他们的模式更改，直到准备好集成时才会影响组合的Product API。

投影配置在这个过程中扮演着关键角色，充当组合各种模式的蓝图。一个配置文件可能类似于以下内容:

product-projection.yml: versions: - version: 3 includes: - name: inventory version: 1 url: https://inventory.service/graphql

这个配置将产生一个可执行的模式，合并Product和Inventory模式，同时为需要委托到远程Inventory服务URL的字段引入@remote指令。

支撑这个复杂的组合过程的是一个精心设计的自定义数据获取器，它首先会检查是否存在@remote指令。这使Buy with Prime能够在版本化的模式和服务之间无缝处理委托，确保为客户提供一致和连贯的体验。

发布管理:在分布式所有权中保障稳定性 随着所有权的分布，一个团队无意中通过模式更改破坏现有客户的API的风险也随之而来。为了减轻这种风险，Buy with Prime实施了一个健壮的“发布”状态投影，这是一种确保在不断演进中保持稳定性和可预测性的保障措施。

这种方法的核心是简单而有效的:一个投影必须处于“发布”状态才能被包含在父级组合中。对标记为“发布”的投影进行任何更改都会触发构建失败，迫使团队遵循一个明确的流程:

1)          在新的“草稿”版本中进行模式更改。

2)          独立测试和验证草稿版本。

3)          准备就绪后将投影标记为“发布”。

4)          父级投影现在可以包含新的发布版本。

这种精心设计的流程不仅确保了模式更改以一种受控和有意的方式在分布式系统中推出，而且还使团队能够独立工作，而不必担心破坏现有客户的整体API。

利用生成式AI进行测试:拥抱全面覆盖的未来 随着Buy with Prime生态系统不断扩展，对他们不断增加的模式版本和组合进行全面测试覆盖的需求变得越来越重要。亚马逊的首席工程师David Ramos登台，揭示了他们利用生成式AI进行这项关键任务的创新方法。

Buy with Prime探索了两种不同但互补的方法:使用AI语言模型从模式生成测试用例描述，以及使用AI模型从这些描述生成实际的测试代码。

使用AI生成测试用例描述 从模式生成测试用例描述的过程在很大程度上依赖于精心设计的提示。这些提示结合了模式定义、测试要求(如成功案例、失败模式、边界条件等)和相关示例。

为了进一步提高生成的测试用例的全面性，Buy with Prime采用了一种称为“思维链”提示的技术。这种方法鼓励AI语言模型分解其推理过程并逐步解释其思维过程，模仿经验丰富的QA工程师可能采用的结构化方法。

通过首先要求AI分析操作并确定测试目标，Buy with Prime确保了语言模型完全理解了需要测试的内容，然后才生成测试用例。当AI提供每个测试用例的推理时，它往往会发现额外的场景或边缘情况，这些是它最初没有考虑到的，进一步增强了生成的测试套件的全面性。

例如，考虑一个用于’createProduct’变更的GraphQL模式，其中包含’Product’输入类型和嵌套的’Price’输入类型。AI生成的测试用例将包括一组全面的与’Product’结构匹配的输入字段，涵盖有效的产品创建场景以及由于违反字段约束(如标题长度验证)而触发的失败模式。

使用AI生成测试代码 将测试用例描述转化为可执行的测试代码的过程遵循了类似的基于提示的方法。Buy with Prime为AI提供了测试用例描述、示例代码片段以及一个精心设计的提示，以指导代码生成过程。

对于’createProduct’变更，AI将生成Python集成测试，构建GraphQL变更、设置基于测试用例的输入变量、执行查询，并验证响应是否与预期结果相匹配——无论是成功创建的产品还是违反约束时的适当错误响应。

虽然基于AI的方法提供了显著的优势，如创造性的测试用例生成、适应不断变化的模式的能力以及随时间改进的潜力，但它们也带来了新的挑战。提示工程技能成为一个关键的先决条件，因为设计有效的提示往往需要对AI的能力和局限性有深刻的理解。

寻求平衡:结合生成式AI和程序化方法 认识到生成式AI和程序化方法的优缺点，Buy with Prime采用了一种混合策略，旨在发挥两者的最大优势。他们的方法结合了生成式AI和程序化测试用例枚举，利用AI填补程序化规则遗漏的空白，同时仍然系统地覆盖已知的约束。

程序化方法确保Buy with Prime能够有系统地覆盖所有已知场景和API约束，而生成式AI技术则提供了创造力的火花，发现人类工程师可能忽略的边缘情况和场景。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。