ninject - 为从 ASP.NET MVC 和工作应用程序使用 RabbitMQ 设计一个好的界面

Question

考虑在 AppHarbor 构建一个在 MVC4 上运行的 Web 应用程序。为了响应速度和性能，运行时间稍长的任务(通常，生成/发送电子邮件、调整图像大小、支付交易处理等)将通过将消息放在消息队列中来处理。

还会有一个或多个工作人员，在某个地方，将消息出列并处理因此需要处理的任何内容。中央排队机制将是 RabbitMQ，特别是通过 AppHarbor 提供的托管 CloudAMQP 服务。理论上，这种架构可以通过添加更多的工作人员来实现“无限”的可扩展性。

现在，为了良好的架构、可测试性等，我想将 RabbitMQ 放在一个或多个易于模拟的接口(interface)后面。在定义这些接口(interface)时，我需要考虑一些注意事项。

在我获得任何付费用户之前，我只能使用免费的 CloudAMQP 产品。这意味着最多三个同时连接。

鉴于先前的限制，我想尝试将自己限制为每个应用程序一个连接。一个用于 MVC 应用程序，每个工作人员一个。就是这样。

RabbitMQ 中的连接被设计为长期存在。尽管如此，许多示例显示的代码显式打开连接(然后是 channel )，发送消息，然后再次关闭它。

对于多线程，可以使用相同的连接，但不能使用相同的 channel 。据我了解，可以在多线程应用程序中共享一个连接，然后打开多个 channel ，例如每个线程一个。

我的 MVC 应用程序通常只是一个发布者。工作人员应用程序既是消费者又是发布者——例如，工作人员可以接收处理付款的消息，这将导致它发布消息以向用户调用指示成功或失败的电子邮件消息。

对于 MVC 应用程序，连接通常只使用很短的时间 - 用于排队消息。

对于工作人员，我正在考虑长期运行的连接，或多或少在工作人员的一生中永久开放。

好的，太好了，所以有很多东西。在这个项目之前没有任何使用 RabbitMQ 的经验，我被一些额外的要点所困扰。

接口(interface)隔离原则。我应该将它分成两个单独的接口(interface) - 比如 IQueueServiceConsumer 和 IQueueServiceProducer - 或者这是否太过分了？我发现我总是可以使用 SRP 等将事物进一步划分为更多的原子单元，并且我不希望 Bob 叔叔追捕我(不仅仅是接口(interface)名称中的 I)，但我想知道我必须走多远拿着这个。

鉴于我只有一个网络服务器，至少一开始是这样，实际上与网络应用程序中的队列建立长期连接是否是一个想法？打开和关闭它们在理论上有可能同时发生多个事件，这意味着冲突和潜在信息丢失。丢失的消息是 Not Acceptable 。

在这种情况下，我将如何处理连接的生命周期？在我的 Ninject 模块中打开它(我的接口(interface)实际上绑定(bind)到 RabbitMQ 特定的实现)，并在应用程序......回收时以某种方式断开它？我怎么能做那样的事情？

对于 worker 来说，生活似乎更轻松。在接口(interface)上放置一个方法来打开连接，然后为线程提供 channel 以获取消息。通过适当调用 CloseConnection 确保应用程序运行良好。或者实现 IDisposable。

有可能 - 无论多么小 - RabbitMQ 将来可能会被其他东西取代，因此我不希望我的接口(interface)过于特定于该特定服务总线(从某种意义上说，这就是我使用它的方式)执行。

在构建类似的应用程序时，是否有其他人已经解决了相同的挑战？您对消息队列接口(interface)的架构和实际实现有什么建议吗？我只是对此感到神经质，还​​是我的担忧值得承认？

如果重要的话，我当前的消息传递需求由单向消息覆盖，除了在处理完成后确认收到的消息外，不需要任何响应。

感谢您的任何见解!

Answer 1

Masstransit会为你做这一切。要么使用MT，要么看看他们有什么done