在AppHarbor上构建一个在MVC4上运行的Web应用程序。为了响应性和性能，可以通过在消息队列上放置消息来处理稍长的运行任务（通常是生成/发送电子邮件，调整图像大小，支付事务处理等）。
在那里的某个地方也会有一个或多个工人，将消息出列并处理因此需要处理的任何内容。中央排队机制是RabbitMQ，特别是通过AppHarbor提供的托管CloudAMQP服务。从理论上讲，这种架构可以通过增加更多的工作人员来实现“无限”的可扩展性。
现在，为了良好的架构，可测试性等，我想将RabbitMQ置于一个或多个易于模拟的接口之后。在定义这些接口时，我需要考虑一些注意事项。
- 在我获得任何付费用户之前，我仅限于免费的CloudAMQP产品。这意味着最多可同时连接三个。
- 鉴于先前的约束，我想尝试将自己限制为每个应用程序一个连接。一个用于MVC应用程序，每个工作一个。就是这样。
- RabbitMQ中的连接旨在长期生活。尽管如此，许多示例仍然显示了明确打开连接（然后是通道），发送消息，然后再次关闭它的代码。
- 对于多线程，可以使用相同的连接，但不能使用相同的通道。据我所知，可以在多线程应用程序中共享连接，然后打开几个通道，例如每个线程一个。
- 我的MVC应用程序通常只是一个发布者。工作者应用程序既可以是消费者也可以是发布者 - 例如，工作人员可以接收处理付款的消息，这将导致其发布消息以向用户调用指示成功或失败的电子邮件消息。
- 对于MVC应用程序，连接通常仅在非常短的时间内使用 - 用于排队消息。
- 对于工人来说，我正在考虑长期连接，或多或少永久性地打开工人的一生。
好的，太好了，所以这很多东西。在这个项目之前没有任何RabbitMQ的经验，我被一些额外的要点所困扰。
- 界面隔离原则。我应该把它分成两个独立的接口 - 比如IQueueServiceConsumer和IQueueServiceProducer - 还是把它拿得太远了？我发现我总是可以使用SRP等将事物进一步划分为更多的原子单位，而且我不希望鲍勃叔叔狩猎我（因为接口名称中的比我更多），但我想知道我有多远拿这个。
- 鉴于我只有一个网络服务器，至少在开始时，是否真的想要在网络应用程序中实现与队列的长期连接？打开和关闭它们给出了几次同时发生的理论机会，这意味着冲突和潜在的信息丢失了。丢失的邮件是不可接受的。
- 在这种情况下，我如何处理连接的生命周期？在我的Ninject模块中打开它（我的界面实际上绑定到RabbitMQ特定的实现），并在应用程序被回收时以某种方式断开它？我怎么能这样做？
- 对于工人来说，生活似乎更容易。在接口上放置一个方法来打开连接，然后将通道提供给线程以获取消息。通过适当调用CloseConnection确保应用程序运行良好。或实施IDisposable。
- 有可能 - 无论多么小 - RabbitMQ可能在将来被其他东西取代，因此我不希望我的接口过于特定于特定的服务总线（从某种意义上说，这就是我的方式）使用它）实施。
在构建类似的应用程序时，是否有其他人已经完成了同样的挑战？您对消息队列的接口的体系结构和实际实现有什么建议吗？我只是对此感到神经质，还是我的担忧值得肯定？
如果重要，我的当前消息传递需求由单向消息覆盖，除了在处理完成后确认收到的消息之外，不需要任何响应。
感谢您的任何见解！