微服务之间怎么通信：REST、RPC 还是消息队列

一、REST / HTTP：最省心的默认选项

最常见的就是 HTTP 接口互调，JSON 当载体。好处是简单、跨语言、抓个包就能看：

// 服务A 调用 服务B 的订单接口
Order order = restTemplate.getForObject(
    "http://order-svc/orders/" + id, Order.class);

适合对外暴露、或者跨语言协作。缺点是每次都是文本序列化，性能一般；而且是同步的，B 挂了 A 也得跟着等。

二、RPC：内部高频调用的性能派

服务都在自己技术栈内、调用又特别频繁时，RPC（如 gRPC）用二进制协议，比 REST 快不少，还带接口契约、类型安全。代价是和框架绑定更紧，调试不如 HTTP 直观。

三、消息队列：彻底解耦的异步派

上面两种都是"你问我答"的同步模式。有些场景根本不需要立刻回答——比如"下单成功发个通知"“库存变了更新缓存”。这时候用消息队列（Kafka/RocketMQ）把事件丢出去，谁关心谁订阅：

kafkaTemplate.send("order-created", orderEvent); // 发完就走，不等

好处是调用方和被调用方彻底解耦，还能削峰填谷。代价是变"最终一致"，链路排查更复杂。

四、怎么选，一张表说清

小结

没有"最好"的通信方式，只有"最合适"的。我的经验是：默认 REST 起步，内部性能瓶颈出现了再上 RPC，真正需要解耦和异步的地方才引入消息队列。一上来全套 MQ，往往是给自己挖坑。通信方式选对了，微服务才算真正"拆得动"，不然就是换了个写法写单体。