服务间通信方式#

微服务间通信分为同步和异步两种方式。同步调用主要有 HTTP/REST 和 RPC 两种：Feign 基于 HTTP/JSON，简单跨语言、调试方便但性能一般，适合对外 API 和简单内部调用；Dubbo 和 gRPC 走自定义协议或 HTTP/2 加二进制序列化，性能高但调试不如 REST（Dubbo 3 的 Triple 协议基于 HTTP/1/2、兼容 gRPC，跨语言和 curl 调试都改善了）。另外 Spring Cloud OpenFeign 自 2022.0 起已宣布功能冻结（feature-complete），官方建议新项目迁到 Spring 的 HTTP Service Clients（@HttpExchange 接口）。同步调用的问题是强耦合和级联故障风险——调用链上任何一个服务超时或宕机都会影响上游。异步消息通过 Kafka 或 RocketMQ 实现，核心优势是解耦和削峰：生产者发消息后不用等消费者处理完就可以返回，消费者按自己的节奏消费，流量高峰时消息在队列里缓冲不会打垮下游。但异步的代价是复杂度高、有延迟、需要处理消息丢失和重复消费等问题。选型原则很清晰：查询和强依赖结果的场景必须同步，比如下单时查库存；通知和触发后续流程的场景优先异步，比如下单成功后发短信、扣积分。

追问方向：

• “同步调用的问题？”→ 调用链长时延迟叠加、任一节点故障导致整体失败、强耦合上下游；需配合超时、重试、熔断来保障可用性
• “异步消息的问题？”→ 无法立即获得结果、消息可能丢失或重复需额外保证可靠性和幂等、排查问题链路长调试困难、引入 MQ 增加系统复杂度
• “什么场景必须同步？”→ 需要立即拿到返回结果的场景：用户查询、支付扣款确认、登录鉴权等；以及需要强一致性保证的操作（如库存扣减需实时确认成功或失败）

易错点：

• ❌ 所有调用都该异步——查询场景必须同步
• ❌ 给 Feign 调用套一层 @Async 就算异步通信——只是调用方线程不阻塞，底层仍是同步 HTTP，下游挂了照样失败、仍然时间耦合；要解耦削峰得走 MQ