消息驱动微服务多节点输入获取及分布式通信架构疑问

问题1：是否应将服务间通信严格限制在消息队列内？即时数据需求下的REST调用是旧思维吗？ #

• 没必要做“严格限制”，核心是适配业务场景选择通信模式：
  • 消息队列（Kafka/Azure Service Bus/SQS）的核心价值是异步解耦、削峰填谷、故障隔离，适合后台批量流程、事件驱动的业务逻辑，比如订单创建后触发库存扣减、物流通知这类异步场景。
  • 对于用户侧的实时数据需求（比如用户查看订单详情时需要同步获取支付状态），直接用REST/gRPC这类同步调用是合理的，这不是“微服务前的思维定式”，而是匹配同步交互场景的必要选择。
• 关键边界：避免跨服务频繁同步调用获取核心数据。如果服务A经常需要服务B的数据，更合理的方式是让B通过消息总线发布数据变更事件，A订阅后将数据缓存到本地存储（比如数据库、Redis），后续A直接从本地取数，既保证性能，又降低耦合。

问题2：服务A需同时获取B、C的消息才能工作，是否应等待C的总线消息？总线的请求-回复模式是否趋近REST？ #

• 若追求完全服务隔离，最优方案是等待C的消息通过总线送达：
  • A只需监听总线中B和C的事件主题，无需知道B、C的存在。当A收到B的消息后，将其存储到本地状态（比如数据库的临时表），待收到C的对应消息后，再触发后续工作流程。这种方式完全基于事件驱动，服务间没有直接依赖，符合隔离原则。
• 关于总线的请求-回复模式：
  • 部分消息中间件（比如Azure Service Bus）确实支持请求-回复语义，但它和REST同步调用有本质区别：REST是直接调用服务实例的地址，而总线请求-回复是通过消息主题传递，A不需要知道C的部署地址，仅需约定回复主题。
  • 但这种模式会增加一定耦合（A需要知道C的回复主题），且同步等待回复会降低服务可用性（若C超时未回复，A可能阻塞）。除非是必须同步获取结果的场景，否则优先用事件驱动的方式，让B、C各自发布事件，A本地聚合数据后触发工作。

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