考虑在 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)的架构和实际实现有什么建议吗?我只是对此感到神经质,还是我的担忧值得承认?
如果重要的话,我当前的消息传递需求由单向消息覆盖,除了在处理完成后确认收到的消息外,不需要任何响应。
感谢您的任何见解!