NestJS+GraphQL混合微服务如何通过Resolver实现服务间通信

当前架构不需要额外给微服务新增REST控制器，以下3种方案均可以直接复用现有Resolver逻辑实现跨服务通信，按改造成本从低到高排序：

方案1：轻量GraphQL客户端直连（零改造首选） #

核心思路是不强行套用TCP微服务的@MessagePattern逻辑，直接在service1内置轻量GraphQL客户端，请求service2暴露的GraphQL端点，调用目标就是service2 Resolver中定义的query/mutation，完全不需要改动service2的现有代码。

• 落地步骤：
  • 在service1中安装轻量请求依赖：npm i graphql-request graphql
  • 在service1的全局模块中注册GraphQL客户端实例，service2的端点地址从配置中心/服务发现组件获取，不要硬编码
  • 将跨服务调用逻辑写在service1的业务Service层，Resolver仅负责接收自身的GraphQL请求、做参数校验、组装返回结果，符合现有无控制器的结构
• 参考实现：

// service1 业务服务层代码
import { Inject, Injectable } from '@nestjs/common';
import { request, gql } from 'graphql-request';

@Injectable()
export class BizService {
  constructor(@Inject('SERVICE2_GQL_URL') private readonly service2GqlUrl: string) {}

  async queryService2BizData(bizId: string) {
    // 直接匹配service2 Resolver中定义的query语句
    const getBizDetailQuery = gql`
      query GetBizDetail($bizId: String!) {
        getBizDetail(bizId: $bizId) {
          id
          bizName
          status
          createTime
        }
      }
    `;
    return request(this.service2GqlUrl, getBizDetailQuery, { bizId });
  }
}

• 适用场景：服务数量少、不想额外做架构改造、需要快速上线的项目，性能完全满足常规业务需求。

方案2：混合应用复用业务逻辑（内网RPC调用场景） #

如果不想走HTTP请求，要复用Nest原生微服务的TCP/Redis/RabbitMQ传输通道，可以把Resolver和微服务处理器的逻辑下沉到公共服务层，避免重复写业务代码。

• 落地步骤：
  • 把service2 Resolver中写死的业务逻辑抽离到独立的公共Provider中，Resolver仅作为GraphQL请求的入口，接收参数后转发给公共Provider处理
  • 给service2开启混合微服务模式，新增对应传输层的消息监听器，用@MessagePattern定义和Resolver方法一一对应的消息标识，监听器内部直接调用公共Provider的对应方法返回结果
  • service1中按照常规Nest微服务的用法，用@Client注入对应微服务客户端，直接发送消息调用即可，不需要感知service2的GraphQL层逻辑
• 注意点：该方案本质是复用Resolver背后的业务实现，不是直接跨进程调用Resolver方法，需要保证消息监听器和Resolver的参数校验、返回结构规则完全一致，避免出现逻辑不一致的问题。
• 适用场景：对跨服务调用性能要求高、已经搭好Nest微服务底层传输通道的项目。

方案3：GraphQL联邦模式（多服务统一网关场景） #

如果后续微服务数量会持续扩张，需要对外暴露统一的GraphQL访问入口，可以直接接入GraphQL联邦架构。

• 落地步骤：
  • 部署GraphQL联邦网关，将service1、service2都作为联邦子图接入
  • 各服务只需要维护自身负责的类型和字段Resolver，跨服务的字段依赖由网关自动编排请求，不需要手动写客户端调用
  • 例如service1需要扩展service2定义的Biz类型字段，只需要在service1的Resolver中编写对应字段的解析逻辑，网关收到请求后会自动拉取service2的基础数据、再请求service1补全扩展字段
• 适用场景：中大型微服务集群、需要统一对外GraphQL入口的项目，缺点是前期网关搭建和子图改造有一定接入成本。

避坑提醒：不要尝试在service1中直接实例化service2的Resolver类发起调用，两个微服务是独立运行的进程，跨进程实例化类无法拿到正确的依赖注入上下文，会直接抛出依赖缺失的运行时错误。

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