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

Question

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

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

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

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

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

谢谢！

Answer 1

我真的不明白这个系统的架构。您是否因为拥有“消息”的域对象而使用消息队列？这些消息中是否有一些实际需要“传递”的东西？它们是否将接收这些消息的异构系统？还是需要进行一些离线处理？

您希望有一个简单的“消息”数据库表，其中包含状态、部门和内容，除非您对这些消息执行某些操作，否则您需要部署太多的基础设施。