消息代理是否适合简单的消息发送者和接收者？
Is a message broker appropriate for a simple message sender and receiver?
我正在参与一个项目，该项目首先将构建一个简单的消息系统，该系统将接收消息、存储它们并将它们路由到适当的部门。基本用例是：
- 某人在网站表单中写了一条消息或一个问题，并选择了一个部门来将消息路由到
- 根据此人的选择，消息被路由到适当部门的消息队列，状态为 "unread," "read," 等（我们尚未确定所有状态） .
- 这些消息成为一个人与网站互动的一部分，即，如果他们致电客户服务，他们将能够调出该人已发送和接收的消息
基本问题是消息代理在这种情况下是否合理。我可以看到支持和反对的论据。首先，简单地将消息写入数据库存在超时、死锁等可能丢失消息的风险。代码需要处理这些场景。消息代理（例如 RabbitMQ）可以处理消息并保存它们，而不管数据库或系统是否已启动 运行，从而减少消息丢失。
另一方面，消息代理似乎也有点矫枉过正，因为它只是将消息传递给一个或多个部门，然后消失在一个人的历史记录中。那么为什么要为如此简单的事情包括所有这些基础设施呢？
这个系统将建立在这个初始框架之上，所以它不会仍然是一个简单的消息发送者，但到目前为止它不会将应用程序或系统连接在一起，它似乎也不会提供任何类似 ESB 功能的东西.目前，计划是使用 RabbitMQ、MassTransit 和 Sagas 来发送、路由和跟踪消息。这太多了吗？还是因为我们的目标是 0% 的故障率，所以它有必要吗？
谢谢！
这个系统的架构我真的不懂。您使用消息队列只是因为您拥有 "message" 的域对象吗？这些消息中有什么东西实际上需要 "delivered" 吗？它们是将要接收这些消息的异构系统吗？或者需要进行一些离线处理？
您希望有一个 "messages" 的简单数据库 table，其中包含状态、部门和内容，除非您对这些消息进行处理，否则您将放置太多基础设施。
我正在参与一个项目，该项目首先将构建一个简单的消息系统，该系统将接收消息、存储它们并将它们路由到适当的部门。基本用例是：
- 某人在网站表单中写了一条消息或一个问题，并选择了一个部门来将消息路由到
- 根据此人的选择，消息被路由到适当部门的消息队列，状态为 "unread," "read," 等（我们尚未确定所有状态） .
- 这些消息成为一个人与网站互动的一部分，即，如果他们致电客户服务，他们将能够调出该人已发送和接收的消息
基本问题是消息代理在这种情况下是否合理。我可以看到支持和反对的论据。首先，简单地将消息写入数据库存在超时、死锁等可能丢失消息的风险。代码需要处理这些场景。消息代理（例如 RabbitMQ）可以处理消息并保存它们，而不管数据库或系统是否已启动 运行，从而减少消息丢失。
另一方面，消息代理似乎也有点矫枉过正，因为它只是将消息传递给一个或多个部门，然后消失在一个人的历史记录中。那么为什么要为如此简单的事情包括所有这些基础设施呢？
这个系统将建立在这个初始框架之上，所以它不会仍然是一个简单的消息发送者，但到目前为止它不会将应用程序或系统连接在一起，它似乎也不会提供任何类似 ESB 功能的东西.目前，计划是使用 RabbitMQ、MassTransit 和 Sagas 来发送、路由和跟踪消息。这太多了吗？还是因为我们的目标是 0% 的故障率，所以它有必要吗？
谢谢！
这个系统的架构我真的不懂。您使用消息队列只是因为您拥有 "message" 的域对象吗？这些消息中有什么东西实际上需要 "delivered" 吗？它们是将要接收这些消息的异构系统吗？或者需要进行一些离线处理？
您希望有一个 "messages" 的简单数据库 table，其中包含状态、部门和内容，除非您对这些消息进行处理，否则您将放置太多基础设施。