GraphQL schema stitching与schema merging的实际区别是什么

二者都是将多个GraphQL Schema组合为统一对外Schema的技术，但底层逻辑和适用场景存在本质区别，并非简单的组织偏好差异。

1. 底层逻辑区别 #

• Schema Merging：属于本地静态合并，所有子Schema的类型定义、解析器会被直接整合到同一个运行时的Schema实例中，相当于把多份Schema代码拼接为一整份完整Schema，所有解析逻辑都在当前服务进程内执行，不存在跨服务调用环节。
• Schema Stitching：属于跨服务动态代理拼接，每个子Schema可以对应独立部署的远程GraphQL服务，上层网关接收请求后会自动将请求拆分到对应子服务执行，再把多个服务的返回结果聚合后返回给调用方，不需要将子服务的代码部署到网关侧，仅需要获取子服务的Schema定义和调用权限即可。

2. 核心能力差异 #

• 类型冲突处理逻辑不同
  • Merging对重名类型的处理是静态覆盖，也可以手动配置合并规则将重名类型的字段整合，所有规则合并完成后运行时不会再变更
  • Stitching支持重名类型的跨服务关联，比如用户服务的User类型包含id、姓名字段，订单服务的User类型包含id、订单列表字段，Stitching可以将两个User类型的字段自动整合，查询时会自动请求两个服务拉取数据合并，不需要将两个服务的代码放在同一进程中运行
• 依赖要求不同
  • Merging要求所有子Schema的代码、解析器都可以在当前服务本地获取，本质是单服务内的Schema模块化拆分方案
  • Stitching仅要求子服务暴露可调用的GraphQL端点，不需要获取子服务的源码，适配跨团队、跨服务的分布式架构
• 性能开销不同
  • Merging没有额外的网络开销，所有解析逻辑都在本地执行，性能更高
  • Stitching会产生网关拆包、请求转发、结果聚合的额外开销，还需要额外处理跨服务的错误、超时等分布式问题

3. 适用场景差异 #

• 选择Schema Merging的场景：
  • 单服务架构下，将不同业务模块的Schema拆分到不同文件维护，最终合并为一个完整Schema对外提供服务
  • 所有子模块的代码都在同一个代码仓库、同个运行时内部署
• 选择Schema Stitching的场景：
  • 微服务架构下，不同团队维护独立的GraphQL服务，需要一个统一的对外网关聚合所有服务的能力
  • 需要整合第三方提供的GraphQL服务，无法获取对方的源码

内容的提问来源于stack exchange，提问作者Peter Malik