26、消息驱动架构与Spring Cloud Stream实战-CSDN博客

本文链接：https://blog.csdn.net/s1t2u3/article/details/149642644

消息驱动架构与Spring Cloud Stream实战

1. 消息架构的缺点

消息架构虽然强大，但也有其权衡之处。基于消息的架构较为复杂，开发团队需要关注以下几个关键方面：
- 消息处理语义 ：在基于微服务的应用中使用消息，不仅要理解如何发布和消费消息，还需考虑消息消费顺序对应用行为的影响，以及消息处理顺序错误时的情况。例如，如果要求单个客户的所有订单必须按接收顺序处理，那么消息处理的设置和结构就与每条消息可独立消费的情况不同。此外，如果使用消息来强制数据的严格状态转换，还需要考虑消息抛出异常或处理顺序错误的场景，如消息处理失败时是重试还是放弃，以及如何处理与该客户相关的后续消息。
- 消息可见性 ：在微服务中使用消息通常意味着同步服务调用和异步服务处理的混合。消息的异步性质使得它们可能不会在发布或消费的附近时间被接收或处理。为了理解和调试应用中的情况，使用关联ID（correlation ID）来跟踪用户在Web服务调用和消息中的事务至关重要。关联ID是在用户事务开始时生成的唯一编号，并会随每个服务调用和消息一起传递。
- 消息编排 ：基于消息的应用使得理解其业务逻辑变得更加困难，因为代码不再以简单的块请求 - 响应模型按线性方式处理。调试基于消息的应用可能需要查看多个不同服务的日志，用户事务可能会以不同的顺序和时间执行。