服务间通信方式#

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

追问方向：

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

易错点：

• ❌ 所有调用都该异步——查询场景必须同步
• ❌ Feign 调用就是同步的——可配合 @Async