Estamos comenzando un nuevo proyecto que tiene algunos requisitos de mensajes y colas que son bastante básicos, pero en el futuro puede haber algunos requisitos adicionales para cosas como sagas para procesar mensajes que pueden llegar fuera de servicio y deben volver a secuenciarse. @

Recientemente lanzamos un proyecto que está completamente alojado en Amazon EC2, que también tiene un sistema de mensajería simple. Tenemos un pequeño mecanismo pub / sub muy simple por el cual recibimos un mensaje y luego determinamos qué controlador usar para el mensaje en función de su tipo. En nuestro nuevo proyecto también tenemos un mecanismo similar y podemos tener algunos requisitos un poco más sofisticados, pero incluso si pudiéramos eliminar nuestro propio código para resolver los manejadores de mensajes, esto también sería genial.

Estamos muy interesados en usar NServiceBus ya que el modelo pub / sub es realmente agradable, pero hasta ahora hemos estado utilizando Amazon SQS como proveedor de colas. Cada una de nuestras máquinas EC2 tiene un trabajador que escucha la misma cola SQS y extrae mensajes para procesarlos. Obviamente, SQS no es compatible como una capa de transporte (y sé que es porque NServiceBus está construido alrededor de una cola confiable y de baja latencia) en NServiceBus.

Sé que NServiceBus tiene un distribuidor, y podría imaginar alojarlo en su propia instancia EC2, pero el problema con eso es que hay un gran punto de falla allí, por lo que básicamente estamos jodidos si eso se cae. Por lo que deduzco, las personas configuran clústeres de conmutación por error de Windows para tratar este problema en las redes internas, pero no sé si esto es aplicable a EC2.

Est fue una de las pocas publicaciones de blog que pude encontrar por alguien que realmente había intentado usar NServiceBus en el contexto basado en la nube, y no parece recomendarlo. Me pregunto si alguien más aquí lo ha intentado y, de ser así, ¿tendrían algún consejo que ofrecer? Parece una pena que no podamos utilizar un marco tan bueno solo porque estamos alojados en la nube.

Parece que hay algunaProgres hecho con Azure Queues, que es algo que podríamos considerar, pero por ahora nos gustaría mantener la infraestructura con Amazon ya que tenemos mucha automatización de compilación que podemos reutilizar que se basa en eso.