Buscando construir una aplicación web que se ejecute en MVC4 en AppHarbor. En interés de la capacidad de respuesta y el rendimiento, las tareas de ejecución ligeramente más largas (por lo general, generación/envío de correos electrónicos, cambio de tamaño de imágenes, procesamiento de transacciones de pago, etc.) se manejarían colocando un mensaje en una cola de mensajes.Diseñando una buena interfaz para usar RabbitMQ desde ASP.NET MVC y aplicaciones de trabajador
También habría uno o más trabajadores, en algún lugar, eliminando mensajes y procesando todo lo que deba procesarse como resultado. El mecanismo de cola central sería RabbitMQ, específicamente el servicio Hosted CloudAMQP disponible a través de AppHarbor. En teoría, esta arquitectura permitiría una escalabilidad "infinita" al agregar más trabajadores.
Ahora, en aras de una buena arquitectura, capacidad de prueba, etc., quiero poner RabbitMQ detrás de una o más interfaces que pueden ser fácilmente burladas. Tengo algunas consideraciones a tener en cuenta al definir estas interfaces.
- Hasta que reciba ningún usuario de pago, estoy limitado a la oferta gratuita de CloudAMQP. Eso significa un máximo de tres conexiones simultáneas.
- Dada la restricción anterior, quiero intentar limitarme a una conexión por aplicación. Uno para la aplicación MVC, uno por trabajador. Eso es.
- Las conexiones en RabbitMQ están diseñadas para vivir durante mucho tiempo. Aún así, muchos ejemplos muestran código que explícitamente abre una conexión (luego un canal), envía un mensaje y luego lo cierra de nuevo.
- Para multihilo, se puede usar la misma conexión, pero no el mismo canal. Por lo que yo entiendo, está bien compartir una conexión en una aplicación multiproceso, luego abrir varios canales, por ejemplo uno por hilo.
- Mi aplicación MVC normalmente solo sería un editor. La aplicación para trabajadores sería tanto un consumidor como un editor; por ejemplo, el trabajador podría recibir un mensaje para procesar un pago, lo que resultaría en que publicara un mensaje para invocar un mensaje de correo electrónico al usuario indicando éxito o falla.
- Para la aplicación MVC, las conexiones se usarían normalmente solo durante un tiempo muy breve: para poner en cola un mensaje.
- Para los trabajadores, estoy pensando en conexiones de larga duración, más o menos permanentemente abiertas durante la vida del trabajador.
Ok, genial, entonces eso es un montón de cosas. Al no tener ninguna experiencia con RabbitMQ antes de este proyecto, me atormentan algunos puntos adicionales.
- Principio de segregación de la interfaz. ¿Debería dividir esto en dos interfaces separadas, como IQueueServiceConsumer y IQueueServiceProducer, o eso es llevar las cosas demasiado lejos? Encuentro que siempre puedo usar SRP, etc. para dividir más las cosas en más unidades atómicas, y no quiero que el tío Bob me busque (más que el I en los nombres de la interfaz), pero me pregunto qué tan lejos tengo de toma esto.
- Dado que solo tendré un único servidor web, al menos al principio, ¿sería una idea tener una conexión duradera con la cola en la aplicación web también? Abrirlos y cerrarlos da la posibilidad teórica de que ocurran varios al mismo tiempo, lo que significa que se pierden conflictos y posibles mensajes. Los mensajes perdidos no son aceptables.
- ¿Cómo manejaría la vida útil de la conexión en este caso? Ábrelo dentro de mi módulo Ninject (donde mi interfaz está realmente vinculada a la implementación específica de RabbitMQ), y desconéctalo de alguna manera cuando la aplicación se ... ¿se recicla? ¿Cómo podría hacer algo así?
- Para los trabajadores, la vida parece más fácil.Ponga un método en la interfaz para abrir la conexión, luego sirva canales a hilos para obtener mensajes. Asegúrate de que la aplicación funciona bien llamando a CloseConnection según corresponda. O implemente IDisposable.
- Existe la posibilidad, aunque pequeña, de que RabbitMQ pueda ser reemplazado por otra cosa en el futuro, por lo que no quiero que mis interfaces sean demasiado específicas para ese bus de servicio en particular (en el sentido de que así es como soy) usándolo) implementación.
¿Alguien más ya ha superado los mismos desafíos al crear una aplicación similar? ¿Tiene algún consejo para la arquitectura y la implementación en la vida real de una interfaz para la cola de mensajes? ¿Estoy siendo neurótico al respecto o mis preocupaciones merecen ser reconocidas?
Si es importante, mis mensajes actuales están cubiertos por mensajes unidireccionales, sin necesidad de ninguna respuesta además de confirmar los mensajes recibidos una vez que se haya completado el procesamiento.
¡Gracias por cualquier idea!
¡Interesante, echaremos un vistazo a esto, gracias! –