Architecture 消息代理是否适合于简单的消息发送者和接收者？

我正在参与一个项目，该项目将首先构建一个简单的消息系统，该系统将接收消息、存储它们并将它们发送到适当的部门。基本用例是：

• 此人在网站表单中编写消息或问题，并选择将消息发送到的部门
• 根据该人员的选择，消息将被路由到相应部门的消息队列，状态为“未读”、“已读”等（我们尚未确定所有状态）
• 这些信息成为一个人与网站互动的一部分，也就是说，如果他们致电客户服务，他们将能够调出该人发送和接收的信息

基本问题是，在这种情况下，消息代理是否合理。我可以看到赞成和反对的论据。首先，简单地将消息写入数据库有超时、死锁等风险，可能会丢失消息。代码需要考虑这些场景。消息代理（如RabbitMQ）可以处理消息并保存它们，而不管数据库或系统是否已启动并正在运行，从而减少消息丢失

另一方面，消息代理似乎也有些过火，因为它只是将消息传递给一个或多个部门，然后消失在一个人的历史中。那么，为什么要为这么简单的东西包括所有这些基础设施呢

该系统将在此初始框架基础上构建，因此它将不再是一个简单的消息发送者，但到目前为止，它不会将应用程序或系统连接在一起，也不会提供类似ESB的功能。目前，计划使用RabbitMQ、MassTransit和Sagas来发送、路由和跟踪消息。这是不是太多了？或者，我们的目标是0%的故障率，这是有保证的吗

---

谢谢大家!

我真的不了解这个系统的架构。您使用消息队列仅仅是因为您拥有“消息”的域对象吗？这些信息是否真的需要“传递”？它们是将要接收这些消息的异构系统吗？或者需要进行一些脱机处理

---

您希望有一个简单的“消息”数据库表，其中包含状态、部门和内容，除非您正在对这些消息进行处理，否则您的基础设施太多。

您好，消息将根据发起消息的人所做的选择路由到各个部门，但这似乎可以由数据库或消息代理以外的其他机制来处理。根据你的回答，我认为这个系统在基础设施方面可能做得太多了，这正是我试图回答的问题。这个系统使用数据库调用会好吗？在这一点上，似乎有一个系统将路由消息-没有呼叫其他微服务等。是的，在“部门”表示另一个软件之前，不要使用消息传递系统。这最好通过直接的数据库呼叫来实现吗？当然，除非您需要一些异步处理，或者显式地需要解耦操作。