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

Question

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

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

基本问题是，在这种情况下，消息代理是否合理。我可以看到赞成和反对的论点。首先，仅将消息写入数据库可能会导致超时，死锁，并可能丢失消息。代码将需要照顾这些情况。消息代理（例如RabbitMQ）可以处理消息并保存它们，而不管数据库或系统是否已启动并正在运行，从而减少了消息丢失。

另一方面，消息代理似乎也有些过分，因为它只是将消息传递给一个或多个部门，然后消失在一个人的历史中。那么，为什么要将所有这些基础结构都包含在内呢？

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

谢谢！

Answer 1

我真的不了解该系统的体系结构。您是否仅由于拥有“消息”的域对象而使用消息队列？这些消息是否确实需要“传递”？它们是否是将要接收这些消息的异构系统？还是需要进行一些离线处理？

您希望拥有一个简单的“邮件”数据库表，其中包含状态，部门和内容，除非您对这些邮件做任何事情，否则将过多地使用基础结构。