使用 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 美元。Merged API 本身不产生额外费用，但源 API 数量有上限（默认 10 个），在大规模微服务环境中需要申请提高配额。源 API 的解析器调用 Lambda 时，Lambda 费用计入源 API 的账户。启用 Merged API 的缓存后，跨源 API 的查询结果会被缓存，减少后端调用次数。
总结
AppSync Merged API 是将多团队的 GraphQL API 整合到单一端点的服务。在保持各团队独立部署的同时，为前端提供简洁的单一端点。是微服务架构中采用 GraphQL 时的标准模式。