2011-09-13 10 views
13

Estamos comenzando un nuevo proyecto que tiene algunos requisitos de mensajería y puesta en cola que son bastante básicos, pero en el futuro puede haber algunos requisitos adicionales para que cosas como sagas procesen mensajes que podrían llegar fuera de servicio y necesita ser resecuenciado.Uso de NServiceBus en una aplicación alojada de Amazon EC2

Acabamos de lanzar un proyecto alojado por completo en Amazon EC2 que también tiene un sistema de mensajería simple. Tenemos un pequeño mecanismo de pub/sub muy simple por el cual recibimos un mensaje y luego descubrimos qué controlador usar para el mensaje en función de su tipo. En nuestro nuevo proyecto, también tenemos un mecanismo similar y puede que tenga 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 realmente interesados ​​en usar NServiceBus ya que el modelo de pub/sub es muy bueno, pero hasta ahora hemos estado utilizando Amazon SQS como el proveedor de colas. Cada una de nuestras máquinas EC2 tiene un trabajador que está escuchando la misma cola SQS y sacando mensajes de eso para procesarlas. Obviamente, SQS no es compatible como una capa de transporte (y sé que es porque NServiceBus se basa en una cola confiable y de baja latencia) en NServiceBus.

Sé que NServiceBus tiene un distribuidor, y me podría imaginar alojar eso en su propia instancia EC2, pero el problema es que hay un gran punto único de falla allí, así que básicamente estamos jodidos si eso sucede abajo. Por lo que sé, la gente configura clústeres de conmutación por error de Windows para tratar este problema para redes internas, pero no sé si esto es aplicable a EC2.

This fue una de las únicas publicaciones de blog que pude encontrar por alguien que realmente intentó utilizar NServiceBus en el contexto basado en la nube, y no parece recomendarlo. Me pregunto si alguien más aquí lo intentó y si es así, ¿tienen 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 se está haciendo algo de progress 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 eso está basado en eso.

Respuesta

5

Según la experiencia de hacer cola en Amazon EC2, hemos encontrado que SQS es muy lento para la mensajería de alto rendimiento.

Actualmente, no utilizamos NServiceBus como interfaz de cola, pero pensé que mencionaría que estamos utilizando correctamente RabbitMQ en instancias de Ubuntu en EC2 como nuestro proveedor de colas.

De acuerdo con this post Udi Dahan suggests que las personas han cambiado MSMQ por RabbitMQ con NServiceBus, podría ser una investigación que vale la pena usar RabbitMQ en EC2.

Hay un great guide on RabbitMQ's website que describe una manera fácil de instalar RabbitMQ en Amazon EC2 mediante el lanzamiento de una imagen compatible de Ubuntu.

Recomiendo mucho instalar el RabbitMQ Management Plugin que también le ofrece una interfaz sencilla de administración web en las colas.