Conmutación por error scenarious para el servicio de autobuses con NServiceBus o MassTransit

Question

Tengo que construir servidor de identidad como el de Microsoft http://login.live.com .

Para hacer frente a la recuperación de fallos tendrá múltiples servidores web nodos. El plan es que todas las operaciones de la base de datos de escritura se realizan mediante el envío de mensajes al servidor de base de datos. Base de datos se refleja o replica. La idea es que se suscribe a las bases de datos las operaciones de escritura pero que otros nodos también suscribirse. De esa manera los otros nodos no necesitan leer desde la base de datos y puede actualizar sus cachés.

Apenas estoy comenzando a aprender la arquitectura de bus de servicios y lo que no me queda claro es cómo manejar escenarios de conmutación por error para el bus de servicio.

Pregunta:

1. Si el servidor de base de datos no está disponible, lo que va a ocurrir con los mensajes publicados?
2. ¿Serán almacenado en algún lugar y dónde?
3. ¿Necesito máquina adicional o un clúster para la conmutación por error mango del bus de servicio?
4. leí que SQL Server puede ser utilizado como un almacén de mensajes, pero puedo utilizar MSMQ duradero? Estoy de Message Queue Server para poder escribirlos en la base de datos por lo que ¿por qué iba a almacenar en el DB primera sólo para tomar y escribirlos de nuevo? O, estoy consiguiendo este mal y DB sólo se utiliza para la lista de suscripciones y no para los mensajes?

Answer 1

1. Esto dependerá de la forma en que está configurado, pero en MassTransit que puede salir de la suscripción activa para que el mensaje todavía será entregado a la cola para el DB. Cuando el PP vuelve a estar activo, puede leer los mensajes de la cola.

2. Cada servicio conectado a un bus de servicio, en MassTransit, tiene una cola activa por sí misma. Los mensajes se almacenan allí.

3. Creo que este es un "depende" ... MassTransit tiene soporte para otros MQS que MSMQ pero es realmente construido alrededor de MSMQ. Nosotros no hemos experimentado un gran apoyo para cosas tales como la conmutación por error de MSMQ. Sin embargo, todo seguirá funcionando sin fallo si el servicio de suscripción (es decir, el bus) no - los servicios que ya saben con quién hablar. Es sólo cuando un cambio en el consumidor (suscribirse o darse), donde esto se convierte en un problema. Para mí, eso es un evento que ocurre casi nunca.

4. Con MassTransit, utilizamos la base de datos para almacenar los estados de suscripción, pero todos los mensajes se almacenan en MSMQ.

Si desea obtener más detalles en una de estas respuestas o si tiene preguntas adicionales sobre MT, puede unirse a nosotros en la lista de correo: http://groups.google.com/group/masstransit-discuss .

Answer 2

Si desea pedir la aplicación de este tipo de arquitectura, usted debe buscar en la aplicación de los principios de CQRS - consultas (es este usuario / pwd combinado válida) no se debe hacer a través del bus; comandos (PWD cambio, se olvidó PWD) se envían a través del bus, no publicada como eventos. Mientras que internamente es probable que utilice eventos para mantener a los lados de mando y de consulta en sincronía, esto no implica el cliente.

Las consultas se pueden hacer usando ado.net simple en contra de los esclavos-leer replicados de su base de datos - lo que se conoce como el modelo de vista persistente en CQRS. Si se quiere, se puede poner un poco de WCF sencilla frente a eso también.

Cuando se utiliza MSMQ, todos los mensajes se entregan a través de store-and-forward. Eso significa que ellos están almacenados primero en el cliente antes de ser entregado al servidor, por lo que si el servidor no funciona, los mensajes se sientan en la sala de espera del cliente. Para tolerancia a fallos, se quiere que los mensajes sean recuperables (escrito en el disco) - este es el defecto en NServiceBus pero no el valor por defecto de la norma MSMQ (no sé acerca MassTransit). No necesita la base de datos para esto.

En NServiceBus, el bus no está instalado en una máquina separada de modo que no es necesario para hacer frente a su disponibilidad de forma independiente del resto del sistema. Es sólo cuando nos fijamos en la ampliación de nuestro el procesamiento de comandos a más nodos que es posible considerar el uso del equilibrador basado en mensajes de carga en NServiceBus (llamado el distribuidor) que, para una alta disponibilidad, debe ser instalado en un hardware de clúster o tolerante a fallos.