快速演进的联邦式GraphQL架构

快速演进的联邦式GraphQL架构

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， 生成式AI， Buy with Prime， Graphql Schema Federation， Schema Versioning Management， Schema Projection Configuration， Federated Architecture Composition， Generative Ai Testing]

导读

在本次会议中，我们将通过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技术则提供了创造力的火花，发现人类工程师可能忽略的边缘情况和场景。

未来探索:推进全面测试的边界

下面是一些演讲现场的精彩瞬间：

演讲者解释了Amazon AppSync如何利用远程指令从下游系统获取数据，扩展了其数据获取能力，不仅限于本地解析器和数据源。

演讲者阐述了管理软件发布安全性的两个重要规则，确保只包含已发布的投影，并且对已发布投影的任何更改都会破坏构建，从而实现适当的变更管理。

演讲者强调了使用AI进行测试用例生成的权衡，包括需要提示工程专业知识、结果可能不一致、依赖外部服务，以及基于AI模型和训练数据的质量差异。

亚马逊展示了基于LLM生成的API测试灵活性和适应性，利用反馈循环提高质量，同时承认与传统模板方法相比可能会增加错误。

演讲者演示了一个端到端的示例，为名为“createProduct”的GraphQL变更操作生成AI测试用例，展示了基于模式和变更定义自动创建测试用例的能力，涵盖成功和失败场景。

演讲者讨论了探索上下文感知的测试演进，其中生成式AI可以根据模式更新、bug报告和其他触发器自动扩展测试套件。

总结

在这个引人入胜的叙述中，我们深入探讨了Buy with Prime这一开创性服务的复杂世界，它将亚马逊Prime的优势延伸到了亚马逊.com之外的商家。这个故事通过Joseph、David和Matt的视角展开，他们分享了对Buy with Prime的GraphQL架构演进以及确保其可扩展性、版本控制和全面测试所采用的创新技术的见解。

Joseph首先介绍了Buy with Prime及其将Prime的优势(如送货承诺、客户服务和无缝退货)外部化给合作商家的使命。然后他将话筒交给Matt，后者深入探讨了管理Buy with Prime的GraphQL API的模式变更、版本控制和发布管理的挑战。

Matt揭示了一种称为“模式投影”的创新方法，它允许从基础模式创建版本化模式，使独立团队能够贡献和发展API，同时保持向后兼容性。他还介绍了“下推组合”的概念，即在系统的各个节点进行GraphQL组合，促进独立开发、测试和部署。

接下来，David出场，阐述了Buy with Prime利用生成式人工智能来提高测试代码覆盖率的努力。他探讨了从API定义生成测试用例描述、将描述转换为测试代码以及采用“思维链”等高级提示技术来增强AI生成测试的全面性和透明度等技术。

在整个叙述过程中，演讲者分享了宝贵的见解，包括生成式AI方法的优缺点、提示工程的重要性，以及AI和程序枚举在全面API测试中的协同作用。他们还概述了未来的发展方向，如分块大型模式、多API交互场景、强大的反馈循环和上下文感知的测试演进。

在结尾时刻，演讲者让观众对他们为解决不断演进的GraphQL架构的复杂性而构建的创新解决方案感到鼓舞，并对生成式AI革新API测试和维护的潜力充满期待。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者，亚马逊云科技正在携手广泛的客户和合作伙伴，缔造可见的商业价值 – 汇集全球40余款大模型，亚马逊云科技为10万家全球企业提供AI及机器学习服务，守护3/4中国企业出海。