# 消息传递架构

## 优点

**消息传递架构**提供了四个好处：松耦合、持久性、可伸缩性和灵活性。

* **松耦合：**消息传递方法允许我们解耦两个服务，因为在通信状态变化时，两个服务互不了解。
* **持久性：**队列的存在使我们能够保证即使消费者服务宕机，消息仍将被传递。
* **可伸缩性：**
  * 因为消息存储在队列中，消息发送方无需等待消息消费者的响应。
  * 如果从队列中读取消息的消费者处理消息的速度不够快，可以轻松地启动更多的消费者，并让它们处理这些消息。
* **灵活性：**消息的发送方不知道谁会消费它。这意味着我们可以轻松地添加新的消息消费者（和新功能），而不影响原始的发送服务。这是一个非常强大的概念，因为可以向应用程序中添加新功能，而无需触及现有服务。相反，新代码可以监听发布的事件并相应地做出反应。

## 缺点

**消息传递架构的主要缺点在于基于消息的架构可能会变得复杂**，并需要开发团队特别关注几个关键点，包括**消息处理语义**、**消息可见性**和**消息编排**。

### **消息处理语义**

在基于微服务的应用中使用消息不仅仅需要理解如何发布和消费消息。还需要我们理解应用程序会根据消息的消费顺序而表现出怎样的行为，以及如果消息被按照不正确的顺序处理会发生什么。例如，如果我们有强制要求要按照接收顺序处理单个客户的所有订单，那么我们需要以不同的方式设置和构建消息处理，以确保消息不会发生错乱或不按照预期的顺序处理。

这还意味着，如果我们使用消息来强制执行数据的严格状态转换，我们需要考虑设计应用程序，以考虑消息引发异常或错误被按顺序处理的情况。如果消息失败，我们是否重试处理错误，还是让其失败？如果某个客户的消息失败，我们如何处理与该客户相关的未来消息？这些都是需要深思熟虑的重要问题。

### **消息可见性**

在我们的微服务中使用消息通常意味着同步服务调用和异步服务处理的混合。消息的异步性意味着它们可能不会在发布或消费消息的时间附近被接收或处理。

### **消息协调**

基于消息的应用使得理解其业务逻辑变得更加困难，因为其代码不再按照简单的请求-响应模型线性处理。相反，调试基于消息的应用可能涉及浏览多个不同服务的日志，用户事务可能按不同的顺序和不同的时间执行。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bohans.gitbook.io/ji-chu/spring/group-1/spring-cloud/spring-cloud-stream/xiao-xi-chuan-di-jia-gou.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.