使用 AWS AppSync Merged API 整合微服务的 GraphQL - 团队分布式开发实践
将多个团队独立开发和部署的 GraphQL API 整合到单一端点。介绍 Schema 冲突的规避策略和认证策略设计。
Merged API 的必要性
在微服务架构中多个团队开发 GraphQL API 时，前端需要向多个端点发送请求，增加了客户端的复杂度。Merged API 解决了这一问题，将多个源 API 整合到单一端点。用户团队的 User API、订单团队的 Order API、商品团队的 Product API 可各自独立开发和部署，而前端只需通过一个 GraphQL 端点即可访问。与基于 REST 的 API Gateway 聚合不同，由于在 GraphQL Schema 层面进行整合，跨服务查询也可在单个请求中执行。
源 API 的设计与独立部署
各团队将独立的 AppSync API 作为源 API 进行开发。Schema、解析器和数据源按源 API 分别管理，团队可自由部署和更新自己的 API。源 API 的更新会自动反映到 Merged API。Schema 冲突（同名 Query 字段、同名类型定义）在合并时被检测并报告为错误。为避免冲突，建议团队间事先约定 Schema 命名规则，使用命名空间式前缀（user_、order_），或将公共类型定义作为共享 Schema 管理。
认证策略
在 Merged API 层面设置默认认证方式（Cognito 用户池、IAM、API Key、Lambda 授权器）。每个源 API 可设置额外的认证方式，对特定字段应用源 API 的认证。例如，将 Merged API 的默认认证设为 Cognito，同时在源 API 层面为管理员 Mutation 添加 IAM 认证。通过 @aws_auth 指令控制字段级认证，可将特定字段仅对特定 Cognito 组公开。 如需深入了解微服务，也可参考Amazon 上的相关书籍。
Merged API 的定价与限制
Merged API 的定价与普通 AppSync API 相同，查询和变更每 100 万次请求约 4.00 美元（截至 2026 年 8 月）。Merged API 本身不产生额外费用，但源 API 数量有上限（默认 10 个），在大规模微服务环境中需要申请提高配额。源 API 的解析器调用 Lambda 时，Lambda 费用计入源 API 的账户。启用 Merged API 的缓存后，跨源 API 的查询结果会被缓存，减少后端调用次数。
总结
AppSync Merged API 是将多团队的 GraphQL API 整合到单一端点的服务。在保持各团队独立部署的同时，为前端提供简洁的单一端点。是微服务架构中采用 GraphQL 时的标准模式。