Failover scenarious per il Service Bus con NServiceBus o MassTransit

Question

Ho bisogno di costruire server di identità come quella di Microsoft http://login.live.com .

Per gestire il failover avrò più web nodi server. Il piano è che tutte le operazioni di scrittura del database sono fatte con l'invio di messaggi al server di database. Database verrà mirroring o replicato. L'idea è che sottoscrive di database per le operazioni di scrittura, ma che altri nodi abbonarsi anche. In questo modo le altri nodi non hanno bisogno di leggere dal database e in grado di aggiornare le loro cache.

sto appena cominciando a imparare l'architettura di bus di servizio e ciò che non mi è chiaro è come gestire scenario di failover per il servizio di autobus.

Domanda:

1. Se il server di database non è disponibile, cosa succederà con i messaggi pubblicati?
2. Saranno in grado di essere memorizzati da qualche parte e dove?
3. Ho bisogno di macchina supplementare o un cluster di failover maniglia del bus di servizio?
4. Ho letto che SQL Server può essere utilizzato come un archivio di messaggi, ma può utilizzare MSMQ durevole? Sto in coda i messaggi per essere in grado di scrivere loro di database in modo perché dovrei memorizzarli al DB prima solo per prendere loro e scrivere di nuovo? O, sto ottenendo questo torto e DB viene utilizzato solo per la lista degli abbonamenti e non per i messaggi?

Answer 1

1. Questo dipenderà da come è configurato, ma in MassTransit si può lasciare l'abbonamento attivo in modo che il messaggio viene comunque consegnato alla coda per il DB. Quando il DB è di nuovo attiva, è possibile leggere i messaggi nella coda.

2. Ogni servizio connesso ad un bus di servizio, in MassTransit, ha una coda attiva per sé. I messaggi saranno memorizzati lì.

3. Credo che questo sia un "dipende" ... MassTransit ha il supporto per altri MQ di MSMQ, ma è in realtà costruito intorno MSMQ. Noi non abbiamo vissuto un grande sostegno per cose come failover da MSMQ. Tuttavia, tutto continuerà a funzionare senza colpa se il servizio di abbonamento (cioè il bus) non riesce - i servizi già sanno con chi parlare. E 'solo quando un cambiamento di un consumatore (iscriverti o cancellarti) in cui questo diventa un problema. Per me, questo è un evento che accade quasi mai.

4. Con MassTransit, usiamo il DB per memorizzare gli stati di sottoscrizione, ma tutti i messaggi sono memorizzati in MSMQ.

Se desideri maggiori dettagli in una di queste risposte o hanno altre domande su MT, è possibile unirsi a noi sulla mailing list: http://groups.google.com/group/masstransit-discuss .

Answer 2

Averla attuazione di questo tipo di architettura, si dovrebbe guardare ad applicare i principi del CQRS - query (è questo utente / pwd combo valido) non dovrebbe essere fatto tramite il bus; comandi (cambiamento PWD, dimenticata PWD) sono inviati tramite il bus, non pubblicata come eventi. Mentre internamente è probabile che utilizzare gli eventi per mantenere i lati di comando e di query in sincronia, ciò non comporta il cliente.

Le query può essere fatto utilizzando semplici ado.net contro gli schiavi-read-replicate del vostro DB - ciò che è noto come la vista persistente modello CQRS. Se ti piace, si può mettere qualche semplice WCF di fronte anche a questo.

Quando si utilizza MSMQ, tutti i messaggi vengono recapitati tramite store-and-forward. Ciò significa che stanno prima memorizzati sul client prima di essere consegnato al server, quindi se il server è inattivo, i messaggi si siedono sul attesa del cliente. Per tolleranza d'errore, si desidera che i messaggi siano recuperabili (scritti su disco) - questo è il default in NServiceBus ma non il valore predefinito di standard di MSMQ (non conoscono MassTransit). Non è necessario il database per questo.

Nel NServiceBus, il bus non è installato su una macchina separata in modo che non c'è bisogno di fare con la sua disponibilità indipendentemente dal resto del sistema. E 'solo quando si guarda a scalare il nostro vostra elaborazione del comando a più nodi che si potrebbe considerare l'uso del bilanciamento del carico basato su messaggi in NServiceBus (chiamato il distributore), che, per l'alta disponibilità, dovrebbe essere installato su un hardware cluster o fault-tolerant.