23.2 服务间通信：HTTP REST、RPC、消息队列

在微服务架构中，每个服务都拥有独立的进程空间和数据存储，服务之间必须通过网络进行协作。这种分布特性带来了一个核心挑战：如何让不同服务之间可靠、高效地交换信息？ 选对通信方式会直接影响系统的性能、可维护性和扩展性。Node.js 生态为这三种主流通信模式提供了丰富的工具支持，本节将它们——HTTP REST（同步请求-响应）、RPC（远程过程调用）、消息队列（异步消息）——分别讲透，并给出真实场景下的选型建议。

1. HTTP REST：最通用的请求-响应模型

REST（Representational State Transfer）基于 HTTP 协议，把服务间的交互设计为对资源的操作。一个服务通过 HTTP 客户端向另一个服务的 REST 接口发起请求，同步等待响应。这是微服务中最直观、最简单、也最普遍的通信方式。

工作原理

客户端构造 HTTP 请求（GET、POST、PUT、DELETE 等），携带 JSON 或表单数据。
服务端处理请求，返回 HTTP 状态码与响应体。
调用方同步等待响应，处理成功或失败分支。

由于 HTTP 协议天然的无状态和文本可读性，REST 风格接口很容易调试和集成。绝大多数 API 框架（Express、Koa、Fastify）都直接支持 REST 风格的接口开发。

Node.js 中的实现

服务端：任意 HTTP 框架均可。

// app1 - 用户服务
app.get('/users/:id', async (req, res) => {
  const user = await db.findUser(req.params.id);
  res.json(user);
});

客户端：通常使用 axios 或 node-fetch。

// app2 - 订单服务
const axios = require('axios');
const getUserInfo = async (userId) => {
  const response = await axios.get(`http://user-service/users/${userId}`);
  return response.data;
};

在生产环境中，强烈建议使用服务发现（如 Consul、Kubernetes Service）代替硬编码 URL，并通过断路器（如 opossum 库）防止级联故障。

REST 的优点与缺陷

优点：

零学习成本：任何后端工程师都熟悉 HTTP，调试工具（Postman，cURL）成熟。
语言无关：只要支持 HTTP 解析，任何语言的服务都能互相调用。
生态丰富：测试工具、负载均衡、API 网关对该模式支持极好。

缺陷：

同步阻塞调用链：如果请求链路 A → B → C，C 的延迟会逐级放大。
接口耦合：服务提供方修改字段名或 URL 时，所有消费方都要同步修改。
不适合高吞吐实时场景：HTTP/1.1 的请求-响应开销较大，虽然 HTTP/2 和连接池能缓解，但逻辑本质仍是同步调用。

REST 最适合 查询与命令的一致性要求高、数据强依赖、链路简单 的场景。例如订单服务必须拿到用户信息才能继续处理，或订单创建后需要同步返回支付状态。

2. RPC：高性能的函数调用抽象

RPC（Remote Procedure Call）试图让远程函数调用像本地函数一样自然。它通过定义接口（IDL，接口定义语言），向开发者暴露一个“函数签名”，底层负责序列化、网络传输、反序列化和超时控制。相比 REST 围绕资源，RPC 更偏向面向过程的动作。

当前微服务中最主流的是 gRPC（基于 HTTP/2 和 Protocol Buffers），由 Google 开源。Facebook 的 Thrift、Apache Avro 也是类似协议，但 gRPC 在云原生生态中占据统治地位。

gRPC 的工作原理

使用 .proto 文件定义服务和消息结构。
通过编译器生成客户端和服务端的 stub（桩代码）。
客户端调用本地 stub 方法，实际上进行 HTTP/2 通信，数据序列化为 Protocol Buffers 二进制格式。
服务端 stub 反序列化并执行实际逻辑，将结果返回。

Node.js 中的 gRPC 实现

安装 @grpc/grpc-js 和 @grpc/proto-loader。
定义 proto (user.proto):

syntax = "proto3";
service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}
message UserRequest { string id = 1; }
message UserResponse { string name = 2; string email = 3; }

服务端：

const PROTO_PATH = './user.proto';
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const packageDef = protoLoader.loadSync(PROTO_PATH);
const userProto = grpc.loadPackageDefinition(packageDef);

const server = new grpc.Server();
server.addService(userProto.UserService.service, {
  GetUser: (call, callback) => {
    const user = { name: 'Alice', email: 'alice@example.com' };
    callback(null, user);
  }
});
server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => server.start());

客户端：

const client = new userProto.UserService('localhost:50051', grpc.credentials.createInsecure());
client.GetUser({ id: '1' }, (err, response) => {
  if (!err) console.log(response);
});

gRPC 支持四种调用模式：一元 RPC（如上面示例）、服务端流式（数据批量推送）、客户端流式（上传）及双向流，灵活度远超 REST。

RPC 的优势与陷阱

优势：

传输效率极高：Protocol Buffers 序列化体积小、解析快，HTTP/2 多路复用降低连接开销。
强类型契约：接口变更有 proto 文件约束，违反协议会生成编译错误。
流式通信：天然支持实时推送、大文件流处理，很适合日志收集、可观察性等场景。

陷阱：

二进制不可读：调试必须借助 grpcurl 或 BloomRPC 等工具，不如 HTTP JSON 直观。
强耦合于 proto 定义：尽管可以做到向后兼容，但对字段修改的约束更强，团队需要遵循严格的变更规范。
浏览器友好度低：Web 客户端通常需要 grpc-web 代理，增加了一层复杂度。若主要暴露给外部前端，REST 或 GraphQL 仍是更自然的选择。

在 内部微服务高频调用、性能要求高、服务众多且语言异构 的环境下，gRPC 凭借高性能和清晰的接口约定常成为首选。反之，如果服务平均调用量低、无需极致性能，或者团队对 proto 不熟，则 REST 的成本更低。

3. 消息队列：异步解耦的终极武器

当操作允许 异步处理，或者需要 消除上游对下游执行结果的即时依赖 时，消息队列应运而生。它将“发送消息”的行为和“处理消息”的行为在时间和空间上彻底分离开。

一条典型的消息通信流程：

生产者（如订单服务）创建一条消息（如“订单已支付”），发送到消息中间件（Broker）。
Broker（如 RabbitMQ、Kafka、Redis）持久化消息，按规则投递给一个或多个消费者。
消费者（如物流服务、积分服务）拉取或推收到消息，执行各自的业务逻辑。
消费者处理成功后确认（ACK），Broker 移除消息；处理失败可重试或移至死信队列。

Node.js 中的消息队列方案

Bull / BullMQ：基于 Redis 的可靠队列库，内置重试、延迟任务、进度跟踪等，轻量易用，适合中小规模。
amqplib：直接操作 RabbitMQ 协议的客户端，可靠性和灵活性极高。
kafkajs：连接 Apache Kafka 的客户端，适合海量事件流的持久化订阅。
Cloud 服务：AWS SQS、Google Pub/Sub，开箱即用，无需自运维。

用 Bull 实现异步积分发放的例子：

// 生产者
const Queue = require('bull');
const rewardQueue = new Queue('reward', 'redis://127.0.0.1:6379');
app.post('/order', async (req, res) => {
  const order = await createOrder(req.body);
  await rewardQueue.add({ userId: req.body.userId, orderId: order.id });
  res.status(201).json(order);
});

// 消费者
rewardQueue.process(async (job) => {
  const { userId, orderId } = job.data;
  await grantPoints(userId, calculatePoints(orderId));
});

消费者可以独立部署在另一台机器，订单服务甚至无需感知积分服务的存在与否。

消息队列的核心价值与边界

核心价值：

彻底解耦：服务只需知道消息格式，不需知道对方的地址或接口。
削峰填谷：突发流量堆积在队列中，由消费者按自身能力消费，保护数据库。
故障隔离与重试：消费者宕机不影响上游，消息持久化后待恢复继续消费。
最终一致性：通过事件驱动，保证多个系统数据的最终一致，无需分布式事务。

边界与代价：

系统复杂度上升：引入队列需要维护 Broker 集群，关注死信、持久化、顺序性等问题。
调试与追踪困难：请求链路断在消息中，必须使用分布式追踪（如 Jaeger）追踪事件流水。
延迟不确定性：消息从生产到消费存在延迟，不适合需要同步响应的场景（如登录校验）。

消息队列是 异步业务、跨服务联动、应对流量峰值 的黄金方案，也是构建事件驱动架构的基础。任何可以“先确认、后处理”的流程，都可以通过消息队列大幅提升系统韧性。

4. 三种通信方式的对比与实战选型

| 通信方式 | 同步/异步 | 主要协议 | 性能 | 耦合度 | 适用场景 |
|----------|----------|----------|------|--------|----------|
| HTTP REST | 同步（默认） | HTTP 1.1/2 + JSON | 中等 | 中等 | 查询类、对外 API、跨团队简单调用 |
| gRPC | 同步/流式 | HTTP/2 + Protobuf | 高 | 强 | 内部高频调用、流处理、多语言环境 |
| 消息队列 | 异步 | AMQP/MQTT/Kafka/Redis | 极高 | 极低 | 事件驱动、异步任务、解耦削峰 |

没有“最佳”通信方式，只有最合适的组合。一个成熟的微服务架构通常同时混合使用多种方式：

业务入口和查询操作：用 REST 作为外部 API 网关，对内也可用于简单同步调用。
内部高频、实时性要求高的调用：gRPC 替代长链路的 REST 调用，降低延迟和带宽。
异步解耦和副作用处理：如发邮件、生成报表、数据同步，一律投递消息队列。

Node.js 为这三种风格提供了充分的开箱支持，结合前文介绍的框架、库与工程实践，团队可以依据实际的流量特征、一致性要求和团队技能选择最恰当的通信手段。在下一节，我们会进一步探讨如何用消息队列实现异步解耦和削峰填谷，以及更复杂的分布式事务问题。